build(reproducibility): pin package-manager identity for deterministic lockfile regeneration

[seonghobae]

Problem

Security remediation #75 exposed a reproducibility gap in the repository dependency-control plane. An earlier lockfile regeneration under an unbound Node/npm toolchain produced the intended nanoid update plus unrelated package metadata churn. Green CI alone therefore did not establish that targeted lockfile regeneration was minimal or reproducible.

Current protected / implementation lineage

PR #76 is now integrated on protected main as merge commit c85d710804139c0697d7ef8fa47d02b1389e6d84; the bounded nanoid@3.3.17 remediation is protected truth.

The old broad implementation #78 and dependency-stacked replacement #89 are superseded/closed. Clean protected-main successor PR #91 is the only active implementation line, exact head ebde3720ee27292be0ce3315986e0438dd66af9f.

#91 preserves the reviewed unique package-manager/reproducibility controls on top of integrated #76:

• Node.js 24.19.0 / npm 11.17.0 exact identity;
• fail-closed package-manager mismatch checks;
• strict-allow-scripts=true with reviewed lifecycle-script identities;
• exact live-base schema-v2 lockfile change control;
• canonical before/after package-object SHA-256 evidence;
• duplicate decoded JSON-key, malformed UTF-8, symlink/race/metadata-churn refusal;
• exact frozen install flags and npm audit --audit-level=high separation;
• APA 7 doctoring and ## Unreleased evidence;
• owned control-plane coverage under the repository exact-coverage gate.

Fresh exact-head evidence for #91:

• application ci run 31367707468: terminal success;
• reviewer-ci run 31367707469: terminal success;
• central Security Scan run 31367707433: terminal success;
• formal reviews: none at latest read;
• inline review threads: none;
• GitHub reports build(reproducibility): restack deterministic npm toolchain #91 mergeable and Ready for review.

The clean technical result is not merge authority. Live enforceable governance under #27 and qualifying independent formal review remain fail-closed gates.

Acceptance criteria

Repository-owned implementation

• Select/document one exact Node/npm toolchain for lockfile-sensitive work.
• Enforce package-manager identity before install/lockfile-sensitive validation.
• Add deterministic lockfile change control that detects unrelated metadata churn and binds package objects to live-base/source evidence.
• Preserve frozen npm ci and npm audit --audit-level=high; never auto-repair in CI.
• Preserve least privilege and prohibit repair/self-modifying write paths.
• Record regeneration/provenance expectations with current primary documentation and APA 7 references.
• Record the control under ## Unreleased on the active line.
• Maintain configured exact owned production/security-control coverage on build(reproducibility): restack deterministic npm toolchain #91.
• Integrate fix(security): update transitive nanoid for CVE-2026-67213 #76 before the broader package-manager control.
• Rebuild the unique package-manager work on the protected post-fix(security): update transitive nanoid for CVE-2026-67213 #76 lineage (build(reproducibility): restack deterministic npm toolchain #91).
• Acquire fresh exact-head application/reviewer/Security Scan evidence on build(reproducibility): restack deterministic npm toolchain #91.

Remaining integration / protected-main acceptance

• Resolve every new valid current-head finding if one appears.
• Satisfy the actual live ruleset and qualifying independent formal-review requirement.
• Merge unchanged build(reproducibility): restack deterministic npm toolchain #91 under protected policy without waiver/synthetic approval.
• After protected integration, run a targeted lockfile-regeneration rehearsal and prove unrelated metadata churn cannot pass without explicit reviewed justification.
• Retain protected-main operational evidence separately from PR/check/model evidence.

Historical RCA only

The earlier unbound regeneration under Node 24.18.0 / npm 11.16.0 remains useful causal evidence for why the control exists; it is not the current implementation baseline.

Related: #27, #29, #79, #91

[seonghobae]

Implementation evidence update for #78 exact head 317ad2fccdfeef1ac84ee739fecc19c55ee70982:

• development/lockfile toolchain is pinned to Node.js 24.18.0 + npm 11.16.0, with a pre-install exact-version CI gate;
• lockfile change-control now uses schema v2 and binds the exact PR base SHA, the complete changed package-lock.json packages key set, and canonical SHA-256 digests of every exact before/after package object (including add/delete presence state), so path-only approval cannot hide resolved, integrity, license, bin, or dependency-edge drift;
• malformed/stale policies, top-level lock metadata movement, unreviewed package churn, symlink/race-prone evidence reads, and invalid UTF-8/oversized inputs fail closed;
• authoritative doctoring and CHANGELOG.md were updated, including APA 7th references to npm/Node primary docs and NIST FIPS 180-4;
• latest exact-head CI reached 100% statements/branches/functions/lines coverage. reviewer-ci and Security Scan are successful.

The exact-head ci run remains failed only at the unchanged npm audit --audit-level=high gate because base main still resolves vulnerable nanoid@3.3.16 tracked in #75/#76. This is intentionally not waived. #78 remains Draft and must not be merged until the dependency remediation, independent approval, and enforceable main governance gates are satisfied.

[seonghobae]

2026-08-09 fresh implementation mapping: PR #78 exact head 8cde63aae7e04808eeda4e9a807941590da99d65 satisfies the source-level implementation portion of this issue: reviewed Node 24.19.0 / npm 11.17.0 identity via repository metadata and CI verification, immutable Node-24-native Action pins, exact live-base refusal before lockfile control, a second ordered post-verification base-drift refusal, closed schema-v2 lockfile package-object digest policy, duplicate-key/race-prone evidence refusal, and explicit install-script authority. Current CI proves exact checkout/toolchain/live-base/lockfile/install/typecheck/683 tests/100% coverage before failing only on the distinct inherited nanoid@3.3.16 advisory; reviewer-ci and Security Scan are terminal-success. Thus #77 should remain open only for integration/acceptance: integrate #76, refresh #78 against the then-live base, obtain full exact-head CI/security/review/governance evidence including the post-release:verify drift check on a successful run, protected-merge #78, then close #77. No lockfile auto-repair, audit waiver, repair workflow, or write-capable CI path is required.

[seonghobae]

2026-08-09 integration-feasibility probe, after refetching live main=9adb784902cae19a150146a8fadd6a0491f67814, #76 head=e0106ce16b7b8b493f46bf075ec5baf58762bd95, and #78 head=8cde63aae7e04808eeda4e9a807941590da99d65:

A reversible retarget of Draft PR #78 from main to #76's fix/nanoid-cve-2026-67213 branch was used only as a GitHub-side mergeability probe. GitHub recalculated the stacked PR as non-mergeable, proving that #76 is not a drop-in base for the unchanged #78 head. The branches diverge from 9adb...: #78 is 53 commits ahead of the common base while #76 is a separate 16-commit line. Their overlapping files include .github/workflows/ci.yml, CHANGELOG.md, and test/workflow-readiness.test.ts; #78 also still contains nanoid@3.3.16 in its exact-head package-lock.json. The #78 CI workflow semantically supersets the exact-checkout/toolchain portion of #76 while adding live-base and lockfile controls, so blindly taking either side would discard reviewed behavior.

The retarget was immediately reverted. Fresh GitHub state now has #78 back on main, exact head unchanged, and mergeability restored. No branch commit/ref was rewritten and no synthetic merge result is being promoted as proof.

Resulting integration contract: keep #78 Draft on main; integrate #76 first under its own gates; then refresh #78 from the new protected-main tip with an actual conflict-resolving source update that preserves #76's nanoid lockfile remediation and #78's stronger CI/lockfile controls, followed by fresh exact-head/live-base tests, successful npm audit, the post-verification base-drift check, review/governance, and protected merge. The tested direct-stack shortcut is rejected rather than retried.

[seonghobae]

Implementation ownership has moved from closed superseded PR #78 to dependency-ordered Draft #89. On #89 exact head adcc42d2b0fec3106faabb59bbf7e79124714f7a, application CI run 31350201695 and reviewer-ci run 31350201710 are terminal-success: exact head and live #76 predecessor binding passed, Node 24.19.0 / npm 11.17.0 passed, schema-v2 lockfile change control passed, 71/71 test files and 692/692 tests passed, configured statements/branches/functions/lines are 100%, and npm audit --audit-level=high reports 0 vulnerabilities. The issue remains open because #89 is stacked on unintegrated #76, central Security Scan is not event-eligible on the feature-base stack, and protected-main governance/formal-review acceptance is not yet established. No predecessor review/check evidence transfers.