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

package/docs/release-promotion-request.md

@@ -1,57 +1,59 @@
 ---
 status: draft
 period: ongoing
-theme: release-promotion-api
-doc_type: manual
+theme: internal-release-promotion-request
+doc_type: technical-reference
 source_level: local-files
 confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-11
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-09
-  visible_context: Current promotion workflows, JSON schemas, request binding implementation and focused tests.
-  invisible_context_boundary: No alpha publication or production promotion was performed.
+  generated_at: 2026-09-20
+  visible_context: Current workflow taxonomy, shared consumer entries, internal promotion components and request schemas.
+  invisible_context_boundary: This source documentation does not claim a new hosted publication or external consumer migration.
 ---
 
-# Release promotion request
-
-`public-release-promote.yml` is the public API. Its single `request-json` input
-uses [`promotion-request-v1.schema.json`](../contracts/promotion-request-v1.schema.json).
-The schema owns field types and defaults. Unknown fields, stringified booleans,
-historical command hooks and caller-supplied internal authority fields are rejected.
-
-```yaml
-jobs:
-  promote:
-    uses: kungfu-systems/buildchain/.github/workflows/public-release-promote.yml@v4-alpha
-    with:
-      request-json: |
-        {
-          "schema": "buildchain.promotion-request/v1",
-          "target-ref": "alpha/v4/v4.1",
-          "target-sha": ${{ toJSON(github.sha) }},
-          "dry-run": true
-        }
-    secrets: inherit
-```
-
-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 selects one runtime through the central runtime entry, admits
-the consumer source and constructs the internal
+# Internal release promotion request
+
+Consumers declare products and legal channel routes in
+`.buildchain/buildchain.toml`. The generated `buildchain.yml` caller invokes
+`public-ops-pipeline.yml`; a channel PR expresses release intent. Consumers do
+not construct a promotion request or add a promotion workflow. See the
+[Golden Path](getting-started.md) for the shared normal and recovery entries.
+
+## Internal schemas and components
+
+The advanced promotion implementation retains
+[`.release-candidate-promote.yml`](../.github/workflows/.release-candidate-promote.yml)
+and [`.release-promote.yml`](../.github/workflows/.release-promote.yml) as
+internal components. Their `request-json` transport is an implementation
+boundary, not a consumer configuration extension.
+
+[`promotion-request-v1.schema.json`](../contracts/promotion-request-v1.schema.json)
+owns the internal request field types and defaults. Unknown fields,
+stringified booleans, historical command hooks and unadmitted authority fields
+are rejected. The request binder constructs a normalized
 [`promotion-invocation-v1.schema.json`](../contracts/promotion-invocation-v1.schema.json)
-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.
-
-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.
+document. QUALIFY, APPLY and SETTLE retain separate jobs and permissions.
+These internals must not be copied into consumer YAML, TOML, or helper scripts.
+
+## Runtime and recovery
+
+The public entry resolves one runtime. Its business jobs use that selected
+runtime while retaining exact source, artifact and publication evidence.
+Buildchain self consumption uses the same generated caller pair and runtime
+selection contract as other repositories.
+
+Recovery goes through `buildchain-recover.yml`, which calls
+`public-ops-recover.yml`. The caller supplies the exact attempt and, only when
+needed, a transient repaired runtime. The retained attempt owns source,
+artifacts, transaction and provider effects; recovery inputs cannot replace
+those identities. See [Runtime entry](runtime-entry.md).
+
+The retired `public-release-promote.yml` path is not an alias in the current
+contract. Historical receipts and published bytes keep their original paths;
+new consumers use the shared pipeline entry after its published qualification.

package/docs/release-propagation.md

@@ -8,16 +8,21 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-09-11
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-09
+  generated_at: 2026-09-20
   invisible_context: not asserted
 ---
 
 # Release Propagation
 
+This page documents internal propagation and native Work contracts. Propagation
+is not an extra public reusable workflow in the minimal consumer contract. A
+consumer does not pass graphs, release envelopes or downstream controller commands
+through its normal/recovery YAML pair.
+
 Release propagation lets a finalized upstream release open a downstream update
 PR using the upstream release passport as the audit source. It is for product
 chains such as:
@@ -485,32 +490,13 @@ observed non-zero bytes, exact deployed Git revision, and matching release and
 artifact digests. The final receipt binds the accepted Work Control Decision
 root.
 
-## Reusable Workflow
-
-Upstream repositories can call
-`.github/workflows/public-release-propagation.yml@v4-alpha` after release finalization:
+## Internal workflow
 
-```yaml
-jobs:
-  propagate-site:
-    uses: kungfu-systems/buildchain/.github/workflows/public-release-propagation.yml@v4-alpha
-    with:
-      agent-work-mode: capture-only
-      graph-json: ${{ needs.release.outputs.propagation-graph-json }}
-      upstream-release-json: ${{ needs.release.outputs.upstream-release-json }}
-      downstream-target: site-libkungfu-dev
-      downstream-repository: kungfu-systems/site-libkungfu-dev
-      downstream-base-ref: dev/v2/v2.7
-      downstream-update-command: >-
-        node scripts/paper-propagation.cjs consume
-        --lock "$BUILDCHAIN_PROPAGATION_LOCK_PATH"
-        && corepack pnpm install --lockfile-only --ignore-scripts
-      downstream-prepare-command: pnpm install --frozen-lockfile --ignore-scripts
-      downstream-verify-command: pnpm run check
-      dry-run: true
-    secrets:
-      propagation-token: ${{ secrets.BUILDCHAIN_PROMOTION_TOKEN }}
-```
+`.release-propagation.yml` is an internal component. Its graph, upstream release
+and downstream Work coordinates are derived and admitted inside the runtime.
+The former standalone public caller and arbitrary consumer update-command
+example are retired. The following source, push and evidence invariants still
+apply to the internal controller.
 
 Execution uses the native Work's exact downstream repository, base revision and
 branch. Push planning verifies that the base has not advanced and is an ancestor

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

@@ -1,6 +1,6 @@
 ---
 status: draft
-period: 2026-08-07
+period: ongoing
 theme: buildchain-release-tail-provider-plane
 doc_type: architecture
 source_level: local-files
@@ -8,64 +8,43 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-09-11
+last_reviewed: 2026-09-20
 ai_provenance:
-  model_family: GPT-5
+  model_family: GPT-6
   product: Codex
-  generated_at: 2026-08-07
+  generated_at: 2026-09-20
   visible_context: Buildchain release-tail declaration, provider adapters, durable transaction implementation, CLI, Action, reusable workflow, tests, and frozen consumer inventory.
   invisible_context_boundary: Did not read credentials, private provider state, signed URLs, unpublished release assets, or production receipts.
 ---
 
 # Declarative release-tail provider plane
 
-Buildchain owns the final release tail as one versioned transaction. A consumer
-supplies a sealed capability declaration and data-only provider bindings; it
-does not supply shell, JavaScript, executable paths, callbacks, or plugins.
-The frozen boundary and migration inventory remain in
-[`release-tail-contract.md`](./release-tail-contract.md).
-
-## Public entry points
-
-- Node: `@kungfu-tech/buildchain/release-tail-provider-plane`,
-  `release-tail-provider-adapters`, and `release-tail-compatibility`.
-- CLI: `buildchain release-tail plan|init|status|verify|compat`.
-- Action: `kungfu-systems/buildchain/actions/release/tail/settle@<exact-ref>`.
-- reusable workflow: `kungfu-systems/buildchain/.github/workflows/public-release-tail.yml@<exact-ref>`.
-
-The Action is the provider-executing entry point. The CLI compiles, initializes,
-inspects, verifies, and diagnoses bounded v3 compatibility using the same core
-transaction format. The reusable workflow checks out an exact Buildchain ref
-and invokes the packaged Action; callers cannot inject an execution command.
-
-The reusable workflow is permission-neutral: it inherits the calling job's
-GitHub token permissions and never elevates them. A rehearsal caller can remain
-`contents: read` and must pass `execute: false`. An effectful production caller
-owns and declares its provider authority explicitly:
-
-<!-- release-tail-production-caller-contract -->
-
-```yaml
-name: Production release tail
-
-on:
-  workflow_dispatch:
-
-jobs:
-  release-tail:
-    permissions:
-      contents: write
-    uses: kungfu-systems/buildchain/.github/workflows/public-release-tail.yml@v4
-    with:
-      declaration-path: .buildchain/release-tail/declaration.json
-      provider-bindings-path: .buildchain/release-tail/provider-bindings.json
-      execute: true
-```
+Buildchain owns release effects and their readback. Consumers declare product
+artifacts and publication targets in schema-2 TOML, then use the shared normal
+and exact-attempt recovery callers. They do not maintain release-tail provider
+bindings, transaction payloads, state artifacts or additional workflows.
+
+## Consumer entry points
+
+- `buildchain.yml` invokes `public-ops-pipeline.yml@v4`.
+- `buildchain-recover.yml` invokes `public-ops-recover.yml@v4`.
+
+Generate both through [init](getting-started.md). Request publication through a
+protected channel PR; recover an interrupted operation by its exact attempt.
+The runtime owns source, artifact and provider-effect selection.
 
