@kungfu-tech/buildchain 4.1.0-alpha.0 → 4.1.0-alpha.2

package/docs/publication-artifacts.md

@@ -156,7 +156,7 @@ jobs:
       toolchain-type: config
       verify-command: make check
       artifact-name: observer-declared-timelines
-      buildchain-contract-lock-path: .buildchain/contract-lock.json
+      contract-lock: .buildchain/contract-lock.json
 ```
 
 The build-only workflow:
@@ -212,7 +212,7 @@ on:
 
 jobs:
   paper-release:
-    uses: kungfu-systems/buildchain/.github/workflows/public-release-paper.yml@<exact-buildchain-sha>
+    uses: kungfu-systems/buildchain/.github/workflows/public-release-paper.yml@v4
     permissions:
       actions: read
       checks: write
@@ -220,12 +220,11 @@ jobs:
       id-token: write
       issues: write
     with:
-      buildchain-ref: <exact-buildchain-sha>
       publisher-workflow-path: .github/workflows/public-release-paper.yml
       toolchain-type: config
       verify-command: make check
       artifact-paths: _build/paper-name.pdf
-      buildchain-contract-lock-path: .buildchain/contract-lock.json
+      contract-lock: .buildchain/contract-lock.json
     secrets:
       BUILDCHAIN_GENERATED_WRITE_APP_CLIENT_ID: ${{ secrets.BUILDCHAIN_GENERATED_WRITE_APP_CLIENT_ID }}
       BUILDCHAIN_GENERATED_WRITE_APP_PRIVATE_KEY: ${{ secrets.BUILDCHAIN_GENERATED_WRITE_APP_PRIVATE_KEY }}

package/docs/publication-authority.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-07-31
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -50,7 +50,7 @@ bound by the manifest digest but excluded from the product-byte set because it c
 be finalized after the lifecycle scan. The verifier also compares the PR evidence tree to the
 admitted post-merge source commit tree. It rejects an unknown
 workflow, stale or replayed nonce, runner downgrade, control-plane drift,
-source/runtime mismatch, and artifact substitution. A successful result is a
+source mismatch, and artifact substitution. A successful result is a
 scoped capability receipt, not a bearer credential.
 
 ## Runner and control-plane evidence

package/docs/release-candidate.md

@@ -111,11 +111,10 @@ finished uploading evidence, the resolver waits up to ten minutes for the exact
 merged PR's successful workflow run and paired artifacts. Polling remains bound
 to the PR/head identity; timeout or a sibling run still fails closed.
 
-The public promotion router preserves the requested `vN` or `vN-alpha` ref as
-audit metadata, but binds the router to GitHub's selected reusable-workflow SHA
-and resolves each remaining floating shell/runtime ref exactly once. Every
-later checkout and delegated promotion receives those immutable SHAs, so a
-channel tag moving during the run cannot mix two Buildchain revisions.
+The public promotion entry selects one execution runtime through the shared
+[Runtime entry contract](runtime-entry.md). Entry and execution commits may differ.
+Every later job prepares that selection without resolving another Buildchain ref
+or checking entry/runtime SHA equality.
 
 ## Resume from an existing candidate run
 
@@ -139,12 +138,10 @@ on:
       candidate-run-id: { required: true, type: string }
       target-sha: { required: true, type: string }
       expected-tree: { required: true, type: string }
-      candidate-runtime-sha: { required: true, type: string }
-      buildchain-runtime-sha: { required: true, type: string }
-
+      runtime-ref: { required: true, type: string }
 jobs:
   resume:
-    uses: kungfu-systems/buildchain/.github/workflows/public-release-promote.yml@<exact-current-buildchain-sha>
+    uses: kungfu-systems/buildchain/.github/workflows/public-release-promote.yml@v4
     permissions:
       actions: write
       checks: write
@@ -153,22 +150,20 @@ jobs:
       pull-requests: write
     secrets: inherit
     with:
-      buildchain-ref: ${{ inputs.buildchain-runtime-sha }}
-      channel: alpha
-      target-ref: alpha/v3/v3.0
-      target-sha: ${{ inputs.target-sha }}
-      artifact-name: product
-      artifact-patterns: product-package-*
-      release-candidate-workflow-file: build.yml
-      release-candidate-workflow-name: Build
-      resume-candidate-repository: ${{ github.repository }}
-      resume-candidate-run-id: ${{ inputs.candidate-run-id }}
-      resume-expected-workflow-file: build.yml
-      resume-expected-workflow-name: Build
-      resume-expected-source-tree: ${{ inputs.expected-tree }}
-      resume-expected-candidate-runtime-sha: ${{ inputs.candidate-runtime-sha }}
-      resume-buildchain-runtime-sha: ${{ inputs.buildchain-runtime-sha }}
-      publish-transaction-override: true
+      runtime-ref: ${{ inputs.runtime-ref }}
+      request-json: >-
+        {"schema":"buildchain.promotion-request/v1",
+        "channel":"alpha", "target-ref":"alpha/v4/v4.1",
+        "target-sha":${{ toJSON(inputs.target-sha) }},
+        "artifact-name":"product", "artifact-patterns":"product-package-*",
+        "release-candidate-workflow-file":"build.yml",
+        "release-candidate-workflow-name":"Build",
+        "resume-candidate-repository":${{ toJSON(github.repository) }},
+        "resume-candidate-run-id":${{ toJSON(inputs.candidate-run-id) }},
+        "resume-expected-workflow-file":"build.yml",
+        "resume-expected-workflow-name":"Build",
+        "resume-expected-source-tree":${{ toJSON(inputs.expected-tree) }},
+        "publish-transaction-override":true}
 ```
 
 `resume-expected-candidate-root` may replace `resume-expected-source-tree`, or
