codex-workflow-v2 2.0.0-beta.13.8 → 2.0.0-beta.14

package/docs/release.md

@@ -1,363 +1,95 @@
-# Release Policy
-
-The npm package is `codex-workflow-v2` with public visibility. Consumers must pin
-an exact version. Stable compatibility covers the latest minor release of the current
-major only; older minors are unsupported unless a release note explicitly says otherwise.
-
-## beta.13.8: explain changes and continue active Milestones
-
-Full autonomy can be issued during an active Milestone using an exact new human-confirmed
-contract. Interrupted event-first issuance remains recoverable after expiry or revision change:
-a fresh confirmation may supersede an inert missing grant, preserving its event and creating a
-new grant identity. Known unpublished grant directories carry no authority; malformed state and
-unknown incomplete delegations still fail closed.
-
-The read-only `change explain` command separates execution context, external approval, semantic
-scope, bounded check-support amendment, Plan correction, membership and context refresh. It
-preserves the current Core route, including credential prerequisites and effective Step scope.
-Its proposal hash is diagnostic evidence, not permission to apply a patch.
-
-Chat dispatch records the observed child checkout and offers an advisory context check before
-writes. Existing Workers are preserved; a parent repository path does not authorize writing
-outside the actual child checkout. Model and reasoning selection remain task-specific.
-
-The exact beta.13.8 runner retains the tested beta.13.6 consumed-carryover source
-recovery profile with beta.13.8 as its pinned target. It does not admit a beta.13.7
-source or a running Step; historical beta.13.7 transcript evidence remains separately
-valid for its original target.
-
-All ordinary release gates below apply to the exact versioned candidate. Historical failed
-real-agent runs remain failed evidence; prior one-time release exceptions are not reused.
-Signal deployment additionally requires a fresh safe update boundary, exact installed provenance
-and verified continuation by the original Worker. This release does not waive external approval
-or claim to prevent every future product failure.
-
-## Active Milestone autonomy contract issuance
-
-The candidate extends full human-confirmed autonomy to an already active Milestone.
-Release evidence must cover both initial active issuance and replacement after revocation
-or expiry, without resetting Task state, changing membership/semantic scope, or replacing
-an existing Worker. A generic delegation is neither upgraded nor revoked implicitly.
-
-The MAC includes the previous contract/grant snapshot so a revoked confirmation cannot
-restore authority. Exact successful and interrupted-write retries must preserve identity;
-legacy event-first records retain their bounded pre-execution recovery. Shared Milestone
-exclusion protects issuance, revocation and scope/status transitions.
-
-Acceptance must continue through same-Worker execution and guarded atomic context refresh
-using the new full contract, with the old grant rejected without Task/Knowledge mutations.
-Include read-only preparation, stale bindings, valid-contract replacement refusal, malformed
-actors/expiry, unavailable Knowledge and disallowed Milestone states. Optional Task-first
-navigation must not replace the current execution/recovery action. Run the full test suite,
-release checks, downstream package smoke and plugin validation on the final candidate.
-
-## beta.13.7 candidate: retire completed carryover authority
-
-After a recovered Step passed review, its recorded dirty-work permission still
-overrode the next Step's route. A later repeated mechanical failure therefore
-returned `doctor` instead of ordinary Plan replacement. The completed record is
-now retained as history and consumed only after its completion evidence, exact
-PRA, required strict review and Git history are verified. Active or damaged
-bindings continue to fail closed. A corrective claim must belong to the same
-Worker who performed the terminal corrective yield.
-
-The exact published beta.13.7 read-only compatibility preflight can guide a
-stranded beta.13.6 source through its existing Plan replacement and original-Worker
-handoff commands before transport. It does not mutate state, authorize execution,
-or waive approval gates. Task and base transport must preserve all product bytes
-and change only the exact Workflow dependency. See the packaged gateway skill for
-the stage-specific bindings and mandatory source status/next readbacks.
-
-Release evidence must include the published beta.13.6 runtime reproducing the
-later-Step blocker, source Plan/PRA/authorization/handoff recovery, dependency
-transport, target provenance/context refresh, same-Worker execution and strict
-review. A route that reaches only `plan-set` is not sufficient. Prior one-time
-release-gate exceptions do not authorize this candidate.
-
-The trusted lifecycle harness must record each compatibility invocation and its
-terminal observation. For source `task plan-set`, record `inputBinding` computed
-from the actual files passed to that command: `candidatePlanHash` is the rendered
-Plan hash, and `candidateInputHash`/`riskAuditInputHash` are SHA-256 of recursively
-key-sorted canonical JSON inputs. Do not copy these values from an approval receipt
-without checking the executed inputs. The validator checks this binding, the resulting
-Plan hash, original-Worker ownership, ordered source status/next checkpoints, live-lease
-waiting, exact stale repair, and a fresh preflight before transport.
-
-## beta.13.6 candidate: preserve work across root-cause replan
-
-A repeated mechanical failure can legitimately yield the same Task to a replacement
-Plan while preserving uncommitted implementation. beta.13.5 authorizes that Plan but
-then rejects its planned Step because the checkout is dirty. Reaching planning or
-reauthorization therefore does not prove recovery.
-
-Acceptance for this candidate must exercise the complete repeated mechanical failure,
-automatic C1 yield, semantic replacement Plan, independent PRA, authorization, and
-same-Worker execution sequence with the original dirty bytes. The carryover assessment
-must bind the source remediation cycle, verified historical and current Plans, current
-PRA and authorization, completed evidence, HEAD, file set and content hash. Every carried
-path must already belong to the replacement Step and remain outside forbidden scope;
-carryover never expands scope or forgives unrelated work.
-
-Navigation and execution must use the same assessment. Changed bytes, paths, HEAD,
-Plan artifacts, audit/authorization evidence or ambiguous source history must fail
-closed before execution. Tests must continue beyond successful start through checks,
-Core commit and strict review, and reject each material binding mismatch.
-
-The stranded-source update must additionally prove a read-only compatibility preflight,
-no writer lease or pending Core operation, exact coherent source/target versions,
-dependency-only Task and Milestone-base commits, registration of the Task dependency
-commit after verification of the base transport, and unchanged product bytes. It must preserve the original Task and Worker and must not
-rely on manual product commits, stash/reset, installed-code edits or state-file edits.
-
-All ordinary release gates below apply. The user's one-time beta.13.5 CI-based release
-exception is consumed and is not evidence or an exception for this candidate.
-
-## beta.13.5 preventive Plan correction before execution
-
-A newly discovered implementation Plan defect can require changing unfinished scope
-before its next Step runs. The preventive route withdraws the current execution
-authorization under an independent blocking Plan Risk Audit, then requires a corrected
-Plan, fresh independent audit and ordinary execution authorization. It must preserve
-the same Task, completed Step definitions and evidence, requirements, acceptance,
-review history and grants. It must not manufacture a failed run to unlock planning.
-
-Initial eligibility is deliberately limited to a coherent, clean, idle `ready` Task
-with no C1 ownership or writer lease. Stale bindings, existing ownership, incomplete
-review, unexpected Git history and damaged state must fail closed. Regression gates
-must prove authority withdrawal and actual same-Task continuation, plus rejection of
-attempts to change the objective, discard completed evidence or weaken guarded scope.
-
-Replacement Plan publication commits Task state, the current and immutable Plan artifacts,
-and its independent audit atomically. Pending correction blocks C1 handoff and dependency
-transport until the corrected Plan can be authorized. Proof bindings retain each Step,
-failure mode and evidence association; revised proof prose requires an independent audit
-with an explicit rationale. Core does not determine whether natural-language proof claims
-are semantically stronger.
-
-External sealed-review CLI help specifies the complete envelope, including its nested
-review. Lifecycle validation admits one bounded expired-credential recovery between a
-review-input syntax refusal and retry, with unchanged sealed evidence and fresh sequential
-status/next bindings; unrelated or unbound mutations remain invalid.
-
-## beta.13.4 candidate: continuation after accepted corrective Plan
-
-This correction is included in beta.13.5; beta.13.4 was not published separately.
-
-The beta.13.3 first-conflict recovery stopped too early: after a replacement Plan
-was accepted and authorized, navigation still applied the old Plan's conflict to
-the now-planned Step. Release acceptance for this correction must exercise the
-complete same-Task sequence through fresh Plan Risk Audit, execution authorization,
-the existing Worker claim, actual Step execution, and another failed review.
-Reaching `task plan-set` alone is not sufficient evidence.
-
-An accepted semantic replacement must be distinguished from a Knowledge-only
-rebind using verified Plan artifacts and audit/review bindings. Historical failures
-and their global ordinals remain append-only. A missing or damaged artifact must
-not silently acknowledge a conflict, and a context refresh must not reopen execution.
-
-## beta.13.3 explicit Plan conflict recovery
-
-A first independently recorded reviewer `route=replan` with a validated Plan conflict
-blocks current execution immediately and exposes corrective replan. Historical
-rolling-cause classification remains unchanged; valid older histories are not
-reclassified as corrupt. Ordinary new fix findings still continue in the same Task.
-The failure transaction yields C1 and releases the exact writer lease. An older
-failed Task with a retained C1 claim follows credential recovery and
-`task corrective-yield` before planning; it cannot run or change its Plan while
-the claim remains. Recovery binds the validated remediation event and preserves
-the Task, review evidence, and existing worker identity.
-The release also includes durable App dispatch and explicit role/phase model selection;
-see the packaged `references/chat-dispatch.md`.
-
-## beta.13.2 review recovery gate
-
-The patch preserves protocol 2 and canonical entity schema 2. In addition to the
-ordinary release gates, `release:check` executes the large-diff, pending-review
-update, supporting-source refresh and Task guard regressions. Acceptance requires
-complete external-sealed Step and Task packets above 2 MiB, explicit bounded
-failure above the Git output limit, exact credential recovery before Knowledge
-refresh, and a Signal-shaped delegated update followed by actual review,
-context refresh and the next ordinary Step. A source preflight alone is not
-recovery completion. See `beta13.2-signal-review-recovery.md`.
-
-## Release gate
-
-Before tagging a release:
-
-1. `npm ci`
-2. `npm run validate`
-3. `npm run test:signal-t10-check-support-e2e`
-4. `npm run test:signal-remediation-e2e`
-5. `npm run pack:check`
-6. `npm run smoke:downstream`
-7. `npm run plugin:check`
-8. `npm run docs:pdf:check`
-9. `npm run release:check`
-10. validate `plugins/codex-workflow-gateway` with the Codex plugin validator
-11. validate the append-only real-agent log with
-   `node scripts/validate-lifecycle-transcript.mjs --file <lifecycle-log.jsonl>`
-
-The beta.13 real-agent gate follows the same Codex App boundary as production: the Task agent keeps
-its live writer authority while a separate App reviewer consumes an external-sealed packet, then the
-Task agent records the result. A nested native `codex exec` launched from inside another Codex agent
-is not accepted as release evidence. Packet generation is a logged read-only observation; recording
-the sealed result remains an exact `next`-authorized mutation followed by `status` and `next`.
-
-The downstream smoke packs the actual tarball, installs it into an empty temporary project,
-runs the packaged CLI handshake, and proves installation created none of `.codex`, `.tasks`,
-`.increments`, or `.memory-bank` in that project.
-
-The PDF check deterministically regenerates all three Russian documents from
-`docs/pdf/sources`, binds the visible package version to the root manifest, and fails when any
-tracked PDF is stale. Source and binary PDFs are one release unit.
-
-For beta.13, `npm run release:check` builds the exact current source before inspecting the packaged
-surface and fails unless all of these release contracts remain present:
-
-- the handshake advertises `cause-bound-rolling-refinement-v1`,
-  `failed-step-continuation-transaction-v1`, `host-safe-credential-reference-v1`,
-  `structural-production-edge-contract-v1`, `observed-route-matrix-v2`, `compact-status-v1`,
-  `reviewer-runtime-preflight-v1`, `explicit-review-mode-v1`, and
-  `app-owned-operational-preflight-v1`;
-- claim/writer credentials are transported only by project/entity/action/actor-bound local
-  references backed by mode-`0600` storage, legacy secret-bearing arguments fail closed, and secret
-  material is absent from argv, output, errors, tool/session/transcript fixtures, and evidence;
-- a failed check commits failure evidence, exact dirty-byte binding, Task continuation state, and
-  lease release through the `failed-step-continuation` transaction; a failed strict review similarly
-  binds remediation, Task pause and exact lease release, and a repeated authoritative reviewer cause
-  adds C1 yield before root-cause replan; the Signal-shaped E2E continues through recovery, the next
-  ordinary Step, Task completion, and next-Task dispatch;
-- five distinct or unclassified review findings continue in the same Task without a numeric cap,
-  while repeated normalized mechanical failures still require root-cause replan; a current
-  explicit external reviewer Plan conflict requires replan immediately, without a synthetic retry;
-- a transitive same-component check owner may refine the same Task only under the unchanged semantic
-  boundary; for a multi-Step `runtime-composition` consumer the independent PRA classification,
-  not a planner opt-in, requires an edge from a transitive owner to an exact executable consumer
-  check. A simple one-Step runtime is exempt; neither assertion claims semantic product truth or
-  P02/P01-B authority;
-- the machine-readable route matrix gives every one of the 13 Signal-observed route classes a
-  unique priority and one exact production transition witness or real terminal observation. The
-  `signal-observed-route-class-witnesses` boundary does not claim every action is exercised:
-  action-level metadata remains `executable-witnessed`, `unwitnessed`, or `unsupported`, and unknown
-  actions fail closed;
-- default `status` is a bounded route-exact projection and full historical state requires explicit
-  `status --full`;
-- reviewer runtime preflight is read-only for the sealed checkout and requires exact declared,
-  locked and repository-local installed Workflow versions plus a hash-verified runtime build manifest;
-  on every call it re-resolves the exact recursive runtime dependency graph from each actual parent
-  package (nested before hoisted) and re-hashes package manifests and executable runtime files, so a
-  warm Node module cache cannot hide a removed, changed, conflicting or symlink-redirected dependency;
-  the exact installed gateway, reviewer, and workflow modules are loaded synchronously through the
-  current Node runtime and must report exact package/protocol/schema versions; this avoids a child-process
-  scheduler deadline without caching a trust decision, and every load or contract failure still fails closed;
-  the native reviewer output schema is accepted by API strict Structured Outputs: every object property
-  is required, optional finding values use explicit nullability, and malformed semantic combinations fail closed;
-  a missing install, missing/stale build or failed handshake returns `prepared=false` with an
-  actionable blocker; every sealed review packet binds `ordinary` or `security` mode, and ordinary
-  review cannot imply a security scan;
-- package-owned operational preflights report worktree observation, watchdog, consent, and
-  coordinator-replacement facts without claiming Codex App scheduling, chat mutation, consent, or
-  atomic App effects.
-
-For beta.13.1 the same gate additionally verifies the post-publish compatibility boundary. A
-markerless pre-authority PRA whose Task has no production-edge fields remains readable and does not
-turn an intact beta.12 state into `STATE_CORRUPT`. Both ordinary and atomic corrective-replan PRA
-writers persist `structuralProductionEdgeAuthority=required-v1`; that hash-chained marker keeps the
-current-Plan structural gate fail-closed even if Task fields are removed. An audit belonging to an
-older Plan is never revalidated against a later Plan's Step/edge graph. This is not signed
-provenance: a privileged rewrite of the complete local Task and self-hashed chain remains outside
-the local-state trust model.
-
-For beta.12.19, the release gate also relies on `npm run release:check` to fail if:
-
-- canonical entity schema 2 shapes drift;
-- protocol 2 is not the active public contract, or intact protocol-1 adoption evidence stops being readable through the bounded compatibility window;
-- the delegated transition allow-list expands;
-- schema-2 adoption is presented as `state migrate` instead of posture sidecars;
-- alpha.7 rescue, Milestone autonomy (including guarded content refresh), derived actor, or
-  proof-obligation capabilities and schemas are absent from the packaged surface;
-- the truthful structural-replacement-disabled capability, project-level transaction recovery,
-  secret-safe lock diagnostics, version/base diagnostics, or serialized maintainer validation are missing.
-- truthful initial-assembly navigation capability is absent from the packaged surface.
-- corrective-yield/replan protocol-v2 commands, closed schemas, Human gate, retained journals,
-  explicit recovery, or dual-readback capabilities are absent from the packaged surface.
-- scoped Task navigation, credential replacement recovery, or sealed external Task/Step review
-  commands are absent from the packaged surface.
-- `task result-set` can enter the unbounded Human final-acceptance gate without consuming a live
-  writer credential and releasing its lease, or claimed Task E2E cannot reacquire a fresh merge credential.
-- bounded dependency-provenance recovery, retained passed-review provenance, the exact Signal T04
-  revision-26 fixture, or pending/corrupt-review rejection regressions are absent.
-- dependency recovery again requires Task-local manifest/lock fields to equal the Milestone base,
-  or a candidate commit can alter any non-Workflow dependency payload.
-- corrective replan drops completed Step evidence from accepted Task history, or an already-stranded
-  Task can register arbitrary/unreviewed history instead of one exact passed and previously accepted
-  Step commit.
-- beta.12.9 cannot install through an exact dependency-only base/Task transport while preserving the
-  active Step worktree, or that compatibility route fails to bind the dependency HEAD, historical
-  commit, current Plan/Step, dirty paths/content hash, and absence of leases/transactions.
-- the read-only Milestone progress projection, replacement regression, project-monotonic chat
-  registry, title fallback/readback, or long-Cyrillic multi-attempt E2E evidence is absent.
-- bounded first- or repeated-failure Plan-integrity recovery, selector-required npm-check
-  feasibility, exact failed-remediation/manifest/worktree
-  bindings, or the no-synthetic-second-failure regression is absent.
-- Plan-integrity update preflight again hard-codes one historical source release instead of deriving
-  a coherent exact beta.12 source from declared/locked/installed/current/base surfaces, or it accepts
-  a source before beta.12.11, a source not older than the runner, or any divergent version surface.
-- a direct migration check can import an external checksum/catalog authority without the producing
-  Step owning it; or in-flight recovery can widen beyond the exact imported support path, bypass
-  `forbiddenScope`, change the Plan hash, skip checks/Core commit/review disclosure, or require a
-  Human approval for the machine-proved scope-only correction.
-- historical check-support evidence is reinterpreted against a later Plan instead of the Plan hash
-  recorded by the event; or a post-rebind update is accepted without one planned Step explicitly
-  owning every previously derived support path in both `allowedWrites` and `expectedOutputs`, exact
-  dirty-byte continuity, coherent versions, and an otherwise idle recovery boundary.
-- downstream proof cannot invalidate only completed transitive-predecessor authority while
-  preserving worktree/HEAD, yielding C1, and returning the same Task to fresh planning; or unrelated
-  dirty files and damaged invalidation evidence do not fail closed.
-- an eligible active downstream proof cannot transport one exact dependency-only update across
-  aligned base/Task commits while preserving product bytes; or unknown history, unrelated dirty
-  scope, content drift within an observation, leases, transactions, and wider candidates do not
-  fail closed before provenance registration and ordinary downstream recovery.
-- the exact beta.12.6 post-invalidation Knowledge-rebind shape cannot pass a read-only source gate,
-  transport beta.12.7 through dependency-only commits, register provenance, restore `needs_fix`,
-  survive required Knowledge refresh, and reach a fresh replacement Plan;
-- preserved dirty bytes can execute without one Step owning the complete bound set, or HEAD/path/hash
-  drift is accepted; or the Signal-shaped E2E stops before checks, Core commit, strict Step review,
-  and fresh navigation to Task submission.
-- bundled gateway guidance treats Docker socket `EPERM` as daemon failure, consumes a remediation
-  attempt before one exact escalated probe, or recommends restarting Docker Desktop without separate
-  authority.
-- the P04-A Milestone dependency/initial-Plan transaction capabilities or the P01-A mechanical
-  feasibility capability is absent from the packaged handshake.
-- continuable guarded remediation or evidence-bound `fix`/`replan` review routing is absent, or a
-  third/later failed review is again converted into an attempt-count stop.
-- audited remediation can change Milestone outcome/success signal/acceptance/checks, omit or add
-  arbitrary predecessor authority, reuse one blocking audit, run with dirty/owned state, or stop
-  before the new Task merges and the original Task completes a subsequent Step.
-- `corrective-derived` Task authorization/final acceptance can exist without the current exact
-  Milestone execution authorization and audited-remediation event, or final Milestone acceptance is
-  derived automatically.
-- the append-only, Human-confirmed beta.11 attempt-four stop override, its exact three-event/
-  continue/stop binding, split rejection, stale-confirmation rejection, or tamper detection is
-  absent from the package.
-- an already-applied beta.11 stop override cannot survive a contiguous append-only chain of later
-  context-only Plan rebinds with exact mechanical audits, delegation, and chronology;
-- Git HEAD may advance between the override and current execution authorization through anything
-  except an exact chain of registered dependency-provenance commits that each change only
-  `package.json` and `package-lock.json`; or the route weakens the generic stale-decision recovery gate.
-- a dependency-provenance recovery recorded after the final mechanical audit cannot explain its
-  exact single Task revision, or an unrelated revision/damaged provenance is accepted as authority.
-
-The separate lifecycle transcript validator fails if the real-agent log contains a mutation that
-bypasses failed `status`/`next`, an unadvertised or failed mutation, an unresolved syntax-only
-retry, or missing post-mutation checkpoints.
-
-Full `npm test` and `npm run validate` invocations share destructive build outputs and are therefore
-single-owner operations. A concurrent invocation fails immediately with
-`VALIDATION_ALREADY_RUNNING`; retry it after the owner exits. Stale process locks are recovered
-automatically.
-
-Tag releases as `v<package-version>`. The tag workflow verifies the tag/package match and
-uses npm trusted publishing with public access. For a public GitHub repository and public
-package, npm trusted publishing generates provenance automatically. Publishing is never
-performed by local validation commands.
+# Current release policy
+
+## One contract, two outcomes
+
+The executable release contract is [scripts/release-contract.json](../scripts/release-contract.json). The passport verifier and qualification pipeline enforce its stages and freshness window. A green `release:check` means **automated candidate qualification only**. It always writes `releaseEligible: false`; it is never permission to publish.
+
+A complete passport needs the exact package version, clean commit SHA, tree and lockfile hashes, one retained tarball SHA-256, all automated evidence, original Codex App lifecycle evidence, and an independent reviewer. Missing, failed, stale, changed or foreign evidence blocks publication. The default evidence window is seven days; evidence dated in the future is invalid. Changing the candidate requires new qualification and App evidence. There is no old-version compatibility bypass.
+
+Use exactly **Node 24.17.0**. The runtime guard checks the actual process, package/lock engines, `.node-version`, `.nvmrc` and both CI jobs before validation writes. Record actual Node, OS platform, OS release and architecture; configuration alone is not execution evidence. Qualification supports POSIX hosts; the current target is macOS, with automated Linux CI. A green run on one host is not a portability claim.
+
+## Automated qualification
+
+Commit the complete candidate, including its current PDF. Install Node dependencies and the pinned PDF renderer, then run the full pipeline once:
+
+```sh
+npm ci
+python3 -m pip install -r docs/pdf/requirements.txt
+npm run release:check
+```
+
+When current guide sources change, first regenerate with `npm run docs:pdf`, inspect the rendered document and commit it. The mandatory `pdf-check` rebuilds the PDF deterministically with ReportLab 4.4.9 and the vendored fonts, compares actual bytes, and records source/generator/font/output hashes. The current source list and output are in the release contract. Historical PDFs are archived documents, not release evidence; they are not regenerated or included in the current guide.
+
+Required stages, in contract order: typecheck; fresh build; runtime build manifest; test compilation; every test file once; PDF freshness; one retained pack; installed downstream smoke using that exact pack; plugin validation; release assertions. Per-file evidence comes from the actual Node test runner and binds file, source hash and qualification ID. Partial inventories, failed/cancelled files, all-skipped files and reused receipts are rejected. Individual optional skips remain visible in the runner counts.
+
+The output is an owned `.release/` directory, excluded from Git and the npm package:
+
+- `passport.json`: exact candidate and references, initially without App evidence.
+- `candidate.tgz`: the single archive used by smoke, later App installation, and publication.
+- `automated.json`, per-file runner receipts, PDF/plugin/downstream reports: hashed evidence.
+
+A failed or interrupted qualification removes the previous passport before starting; it does not preserve an earlier green admission. Source changes during the run also invalidate the result. Do not prepend `validate` or another full suite; they repeat the same tests. `release:verify` consumes evidence and does not rerun the suite or repack.
+
+The supervisor reports stage deadlines, startup receipts and exit reasons. Do not increase waits or silently retry to manufacture green. Native pre-JavaScript startup stalls remain a separate host limitation. R2 remains open: an escaped detached descendant can survive a check timeout; `cleanupComplete` proves only the owned process group. These facts are not erased by qualification.
+
+## Original App evidence
+
+Run the disposable synthetic project in the real Codex App using the exact retained `candidate.tgz`. Do not run against the live consumer. Create a new Worker task and a separate independent reviewer task; preserve their original App records. The new Worker must resolve the installed gateway skill from its actual App catalog and record that selected path, skill hash and plugin-manifest hash; these must match the packed candidate. Hashing an arbitrary repository copy is not evidence of the loaded skill. Exercise installed gateway handshake, actual Task execution and completion, a sealed independent review and a later merged Task outcome. The reviewer must return its own original result, not a result authored by Worker or Coordinator.
+
+Capture the actual CLI log with `scripts/capture-lifecycle.mjs`, retaining command begin/end and successful status/next checkpoints. Preserve its candidate, archive, installed CLI/projector and capture-tool bindings. The full contract and evidence-envelope fields are documented in [release App evidence](release-app-evidence.md). The verifier calls the executable lifecycle validator and checks exact packet/seal hashes, independent identities, actual creation records and terminal continuation. It verifies the local validator's built projector dependency bytes against the same tarball; run `npm run build` in a fresh verification checkout first.
+
+The App provider currently supplies no cryptographic provenance used by this repository. Hashes and structural checks bind the candidate, **automated report hash**, original artifact bytes and lifecycle records; they do not independently prove that supplied JSON is a genuine App export. Original live records remain required, but no owner attestation, signature or signing key is required. Publication still requires separate explicit user authorization outside the evidence artifact.
+
+Copy the supplied App bundle into `.release/app/`, preserving its relative artifact paths, then attach it:
+
+```sh
+npm run release:passport -- --passport .release/passport.json --app .release/app/evidence.json
+npm run release:verify -- --passport .release/passport.json
+```
+
+Neither command requires a signing key. The attachment never infers publication consent or generates an App record. Missing live evidence is an actionable `RELEASE_APP_EVIDENCE_MISSING`, not a skipped test or a simulated success. Stored `releaseEligible` flags have no authority; verification recomputes eligibility from bytes every time.
+
+## Publication and CI
+
+PRs, `main`, `codex/**` pushes and manual validation run automated qualification without publish credentials. CI uploads the automated `.release/` bundle with an explicit incomplete-release warning. This artifact is useful for App qualification but cannot publish by itself.
+
+The separate Release workflow runs on a pushed `v<version>` tag. Before pushing that tag, push a data-only branch `release-evidence/v<version>` containing `bundle.zip` and `bundle.sha256` (the latter is one hexadecimal SHA-256). ZIP root must contain `passport.json`, `automated.json`, `candidate.tgz` and every referenced report/App file. The branch is transport, not an approval or signature: its hash detects corruption; the passport verifies the exact tag commit, version, tarball and all mandatory evidence. Missing branches, incomplete bundles and mismatched evidence fail publication. Evidence-branch code is never executed.
+
+Push the qualified candidate to `origin/main`, push its completed evidence branch, then push its release tag. The workflow checks archive integrity before safe extraction, rejects links/traversal/duplicates/oversized input, builds verifier dependencies only, verifies the complete passport and publishes the retained tarball. It never reruns qualification or repacks. Verify the published version and artifact hash through npm afterward. No manual dispatch, external HTTPS bundle hosting or mandatory GitHub environment is required.
+
+Removing the mandatory environment restores the earlier tag-push OIDC flow. The evidence checkout resolves the branch once to a commit and records that SHA in the job log. The workflow requests an OIDC token for npm trusted publishing. Existing registry authorization must allow this repository and workflow; a tag push does not create registry access. Failure to authenticate is a failed publication, never a reason to bypass the passport. No additional owner signature or environment approval is part of this release contract.
+
+For an explicitly authorized local release, set the exact `RELEASE_TAG`, then use:
+
+```sh
+npm run publish:release -- --passport .release/passport.json
+```
+
+The entry point re-verifies the passport, source, tag and packed package identity, copies already verified bytes into a private staging directory, checks the staging hash and publishes **that archive**. It never publishes a directory or repacks the checkout. Direct checkout `npm publish` is blocked by `prepublishOnly`. That hook prevents accidents; a credential holder can bypass npm hooks with `--ignore-scripts` or another client. The enforceable external boundary is registry credential/OIDC access, not a claim that repository code controls every npm client.
+
+## Remaining product limits
+
+The specific A1 and M04 route results retain their accepted scope. Broader A4 autonomy metrics, R2 escaped-session cleanup, native host startup diagnosis and any absent live App qualification remain explicit. Positive validator tests use temporary synthetic records; they test rejection/acceptance logic and never substitute for a real App run. A publication decision does not silently close these findings or demonstrate universal lifecycle completion.
+
+## 2.0.0-beta.14 candidate inventory
+
+The reproducible branch is `codex/release-candidate-beta.14`, based on tag
+`v2.0.0-beta.13.16` (commit `500c783d469f8c571a136c6763b7781091406cb1`).
+[The release inventory](beta14-release-inventory.json) maps each agreed change to ancestor commits,
+final files, test selectors and limitations. The final commit and actual receipts are recorded in
+the external qualification manifest after committing; this document does not claim a test result.
+
+Product graph is inactive: no missing/stale graph gate, refresh obligation or Knowledge approval
+is introduced. Existing schema/state fields remain readable. Installed-workflow and maintainer
+graphs retain separate exact source roots; provider ready alone does not prove source freshness.
+
+Protocol and state schema numbers remain 2, but the JSON Schema contracts do change: persisted
+Knowledge timestamps, pending base-sync validation and native/navigation carryover are represented.
+This is not a claim of unchanged schema or compatibility with every historical state. Before release,
+revalidate a fresh isolated Signal snapshot and its next allowed transition. Recovery preserves
+history and dirty bytes and requires renewed execution authority. Signal is not updated by assembly.
+
+R2 escaped detached descendants, broad A4 autonomy, native host startup stalls and graph freshness
+limitations remain open. Original App lifecycle/reviewer evidence remains mandatory and is not supplied by automated tests.
+Publication requires separate explicit user authorization, not a signed evidence field. No tag, publication or Coordinator
+instruction is authorized by this candidate assembly.