@kungfu-tech/buildchain 4.1.3-alpha.9 → 4.1.4-alpha.0

package/docs/release-discussions.md

@@ -1,20 +1,20 @@
 ---
-status: draft
+status: active
 period: ongoing
 theme: release-discussion-transactions
-doc_type: implementation-contract
-source_level: user-consensus
-confidence: medium
+doc_type: technical-reference
+source_level: local-files
+confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-12
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-12
-  visible_context: Release workflow implementation and agreed consumer Discussion transaction model.
-  invisible_context_boundary: Hosted token qualification and alpha publication are not claimed by this document.
+  generated_at: 2026-09-20
+  visible_context: Schema-2 consumer contract, pipeline and recovery entries, and internal release implementations.
+  invisible_context_boundary: No unobserved hosted publication or external consumer migration is claimed.
 ---
 
 # Release Discussion transactions
@@ -26,29 +26,15 @@ operations receive the exact Discussion ID. Categories have repository-specific
 IDs. Enable Discussions and retain the Announcements category before executing a
 release. A preview performs no Discussion reads or writes.
 
-The caller grants `discussions: write` to the reusable workflow job alongside its
-existing release permissions. The called workflow uses the consumer's automatic
-`GITHUB_TOKEN`. Checking out Buildchain does not change that repository or token.
-A reusable workflow cannot elevate the permissions granted by its caller.
-
-```yaml
-jobs:
-  release:
-    permissions:
-      contents: write
-      discussions: write
-      actions: write
-      id-token: write
-    uses: kungfu-systems/buildchain/.github/workflows/public-release-promote.yml@v4
-    with:
-      request-json: ${{ inputs.request-json }}
-      runtime-ref: ${{ inputs.runtime-ref || '' }}
-```
+The generated normal and recovery callers declare the required permissions,
+including `discussions: write`. Consumers use the shared caller pair; they do not
+write a separate Discussion workflow or pass transaction envelopes. The runtime
+uses the consumer repository's scoped authority. Checking out Buildchain does not
+change that repository identity, and a reusable workflow cannot elevate its
+caller's permission grant.
 
