FINAL v0.12.0 release closure — single consolidated remediation and acceptance gate

Product Owner instruction (13 October 2026): “Make sure all is covered. This will be the last loop before v12.0 is published.”

Current source checked: PR #83 release/v0.12-no-state-engine at 03180305c356eb569ee3017f3927f5e8dfda059c.
CI: Run 38383915731 Windows PASS, Ubuntu PASS on this SHA.
GitHub review: 1 Codex COMMENTED review, 6 unresolved threads (3 P1, 3 P2). This is NOT approved.
Scope authority: Issue #82; nine tasks (T01–T03, T05–T10), 35 required AC; T04, AC-012–015 and AC-034 explicitly deferred to P0 v0.13 Issue #84 with full Windows restore Issue #73 unchanged.
Previous review: Antigravity single-session report PASS for older 6200d828857cdec249ca2d612f5c4b9bd15d4ebe, invalid for current HEAD; it also missed a CORS lookalike-origin vulnerability fixed in 03180305.

A. Mandatory remediation — all six source-bound open Codex defects

P1 [ ] F1 Authority-aware re-entry: runtime/orchestration/discovery-reentry.mjs resolveReentryStage ignores affectedAuthority. Normalize and validate authority entries; the safest/higher authority determines minimum re-entry stage (spec DEFINE > architecture DESIGN > plan PLAN > implementation IMPLEMENT). Untrusted event classification may never downgrade authority-driven re-entry or its required human approval. validateDiscoveryEvent must recompute and reject inconsistent minimumReentryStage / approval flags. Tests: contradictory class vs authority, malformed types/unknown kinds, spoofed events, no authority, mixed authority, actual review stage.

P1 [ ] F2 Enforce gate profiles at real run AND acceptance: runtime/orchestration/gate-profiles.mjs currently resolves profiles but orchestration-run.mjs + acceptance-engine.mjs still invoke selectRequiredGates directly. Bind validated required profile IDs and project configuration/capabilities in authoritative, source-fingerprinted contract or trusted inputs; choose the same effective gate resolver at run creation and at decideAcceptance. Required verification classes, code/security/architecture reviewers, control domains and human approvals must cause ACCEPTED to fail/pending when missing. No caller-supplied or custom-profile downgrade/override, and no bypass by omitting profile inputs at acceptance. Tests: gp-consequential missing approval, gp-high-assurance missing security review, spoofed custom ID, accepted with complete proper authentic evidence.

P1 [ ] F3 Connect extension failures to canonical acceptance: verification-extension-sdk.mjs evaluateInvariant and VerificationExtensionRegistry are currently disconnected from verifier/acceptance engine. Map project-owned validators, numeric checks and golden dataset freshness into actual canonical verification criteria with authenticated evidence/source fingerprints, unknown/FAIL/exception -> FAIL or INCOMPLETE (never PASS), preserve independent verifier boundary, no self-acceptance. Demonstrate two different project-owned extensions that block or permit normal acceptance without core code modifications. Tests: failed invariant blocks even with other PASS criteria, stale golden fingerprint blocks, unregistered extension/malformed output fails, no synthetic PASS.

P2 [ ] F4 Durable discovery evidence: Persist/load/replay typed discovery-event records including affected authority, evidence fingerprints, invalidated tasks, approval references and timestamps using existing stable v0.11 snapshot/approved persistence patterns, not T04. Crash/interrupted-write safety, project isolation, idempotent identifiers, reload across restart, corrupted event -> fail closed; no arbitrary event edit to forge approval.

P2 [ ] F5 Legacy lifecycle rehydration: ensureProjectLifecycle({rootDir}) must read the incumbent getCurrentState(rootDir) whenever no explicit state supplied. Preserve stage, workflow state, revision, parent/child and completed/blocked semantics, and avoid writing during a read; no reset to UNDERSTAND. Explicit supplied legacy state must have documented precedence; malformed existing state must not be silently reinitialized.

P2 [ ] F6 Operational Control Center: GET /v1/scale-context currently exposes module-file presence, not persisted cost ledger, target registry, lifecycle instances, discovery queue, context cache status, effective gates, or evidence-backed acceptance. Build safe read-only typed projections from actual project-local canonical sources. Represent missing/unavailable/stale/degraded as such, no fabricated healthy/accepted, no hidden mutation on GET, no secrets/path leaks. When no persisted data for a module, return unavailable rather than pretend there is operational state. Include negative/positive cross-project tests and CORS spoofed-origin regression coverage.

DO NOT delete ignored .development-kit/contracts or overwrite local user state to fix test failures; Antigravity's previous report showed deletion of local contracts and their backup. Distinguish fixture cleanup from live project state. Use disposable temporary fixtures and safe, user-visible migration handling.

B. Release acceptance evidence — correct old PASS matrix

[ ] 35 criterion evidence inventory on the FINAL SHA. For each criterion record canonical wording (read original specification), implementation path, executable test+result, real/synthetic evidence category, independent reviewer, source SHA, and PASS/FAIL/UNVERIFIED. Deferred AC-012–015/034 remain DEFERRED, not PASS.

