Audit dependency risk

Objective

Take an immutable set of dependency declarations, the lockfile graph they resolve to, and a dated advisory snapshot, then turn them into three artifacts: a reproducible inventory, an evidence-ranked finding register, and a dependency action plan. The quality constraint that matters most is keeping three statements apart: affected-version presence, vulnerable-API reachability, and demonstrated exploitability. Never collapse them into a single claim.

When to use

• You need a supply-chain risk snapshot before a release.
• Runtime dependencies need an assessment covering removal, upgrade, license, provenance, or maintenance.
• A repository needs a time-bounded decision about a specific advisory or an unused direct dependency.

When not to use

• The manifest and its matching lockfile are unavailable.
• Resolving the dependency graph would require executing untrusted install scripts.
• The request calls for a legal conclusion rather than an engineering risk assessment.
• The advisory source, snapshot time, affected range, or vulnerable condition cannot be retained.

Required inputs

• Immutable revision, dependency manifests, and dependency-group policy: Supply the commit or archive digest, the complete manifest excerpts, the workspace boundaries, and the rule that tells runtime, development, optional, peer, and build dependencies apart. Together these define what the project declares and where the audit stops. Resolve the revision, then confirm that the manifest excerpts and the policy belong to it.
• Matching lockfiles with complete resolved graph, versions, and integrity records: Supply every importer entry, package node, graph edge, resolved version, and integrity field for the audited scope. This is the evidence of what actually gets installed or packaged, as opposed to what the manifest merely requests. Confirm that frozen resolution succeeds without manifest drift, or parse a trusted existing lockfile instead, and never execute package lifecycle scripts either way.
• Dated advisory records with affected ranges, conditions, and source identity: Supply the snapshot timestamp, advisory identifier, ecosystem, affected range, vulnerable API or configuration, fixed boundary when one is known, and the retained source identity. This record makes the result reproducible, and it keeps a bare package-name match from quietly becoming an exploitability claim. Validate the advisory syntax and keep the exact snapshot; refreshing it during analysis would silently change your evidence.

Optional inputs

• Runtime import, call-site, and packaged-artifact inventory: Improves reachability analysis by identifying static imports, dynamic loaders, plugins, generated code, and bundled packages.
• Software bill of materials: Lets you compare what the lockfile resolved against what the produced artifact actually contains.
• License policy and provenance records: Let you classify approved licenses, registries, signatures, and maintainership as an engineering matter, without replacing legal review.

Preconditions

• The manifest and lockfile belong to the same immutable revision.
• Production and development dependencies can be told apart.
• The advisory snapshot carries an explicit timestamp and a retained source identity.
• Registry credentials and private registry addresses can stay redacted throughout.
• Lockfile inspection, and any experimental resolution, can run with lifecycle scripts disabled and inside a disposable directory.

Workflow

1. Freeze the audit boundary. Record the immutable revision, the workspace and ecosystem scope, the manifest and lockfile paths, the dependency-group policy, the advisory snapshot time, and any exclusions. Hash or otherwise identify each artifact you were given. Advance only when every manifest maps to a lockfile importer from the same revision; if any pair disagrees, stop under F1.
2. Build the resolved dependency inventory. Parse the direct declarations and walk the lockfile graph, without running lifecycle scripts. For each package, record direct or transitive status, dependency group, exact version, parent path, integrity presence, registry class, and any platform conditions. Reconcile duplicate versions and peer resolutions before moving on.
3. Reconcile packaged and runtime scope. When the optional inventories are supplied, compare the lock graph against the SBOM, the bundle, runtime imports, dynamic loading, generated code, plugins, and build scripts. A package absent from the packaged artifact is not the same as a package that static source merely never references, so mark the two cases separately. Do not claim absence while runtime mechanisms remain uncovered.
4. Match advisory records. Check each resolved version against the exact affected range and ecosystem in the retained snapshot. Record advisory presence, the vulnerable API or configuration, the fixed boundary, and any fields the record leaves out. A name or version match creates an affected-version observation, nothing more; it is not proof of reachability.
5. Assess reachability and exposure. Search the supplied imports and call sites for the vulnerable API, then inspect the configuration and data sources the advisory condition depends on. Keep three kinds of evidence apart: what static analysis showed, which runtime mechanisms went uninspected, and any safe runtime result that was supplied. Assign reachability as demonstrated, not observed, unknown, or not applicable, with a rationale for your confidence.
6. Assess non-advisory dependency risk. Apply the supplied policies to unused direct dependencies, unsupported runtimes, provenance, integrity, maintenance, and licenses. Do not issue a legal conclusion, and do not treat missing optional provenance as malicious behavior.
7. Select an action with evidence. For each finding, weigh removal, an exact-version upgrade, a constraint change, monitoring, and temporary acceptance against each other. Spell out the consumer impact, the owner role, the required approvals, exact copyable mutation and validation commands, the exit criteria, and the rollback path to the retained manifest and lockfile. Treat every command as proposed until its retained result identifies the isolated revision and the exit status. Never name an upgrade target unless the supplied advisory or a trusted package record supports it.
8. Produce and approve the audit artifact. Deliver the scope, the complete inventory, the finding register, the actions, executed and proposed checks, assumptions, limitations, and traceability. Obtain repository-maintainer approval before removing public runtime capability, and security-owner approval before temporarily accepting a vulnerable dependency.