-This fragment illustrates the additional Discussion permission; retain other
-permissions required by the consumer's publication provider. The platform
-contracts are documented in GitHub's [reusable workflow reference](https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations)
-and [Discussions API guide](https://docs.github.com/en/graphql/guides/using-the-graphql-api-for-discussions).
+See [the minimal consumer contract](getting-started.md) for installation and
+[attempt recovery](bootstrap-recovery.md) for the only manual recovery input.
 
 ## Records and concurrency
 
@@ -152,42 +138,25 @@ same Discussion. It neither rewrites X's records nor changes the release intent.
 presentation, declared evidence and recovery contracts. `threads.js` checks
 provider placement; `presentation.js` renders contextual Markdown; `evidence.js`
 builds bounded attachment descriptors and diagnostic reports. `packages/core/providers/github/discussions` owns GitHub
-transport and immutable material IO. The existing public promotion workflow
-owns job boundaries; the Rust publication state machine still owns publication
+transport and immutable material IO. Internal pipeline and publication workflows
+own job boundaries; the Rust publication state machine still owns publication
 decisions and provider-effect ordering.
 
-The public Bootstrap API also exposes the `release-discussion` capability for
-consumer transport qualification and read-only diagnosis. Buildchain's existing
-Bootstrap dogfood caller accepts this request through its manual
-`request-json` input, preserving the same public entry and central
-runtime preparation as other consumers.
-
-## First publication with a selected runtime
-
-For Buildchain self-publication, dispatch `self-release-promote.yml` with the exact
-protected alpha `sha`, its `target-ref`, `dry-run: "false"`, and the desired
-`runtime-ref`. Leave recovery selectors empty for a first publication. The public
-publisher still verifies the protected source and obtains fresh hosted admission.
-`recover-durable-transaction` is reserved for an existing partial publication;
-it is not required merely because the selected runtime differs from the entry.
-
-## Resume by Discussion
-
-Pass `resume-discussion-id` in the public promotion request and select the repaired
-train through `runtime-ref`. Keep the protected target ref and source coordinates.
-The qualifier restores content-addressed candidate material, verifies original
-qualification, then re-observes providers before any remaining publication effect.
-Do not combine this selector with candidate-run or transaction-id recovery.
-
-When standalone binary distribution is requested, the intent also requires the
-`binary-distribution` node. Its separate workflow resolves the immutable locator
-from the public release, captures the active attempt, and appends provider readback
-to that attempt. A result arriving after recovery stays on the older attempt.
-The terminal publication receipt remains independently verifiable even while
-next-development or binary distribution is incomplete.
-
-The manual Bootstrap caller inherits the declared repository workflow permissions;
-the typed capability request must declare its own subset. `verifyMaterials: true`
-on a qualification request additionally tests draft Release asset retention using
-`contents: write`. The initial injected failure is intentional and leaves durable
-records for a subsequent runtime recovery probe.
+## First publication and recovery
+
+A legal channel PR expresses publication intent. The shared normal pipeline
+qualifies the exact protected source, materializes the version, builds declared
+products and performs publication through internal provider jobs. There is no
+consumer publication request JSON or separate self-release dispatch.
+
+For interruption recovery, select the exact attempt in `buildchain-recover.yml`.
+An optional repaired runtime may continue from its immutable records and sealed
+material. The runtime resolves the original Discussion and internal transaction;
+the consumer does not choose replacement Discussion, candidate-run, source or
+transaction coordinates.
+
+Publication, binary distribution and next-development have separate evidence.
+A terminal publication receipt does not imply the later required nodes have
+completed. Late provider results remain attached to their original attempt and
+cannot settle a successor. Historical receipts and their retained readers stay
+immutable when the current public entry changes.

package/docs/release-flow.md

@@ -6,378 +6,119 @@ doc_type: technical-reference
 source_level: local-files
 confidence: high
 sensitivity: public
-evidence_grade: A
+evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-05
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-05
-  invisible_context: not asserted
+  generated_at: 2026-09-20
+  visible_context: Schema-2 consumer contract, pipeline and recovery entries, and internal release implementations.
+  invisible_context_boundary: No unobserved hosted publication or external consumer migration is claimed.
 ---
 
 # Release Flow Diagrams
 
-This document describes v4 alpha publication and the legacy v3 release flow.
-See [Release governance](release-governance.md) for the design rationale.
+Consumers express intent through a legal channel PR. The generated normal entry
+owns delivery and publication; the generated recovery entry resumes an exact
+attempt. See [Release governance](release-governance.md).
 
 ## Architecture
 
 ```mermaid
 flowchart TD
-  Maintainer["Maintainer opens channel PR"]
-  Verify["Release - Verify"]
-  Review["Protected branch review"]
-  Merge["Merge PR into alpha or release"]
-  Promotion["Buildchain Ref Promotion"]
-  StableDecision{"Release channel?"}
-  StableGate["Stable only: exact-alpha canaries + soak + cooldown"]
-  Action["promote-buildchain-ref action"]
-  VersionState["Version-state commit"]
-  ExactTag["Exact tag"]
-  FloatingRefs["Floating tags and channel branches"]
-  Consumers["Consumers pin stable or exact refs"]
-
-  Maintainer --> Verify
-  Verify --> Review
-  Review --> Merge
-  Merge --> Promotion
-  Promotion --> StableDecision
-  StableDecision -->|yes| StableGate
-  StableDecision -->|no: alpha| Action
-  StableGate --> Action
-  Action --> VersionState
-  Action --> ExactTag
-  Action --> FloatingRefs
-  ExactTag --> Consumers
-  FloatingRefs --> Consumers
+  PR[Legal channel PR] --> Pipeline[Shared normal pipeline]
+  Pipeline --> Source[Exact source and product qualification]
+  Source --> Review[Independent review and protected merge queue]
+  Review --> Develop{Channel operation}
+  Develop -->|develop| Land[Protected development delivery]
+  Develop -->|alpha, stable or major| Version[Qualified version material]
+  Version --> Publish[Internal provider publication]
+  Publish --> Readback[Exact tags, package integrity and asset readback]
+  Readback --> Followup[Required distribution and next-development]
+  Followup --> Terminal[Verified terminal attempt]
+  Land --> Terminal
+  Recovery[Exact attempt recovery] --> Retained[Original source, records and sealed material]
+  Retained --> Remaining[Read providers and continue remaining work]
+  Remaining --> Terminal
 ```
 
-Buildchain treats the PR merge as release intent and the promotion action as the
-only component allowed to turn that intent into release refs.
-
-`StableGate` applies only to Buildchain's release channel. Alpha and train
-iteration bypass it. See [Stable Release Throttle And Canary Gate](release-governance.md#stable-release-throttle-and-canary-gate)
-for the versioned policy and evidence contract.
+This is an ownership diagram; exact stage dependencies belong to the runtime.
+The consumer does not dispatch each node or pass state between them. Product
+commands and artifact declarations are in TOML; provider effects and receipts
+are internal.
 
 ## Ref State
 
-| Ref kind | Example | Mutability | Purpose |
-| --- | --- | --- | --- |
-| Development branch | `dev/v4/v4.0` | moves | next source state for a minor line |
-| Alpha branch | `alpha/v4/v4.0` | moves | latest test state for a minor line |
-| Release branch | `release/v4/v4.0` | moves | latest production state for a minor line |
-| Major gate branch | `publish-gate/major` | moves | reviewed administrator gate for publishing the next major |
-| Exact alpha tag | `v4.0.3-alpha.0` | immutable | audit ref for one tested prerelease |
-| Exact release tag | `v4.0.2` | immutable | audit ref for one production release |
-| Floating alpha tag | `v4.0-alpha` | moves | latest test channel for a minor line |
-| Floating major alpha tag | `v4-alpha` | moves | latest test channel on the highest published alpha minor for a major line |
-| Floating minor tag | `v4.0` | moves | latest production patch on a minor line |
-| Floating major tag | `v4` | moves | selected stable major entrypoint |
-
-## Ref Protection Contract
-
-Repository rulesets must distinguish immutable evidence refs from mutable
-channel refs.
-
-Protect exact release and alpha tags as immutable evidence:
-
-```text
-refs/tags/v*.*.*
-```
-
-Do not apply immutable-tag rulesets to every `refs/tags/v*` ref. Buildchain
-must be able to update floating channel tags such as `v4`, `v4.0`, `v4.0-alpha`,
-and `v4-alpha` after the exact tag and publish evidence are valid. A ruleset that
-matches all `v*` tags also matches floating tags, so release finalization can
-fail with GitHub protected-ref errors even though the exact release tag and
-published artifacts are already durable.
-
-The intended governance split is:
-
-- exact tags such as `v4.0.2` and `v4.0.3-alpha.0` are immutable audit refs;
-- for publish transactions, the exact tag points to the transaction
-  `source_sha`, matching package-registry source metadata such as npm
-  `gitHead`; generated version-state commits remain on protected branches and
-  floating channel refs;
-- floating tags such as `v4`, `v4.0`, `v4.0-alpha`, and `v4-alpha` are mutable channel refs
-  owned by the Buildchain promotion token;
-- protected branches still require reviewed channel PRs before Buildchain can
-  move any exact or floating release refs.
-
-## Opening a Minor Line
-
-New minor lines should be opened through Buildchain instead of hand-created
-branches. The reusable entrypoint is the `Release Line Bootstrap` workflow. It
-defaults to dry-run so maintainers can inspect the planned refs, protection
-contract, initial version, and first alpha PR before any mutation.
-
-The workflow is backed by the CLI command:
-
-```bash
-buildchain release line open \
-  --major 4 \
-  --minor 1 \
-  --source-ref release/v4/v4.0 \
-  --json
-```
-
-When the workflow is run with `apply=true`, Buildchain:
-
-- writes the initial version-state commit, such as `4.1.0-alpha.0`;
-- creates `dev/v4/v4.1` from that commit;
-- creates `alpha/v4/v4.1` and `release/v4/v4.1` from the selected source ref;
-- applies branch protection with one approving review and the configured
-  required status check; dev starts strict, while alpha and release also require
-  the pair-specific `verify` aggregate without a source-up-to-date ancestry loop;
-- reconciles the new dev branch's explicitly declared merge queue, or inherits
-  the exact queue parameters and bypass actors from the current default dev
-  branch when the policy is `inherit` or absent;
-- switches the repository default branch to the new dev line when requested;
-- opens the first `dev/v4/v4.1 -> alpha/v4/v4.1` channel PR when requested.
-
-This makes minor-line creation a single audited operation. The channel PR still
-goes through the normal verify/review/promotion path before an alpha is
-published. Queue reconciliation runs after branch protection and before the
-default-branch switch, so a failed governance apply leaves the old active line
-in place and the idempotently created new refs can be retried.
-
-## V4 Alpha Publication
-
-The protected `dev/v4/v4.0 -> alpha/v4/v4.0` channel PR admits the source.
-Publication creates the immutable `v4.0.Z-alpha.N` tag and advances the eligible
-floating alpha refs to that published source. Its completed receipt and original
-Release Passport remain the publication authority.
-
-A separate protected next-development PR prepares `4.0.Z-alpha.(N+1)` on
-`dev/v4/v4.0`. Preparing that version does not publish another exact tag or move
-the alpha refs. A review, queue, or transient API failure in that PR leaves
-publication complete and next-development incomplete; recovery resumes the
-missing tail. Binary distribution has its own evidence and completion state.
-See [What each verification proves](#what-each-verification-proves).
-
-## Legacy V3 Alpha Promotion
-
-```mermaid
-sequenceDiagram
-  participant Dev as dev/vX/vX.Y
-  participant PR as PR dev -> alpha
-  participant Verify as Release - Verify
-  participant Alpha as alpha/vX/vX.Y
-  participant Promote as Buildchain Ref Promotion
-  participant Tags as Tags
-
-  Dev->>PR: open channel PR
-  PR->>Verify: run verification checks
-  Verify-->>PR: check succeeds
-  PR->>Alpha: reviewed merge
-  Alpha->>Promote: Verify workflow_run completed
-  Promote->>Promote: validate same-repo merged PR
-  Promote->>Promote: compute next vX.Y.Z-alpha.N
-  Promote->>Promote: write and verify version state
-  Promote->>Tags: create or reuse vX.Y.Z-alpha.N
-  Promote->>Tags: move vX.Y-alpha
-  Promote->>Tags: move vX-alpha when X.Y is the highest published alpha minor
-  Promote->>Alpha: move alpha/vX/vX.Y
-  Promote->>Dev: move dev/vX/vX.Y
-```
-
-Result:
-
-```text
-vX.Y.Z-alpha.N
-vX.Y-alpha
-vX-alpha when X.Y is the highest published alpha minor
-alpha/vX/vX.Y
-dev/vX/vX.Y
-```
-
-all point at the generated alpha version-state commit.
-
-## Legacy V3 Release Promotion
-
-```mermaid
-sequenceDiagram
-  participant Alpha as alpha/vX/vX.Y
-  participant PR as PR alpha -> release
-  participant Verify as Release - Verify
-  participant Release as release/vX/vX.Y
-  participant Promote as Buildchain Ref Promotion
-  participant Tags as Tags
-  participant Dev as dev/vX/vX.Y
-
-  Alpha->>PR: open channel PR
-  PR->>Verify: run verification checks
-  Verify-->>PR: check succeeds
-  PR->>Release: reviewed merge
-  Release->>Promote: Verify workflow_run completed
-  Promote->>Promote: validate same-repo merged PR
-  Promote->>Promote: find same-patch alpha tag
-  Promote->>Promote: compare release tree with tested alpha tree
-  Promote->>Promote: write final version state or verify anchored material
-  Promote->>Tags: create or reuse vX.Y.Z
-  Promote->>Tags: move vX.Y
-  Promote->>Tags: move vX when eligible
-  Promote->>Release: move release/vX/vX.Y
-  Promote->>Promote: prepare vX.Y.(Z+1)-alpha.0
-  Promote->>Tags: create or reuse vX.Y.(Z+1)-alpha.0
-  Promote->>Tags: move vX.Y-alpha
-  Promote->>Tags: move vX-alpha when X.Y is the highest published alpha minor
-  Promote->>Alpha: move alpha/vX/vX.Y
-  Promote->>Dev: move dev/vX/vX.Y
-```
-
-Result:
-
-```text
-vX.Y.Z
-vX.Y
-vX
-release/vX/vX.Y
-```
-
-point at the production version-state commit, while:
-
-```text
-vX.Y.(Z+1)-alpha.0
-vX.Y-alpha
-vX-alpha when X.Y is the highest published alpha minor
-alpha/vX/vX.Y
-dev/vX/vX.Y
-```
-
-point at the next alpha version-state commit.
-
-## Legacy V3 State Machine
-
-```mermaid
-stateDiagram-v2
-  [*] --> Development: work lands on dev/vX/vX.Y
-  Development --> AlphaCandidate: PR dev -> alpha
-  AlphaCandidate --> AlphaPublished: Verify + review + merge + promotion
-  AlphaPublished --> ReleaseCandidate: PR alpha -> release
-  ReleaseCandidate --> ProductionPublished: Verify + review + merge + promotion
-  ProductionPublished --> NextAlphaPrepared: prepare vX.Y.(Z+1)-alpha.0
-  NextAlphaPrepared --> Development: dev and alpha refs move to next alpha
-```
+| Ref kind | Example | Purpose |
+| --- | --- | --- |
+| Development branch | `dev/v4/v4.1` | reviewed source for the minor line |
+| Alpha branch | `alpha/v4/v4.1` | prerelease channel |
+| Release branch | `release/v4/v4.1` | stable channel |
+| Major gate branch | `publish-gate/major` | reviewed next-major intent |
+| Exact alpha tag | `v4.1.4-alpha.1` | immutable prerelease identity |
+| Exact stable tag | `v4.1.3` | immutable stable identity |
+| Floating alpha refs | `v4.1-alpha`, `v4-alpha` | published prerelease channel |
+| Floating stable refs | `v4.1`, `v4` | published stable channel |
 
-The same minor line can loop through this state machine many times.
+Examples illustrate ref shapes, not current provider observations. Tool-maintained
+locks bind qualified runtime identities separately from the source being built.
 
-## Legacy V3 Version Examples
-
-Assume `v3.0.2-alpha.1` has been tested and a maintainer merges
-`alpha/v3/v3.0 -> release/v3/v3.0`.
+## Ref Protection Contract
 
-Buildchain should produce:
+Exact release and alpha tags are immutable evidence. Mutable channel refs must
+remain distinguishable from exact tags in repository rules. A blanket immutable
+rule matching every `v*` tag would also prevent intended floating-channel updates.
 
-```text
-v3.0.2                  exact production tag
-v3.0                    floating minor tag
-v3                      floating major tag when v3.0 is the selected major line
-release/v3/v3.0         production channel branch
-```
+Protected branch movement remains subject to declared reviews and checks.
+Publication authority validates the recorded source/material identity before
+creating or advancing refs. An already-published immutable ref or asset cannot
+be overwritten to make a new attempt appear successful.
 
-It should also prepare:
+## Alpha and stable publication
 
-```text
-v3.0.3-alpha.0          exact next alpha tag
-v3.0-alpha              floating alpha tag
-v3-alpha                floating major alpha tag when v3.0 is the highest published alpha minor
-alpha/v3/v3.0           alpha channel branch
-dev/v3/v3.0             development channel branch
-```
+A development-to-alpha PR requests a fresh prerelease. An alpha-to-release PR
+requests stable publication. The selected runtime qualifies the source,
+materializes the version and publishes the declared products. Stable additionally
+checks its version-bound policy and published-entry evidence before publication.
+Buildchain's current minimum interval and soak are zero; see the
+[Stable Release Evidence Gate](release-governance.md#stable-release-evidence-gate).
 
-This is expected behavior. A production release closes one patch and opens the
-next test patch on the same minor line.
+Next-development is a follow-up with its own evidence. Stable completion prepares
+the next patch at `alpha.0` from the current protected development source without
+losing concurrent changes. Its [contract](next-development-transition.md) owns
+retry, source preservation and protected landing.
 
 ## Major Gate Promotion
 
-```mermaid
-sequenceDiagram
-  participant Release as release/vX/vX.Y
-  participant PR as PR release -> publish-gate/major
-  participant Verify as Release - Verify
-  participant Gate as publish-gate/major
-  participant Promote as Buildchain Ref Promotion
-  participant Tags as Tags
-  participant Next as dev/alpha/release v(X+1).0
-
-  Release->>PR: open administrator PR
-  PR->>Verify: run verification checks
-  Verify-->>PR: check succeeds
-  PR->>Gate: reviewed merge
-  Gate->>Promote: Verify workflow_run completed
-  Promote->>Promote: validate same-repo release -> publish-gate/major PR
-  Promote->>Promote: write v(X+1).0.0 version state
-  Promote->>Tags: create v(X+1).0.0
-  Promote->>Tags: move v(X+1).0 and v(X+1)
-  Promote->>Gate: move publish-gate/major to v(X+1).0.0
-  Promote->>Next: move release/v(X+1)/v(X+1).0 to v(X+1).0.0
-  Promote->>Promote: prepare v(X+1).0.1-alpha.0
-  Promote->>Next: move alpha/dev v(X+1).0 to next alpha
-```
-
-`publish-gate/major` is intentionally not an active source branch. It is the PR
-target for the administrator's "publish the next major" decision. The older
-`major-gate` name is a compatibility alias only.
+`release/vX/vX.Y -> publish-gate/major` expresses the next-major decision through
+the same reviewable PR interface. It does not add a consumer workflow, manual
+provider command or separate product-specific publish controller.
 
 ## Failure Boundaries
 
-Promotion should stop before moving refs when:
-
-- the run is a non-dry-run manual dispatch;
-- the expected same-repository PR cannot be found;
-- the PR was not merged;
-- the branch pair is not a valid channel path;
-- the required status check did not pass;
-- a release tree does not match the same-patch alpha tag tree, except for the
-  declared anchored/manual version files and anchor manifest that
-  `lifecycle.verify` or `verification-command` validates;
-- version-state verification fails;
-- a required exact tag already exists at a commit unrelated to the active
-  transaction or finalized channel head.
-
-These failures are intentional. They protect consumers from refs that look
-released but do not have a complete evidence chain.
+Missing or stale source authority, failed product verification, missing review,
+invalid branch pairs, ambiguous provider state and immutable collisions block
+the affected stage. Recovery uses the exact attempt and retained material.
+An optional repaired runtime changes execution implementation, not historical
+source, already-published bytes or receipt ownership.
 
-During transaction finalization recovery, the current channel head may be a
-generated version-state merge commit. Buildchain validates that the durable
-transaction version, exact tag, evidence, and release material match, and that
-the current target ref contains or corresponds to the recorded
-`release_material_sha`. It must then tolerate exact tags, dev refs, or alpha
-refs that have already moved and continue filling any missing floating tags
-before writing the transaction state as `complete`.
+The two public entries do not expose Discussion/run/transaction selector
+combinations. A new version is a new publication. Old failed versions can remain
+historical without being repaired or republished.
 
 ## What each verification proves
 
-| Evidence | Meaning and reuse boundary |
+| Evidence | Meaning |
 | --- | --- |
-| Full source execution | `pnpm run check` runs source tests, Rust gates, policy checks and generated artifact checks. Each Node test file runs once; the focused `check:contracts` command still includes its 22 contract test files. |
-| Merge queue proof | A successful full merge-group run seals its exact source SHA/tree, workflow, check definition, WASM runtime, toolchain versions, dependency locks, hosted image and platform. The proof expires after six hours and is verified against the completed GitHub run attempt and artifact archive digest. |
-| Push reuse | A Dev push may reuse that exact full execution. Its summary links the original run and proof; it does not claim to have rerun tests. Missing, failed, expired, ambiguous, tampered or unavailable evidence executes the full check. |
-| Version-state projection | Requires an authenticated full-source proof for the exact base and an ancestor-bound delta containing only declared version files and derived material. The base generator reconstructs every tracked byte, including derived digests. Any source, workflow, lock, configuration, file-mode or unexplained output change executes the full check. Projection results cannot issue a new full-source proof. |
-| Generated version-state check | `Version-state projection / <context>` describes generated material. It never uses a protected full-source check's name on v4. Required PR lineage, review and merge queue gates remain independent. |
-| Candidate qualification | Validates the sealed candidate, admitted runtime, source lock and publication authority. Source test reuse grants no provider mutation authority. |
-| Provider readback and settlement | Verifies actual tags, npm integrity, release assets and native receipt roots. Publication, next-development and binary distribution are reported separately. |
-
-The protected `check` context keeps its stable name while step names and summaries
-identify full execution, exact proof reuse, or generated projection. The two
-consumer-policy checks execute inside the root check, without duplicate Verify
-pre-steps. The root check uses the Rust-only contract command before its complete
-Node suite, removing 22 repeated test-file executions without removing tests.
-
-The public v4 consumer remains a thin floating-channel caller with both locks.
-Linux, macOS and Windows each execute the declared lifecycle, clean-process
-restore and runtime/source binding. Their platform and called-runtime identities
-differ from the source Verify lane, so a Linux source proof cannot replace them.
-The Stage Capsule checkpoint matrix also retains all three platforms. Shared
-platform-independent logic lives in the root check and public runtime; there is
-no Buildchain-only dogfood exception or persisted candidate runtime selector.
-
-A local Linux sample on 2026-09-05 measured the original full check at
-`a41c00a0c0b2dbd57c238cd9b326b167a1d27ca8` at 148.772 seconds and the updated check
-at 126.731 seconds, both exit 0. The original plan executed 226 Node test files
-plus 22 duplicate selections; the updated plan executes all 231 files once,
-including the new negative and recovery tests (2,047 tests). These are individual
-local measurements with existing tool caches; hosted queue/push reuse is proved
-separately by the exact run attempt and evidence roots in each job summary.
+| Local repository checks | source tests and generated consistency for the checked worktree |
+| Hosted source/platform qualification | exact source/runtime and required platform results |
+| Independent review and merge queue | protected landing of the admitted candidate |
+| Version material verification | declared version material agrees with its qualified source |
+| Provider readback | actual package, tags and Release assets agree with publication evidence |
+| Follow-up receipts | required distribution and next-development outcomes |
+| Terminal attempt | all required stages have verified terminal evidence |
+
+No earlier row substitutes for a later one. Reused proof must retain its original
+source and execution identity; a projection must not claim it reran a build.
+See [release discussions](release-discussions.md) for immutable attempt records.