@@ -321,8 +316,7 @@ and payload bytes. It can read those inputs through
 permission, or provider write permission. Buildchain validates the aggregate
 digest and exact source binding before it seals a capability. Exactly one of
 the supplied aggregate, consumer command, or explicit no-Gate decision is
-allowed. Buildchain still requires caller-owned RC evidence, an exact authority
-runtime and source SHA, a repository-local publisher workflow, matching npm
+allowed. Buildchain still requires caller-owned RC evidence, an exact source SHA and prepared execution runtime, a repository-local publisher workflow, matching npm
 target/package identity or exact caller-bound GitHub Release target, and a
 qualifying control-plane audit.
 

package/docs/release-governance.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-09-08
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-6
   product: Codex
@@ -250,7 +250,7 @@ Two independent thin workflows continuously qualify the published channels.
 runs the root project's real install, build, and verify lifecycle.
 `self-build-stable-dogfood.yml` calls `build.yml@v4` with only the nested fixture's
 `config-path`, including native and Linux container builds. Project settings
-live in TOML; the called workflow binds its exact runtime SHA and configuration
+live in TOML; the selected runtime records its execution SHA and configuration
 root into the build receipts. Separate workflow validation allows each channel
 to advance independently during a breaking producer-first release.
 
@@ -631,12 +631,12 @@ complete interface are bound into `contractRoot`; the receipt additionally
 binds the caller commit/tree and both workflow digests.
 
 ```sh
-node .buildchain/workflow-contract-runtime/packages/core/contracts/commands/workflow-call-contract.mjs check \
+node .buildchain/runtime/packages/core/contracts/commands/workflow-call-contract.mjs check \
   --caller-root . \
   --caller-workflow .github/workflows/self-release-new-version-compat.yml \
   --caller-repository kungfu-systems/example \
   --job promote \
-  --callee-root .buildchain/workflow-contract-runtime \
+  --callee-root .buildchain/runtime \
   --callee-workflow .github/workflows/public-release-promote.yml \
   --callee-repository kungfu-systems/buildchain \
   --trusted-event workflow_dispatch \
@@ -645,11 +645,11 @@ node .buildchain/workflow-contract-runtime/packages/core/contracts/commands/work
   --output .buildchain/workflow-call-receipts/release-new-version.json
 ```
 