Decision points

• If the manifest and lockfile disagree, stop and regenerate or obtain the matching immutable pair.
• If an advisory affects a resolved version but no runtime path is shown, report affected presence and mark reachability as unknown.
• If static search finds no use of the vulnerable API while dynamic loading, plugins, generated code, or reflection remain uninspected, classify reachability as unknown rather than unreachable.
• If the advisory lacks a supported fixed boundary, do not guess an upgrade target; request authoritative version evidence or choose a separately justified mitigation.
• If a removal changes public runtime capability, require repository maintainer approval before implementation.
• If a reachable vulnerability cannot be remediated before release, require security-owner acceptance with controls, an owner, an expiry, and revalidation evidence.
• If the only way to resolve metadata is running an unknown lifecycle script, stop dynamic resolution and rely on static evidence with the gap documented.
• If private metadata is inaccessible, stop findings and actions for that package subtree; continue unrelated graph analysis only when the lockfile proves the subtree boundary, and stop the requested release decision when the inaccessible subtree can change that decision.

Safety guardrails

• Never run install or lifecycle scripts from unknown packages during the audit.
• Never print registry tokens, and never copy private registry URLs into public output.
• Do not claim exploitability without reachability evidence.
• Do not install, publish, remove, or upgrade dependencies in the audited working tree during a read-only audit.
• Perform experimental resolution only in a disposable directory, with scripts disabled and no production credentials present.
• Do not contact unapproved private registries, and do not include private package contents in a public artifact.
• Preserve the original manifest and lockfile as rollback evidence for any proposed change.

Human approval gates

• Before removing a public runtime capability, the repository maintainer approves the static and packaged usage evidence, the consumer impact, the validation plan, and the manifest-and-lockfile rollback.
• Before temporarily accepting a vulnerable dependency, the security owner approves the affected-version and reachability evidence, the severity, the compensating controls, the accountable owner, the expiry, and the revalidation date.

Expected output

• Reproducible dependency inventory and audit scope: The immutable revision, snapshot time, and artifact identities, plus every in-scope direct and transitive resolution with its dependency group, integrity status, and coverage exclusions.
• Risk-ranked dependency finding register with reachability dispositions: One row per finding, carrying the finding, evidence, impact, severity, confidence, recommendation, verification, disposition, advisory status, and reachability.
• Removal, upgrade, monitoring, or acceptance plan: The exact target when evidence supports one, the owner role, dependencies, commands to run, objective exit criteria, rollback, approvals, assumptions, and limitations.

The artifact must keep observations, inferences, recommendations, executed checks, proposed checks, assumptions, limitations, and next actions clearly apart. Material claims must cite example evidence IDs.

Completion criteria

• The inventory is tied to an immutable revision and a timestamp.
• Every in-scope direct and transitive resolution carries an exact version and an integrity disposition.
• Every advisory finding identifies its affected resolved version, source snapshot, range, and vulnerable condition.
• Reachability is either evidenced or explicitly unknown, and exploitability is never claimed without validation.
• Every action has an owner, a supported target or an explicit target blocker, validation, rollback, and its required approval gate.
• Executed package operations are clearly distinguished from proposed isolated changes.

Failure modes