-Omitting caller write authority cannot be repaired by the reusable workflow;
-GitHub rejects or constrains the call before provider execution. `execute:
-false` remains a plan/rehearsal boundary and does not authorize production
-mutation even when a caller token has broader ambient permissions.
+## Internal provider implementation
+
+The Node modules `release-tail-provider-plane` and `release-tail-provider-adapters`,
+the `release-tail` diagnostic CLI, `actions/release/tail/settle`, and the internal
+`.release-tail.yml` workflow implement and inspect bounded release transactions.
+They are maintenance interfaces, not additional consumer wiring.
+
+The internal reusable workflow is permission-neutral. Its owning runtime job
+supplies explicit provider permissions, while rehearsal runs retain read-only
+permissions and no production execution authority. A rehearsal or simulation
+result cannot authorize publication. Provider credentials remain separate from
+consumer commands and serialized transaction data.
 
 ## Inputs and secrets
 
@@ -117,18 +96,12 @@ resume boundary and evidence source, not a disposable log.
 
 ## Buildchain self-promotion route
 
-Buildchain invokes `./.github/workflows/public-release-promote.yml` at the same
-commit as its caller. Admission independently verifies the defining repository,
-exact committed workflow bytes and both consumer lock roots. External consumers
-use the public floating-channel API after publication. See
-[Promotion request](release-promotion-request.md).
-
-The promotion action executes one declaration-driven GitHub Release transaction.
-Its plan, provider observations and receipts bind the exact subject and asset
-roots. A completed-transaction recovery explicitly verifies the existing public
-Passport and immutable assets before reusing or repairing evidence. A provider
-failure cannot select a different publication implementation.
-
-Release metadata follows the declared tag and channel. The old mode selector and
-custom title/notes ports are removed. Retired shell-hook compatibility commands
-are absent; the current typed request rejects undeclared fields.
+Buildchain uses the same generated normal and recovery callers as other consumers.
+The published runtime selects its internal publication jobs, binds their source
+and artifacts, and performs provider readback. Its product publisher is
+`.release-pipeline-products.yml`; consumer YAML does not call that component.
+
+Completed-publication recovery verifies the existing publication and immutable
+assets before continuing. A provider failure cannot select replacement product
+bytes or a different source. Internal transaction fixtures and retained historical
+receipts remain evidence of their original execution, not extra current callers.

package/docs/reusable-build-surface.md

@@ -1,5 +1,5 @@
 ---
-status: draft
+status: active
 period: ongoing
 theme: buildchain-reusable-build
 doc_type: technical-reference
@@ -8,210 +8,92 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-09
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-09
-  invisible_context_boundary: No private credentials or unrelated repositories inspected.
+  generated_at: 2026-09-20
+  visible_context: Shared caller generator, schema-2 product plan, pipeline build node and internal signing workflow.
+  invisible_context_boundary: Local source inspection does not establish hosted release qualification or provider authorization.
 ---
 