-The checkout at `.buildchain/workflow-contract-runtime` must use the same
-40-character SHA written in the caller's `uses:` edge. To accept an intentional
-contract change, first run without `--expected-contract-root`, review the full
-diagnostic and exact coordinates, then replace only the committed root. The
-ordinary PR check runs this command before any candidate or promotion dispatch.
+Use the runtime prepared by the central entry for this offline contract audit.
+The caller persists a floating entry; its resolved API definition is distinct
+from the selected execution runtime. To accept an intentional contract change,
+review the full diagnostic and source coordinates before replacing the committed
+contract root. This audit does not add a runtime-SHA equality gate to execution.
 Local pre-commit rehearsal may add `--allow-dirty`; that result is marked
 `receiptReusable: false` and cannot replace the clean exact-source receipt.
 
@@ -662,7 +662,7 @@ command = "cargo test --workspace --locked"
 ```
 
 Consumers that want Buildchain to own the check wrapper can call
-`.github/workflows/public-build-check.yml@v3`. The wrapper runs the declared
+`.github/workflows/public-build-check.yml@v4`. The wrapper runs the declared
 `lifecycle.install` and `lifecycle.verify` stages and fails the `check` job when
 either declaration is missing or the command exits non-zero.
 

package/docs/release-promotion-request.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-09
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-6
   product: Codex
@@ -43,22 +43,15 @@ Serialize dynamic values with `toJSON` so quotes, newlines, numbers and booleans
 retain their original meaning. Permissions remain an explicit caller responsibility;
 an input cannot grant a job credentials or provider authority.
 
-The public workflow resolves identities, admits the consumer and calls the current
-publisher component. The admission node creates one complete internal
+The public workflow selects one runtime through the central runtime entry, admits
+the consumer source and constructs the internal
 [`promotion-invocation-v1.schema.json`](../contracts/promotion-invocation-v1.schema.json)
-document containing the exact router, publisher, runtime, contract lock and any
-independently authorized transient runtime selection. The component verifies that
-document before loading the selected runtime, then runs QUALIFY, APPLY and SETTLE
-with their separate job permissions.
+document. QUALIFY, APPLY and SETTLE prepare that selected runtime and retain their
+separate job permissions. Later nodes validate source, artifact and publication
+evidence without comparing Buildchain SHAs.
 
-Consumer repositories adopt this API when the selected distribution channel
-contains it. Development self-calls use the source-owned public entry so that
-the definition and request contract come from the same reviewed commit. This
-development arrangement does not move a floating tag or publish an alpha package.
-
-The source-owned promotion API uses the caller's exact defining commit. Its
-consumer lock roots describe published external dependencies; they do not claim
-that the new local API is compatible with a previously published workflow. The
-source-owned path authenticates Git content instead of granting a historical
-compatibility exception. External floating calls still require selected-lock
-compatibility with the resolved public workflow.
+Buildchain dogfood and external consumers use the same `@v4` or `@v4-alpha`
+public entry. The entry commit owns the API shell; the selected runtime owns
+business actions, modules and resources. A transient `runtime-ref` can select a
+repaired train while preserving the original publication source and evidence.
+See [Runtime entry](runtime-entry.md) for selection precedence and recovery.

package/docs/release-propagation.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-09-09
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-6
   product: Codex
@@ -520,10 +520,9 @@ branch or a concurrent incompatible update fails; the workflow does not replace
 its history. The controller retains the exact branch reconciliation and PR
 coordinates.
 
-The workflow checks out the Buildchain runtime selected by
-`buildchain-repository` and `buildchain-ref` into `.buildchain/runtime`, invokes
-that runtime for the propagation plan and lock write, then checks out the
-downstream repository and writes the exact lock. If
+The central entry prepares `.buildchain/runtime` once for each execution job.
+The selected runtime owns the propagation plan and lock write; the downstream
+repository checkout is the consumer source. If
 `downstream-update-command` is set, Buildchain runs that consumer-owned command
 after writing the lock and exposes the exact lock path, lock SHA-256,
 propagation key, branch, and upstream release JSON as
@@ -550,7 +549,7 @@ publication, deployment, and readback entrypoints. A byte-identical rerun is an
 explicit successful no-op, never a synthetic completion.
 
 For unreleased runtime validation, keep the caller's reusable workflow reference
-on `@v3` and pass a temporary train ref through `buildchain-ref`.
+on `@v4` and pass a temporary train through `runtime-ref`.
 
 ## kfd to site-libkungfu-dev
 

package/docs/release-tail-provider-plane.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-08-07
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -55,9 +55,8 @@ jobs:
   release-tail:
     permissions:
       contents: write
-    uses: kungfu-systems/buildchain/.github/workflows/public-release-tail.yml@<exact-buildchain-sha>
+    uses: kungfu-systems/buildchain/.github/workflows/public-release-tail.yml@v4
     with:
-      buildchain-ref: <exact-buildchain-sha>
       declaration-path: .buildchain/release-tail/declaration.json
       provider-bindings-path: .buildchain/release-tail/provider-bindings.json
       execute: true

package/docs/reusable-build-surface.md

@@ -34,11 +34,16 @@ jobs:
     uses: kungfu-systems/buildchain/.github/workflows/build.yml@v4
 ```
 