• F1: The lockfile does not match the manifest.
• F2: An advisory record lacks the affected range, vulnerable condition, or fixed-version evidence that the requested decision needs.
• F3: Private package metadata cannot be reached without exposing credentials or contacting an unapproved registry.
• F4: Safe resolution would require running unknown lifecycle scripts.

Recovery procedure

• R1: Obtain the matching immutable manifest-lockfile pair, or generate one in an approved disposable environment with scripts disabled, then retain the new artifact identities and restart at workflow step 1.
• R2: Request a complete retained advisory record, keep target selection and affected-status conclusions blocked in the meantime, and resume at workflow step 4 only after the record is validated.
• R3: Stop advisory, provenance, license, and action conclusions for the inaccessible private package and its affected subtree, retain only redacted metadata, and escalate through the package owner without contacting the registry. Continue analyzing unrelated nodes only when the supplied lockfile establishes a complete subtree boundary; otherwise stop any audit conclusion that depends on graph completeness. Resume at workflow step 2 once the package owner supplies an approved immutable metadata record with provenance, or at step 4 when only a complete retained advisory record was missing, and re-run every downstream inventory and finding that included the subtree.
• R4: Stop dynamic resolution, fall back to static manifest and lockfile analysis, record lifecycle-dependent coverage as unknown, and resume at workflow step 2 without claiming a complete runtime inventory.

Example

The complete synthetic example lives in #complete-example-input, and its complete artifact is in #complete-expected-output. It demonstrates evidence traceability without relying on external sources.

Output contract

The expected artifact is validated by the recipe-specific contract below.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://agentic-workflows.dev/output-contracts/dependency-audit/1.0.0",
  "title": "Dependency audit output contract",
  "description": "Validates the resolved inventory, evidence-ranked findings, bounded action plan, proposed commands, approvals, limitations, and traceability in the reference Markdown output.",
  "type": "string",
  "contentMediaType": "text/markdown",
  "x-awf-output-contract": {
    "container": "document",
    "artifacts": [
      {
        "path": "dependency-audit.md",
        "audience": "Repository maintainers and security owners",
        "requires_title": true,
        "required_headings": [
          "Scope",
          "Inventory",
          "Findings",
          "Action plan",
          "Proposed command sequence",
          "Approval and decision record",
          "Limitations",
          "Traceability"
        ],
        "required_literals": [
          "| Package | Relationship | Resolved version | Integrity | Runtime and package status | Advisory status | Evidence |",
          "| Severity | Confidence | Reachability | Finding | Evidence | Impact | Recommendation | Verification | Disposition |",
          "| Order | Proposed action | Owner | Dependency and approval | Exit evidence | Recovery |",
          "| Material conclusion | Evidence |"
        ],
        "evidence_references": "required",
        "minimum_distinct_evidence_references": 2
      }
    ]
  }
}

Complete example input

This is a synthetic, self-contained scenario. No external record should be consulted.

Context

Synthetic Node.js service at immutable revision d300000000000000000000000000000000000000. The audit is limited to the complete three-package runtime graph supplied below.

Request

Audit runtime dependencies and recommend evidence-supported actions.

Constraints

• Use only the evidence below.
• Treat commands as executed only when their evidence explicitly records a result.
• State assumptions and limitations.
• Do not contact a registry, run lifecycle scripts, or modify the supplied manifest and lockfile.

Evidence inventory

E1 - Immutable manifest and scope policy

• Type: Manifest excerpt and repository policy.
• Content: Revision d300000000000000000000000000000000000000 contains this complete dependency declaration:

{
  "dependencies": {
    "kleur": "4.1.5",
    "left-pad": "1.3.0",
    "lodash": "4.17.20"
  },
  "devDependencies": {}
}

• Content: The repository classifies entries under dependencies as direct runtime dependencies and contains no workspaces, optional dependencies, peer dependencies, or build-time dependency group.
• Integrity: The excerpt is from immutable revision d300000000000000000000000000000000000000.
• Establishes: Complete direct declarations and dependency-group classification.

E2 - Matching lockfile graph

• Type: Lockfile parser record.
• Content: The complete synthetic resolution excerpt is:

importers:
  .:
    dependencies:
      kleur: { specifier: 4.1.5, version: 4.1.5 }
      left-pad: { specifier: 1.3.0, version: 1.3.0 }
      lodash: { specifier: 4.17.20, version: 4.17.20 }