-# Reusable Build Surface
-
-A project declares its build in `buildchain.toml`. The reusable workflow owns
-job sequencing, admission, runner boundaries and evidence aggregation. Ordinary
-single-project calls have no inputs:
-
-```yaml
-permissions:
-  issues: write
-  actions: read
-  contents: read
-  id-token: write
-  attestations: write
-jobs:
-  build:
-    uses: kungfu-systems/buildchain/.github/workflows/build.yml@v4
-```
+# Consumer build and verification
 
-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
-
-At the repository root, exactly one of `.buildchain/buildchain.toml` and
-`buildchain.toml` must exist. Missing or ambiguous configurations fail before
-matrix scheduling. A nested project is selected with its configuration location:
-
-```yaml
-jobs:
-  native:
-    uses: kungfu-systems/buildchain/.github/workflows/build.yml@v4-alpha
-    with:
-      config-path: packages/native/.buildchain/buildchain.toml
-```
+A repository declares products in `.buildchain/buildchain.toml`. The shared
+`buildchain.yml` caller invokes `public-ops-pipeline.yml@v4`; the shared
+`buildchain-recover.yml` caller invokes `public-ops-recover.yml@v4`.
+Use [init](getting-started.md) to generate both callers. Their bytes are the same
+for npm packages, binary archives and Paper PDFs.
 
-The config location determines the project working directory. Planning and
-lifecycle execution discover the same file. Absolute paths, parent traversal,
-symlink escape, malformed TOML and unknown `[build]` keys fail closed. A
-configuration locator cannot carry a profile override or execution authority.
+## Product commands
 
-## Project configuration
+Each schema-2 `[[products]]` entry declares its product type, supported platforms,
+install/build/verify commands, artifacts and publication targets. For example:
 
 ```toml
-schema = 1
-
-[lifecycle.install]
-command = "corepack pnpm install --frozen-lockfile"
-
-[lifecycle.build]
-command = "corepack pnpm build"
-
-[lifecycle.verify]
-command = "corepack pnpm test"
-
-[build]
-environment = "github-hosted"
-timeout_minutes = 120
-fail_fast = false
-
-[build.tools]
-node = "24"
-rust = "stable"
-go = "1.25.x" # optional; omitted toolchains are not installed
-
-[build.artifacts]
-name = "my-library"
-paths = ["dist"]
-required_paths = ["dist/library.js"]
-min_files = 1
-release_candidate = true
-retention_days = 14
-compression_level = 0
+schema = 2
+
+[[products]]
+id = "library"
+type = "npm"
+platforms = ["linux-x64"]
+install = ["corepack pnpm install --frozen-lockfile"]
+build = ["corepack pnpm run build"]
+verify = ["corepack pnpm run check"]
+
+[[products.artifacts]]
+id = "package"
+path = "."
+kind = "npm-package"
+
+[[products.targets]]
+provider = "npm"
+access = "public"
+artifacts = ["package"]
 ```
 