-Use `@v4-alpha` to select the alpha runtime. The exact called workflow SHA is
-the runtime SHA; a second runtime selector cannot override it. Both the public
-`build.yml` and the `.build.yml` backbone expose exactly one optional input:
-`config-path`. Neither accepts command overrides, runtime refs, arbitrary JSON
-configuration or legacy aliases.
+Use `@v4-alpha` for the alpha entry. The entry selects the execution runtime
+from a transient `runtime-ref`, the selected `contract-lock`, or its own commit
+by default. The build API also accepts `config-path` and `resume-run-id`;
+`runtime-selection` transports the entry decision through nested workflows.
+All project commands and build options remain in TOML.
+
+A new recovery dispatch can pass a repaired train and the original failed run
+ID through the same entry. It restores matching retained build outputs, executes
+remaining verification and reads back provider effects. An entry defect requires
+an upgraded published entry and a full run. See [Runtime entry](runtime-entry.md).
 
 ## Project discovery
 
@@ -118,8 +123,9 @@ Other optional project sections are:
 | `build.evidence` | Repository files containing gate and candidate-family evidence |
 
 Declarative signing targets continue to belong to `[signing.artifacts]`.
-The 4.1 formal signing contract requires `authority/v4/v4.1/artifact-signing`
-with the protected `buildchain-artifact-signing` environment.
+Signing uses `public-release-signing-authority.yml@v4`, passes the selected runtime
+through its runtime parameter and retains the protected
+`buildchain-artifact-signing` environment.
 Credentials, authority profiles and signer identities cannot be supplied through
 that declaration. See [Release Candidate](release-candidate.md)
 and [GitHub Artifact Attestation](github-artifact-attestation.md).

package/docs/runtime-entry.md