packages:
  kleur@4.1.5:
    resolution:
      integrity: sha512-d6WARGQ/CT335eCASLGn3xhwGwW5j0jilIeEuU2brOdBxWJi+HYsy5zjN66YA5AaCRmIOBN6QkPo/Rzlij4kDg==
  left-pad@1.3.0:
    resolution:
      integrity: sha512-9EwzZSPvj3frCmYXxxCGcx6xaxCj0LkuFUbVw8pSzOzd/qoru+5byLFcik38Wdm3A5XI8Bxj6wrpiw5Lj9eCZQ==
  lodash@4.17.20:
    resolution:
      integrity: sha512-20rm38VK80iYfygSgfmU/VXFfoqB3fRhO4AxKTXFHL9SUFa8+Vmw3P7uXOoCb1eHnYBAA5bb6HPdO7ax1XmXgQ==

• Content: The complete graph has those three package nodes, no transitive edges, and one distinct version of each package.
• Content: Each node is reached directly from root importer ., resolves from the approved public npm registry class, and has no operating-system, CPU, or other optional-platform condition.
• Content: Frozen resolution reports no manifest-lockfile drift at revision d300000000000000000000000000000000000000; this result was supplied, not executed during the example.
• Integrity: Immutable synthetic artifact identifier lock-d300000000000000000000000000000000000000-v1 ties this excerpt to revision d300000000000000000000000000000000000000.
• Establishes: Exact resolved graph, direct status, parent paths, registry class, optional-platform disposition, integrity presence, and manifest correspondence.

E3 - Runtime import inventory

• Type: Complete static and packaged usage inventory.
• Content: src/read-config.ts imports get from lodash/get; src/format.ts imports kleur; no source, generated file, build script, plugin declaration, or packaged module references left-pad.
• Content: The application has no runtime plugin loader, reflection-based module loading, or externally supplied module path.
• Content: The packaged-artifact inventory contains lodash and kleur but not left-pad.
• Integrity: The inventory was generated from revision d300000000000000000000000000000000000000 and immutable synthetic package artifact package-d300000000000000000000000000000000000000-v1; both the source search record and packaged inventory identify that same revision and artifact.
• Establishes: Observed runtime uses, covered dynamic mechanisms, and absence of left-pad from the supplied artifact.

E4 - Advisory snapshot

• Type: Retained synthetic advisory record.
• Content: Advisory ADV-1 for the npm ecosystem affects lodash >=4.0.0 <4.17.21 only when untrusted input reaches lodash/template.
• Content: The first version outside the supplied affected range is 4.17.21.
• Content: The retained snapshot contains no advisory entry for kleur@4.1.5 or left-pad@1.3.0.
• Content: The synthetic advisory source identity is fixture://advisories/ADV-1, captured 2026-01-10.
• Integrity: This is the complete advisory record supplied for the example, not a current external lookup.
• Establishes: Affected range, vulnerable API condition, candidate fixed boundary, source identity, and timestamp.

E5 - Call-site search

• Type: Static reachability record.
• Content: Exact-symbol and property-access searches find no import, require, re-export, or call of lodash/template or _.template; only lodash/get is referenced.
• Content: No supplied input reaches a dynamically selected lodash function.
• Integrity: The search covers source, generated code, build scripts, and the packaged artifact at revision d300000000000000000000000000000000000000.
• Establishes: The vulnerable API is not observed within the supplied static and packaged scope; no runtime experiment proves non-reachability.

E6 - Audit context

• Type: Execution record.
• Content: No install script, package-manager command, registry request, dependency update, removal, build, test, or runtime command was executed for this example.
• Content: All resolution and usage records were supplied as synthetic evidence.
• Content: No license, maintainer, registry-provenance, or signature policy was supplied, so those concerns are outside this example's requested finding scope.
• Establishes: Static-only execution status and the boundary between evidence and proposed work.

E7 - Action constraints

