release: reconcile Office and npm versions before next stable registry publication

[seonghobae]

Stable-release operational acceptance

This issue is the canonical release-acceptance boundary for the next stable Inkspan publication. It intentionally does not embed a protected-main SHA, PR head SHA, workflow run ID, review count, release inventory count, or registry version as current truth. Those values are mutable and must be refetched immediately before every lifecycle decision.

Protected main is the only shipped-source authority. Source metadata is not registry-publication evidence, a branch ref is not a release identity, and predecessor or synthetic-merge workflow evidence never transfers to a new protected tip.

Mandatory live refetch

Before merge-to-release, tag, GitHub Release, npm/PyPI publication, issue closure, or any claim that the stable train is ready, independently refetch:

• the exact protected main tip, verification, and ancestry;
• the then-authoritative root and Office version metadata plus CHANGELOG.md;
• the exact protected .github/workflows/release.yml and every asset/provenance rule it currently declares;
• all open Inkspan PRs/issues that own release-blocking source, workflow, accessibility, dependency, package, or review work;
• exact candidate heads and independently resolved live bases;
• formal reviews and unresolved review threads;
• all required CI/security/SAST/dependency/coverage/browser/Office/fidelity/accessibility/package/SBOM/provenance/reproducibility/rollback/operational workflows;
• each required workflow job's actual checkout SHA and repository identity;
• live repository/organization rulesets and protection;
• any open organization-level merge-admission/ruleset-bypass incident that affects the protected lineage, including its audit-log / Rule Insights disposition and remediation status;
• tags and GitHub releases;
• public npm/PyPI state and, after publication, exact artifact digests/provenance.

Pending, queued, skipped, cancelled, absent, neutral, failed, stale, predecessor, status-only, model-only, wrong-checkout, synthetic-merge-only, or vacuous evidence is non-passing. An aggregate green status is insufficient when an underlying required path was skipped or consumed the wrong revision.

Existing owner lanes to refetch, not duplicate

Known release-related owner paths include Inkspan accessibility/product repair, the release-workflow stack, exact-head stacked-PR workflow evidence, and central review/security/merge-admission control-plane repairs. Historically these have included Inkspan PRs/issues such as #362, #285, #298/#299 and central .github owner paths #771, #814, #810/#897, and #1222/#941. Their current state, head, base, ownership, and continued applicability must be refetched; this list is routing context, not a status snapshot.

Do not create a competing Inkspan source writer when one of those live paths already owns the causal boundary. If a central/foreign defect still owns the first causal failure and no correct Inkspan-local remedy exists, advance that existing owner path with the exact affected source SHA, run/job, reproduction, falsifiable RCA, RED acceptance, smallest remedy, GREEN proof, and Inkspan-side revalidation.

Required dependency discipline

1. Resolve protected-product correctness/accessibility blockers through their existing source owners.
2. Resolve exact-head workflow/security/review-control defects at the actual owning boundary; false-green central evidence is non-passing.
3. Treat an unexplained protected-main admission that lacks then-required formal review/gate evidence as a release blocker, even if the resulting protected commit is technically green. Do not make the later tag/publication path retroactively legitimize the admission. The actual merge/authentication path and ruleset decision must be reconstructed through the existing governance owner, the fail-closed admission contract repaired, and the resulting protected lineage revalidated under ordinary non-bypass governance before release acceptance.
4. Integrate source stacks dependency-first under then-live governance, regenerating exact-current-head evidence for every descendant rather than transferring parent/predecessor runs.
5. Integrate the release-workflow owner only after its dependencies are ready; after integration, refetch protected release.yml and treat only that exact protected workflow as the authoritative release asset, timeout, SBOM, provenance, browser, and publication contract.
6. On one unchanged protected tip, regenerate every applicable required gate.
7. Create the stable tag/GitHub Release only through supported release authority at that exact protected tip. Never emulate release identity by moving or naming a branch ref.
8. Publish npm/PyPI only through the then-accepted registry mechanism and policy; do not weaken provenance, reuse ambiguous bytes, or use skip-existing to conceal partial publication.
9. Verify public registry digests against the exact accepted release artifacts. On partial publication or mismatch, record an incident and do not rebuild different bytes under the same immutable version.
10. Close this issue only after public artifact, digest, provenance, rollback, and operational acceptance are proven.

Stable release acceptance criteria

Close only when one exact protected lineage proves all then-applicable requirements, including:

• root/Office/tag/release metadata agree;
• deterministic JavaScript and Office builds from immutable dependencies;
• repository-required test, exact coverage, and public-doc/docstring thresholds;
• packed-package consumer verification;
• dependency-locked real Chromium/Firefox/WebKit evidence where applicable;
• accessibility and deterministic Office/fidelity evidence;
• security, SAST, dependency, package, SBOM, provenance, reproducibility, rollback, and operational gates;
• qualifying formal independent reviews under live governance;
• no unresolved merge-admission/ruleset-bypass incident capable of undermining the protected lineage used for release;
• release artifacts built from and attributable to the exact protected source;
• public registry digests matching those exact artifacts;
• no unresolved contradiction between source, release metadata, registry state, governance evidence, and canonical documentation.

Branch CI, active-PR metadata, queued review dispatch, model verdicts, local-only tests, predecessor runs, or unmerged repairs do not satisfy acceptance.

Authority/tool boundary

If the currently available mutation surface does not expose safe Git-tag or GitHub-Release creation, classify only that exact release mutation as unavailable and continue every other safe repository action. Do not evade that boundary with lower-level branch-ref mutation or fabricate a release identity.

The canonical product/technical maintenance baseline is docs/product-technical-gap-baseline.md; it must likewise avoid treating mutable GitHub lifecycle snapshots as protected static truth.