@@ -0,0 +1,122 @@
+---
+status: draft
+period: ongoing
+theme: unified-runtime-entry
+doc_type: implementation-contract
+source_level: user-consensus
+confidence: high
+sensitivity: public
+evidence_grade: B
+review_state: unreviewed
+last_reviewed: 2026-09-11
+ai_provenance:
+  model_family: GPT-6
+  product: Codex
+  generated_at: 2026-09-11
+  visible_context: Explicit user-approved runtime selection, recovery and alpha publication requirements.
+  invisible_context_boundary: This contract does not claim implementation or hosted qualification is complete.
+---
+
+# Runtime entry contract
+
+Consumers persist a public workflow reference at `@v4` or `@v4-alpha`.
+GitHub resolves that entry to a commit. The entry selects execution runtime X
+from an explicit transient parameter, the selected contract lock, or the entry
+commit default, in that order. The entry commit and runtime commit may differ.
+
+`actions/runtime/environment/prepare` is the sole runtime preparation owner.
+Selection is resolved once per execution. Each executing job prepares that
+selected runtime through the same implementation. Business workflows and
+actions cannot acquire, replace, reselect or install their own Buildchain
+runtime. All business composites, JavaScript modules, WASM and resources come
+from X. Runtime identity is retained as provenance; subsequent business nodes
+do not compare Buildchain SHAs or require equality with the workflow commit.
+
+A runtime failure can start a recovery execution through the same public
+entry with a transient repaired train branch or tag. The new execution selects
+runtime Y and retains the original task, source and evidence. Valid completed
+results can be reused; provider effects require readback before further writes.
+Switching runtimes does not automatically qualify all previous results for reuse.
+Neither the persisted caller nor its contract lock needs a train rewrite.
+
+An entry failure is repaired by publishing and adopting a corrected entry and
+starting a complete run. Recovering an invalid entry is not a runtime feature.
+Buildchain self-dogfood uses exactly the same consumer contract and has no
+repository-specific execution or recovery route.
+
+Source checkouts are separate business inputs. Building Buildchain itself may
+check out its source, but that source cannot implicitly replace the selected
+execution runtime. Source, artifact and publication-effect checks retain their
+business meaning; they do not reintroduce downstream Buildchain SHA checks.
+
+Acceptance requires a complete workflow/action acquisition inventory, enforced
+single preparation ownership, different entry/runtime execution, train recovery,
+platform and multi-job qualification, and validation of the published consumer
+entry. A source test or a successful package import alone is insufficient.
+
+## Consumer build and recovery
+
+```yaml
+on:
+  push:
+  workflow_dispatch:
+    inputs:
+      runtime-ref:
+        description: Optional repaired train for this execution
+        default: ""
+        type: string
+      resume-run-id:
+        description: Original failed build run to recover
+        default: ""
+        type: string
+jobs:
+  build:
+    uses: kungfu-systems/buildchain/.github/workflows/build.yml@v4
+    with:
+      runtime-ref: ${{ inputs.runtime-ref || '' }}
+      resume-run-id: ${{ inputs.resume-run-id || '' }}
+```
+
+Ordinary executions use `.buildchain/contract-lock.json`; the alpha entry defaults
+to `.buildchain/alpha-contract-lock.json`. `contract-lock` selects another relative
+lock path. A missing default lock falls back to the entry commit; an invalid lock
+or an unreadable source fails preparation. A supplied runtime parameter overrides
+the lock and requires caller repository write authority. For `workflow_dispatch`,
+GitHub enforces repository Actions write permission before creating the run,
+including calls using installation tokens. The entry uses that authorization;
+an installation bot does not need to be a human repository collaborator.
+Other event types retain the entry's write, maintain or admin collaborator check.
+See GitHub's [workflow dispatch authorization](https://docs.github.com/en/rest/actions/workflows#create-a-workflow-dispatch-event).
+Branches and tags are resolved to an immutable commit during selection.
+
+For a Buildchain runtime fault, dispatch the same consumer workflow with
+`runtime-ref: train/v4/v4.1/<repair>` and the original `resume-run-id`. The entry
+retains the original source commit and rejects unrelated workflows or fork runs.
+Install hydrates the new workspace; completed build outputs are restored only
+when source, configuration, platform, tools, artifact producer and all retained
+bytes qualify. The remaining verification runs with the repaired runtime.
+Existing provider effects use their transaction evidence and live readbacks.
+A failed-job rerun cannot supply new inputs; recovery therefore starts a new run.
+
+`runtime-selection` is an internal reusable-workflow transport for an already
+selected runtime. Components forward it unchanged instead of resolving another
+reference. Consumers normally supply `runtime-ref` or a lock, not this transport.
+
+Nested components preserve the selected runtime and contract metadata without
+re-reading the lock or comparing the runtime SHA. The internal transport carries
+a trusted entry output; consumer source binding and override authorization remain
+entry concerns. Recovery selectors request `actions: read` to read the original
+run in private repositories as well as public repositories.
+
+Business adapters also keep the runtime installation directory separate from the
+consumer workspace. Queue reconciliation, npm preview, runner qualification and
+binary packaging read consumer source from the workspace while executing selected
+runtime code. Directory equality is not an admission rule; source SHA and artifact
+containment checks still apply. The architecture gate parses business JavaScript
+and rejects direct or aliased runtime/source directory equality comparisons.
+
+Publication authority adapters take runtime repository and revision provenance
+from the prepared entry selection. Consumer requests provide source, artifact
+and effect authority; they do not supply or readmit a Buildchain SHA. Governance
+and sealed publication evidence retain the selected runtime as provenance while
+validating their own source, policy and provider bindings.