• Type: Repository dependency and severity policy.
• Content: An affected direct runtime version with the vulnerable API unobserved is Medium until the upgrade or an approved runtime validation closes the exposure question.
• Content: A direct package absent from source, dynamic loading, and the packaged artifact is Low, but removal still requires compatibility checks and repository-maintainer approval.
• Content: The repository maintainer owns dependency changes and requires lockfile review, build, unit tests, packaging comparison, and manifest-lockfile rollback evidence before merge.
• Content: The unit-test inventory at d300000000000000000000000000000000000000 includes test/advisory-match.test.ts, which matches the resolved lodash version against retained snapshot ADV-1 and fails if a lodash/template or _.template reference appears in the complete static scope, and test/read-config.test.ts, which exercises configuration reads through lodash/get.
• Content: The repository runbook supplies these exact commands for an isolated branch based on d300000000000000000000000000000000000000: pnpm --config.ignore-scripts=true add --save-exact lodash@4.17.21, pnpm --config.ignore-scripts=true remove left-pad, pnpm install --frozen-lockfile --ignore-scripts, pnpm test -- advisory-match, pnpm test -- read-config, pnpm build, pnpm test, pnpm pack --dry-run --json, and git diff -- package.json pnpm-lock.yaml.
• Content: The rollback command is git restore --source=d300000000000000000000000000000000000000 -- package.json pnpm-lock.yaml, followed by pnpm install --frozen-lockfile --ignore-scripts; update and removal must use separate isolated branches.
• Content: Temporary acceptance of an affected runtime dependency requires security-owner approval, compensating controls, an owner, and an expiry.
• Establishes: Severity, action ownership, focused advisory, vulnerable-API, and configuration-read checks, exact proposed commands, exit evidence, rollback, and approval rules.

E8 - Compatibility constraints

• Type: Supported runtime and API record.
• Content: The service supports Node.js 20, and both lodash@4.17.20 and the proposed boundary lodash@4.17.21 declare compatibility with that runtime in the supplied package records.
• Content: No public service contract is documented as depending on left-pad; the usage and packaging inventory in E3 remains the evidence required before removal.
• Establishes: Candidate target runtime compatibility and the limit of known removal impact.

Complete expected output

Scope

Revision: d300000000000000000000000000000000000000. Snapshot: 2026-01-10. Scope: the complete three-node direct runtime graph from the matching manifest and lockfile [E1, E2]. No install script, package-manager command, registry request, update, removal, build, test, or runtime command was executed [E6].

Inventory

Package	Relationship	Resolved version	Integrity	Runtime and package status	Advisory status	Evidence
kleur	Direct runtime	4.1.5	Present	Imported and packaged	No supplied advisory	E1, E2, E3, E4
left-pad	Direct runtime	1.3.0	Present	No source, dynamic, generated, build, or packaged reference	No supplied advisory	E1, E2, E3, E4
lodash	Direct runtime	4.17.20	Present	lodash/get imported and package included	Resolved version falls within ADV-1; vulnerable template API not observed	E1, E2, E3, E4, E5

Package	Parent path	Registry class	Optional platform conditions	Evidence
kleur	Root importer .	Approved public npm registry	None	E2
left-pad	Root importer .	Approved public npm registry	None	E2
lodash	Root importer .	Approved public npm registry	None	E2

There are no transitive graph nodes, duplicate versions, optional packages, peer packages, or workspace importers in the supplied scope [E1, E2].

Findings

Severity	Confidence	Reachability	Finding	Evidence	Impact	Recommendation	Verification	Disposition
Medium	High for affected presence; Medium for reachability because complete static and packaged mechanisms were inspected but no runtime experiment ran	Not observed	lodash@4.17.20 is inside synthetic advisory ADV-1; the required template call is not observed in the complete supplied static and packaged scope.	E2, E3, E4, E5, E6, E7	Observation: an affected version is shipped. Inference: the advisory condition is not currently reachable through the supplied inventory, but no runtime experiment establishes non-reachability.	Upgrade to the supplied first outside-range boundary 4.17.21 in an isolated change and retain the exact resolution. Do not claim current exploitability.	Run the exact update, frozen install, build, unit-test, pack, and diff commands in the proposed command sequence, compare immutable artifact package-d300000000000000000000000000000000000000-v1, exercise configuration reads using lodash/get, and verify the exact rollback. None has run.	Open until the upgrade and compatibility evidence pass, or the security owner accepts temporary risk
Low	High because the complete source, dynamic-loading, generated, build, and immutable packaged-artifact inventories agree	Not applicable, because no advisory or vulnerable condition is supplied for left-pad	left-pad@1.3.0 is a direct runtime declaration absent from the supplied source, covered dynamic mechanisms, and packaged artifact.	E1, E2, E3, E6, E7, E8	It increases dependency and supply-chain surface without an observed packaged capability; unknown external consumer dependence is not claimed.	Remove it in a separate isolated change after repository-maintainer approval.	Run the exact removal, frozen install, build, unit-test, pack, and diff commands in the proposed command sequence, compare immutable artifact package-d300000000000000000000000000000000000000-v1, and verify the exact rollback. None has run.	Removal candidate pending repository-maintainer approval and validation