-Commands remain exclusively in `[lifecycle]`. The backbone explicitly invokes
-install, build and verify in that order on each platform. Build is required;
-install and verify are required when declared. Unneeded stages require no
-additional boolean setting. Per-stage lifecycle timeout declarations retain
-precedence over the build timeout fallback.
-
-Artifact paths and required file paths are relative to the selected project.
-Platform artifact names derive from the configured base name,
-platform and source SHA; callers do not supply naming templates. The final
-manifest checks `min_files`, `max_files`, `min_total_bytes` and `required_paths`.
-
-Other optional project sections are:
-
-| TOML section | Responsibility |
-| --- | --- |
-| `build.diagnostics` | Process sampling and expected parallelism |
-| `build.verification` | Consumer-produced verify substage evidence location |
-| `build.finalization` | Verification of final signed bytes and platform placement |
-| `build.transport_smoke` | Transport simulation scenario and artifact root |
-| `build.attestation` | Subject path and attested platform |
-| `build.macos_signing` | App path and sealed-input platform |
-| `build.contract` | Compatibility and drift reporting policies |
-| `build.evidence` | Repository files containing gate and candidate-family evidence |
-
-Declarative signing targets continue to belong to `[signing.artifacts]`.
-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).
-
-## Governed environments
-
-`build.environment` selects a profile in
-[`architecture/build-environments.json`](../architecture/build-environments.json)
-from the exact Buildchain runtime. Infrastructure owners maintain runner
-presets/platforms, Linux container images, mirrors, cache transport, artifact
-relay settings and credential-island environments there. Adding a runner label
-or provider role requires reviewing that profile; project TOML cannot redefine
-it. Secrets still cross explicit workflow secret/environment boundaries.
-
-The profiles are `github-hosted`, `github-hosted-container`, `kungfu-hosted`,
-`kungfu-v4-native` and `kungfu-v4-self-hosted`. `kungfu-hosted` preserves the
-Kungfu release matrix on GitHub-hosted Ubuntu 24.04 x64 and ARM64, macOS 15
-ARM64 and Windows 2022 x64. It selects GCC 14 for Linux x64, full Git history
-and the required Windows sccache profile at
-`docs/shifu/windows-alpha-sccache.cache-profile.json`, bound to its reviewed
-digest in the environment registry. All four lanes transfer artifacts directly
-through GitHub; the profile adds no provider roles or signing authority.
-Existing profiles retain their runner and cache policies. The container profile
-uses the existing digest-pinned `kungfu-verify` image. Native and container jobs remain
-separate because GitHub selects `runs-on` and `container` before executing
-steps. Their shared behavior is owned by these composite actions:
-
-| Action | Owner responsibility |
-| --- | --- |
-| `resolve-build-plan` | Admission and complete plan |
-| `prepare-build-environment` | Source and toolchains |
-| `run-build-stage` | Ordered lifecycle and diagnostics |
-| `transfer-build-artifact` | Exact artifact coordinates and transport |
-| `sign-build-artifact` | Isolated signing and final bytes |
-| `attest-build-artifact` | Provider identity and final-byte attestation |
-| `finalize-build-result` | Complete coverage and final result |
-
-The backbone has six jobs: `plan`, `build-native`, `build-container`, `sign`,
-`attest` and `deliver`. It owns install → build → verify order, job dependencies,
-permissions, signing control, credential-island placement and final aggregation.
-A composite's internal receipt inputs transport already resolved facts; they
-are not additional reusable-workflow configuration inputs.
-
-## Identity and admission
-
-The configuration resolver reads the exact consumer source without executing
-consumer commands. It emits a deterministic plan/root binding configuration
-bytes, source SHA, called-workflow SHA, selected environment, toolchain and
-cache roots. Trust checks run before project execution or privileged runners.
-
-Tracked consumer workflows use `@v4` or `@v4-alpha` and commit both
-`.buildchain/contract-lock.json` and `.buildchain/alpha-contract-lock.json`.
-The called channel selects its matching lock. Source-persisted train/SHA
-selectors and mismatched locks remain forbidden. Ordinary builds have no
-runtime-override path; specialized release/recovery entry points keep their
-separate, bounded admission contracts.
-
-Bootstrap owns its admitted release and recovery capabilities. It is not an
-alternate parameter envelope for ordinary builds and is not injected into the
-build backbone. Release promotion consumes an already sealed candidate and
-must verify the source, artifacts and receipts independently.
-
-## Evidence and failure behavior
-
-The backbone returns one rooted `result` containing source/runtime identity and
-exact provider references for payloads, diagnostics, summary, signing, attestation
-and candidate evidence. The public facade exposes that result plus the candidate
-and controller artifact names for direct `download-artifact` calls.
-Platform manifests include deterministic payload hashes; transport preserves
-hidden artifacts and provenance. Substage failure evidence is collected even
-when verify fails. Untrusted events cannot reach build runners.
-
-The `sign` matrix uses separate ordinary artifact and protected macOS credential
-instances. The credential instance never checks out or executes consumer source.
-A hosted artifact instance may use its platform when final-byte verification
-requires that operating system; it receives no certificate or notary inputs. Imported signed bytes undergo consumer verification before
-manifests are recomputed. Release builds produce candidates; registry publishing
-belongs to the protected release path.
-
-## Maintaining the contract
-
-Update the TOML parser and plan resolver, owner contracts, affected consumers
-and tests together. Run
-`pnpm run generate:workflows`, generated reference/site checks and the full
-`pnpm run check`. Breaking input removal is intentional: migrate old `with`
-settings to TOML and remove them from calls; no compatibility forwarding exists.
-
-The Buildchain fixture at `fixtures/libnode-shaped/buildchain.toml` exercises
-native macOS/Windows and Linux-container builds through this public contract.
+This excerpt describes a product. The complete configuration also declares version
+sources, protected channel routes and review policy; use the
+[complete standard examples](../templates/minimal-consumer/) for those sections.
+
+The runtime executes install, build and verify in order for each selected product.
+Commands run in the product directory inside the admitted checkout. They receive
+an environment without provider credentials, and their output cannot become a
+privileged action's authority output. Runner environment/path file commands can
+carry product toolchain settings between phases.
+
+Build source verification binds the exact Git commit, tree and TOML blob, and
+checks tracked file bytes and modes before and after execution. A failed product
+command or source change fails that observation. Successful product execution is
+an input to the runtime's independent qualification and publication stages.
+
+## Runtime selection and recovery
+
+Caller source selects `v4` or `v4-alpha`. A tool-maintained contract lock, when
+present, selects its qualified runtime. Without a lock, the entry selects its own
+exact runtime commit. Source-persisted train or SHA overrides are not consumer
+configuration.
+
+For an interrupted operation, select its exact attempt in `buildchain-recover.yml`.
+An optional repaired runtime belongs to that recovery request. Source, artifacts,
+provider effects and prior receipts remain bound to the original attempt. See
+[the Golden Path](getting-started.md) for the normal protected PR flow.
+
+## Internal implementation boundaries
+
+The [workflow catalog](workflow-catalog.md) identifies internal components.
+Consumers do not call their workflows/actions or supply material roots, provider
+payloads, Warrant state or direct artifact-download handoffs.
+
+The internal `.release-signing-authority.yml` owns native signing credentials and
+provider verification. Its protected `buildchain-artifact-signing` environment
+retains certificate/notary inputs; the credential job never checks out or executes
+consumer source. Ordinary artifact jobs receive no certificate or notary secrets.
+The signing adapters verify returned bytes and provider results before delivery.
+These implementation contracts do not add another consumer entry or imply that
+all internal product capabilities are schema-2 configuration options.
+
+Maintainers changing product execution or credential boundaries must update the
+plan, implementation, source-bound tests, generated references and site bundle,
+and run the full repository check. Retained schema-1 build fixtures exercise
+internal implementation history; they are not current consumer templates.

package/docs/runtime-train-validation.md

@@ -8,11 +8,11 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-14
+last_reviewed: 2026-09-19
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-14
+  generated_at: 2026-09-19
   visible_context: Source-bound caller installation, pipeline wake implementation and GitHub event documentation.
   invisible_context_boundary: No unobserved provider execution or publication authority is claimed.
 ---
@@ -72,7 +72,9 @@ the normal pipeline before recovering a current admitted attempt. An installatio
 merge advances the protected base, so an older unmerged source attempt must be
 re-admitted on the current base before recovery.
 
-Both callers are byte-identical to the generated consumer entries and call the
-published `@v4-alpha` public workflows. Recovery accepts only `attempt` and
-optional `runtime-ref`; the normal caller retains its protected config path.
-This installation order does not qualify the full self cutover or Stable release.
+The tracked callers are byte-identical to the default generated consumer entries:
+published `@v4` public workflows and `.buildchain/buildchain.toml`. Recovery accepts
+only `attempt` and optional `runtime-ref`. The stable entry must be published and
+qualified before adopting these defaults. Historical installation and recovery
+receipts retain their original transition path and runtime identities; installation
+order alone does not qualify a Stable release.