package/docs/runtime-train-validation.md

@@ -18,44 +18,33 @@ ai_provenance:
 
 # Runtime Train Validation
 
-Ordinary builds use the public `build.yml@v4` or `build.yml@v4-alpha`
-workflow and select all project settings from `buildchain.toml`. The called
-workflow SHA also selects the runtime; there is no second runtime selector.
-See [Reusable Build Surface](reusable-build-surface.md) for configuration,
-zero-input calls and the optional nested-project locator.
-
-## Alpha qualification
-
-Buildchain changes enter the protected development branch after review and
-checks. Publish an alpha through the protected release workflow, then exercise
-that public alpha on the exact consumer source. Record the called workflow SHA,
-source SHA, channel-matching contract lock, configuration root and artifact
-manifests. Promote stable only after the required alpha evidence succeeds.
-
-For a breaking build-interface change, publish the producer before changing
-its own public consumers. Retain the callers and locks for the currently
-published interface while creating the first alpha from a successful PR-stage
-candidate. Then migrate the callers and accept the published alpha contract,
-qualify that public interface, and publish the completed alpha and stable.
-This ordering adds no compatibility inputs to the new build workflow.
-
-Source checks verify each consumer lock against the immutable source contract
-at its accepted SHA. Hosted consumer admission separately verifies the actual
-called floating workflow; unpublished producer code is not that dependency.
-
-A train branch is a temporary diagnostic pointer, never a release channel or a
-persisted consumer dependency. Ordinary builds do not accept train, SHA or
-`buildchain-ref` inputs. Initialization does not create a runtime pass-through.
-
-## Specialized release and recovery
-
-Release and recovery entry points retain their own bounded runtime admission
-contracts. Their runtime override capability does not extend to ordinary builds.
-Follow [Release Flow](release-flow.md) and the particular entry point's contract;
-a diagnostic train does not authorize publication, signing, or floating-ref
-movement. Preserve existing source locks, exact candidate lineage and terminal
-receipts when recovering a release.
-
-The Buildchain self-build callers exercise the public floating channels using
-root or fixture TOML. They do not commit a private runtime selector to qualify
-that channel.
+A train repairs the execution runtime without changing the consumer's durable
+public entry. All public workflows, including ordinary builds, use the same
+[Runtime entry contract](runtime-entry.md). The transient runtime parameter
+wins over the consumer lock. Buildchain dogfood follows this same path.
+
+## Validate a runtime change
+
+1. Commit the candidate with its action bundles, WASM and runtime contract.
+2. Publish the candidate at `train/v4/v4.1/<capability>`.
+3. Dispatch the consumer's existing public entry with `runtime-ref` set to that
+   train. Record the selected runtime, consumer source and resulting evidence.
+4. After checks and independent review, merge into protected Dev and publish
+   the requested Alpha. Qualify the published entry before Stable promotion.
+
+Train selection is a trusted non-persistent runtime input. It never grants
+publication or signing authority by itself; those business effects retain their
+provider credentials, capability constraints and readback requirements.
+
+## Recover a runtime failure
+
+Start a new dispatch through the same public entry with the repaired train.
+For builds, supply `resume-run-id`; for release promotion, preserve the original
+candidate run and transaction in the typed request. The entry prepares runtime
+Y while the task keeps its original source and valid completed evidence.
+A GitHub failed-job rerun does not change its inputs and cannot select a new
+runtime. Do not persist the train into the caller workflow or contract lock.
+
+If the public entry itself is defective, publish and adopt the corrected entry
+and start a full run. Copied consumer recovery packages and alternate recovery
+workflows are not part of the runtime contract.