Action plan

Order	Proposed action	Owner	Dependency and approval	Exit evidence	Recovery
1	Update only lodash from 4.17.20 to exact 4.17.21 in an isolated branch.	Repository maintainer	Candidate boundary and Node.js 20 compatibility are supplied [E4, E8].	Exact lock resolution, reviewed lock diff, passing build and unit tests, unchanged package entry points, and pnpm test -- read-config passing the supplied lodash/get configuration-read check [E7].	Restore the retained manifest and lockfile from d300000000000000000000000000000000000000, then rerun frozen resolution in the isolated branch.
2	Re-run the retained advisory match and static template search through pnpm test -- advisory-match.	Repository maintainer	Step 1 candidate artifacts and the focused test inventory supplied by E7.	ADV-1 range no longer matches and no newly introduced lodash/template or _.template reference appears [E4, E5, E7].	Keep the finding open and do not merge the update if evidence disagrees.
3	Remove left-pad in a separate isolated branch.	Repository maintainer	Repository-maintainer approval based on complete usage and package evidence [E3, E7].	Reviewed manifest and lockfile diff, passing build and unit tests, and package artifact comparison [E7].	Restore both retained files and reject removal if any capability or artifact regresses.

All actions and validation commands are proposed and unexecuted [E6].

Proposed command sequence

Run the lodash change only in its isolated branch based on d300000000000000000000000000000000000000 [E7]:

pnpm --config.ignore-scripts=true add --save-exact lodash@4.17.21
pnpm install --frozen-lockfile --ignore-scripts
pnpm test -- advisory-match
pnpm test -- read-config
pnpm build
pnpm test
pnpm pack --dry-run --json
git diff -- package.json pnpm-lock.yaml

Run the left-pad removal only after repository-maintainer approval and in a separate isolated branch based on d300000000000000000000000000000000000000 [E7]:

pnpm --config.ignore-scripts=true remove left-pad
pnpm install --frozen-lockfile --ignore-scripts
pnpm build
pnpm test
pnpm pack --dry-run --json
git diff -- package.json pnpm-lock.yaml

If either isolated change fails its exit evidence, restore the retained dependency files and resolution [E7]:

git restore --source=d300000000000000000000000000000000000000 -- package.json pnpm-lock.yaml
pnpm install --frozen-lockfile --ignore-scripts

These commands were supplied by the synthetic runbook and were not executed for this example [E6, E7].

Approval and decision record

The repository maintainer must approve the left-pad capability-removal evidence before implementation [E7]. No temporary acceptance is proposed because an evidence-supported candidate lodash boundary is available. If the update cannot be completed before release, the security owner must approve compensating controls, owner, expiry, and revalidation before temporary acceptance [E7].

Limitations

The inventory is complete only for the synthetic three-node scope at revision d300000000000000000000000000000000000000 [E1, E2]. The supplied application has no plugin or reflective loader, but no runtime experiment was performed [E3, E5, E6]. Advisory data is the retained synthetic snapshot, not a current external lookup [E4]. Version 4.17.21 is supported only as the first boundary outside the supplied range and a Node.js 20-compatible candidate; it is not described as validated in this service [E4, E8]. License, maintainer, registry-provenance, and signature risk are outside the supplied policy and evidence scope [E6].

Traceability

Material conclusion	Evidence
Immutable direct declarations and dependency groups	E1
Complete resolved graph and integrity presence	E2
Runtime, dynamic-loading, and immutable packaged-artifact usage	E3
Affected range, condition, boundary, source, and date	E4
Vulnerable API not observed in supplied scope	E5
No package or validation command executed	E6
Severity, owner, exact proposed commands, rollback, and approval policy	E7
Node.js 20 target compatibility and removal-impact limit	E8