[ ] AC-019 persisted discovery evidence across restart (F4); AC-020 authority-derived minimum safe re-entry (F1); AC-022/023 effective profiles enforced by actual acceptance (F2); AC-026/027/038 real SDK extension effects and two independent examples (F3); AC-016–018 lifecycle legacy rehydration and no premature completion (F5); AC-030 actual noncanonical operational Control Center with no fabricated claims (F6); AC-036 no new false ACCEPTED; AC-039 must prove capability/configuration-driven routing rather than technology-name-driven (prior matrix mislabeled AC-039 as end-to-end integration).

[ ] AC-033 measure true baseline-vs-v0.12 cost on a matched, reproducible workload at exact v0.11.2 baseline and scoped candidate SHA, using observed Cost Observatory data where available. Synthetic cost-observatory.test.mjs baseline/current arithmetic fixture is a valid test of the comparator but NOT a release cost measurement. Report provider billing/token counters unavailable when uninstrumented; do not infer 0.

[ ] AC-035 run representative baseline-vs-v0.12 context/orientation workload and publish exact source, node/runtime, OS, task fixture, method, inputs, measured estimates/counters, reduction/neutral/increase, and limits. token-efficiency.test.mjs verifies within-version token algorithms, not a historical before/after release improvement. Fail release criterion as UNVERIFIED if its evidence is mandatory and absent rather than asserting unsupported gains.

[ ] T10 comparative release evidence: test single package, multi-package, numerical verification, existing legacy project and fresh project; verify end-to-end actual state and acceptance, not just module existence. Verify zero changes to T04 source/runtime, no State Engine V2 import, and no T04 fixtures in npm package. Preserve existing /dk-* commands and installers on Windows/Ubuntu.

C. Security, packaging and quality freeze

[ ] Independently reproduce and verify the CORS origin fix on final source: exact parsed localhost/127.0.0.1/[::1] HTTP origins permitted only under intended policy; lookalike, malformed, null, credentialed, file/https remote origins fail closed. Test state-pointer traversal, malformed revision files, side-effect-free GET, missing secrets and improper session token/origin access. Consider accepted threat model and other potential remote loopback abuse.

[ ] Build full integration tests for T01→T03→T05→T06→T07→T08→T09→T10, including every negative/bypass path. No test-only integration adapter that production never calls.

[ ] Run npm run release:validate, npm run release-scope:v012, npm pack --dry-run, git diff --check, full install/consumer smoke, docs/version consistency, Node 22 supported runtime, Windows+Ubuntu GitHub Actions on the final immutable SHA; record passes/failures/skips and links. Ignore no failing/skipped mandatory tests.

[ ] Source-bound code, architecture and security review: use fresh, independent reviewer contexts/identities allowed by current DKF gate and record authenticated role provenance. One agent's three role headings is NOT automatically three independent reviews. Fix findings with specific regression, rerun affected reviews on changed SHA. Reviewer absence -> explicit blocker, no invented PASS.

[ ] main still contains package 0.11.2 until reviewed PR is merged. Never merge an unaccepted PR, claim published from green CI, or trigger release issue early.

D. Single deterministic final decision

One FINAL ACCEPTANCE MANIFEST should contain final SHA, all 35 criterion evidence, explicit five deferrals, six Codex finding dispositions and tests, actual benchmarks, reviewer identity/provenance, exact cross-platform CI run, supported package files, changelog docs, version manifests, npm secret/environment readiness and an explicit GO or NO_GO.

Only GO if all six mandatory defects are corrected, all required evidence and independent reviewers pass, no unresolved blocking review threads, T04 is absent, and release workflow preflight passes. No speculative PASS. No waiting for successive vague “one more review” cycles; batch all source remediation and tests, obtain one final source-bound review and freeze the SHA.

E. Publication once GO is demonstrated

1. Confirm PR release(v0.12): ship stable-state features, defer T04 to v0.13 #83 is reviewable (already marked ready), source SHA unchanged after reviewer signoff, correct merge authorization and required branch protections.
2. Merge PR release(v0.12): ship stable-state features, defer T04 to v0.13 #83 into main, verify main commit, rerun Windows/Ubuntu CI on integrated source.
3. Existing authenticated maintainer issue workflow accepts issue title exactly Release v0.12.0, body exactly /release v0.12.0. Issue must be created by the repository owner, after main package.json is 0.12.0.
4. Workflow creates v0.12.0 tag and GitHub Release, attempts npm package development-kit@0.12.0. If NPM_TOKEN is absent, workflow reports skipped-no-token: that is NOT successful npm publication. Verify exact npm view development-kit@0.12.0 version and GitHub Release after completion.
5. Close this issue only once BOTH public GitHub release and npm exact version are independently verified.

The PO has authorized publication when legitimate GO is achieved. Do not require redundant release confirmation.

Tracking: release PR #83, rescope Issue #82, v0.13 P0 Issue #84, Windows Issue #73.