package/docs/v4-publication-rehearsal.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: self-reviewed
-last_reviewed: 2026-08-16
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -107,13 +107,13 @@ effect_default = "disabled"
 The public reusable
 [`public-release-tail.yml`](../.github/workflows/public-release-tail.yml) accepts the same
 capsule, candidate root, mode, state and evidence paths. Before publication,
-Buildchain dogfoods that public surface through a thin same-commit local reusable
-call with the exact PR-head or dispatch SHA as its runtime. The reusable is
+Buildchain dogfoods that public surface through the same floating `@v4` entry
+as external consumers. The shared entry selects the runtime from the transient
+parameter, consumer lock, or entry default, and prepares it in each job. The reusable is
 permission-neutral and the self-dogfood caller stays `contents: read`, passes
 `execute: false`, and therefore cannot inherit or synthesize production write
 authority. Effectful production callers must explicitly declare their own
-provider permission. Durable external consumers remain on the floating
-`@v4-alpha` contract. Provider mode additionally requires the exact authority
+provider permission. Durable external consumers use `@v4` or `@v4-alpha`. Provider mode additionally requires the exact authority
 path. Provider bindings come from the capsule; an optional external bindings
 input is accepted only when its canonical exact root and payload equal the
 capsule binding. Ordinary calls default to `simulate`.

package/docs/v4-stage-capsule.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-08-10
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -122,7 +122,7 @@ access and produce the same ordered decisions and `planRoot`.
 
 An eligible completed dependency becomes an exact-root restore; a missing or
 invalid target becomes a rebuild, and only that target's dependency closure is
-scheduled. Source, platform, toolchain, runtime, policy, declared-input,
+scheduled. Source, platform, toolchain, policy, declared-input,
 transformation, output-manifest, and retention changes carry rooted causal
 invalidation fields. Cross-platform reuse, corrupt or partial content, root
 mismatch, and insufficient qualification reject reuse fail closed.
@@ -139,13 +139,11 @@ Buildchain-owned public reusable workflow,
 `.github/workflows/public-build-stage-capsule-canary.yml`. Buildchain's caller is the thin
 `.github/workflows/self-build-public-consumer-dogfood.yml`; it has no steps, copied
 orchestration, local action, direct qualification invocation, or private
-consumer profile. Candidate recursion is resolved only by publishing the exact
-candidate at `train/v4/v4.0/<capability>` and calling that fully qualified
-public ref. After successful qualification and protected merge, the caller can
-be pinned to the exact protected commit. An internal exception is never a
-permitted recursion mechanism.
+consumer profile. The persisted caller uses `@v4`. Candidate validation passes
+`train/v4/v4.1/<capability>` as the transient `runtime-ref` input, through the
+same central selection and preparation entry as external consumers.
 
-The called workflow checks out that same commit as its runtime, reads the consumer's
+The called workflow prepares the selected runtime and reads the consumer's
 tracked `.buildchain/buildchain.toml`, and executes only `install`, `build`,
 and `verify` on GitHub-hosted Linux x64, macOS arm64, and Windows x64 runners.
 Each stage binds its declared command, dependency edge, exact consumer source,
@@ -157,8 +155,9 @@ paths; it does not copy the campaign orchestration.
 The external seed retains `install` and `build` before an intentional late
 `verify` failure. A clean process reads the retained store, restores only the
 exact `build` root, rebuilds `verify`, and compares the result with the fresh
-three-stage aggregate. Runtime-ref, source, command/profile, manifest, summary,
-output, platform, and Capsule-root drift all stop with typed diagnostics.
+three-stage aggregate. A repaired runtime may continue the campaign. Source,
+command/profile, manifest, summary, output, platform and Capsule integrity drift
+still stop with typed diagnostics; runtime provenance does not invalidate reuse.
 
 Qualification compares the declared artifact-manifest and aggregate content
 roots from a fresh full build with the roots assembled from retained and rebuilt