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

package/AGENTS.md

@@ -8,11 +8,11 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-14
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-14
+  generated_at: 2026-09-20
   visible_context: Buildchain 4.1 source, architecture registries and local validation.
   invisible_context_boundary: No unpublished release or external consumer qualification is claimed.
 ---
@@ -45,20 +45,18 @@ caller invokes the published `public-ops-pipeline.yml`; recovery accepts only an
 exact attempt and an optional repaired runtime through `public-ops-recover.yml`.
 No repository-specific runtime selection or recovery exception is allowed.
 
-During the protected migration, both callers use `@v4-alpha` and the prepared
-`.buildchain/minimal-consumer.toml` path, kept byte-identical to the canonical
-TOML. The pipeline reads policy at the same path on its protected target branch,
-so each target must contain the schema-2 policy before its first pipeline PR.
-The TOML declares `feature/*`, `fix/*`, `chore/*`, `docs/*`, `ci/*`, and
-`refactor/*` development routes before the first new-pipeline Alpha qualification.
-After the canonical path is protected and the stable entry is qualified,
-regenerate the same pair using the default path and `@v4`.
-Do not claim the transition complete while that final cleanup is outstanding.
+Both callers use the published `@v4` entry and the default
+`.buildchain/buildchain.toml` path. The pipeline reads policy at the same path on
+its protected target branch, so each target must contain the schema-2 policy
+before its first pipeline PR. The TOML declares `feature/*`, `fix/*`, `chore/*`,
+`docs/*`, `ci/*`, and `refactor/*` development routes. The tool-maintained stable
+contract lock binds the qualified published runtime.
 
 Products declare their own install, build, and verification commands in TOML.
 Publication, source qualification, reviews, merge queues, provider readback and
-recovery belong to the published runtime. Internal workflow libraries may be
-retained, but self callers must use the same public reusable-workflow contract as every other consumer.
+recovery belong to the published runtime. Internal workflow libraries and actions are implementation only. The complete
+public reusable API is `public-ops-pipeline.yml` and `public-ops-recover.yml`;
+self callers use the same public reusable-workflow contract as every other consumer.
 
 ## Building this repo
 

package/CONTRIBUTING.md

@@ -8,11 +8,11 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-14
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-14
+  generated_at: 2026-09-20
   visible_context: Repository contribution rules and implementation naming and release transition changes.
   invisible_context_boundary: No private credentials or unpublished external release state.
 ---
@@ -89,14 +89,32 @@ category vocabulary is enforced by `architecture/workflow-taxonomy.json`:
 
 | Role | Filename | Scope |
 | --- | --- | --- |
-| Public | `public-<category>-<purpose>.yml` | Consumer entry |
-| Component | `.<category>-<purpose>.yml` | Advanced reusable component |
+| Public | `public-ops-pipeline.yml`, `public-ops-recover.yml` | Normal execution and exact-attempt recovery |
+| Component | `.<category>-<purpose>.yml` | Internal runtime topology or dispatch service |
 | Self | `buildchain.yml`, `buildchain-recover.yml` | Generated normal and recovery callers |
 
 Categories are only `build`, `release`, and `ops`. Register the identity, role,
 category, purpose, owner, lifecycle status, invocation, and rationale before
 adding its derived filename. The [Workflow Catalog](docs/workflow-catalog.md)
-lists every canonical API and component path; self automation has only the generated normal and recovery entries. Retired paths have no generated aliases. A matching prefix alone does not admit an unregistered workflow.
+lists every canonical API and component path. Consumers select only the two public
+entries; actions and product-specific components are internal. Self automation
+has only the generated normal and recovery entries. Retired paths have no generated aliases. A matching prefix alone does not admit an unregistered workflow.
+
+`validate`, `doctor`, and consumer source inspection check the generated caller
+bytes and the registered implementation inventory separately. A repository that
+also implements the runtime may retain its declared workflow libraries. Every
+library must pass the same taxonomy checks; an extra repository event root or
+unregistered workflow is rejected, including in Buildchain's own repository.
+
+Source inspection follows product commands, package scripts and reachable local
+modules, rejecting recognized publication or recovery control calls before a
+product runs. Unsupported syntax, dynamic code and external tools remain explicit
+unresolved diagnostics; passing the control checks is not proof of a complete
+static program graph. Product commands still run in the runtime's read-only jobs
+with filtered child environments and private command files. The required tests
+enforce this boundary for normal builds, publication builds and version generation.
+Independent provider qualification grants authority; a product's output cannot.
+This boundary does not claim to sandbox arbitrary hostile code on a local machine.
 
 Run `pnpm run generate:workflows`, `pnpm run check:workflows`, then the full
 `pnpm run check`. The product verification commands run this gate through the shared pipeline on PRs, merge
@@ -152,10 +170,10 @@ release/vX/vX.Y -> publish-gate/major
 - Recover an interrupted operation through `buildchain-recover.yml` using its
   exact attempt and, when required, one transient repaired runtime. Recovery
   does not accept replacement source, artifact or provider-effect parameters.
-- During this repository's protected cutover, both generated callers use
-  `@v4-alpha` and the protected `.buildchain/minimal-consumer.toml` policy path;
-  see `AGENTS.md` for target-policy admission, stable qualification and final
-  default-path cleanup requirements.
+- Both generated callers use the published `@v4` entry and the default
+  `.buildchain/buildchain.toml` policy path. Adopt the stable contract lock only
+  after the published entry has qualified; see `AGENTS.md` for target-policy
+  admission requirements.
 
 See [`docs/release-governance.md`](docs/release-governance.md),
 [`docs/release-flow.md`](docs/release-flow.md), and
@@ -182,3 +200,8 @@ Stable completion under `semver/auto` prepares the next patch at `alpha.0` from
 the exact current protected development commit. See the generated
 [next-development contract](docs/next-development-transition.md) for retry,
 independent review, and publication-preservation behavior.
+
+Stable eligibility is checked before publication. Once the native publication
+phase has succeeded, distribution and next-development continue from the retained
+publication, source and runtime. Later Alpha PR events do not restart that gate;
+the follow-up stages still verify their original publication and protected merge.

package/README.md

@@ -8,20 +8,24 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-10
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-10
+  generated_at: 2026-09-20
   visible_context: Buildchain 4.1 source, architecture registries and local validation.
   invisible_context_boundary: No unpublished release or external consumer qualification is claimed.
 ---
 
 # Buildchain
 
-Development: **4.1.0-alpha.0** on `dev/v4/v4.1`. This development version has
-not been published. See [Code organization](docs/code-organization.md) for the
-workflow → action → JavaScript/Rust implementation layers.
+Development continues on `dev/v4/v4.1`. The package version and published
+Release Passport identify source and release state. See
+[Code organization](docs/code-organization.md) for the workflow, action,
+JavaScript and Rust implementation layers.
+
+The retained animation below demonstrates an older initializer. For the current
+schema-2 caller pair, follow the [Golden Path](docs/getting-started.md).
 
 <!-- buildchain-auditable-demo:start -->
 
@@ -60,9 +64,7 @@ This exact standalone-binary scenario proves deterministic local bootstrap behav
 [![Buildchain Release Passport: passed](https://buildchain.libkungfu.dev/badges/v1/buildchain-release-passport/passed.svg)](https://github.com/kungfu-systems/buildchain/releases/latest/download/buildchain.release.json)
 [![License: Apache-2.0](https://img.shields.io/badge/license-Apache--2.0-0969da.svg)](https://github.com/kungfu-systems/buildchain/blob/HEAD/LICENSE)
 [![Platform: macOS | Linux | Windows](https://img.shields.io/badge/platform-macOS%20%7C%20Linux%20%7C%20Windows-6e7781.svg)](https://github.com/kungfu-systems/buildchain/releases/latest/download/buildchain.release.json)
-[![Verify](https://github.com/kungfu-systems/buildchain/actions/workflows/self-build-verify.yml/badge.svg)](https://github.com/kungfu-systems/buildchain/actions/workflows/self-build-verify.yml)
-[![Buildchain Ref Promotion](https://github.com/kungfu-systems/buildchain/actions/workflows/self-release-promote.yml/badge.svg)](https://github.com/kungfu-systems/buildchain/actions/workflows/self-release-promote.yml)
-[![Binary Distribution](https://github.com/kungfu-systems/buildchain/actions/workflows/self-build-binary-distribution.yml/badge.svg)](https://github.com/kungfu-systems/buildchain/actions/workflows/self-build-binary-distribution.yml)
+[![Buildchain pipeline](https://github.com/kungfu-systems/buildchain/actions/workflows/buildchain.yml/badge.svg)](https://github.com/kungfu-systems/buildchain/actions/workflows/buildchain.yml)
 <!-- buildchain:badges:end -->
 
 Buildchain Release Passport is a mature product release record for artifacts
@@ -86,7 +88,7 @@ The same mechanism releases Buildchain itself.
 | operating an advanced build or release | [Documentation Map](docs/MAP.md)                           | capability-, intent-, and maturity-based navigation to normative contracts                                           |
 
 Production release operators should also read the
-[Buildchain v4 production release runbook](docs/v4-production-release.md).
+[release governance guide](docs/release-governance.md).
 
 The Golden Path is the beginner lane. Advanced workflow, signing, publishing,
 and governance manuals remain separate so a first-time consumer does not need
@@ -231,154 +233,68 @@ writeDiagnosticsArtifact(".buildchain/artifacts/diagnostics.json", {
 });
 ```
 
-`buildchain lifecycle run` writes a small `diagnostics.json` next to the
-platform manifest. It includes lifecycle-wide observability, runner/tool/cache
-snapshots, Git state, and links to the larger manifest and artifact outputs.
-
-Consumers can report Buildchain-owned workflow failures directly to the
-Buildchain repository with a scoped issue-write token:
-
-```yaml
-- uses: kungfu-systems/buildchain/actions/governance/incident/report@v4
-  if: failure()
-  with:
-    token: ${{ steps.buildchain-issue-token.outputs.token }}
-    summary: "Reusable build failed before artifact finalization"
-    failure-code: reusable-build-failed
-    buildchain-ref: v4
-    diagnostics-path: .buildchain/artifacts/diagnostics.json
-```
-
-The action deduplicates by fingerprint, comments on existing open reports, and
-is fail-soft by default so issue reporting does not hide the original failure.
-Use `report-kind: workflow-friction` when Buildchain workflows should report
-their own repeated release friction back to the Buildchain issue tracker.
-
 ## Use Buildchain
 
-Bootstrap a repository:
+In an existing npm product with a versioned `package.json` and build/check scripts:
 
 ```bash
-npx @kungfu-tech/buildchain init --type package --package-manager pnpm
-npx @kungfu-tech/buildchain validate --require-version-state
-npx @kungfu-tech/buildchain release --dry-run --target-ref alpha/v4/v4.0
+pnpm add -D --save-exact @kungfu-tech/buildchain
+pnpm exec buildchain init --type npm --package-manager pnpm
+pnpm exec buildchain validate --require-version-state
+pnpm exec buildchain doctor --json
 ```
 
-Bootstrap and inspect a governed paper repository through one interface:
+Use `--type binary` for a CMake product or `--type paper` for an existing PDF
+product. The initializer writes the shared caller pair and product declarations;
+edit the TOML to match your product's build, verification and artifact paths.
+
+To create Paper source as well as the shared configuration:
 
 ```bash
-npx @kungfu-tech/buildchain paper scaffold \
+pnpm exec buildchain paper scaffold \
   --package @kungfu-tech/paper-example \
   --repository kungfu-systems/paper-example
-pnpm add -D @kungfu-tech/buildchain@<exact-v4-version>
-pnpm exec buildchain paper work start <topic>
-pnpm exec buildchain paper work submit
+pnpm exec buildchain paper scaffold \
+  --package @kungfu-tech/paper-example \
+  --repository kungfu-systems/paper-example --write
 pnpm exec buildchain paper preflight --offline
 pnpm exec buildchain paper status
 ```
 
-The paper surface is dry-run first. Add `--write` only to create missing
-scaffold files. `work start` and `work submit` validate the canonical remote,
-exact development SHA, clean source, safe branch, and fast-forward boundary
-before changing local or GitHub state. External mutations such as npm
-bootstrap, Alpha PR creation, and release resumption require `--execute`. See
-[`docs/publication-artifacts.md`](docs/publication-artifacts.md) for the
-evidence-state model and operator flow.
+Scaffolding first shows the planned files; `--write` creates them. Paper products
+publish PDFs as GitHub Release assets through the same pipeline as other products.
+See [Paper products and migration](docs/publication-artifacts.md) for source
+prerequisites and preservation of historical publication records.
 
-Buildchain supports package and non-package projects through
-`.buildchain/buildchain.toml`. Legacy root `buildchain.toml` files remain
-readable, but new consumers should keep Buildchain-owned files under
-`.buildchain/`:
+After one-time repository/provider setup, commit your product and generated
+configuration and open a protected channel PR. Buildchain handles delivery and
+publication. Recover an interrupted operation by selecting its exact attempt in
+`buildchain-recover.yml`. npm Trusted Publishing authenticates hosted npm releases.
 
-```text
-.buildchain/buildchain.toml
-.buildchain/contract-lock.json
-.buildchain/kfd/kfd-3/surfaces.json
-.buildchain/release-passport/buildchain.release.json
-```
+Product commands can use pnpm, npm, yarn, pip, Conan, CMake, Make or repository
+build scripts. They produce and verify product artifacts; the published runtime
+owns release orchestration and its evidence.
 
-Lifecycle commands can call pnpm, npm, yarn, pip, Conan, CMake, Make, custom
-scripts, or any other command that can run in the repository checkout.
-
-The KFD entrypoint is `buildchain kfd`. Buildchain provides concrete KFD-1
-contract-world, KFD-2 trust-claim, and KFD-3 collaboration-surface workflows,
-plus fail-closed product-evidence gates for KFD-4, KFD-5, and KFD-7. These
-gates preserve product-owned qualification and support decisions; they do not
-turn a schema-valid record into certification or shipped support.
-
-Reusable workflows are the primary consumer API. The generated action registry
-indexes the capability/group/operation hierarchy and marks direct action contracts.
-The direct consumer integration actions are:
-
-- `actions/build/lifecycle/validate`
-- `actions/build/lifecycle/run`
-- `actions/release/promotion/ref`
-- `actions/governance/incident/report`
-- `actions/release/tail/settle`
-- `actions/release/promotion/candidate`
-
-Three additional release-authority components are also registered and versioned:
-
-- `actions/build/artifact/prepare-attestation`
-- `actions/build/artifact/seal-attestation`
-- `actions/build/credential/macos-island`
-
-Seven shared build components have explicit ownership in
-`architecture/build-orchestration.json`:
-
-- [`actions/build/lifecycle/plan`](actions/build/lifecycle/plan/action.yml)
-- [`actions/build/lifecycle/prepare`](actions/build/lifecycle/prepare/action.yml)
-- [`actions/build/lifecycle/stage`](actions/build/lifecycle/stage/action.yml)
-- [`actions/build/artifact/transfer`](actions/build/artifact/transfer/action.yml)
-- [`actions/build/artifact/sign`](actions/build/artifact/sign/action.yml)
-- [`actions/build/artifact/attest`](actions/build/artifact/attest/action.yml)
-- [`actions/build/artifact/finalize`](actions/build/artifact/finalize/action.yml)
-
-`dist/site/workflow-registry.json#actions` is the machine-readable inventory;
-this split keeps the older four-action consumer snapshot from being mistaken for
-the complete current registry.
-
-The active reusable workflow surfaces are:
-
-- `.github/workflows/.build-gate-profile.yml` for project-neutral Shifu Gate profile
-  planning, capability-aware runner dispatch, receipt validation, and one
-  stable aggregate check;
-- `.github/workflows/.build-demo-adapter.yml` for exact-artifact demo
-  qualification, transcript-bound renderer smoke, optional media rendering
-  from the exact passing Gate bundle, and opt-in content-addressed web-delivery
-  profiles with independently verified rendition roles;
-- `.github/workflows/public-build-demo.yml` for standalone binary
-  consumers that provide only a versioned multi-demo argv scenario and exact
-  same-run binary artifact coordinates; Buildchain owns isolated native
-  capture, Gate, Release Passport, materialization, and protected README PRs;
-- `.github/workflows/.build.yml` for deterministic multi-platform build and
-  artifact contracts;
-- `.github/workflows/build.yml` for the single-config channel router that uses
-  `vN-alpha` during development/prerelease work and `vN` for stable releases;
-- `.github/workflows/public-release-promote.yml` for post-merge
-  promote-only publication from a PR-stage release candidate, without a second
-  heavy build;
-- `.github/workflows/public-release-web.yml` for preview, staging, production, and
-  cleanup plans for site/app repositories;
-- `.github/workflows/self-release-promote.yml` for protected release
-  promotion and version-state transactions;
-- `.github/workflows/self-build-binary-distribution.yml` for Buildchain's own release
-  passport proof case.
-
-Stable consumers should reference actions and workflows through floating major
-refs after reviewing the exact release passport:
-
-```yaml
-uses: kungfu-systems/buildchain/actions/build/lifecycle/validate@v4
-```
+## Consumer workflow contract
 
-```yaml
-uses: kungfu-systems/buildchain/.github/workflows/build.yml@v4
-```
+Every product uses the same two generated files:
 
-```yaml
-uses: kungfu-systems/buildchain/.github/workflows/public-release-promote.yml@v4
-```
+- `.github/workflows/buildchain.yml` calls `public-ops-pipeline.yml@v4`.
+- `.github/workflows/buildchain-recover.yml` calls `public-ops-recover.yml@v4`.
+
+Declare npm packages, binary archives or Paper PDFs in
+`.buildchain/buildchain.toml`. Their install, build and verification commands
+remain product code. Open the appropriate protected channel PR to request a
+release. The runtime manages publication, provider readback and completion.
+Recovery takes an exact attempt and, when needed, one temporary repaired runtime.
+
+The [workflow catalog](docs/workflow-catalog.md) distinguishes the two public
+entries from internal components. Consumers do not call internal workflows or
+actions, supply publication payloads, or implement their own release controller.
+The three [standard examples](templates/minimal-consumer/) share identical caller
+bytes; their TOML and product source differ. Tool-maintained locks bind the
+published runtime. Existing npm Trusted Publishing continues to authenticate
+publication in the hosted workflow.
 
 ## Release Model
 
@@ -461,8 +377,8 @@ The first screen should be derived from:
 - Lead: the opening paragraph that defines Buildchain Release Passport.
 - Trust signal: the start of `Install and Verify`, especially passport-first
   binary verification.
-- Use signal: the start of `Use Buildchain`, especially the reusable workflow
-  and action surfaces.
+- Use signal: the start of `Use Buildchain`, especially the shared normal and recovery
+  workflow callers.
 
 The package-owned site bundle exposes ordered `homepage.sections`,
 `homepage.displayPlan`, `homepage.rendererContract`, and a complete

package/actions/release/promotion/ref/README.md

@@ -20,7 +20,7 @@ ai_provenance:
 # Release promotion adapter
 
 The consumer API is
-[public-release-promote.yml](../../../../.github/workflows/public-release-promote.yml).
+[.release-candidate-promote.yml](../../../../.github/workflows/.release-candidate-promote.yml).
 It admits one closed JSON request, qualifies exact source and runtime identities,
 applies the admitted publication plan, and settles provider evidence in separate
 permission boundaries. See the [request contract](../../../../docs/release-promotion-request.md).

package/architecture/action-taxonomy.json

@@ -2,7 +2,7 @@
   "schema": "buildchain.action-taxonomy/v1",
   "path": "actions/<capability>/<group>/<operation>",
   "rules": {
-    "workflowRole": "Reusable workflows own the consumer API and job authority boundaries.",
+    "workflowRole": "Only pipeline and recovery reusable workflows own the consumer API. Other workflows and every action are internal runtime nodes owning job and credential boundaries.",
     "compositeRole": "Composite actions compose external and internal uses only.",
     "javascriptRole": "JavaScript actions adapt declared inputs to named domain APIs; modules own business orchestration.",
     "reuseBoundary": "Share actions for coherent cross-workflow capabilities; share ordinary functions through core modules.",

package/architecture/agent-change-map.md

@@ -39,8 +39,6 @@ Safe change route: Reduce one declared responsibility in its owning module, run
 - sources: `packages/core/governance/issue-reporting.js`
 - sources: `packages/core/index.js`
 - sources: `packages/core/observability/diagnostics.js`
-- sources: `packages/core/paper/commands/paper.mjs`
-- sources: `packages/core/paper/paper-npm-bootstrap.js`
 - sources: `packages/core/providers/commands/infra-contract-core.mjs`
 - sources: `packages/core/providers/commands/infra-contract.mjs`
 - sources: `packages/core/publication/publication-artifact.js`
@@ -107,42 +105,30 @@ Safe change route: Reduce one declared responsibility in its owning module, run
 - tests: `tests/release-passport.test.mjs`
 - tests: `tests/release-propagation.test.mjs`
 - tests: `tests/web-surface.test.mjs`
-- workflows: `.github/workflows/public-release-web.yml`
+- workflows: `.github/workflows/.release-web.yml`
 
 ### Current top twenty maintenance hotspots
 
-- `tests/internal-architecture.test.mjs`
 - `tests/build-surface-promotion.test.mjs`
+- `tests/internal-architecture.test.mjs`
 - `tests/build-surface.test.mjs`
-- `tests/buildchain-ref-promotion-recovery-entry.test.mjs`
+- `tests/release-topology.test.mjs`
 - `scripts/check-inventory.mjs`
-- `.github/workflows/.build.yml`
-- `tests/dev-delivery-minimal-request.test.mjs`
 - `tests/build-configuration.test.mjs`
-- `.github/workflows/build.yml`
-- `scripts/generate-channel-promotion-workflow.mjs`
-- `tests/github-governance-authority.test.mjs`
-- `tests/maintainability.test.mjs`
-- `tests/oci-publication.test.mjs`
-- `tests/release-candidate-recovery.test.mjs`
-- `.github/workflows/.release-promote.yml`
-- `.github/workflows/public-build-adopter-qualification.yml`
-- `.github/workflows/public-build-stage-capsule-canary.yml`
-- `.github/workflows/public-release-oci-compose-preview.yml`
-- `.github/workflows/public-release-promote.yml`
-- `.github/workflows/.release-binary-assets.yml`
-- `.github/workflows/public-ops-dev-auto-merge.yml`
-- `tests/release-topology.test.mjs`
-- `scripts/check-release-topology.mjs`
+- `tests/dev-delivery-minimal-request.test.mjs`
+- `tests/workflow-taxonomy.test.mjs`
 - `packages/core/governance/buildchain-publication-authority.js`
+- `tests/minimal-consumer-contract.test.mjs`
+- `scripts/check-release-topology.mjs`
+- `tests/floating-consumer-policy-contract.test.mjs`
 - `scripts/check-universal-workflow-bootstrap.mjs`
-- `packages/core/providers/github/discussions/materials.js`
+- `tests/adopter-delivery.test.mjs`
+- `tests/buildchain-ref-promotion-recovery-entry.test.mjs`
 - `tests/controller-evidence.test.mjs`
-- `tests/floating-consumer-policy-contract.test.mjs`
+- `tests/github-governance-authority.test.mjs`
 - `tests/macos-credential-island.test.mjs`
-- `tests/minimal-consumer-contract.test.mjs`
 - `tests/native-artifact-signing-authority.test.mjs`
-- `tests/workflow-taxonomy.test.mjs`
+- `tests/release-candidate-recovery.test.mjs`
 
 ## action-process-runtime
 
@@ -724,7 +710,7 @@ Owner: Buildchain release provider maintainers
 
 - `contracts/release-tail-capabilities-v1.schema.json`
 - `contracts/release-tail-provider-bindings-v1.schema.json`
-- `.github/workflows/public-release-tail.yml`
+- `.github/workflows/.release-tail.yml`
 - `actions/release/tail/settle/action.yml`
 - `docs/release-tail-provider-plane.md`
 
@@ -1052,10 +1038,13 @@ Owner: Buildchain consumer contract maintainers
 
 ### Implementation
 
+- `packages/core/adoption/commands/init-repo.mjs`
+- `packages/core/adoption/consumer-init.js`
 - `packages/core/consumer/contract/entries.js`
 - `packages/core/consumer/contract/examples.js`
 - `packages/core/consumer/contract/identity.js`
 - `packages/core/consumer/contract/inspection.js`
+- `packages/core/consumer/contract/local-validation.js`
 - `packages/core/consumer/contract/plan.js`
 - `packages/core/consumer/contract/products.js`
 - `packages/core/consumer/contract/reader.js`
@@ -1068,8 +1057,9 @@ Owner: Buildchain consumer contract maintainers
 
 ### Tests
 
-- `tests/minimal-consumer-contract.test.mjs`
+- `tests/consumer-init.test.mjs`
 - `tests/consumer-product-config.test.mjs`
+- `tests/minimal-consumer-contract.test.mjs`
 
 ### Generated outputs
 
@@ -1078,7 +1068,7 @@ Owner: Buildchain consumer contract maintainers
 
 ### Minimal validation
 
-- `node --test tests/minimal-consumer-contract.test.mjs`
+- `node --test tests/minimal-consumer-contract.test.mjs tests/consumer-product-config.test.mjs tests/consumer-init.test.mjs`
 - `node scripts/generate-minimal-consumer-contract.mjs --check`
 
 ## minimal-consumer-pipeline
@@ -1370,7 +1360,6 @@ Owner: Buildchain Paper maintainers
 - `packages/core/paper/commands/paper-work-fleet-cli.mjs`
 - `packages/core/paper/paper-agent-entry.js`
 - `packages/core/paper/paper-fleet.js`
-- `packages/core/paper/paper-npm-bootstrap.js`
 - `packages/core/paper/paper-repository.js`
 - `packages/core/paper/paper-runtime-channels.js`
 - `packages/core/paper/paper-scaffold-content.js`
@@ -1405,24 +1394,20 @@ Owner: Buildchain Paper maintainers
 
 ### Implementation
 
-- `packages/core/paper/operations/bootstrap.js`
+- `packages/core/paper/consumer-status.js`
 - `packages/core/paper/operations/files.js`
 - `packages/core/paper/operations/github-observation.js`
 - `packages/core/paper/operations/identity.js`
+- `packages/core/paper/operations/migration.js`
 - `packages/core/paper/operations/npm-observation.js`
-- `packages/core/paper/operations/plans.js`
 - `packages/core/paper/operations/preflight-checks.js`
 - `packages/core/paper/operations/provisioning-validation.js`
-- `packages/core/paper/operations/provisioning.js`
 - `packages/core/paper/operations/runtime-observation.js`
 - `packages/core/paper/operations/runtime.js`
-- `packages/core/paper/operations/scaffold-config.js`
-- `packages/core/paper/operations/scaffold-workflows.js`
 - `packages/core/paper/operations/scaffold.js`
 - `packages/core/paper/operations/status-facts.js`
 - `packages/core/paper/operations/status.js`
 - `packages/core/paper/operations/toolchain-observation.js`
-- `packages/core/paper/operations/workspace.js`
 
 ### Contracts
 
@@ -1431,6 +1416,8 @@ Owner: Buildchain Paper maintainers
 ### Tests
 
 - `tests/paper-check-policy.test.mjs`
+- `tests/paper-consumer-migration.test.mjs`
+- `tests/paper-consumer-scaffold.test.mjs`
 - `tests/paper-migration.test.mjs`
 - `tests/paper-publication-controller.test.mjs`
 - `tests/paper-publication-node.test.mjs`
@@ -2125,7 +2112,7 @@ Owner: Buildchain maintainers
 ### Contracts
 
 - `.github/workflows/.release-promote.yml`
-- `.github/workflows/public-release-promote.yml`
+- `.github/workflows/.release-candidate-promote.yml`
 
 ### Tests
 
@@ -2135,7 +2122,7 @@ Owner: Buildchain maintainers
 
 ### Generated outputs
 
-- `.github/workflows/public-release-promote.yml`
+- `.github/workflows/.release-candidate-promote.yml`
 
 ### Minimal validation
 
@@ -2190,7 +2177,7 @@ Owner: Buildchain workflow maintainers
 ### Contracts
 
 - `.github/workflows/.build.yml`
-- `.github/workflows/build.yml`
+- `.github/workflows/.build-candidate.yml`
 - `architecture/build-environments.json`
 - `actions/build/lifecycle/plan/action.yml`
 - `actions/build/lifecycle/prepare/action.yml`
@@ -2213,7 +2200,7 @@ Owner: Buildchain workflow maintainers
 
 ### Generated outputs
 
-- `.github/workflows/build.yml`
+- `.github/workflows/.build-candidate.yml`
 - `actions/build/lifecycle/run/dist/index.js`
 
 ### Minimal validation
@@ -2537,7 +2524,7 @@ Owner: Buildchain adopter delivery maintainers
 - `contracts/fixtures/v4-adopter-delivery-v1/gate-positive.json`
 - `contracts/fixtures/v4-adopter-delivery-v1/gate-unknown-selector.json`
 - `contracts/fixtures/v4-adopter-delivery-v1/offline-vectors.json`
-- `.github/workflows/public-build-adopter-qualification.yml`
+- `.github/workflows/.build-adopter-qualification.yml`
 - `docs/v4-adopter-delivery.md`
 
 ### Tests
@@ -2649,7 +2636,7 @@ Owner: Buildchain architecture maintainers
 - `architecture/tail-reseal-parity.json`
 - `contracts/v4-tail-reseal-v1.schema.json`
 - `contracts/fixtures/v4-tail-reseal-v1/valid.json`
-- `.github/workflows/public-ops-tail-reseal.yml`
+- `.github/workflows/.ops-tail-reseal.yml`
 - `docs/v4-stage-capsule.md`
 - `docs/v4-tail-reseal.md`
 
@@ -2759,7 +2746,7 @@ Owner: Buildchain protected delivery maintainers
 - `architecture/decisions/0003-two-phase-delivery-warrant.md`
 - `contracts/dev-delivery-authority-v2.schema.json`
 - `dist/site/schemas/dev-delivery-authority-v2.schema.json`
-- `.github/workflows/public-ops-dev-auto-merge.yml`
+- `.github/workflows/.ops-dev-auto-merge.yml`
 - `templates/native-dev-delivery.yml`
 - `docs/dev-delivery-warrant.md`
 - `docs/dev-delivery-qualification-landing-adr.md`
@@ -2829,7 +2816,7 @@ Owner: Buildchain workflow maintainers
 - `architecture/universal-workflow-bootstrap.json`
 - `architecture/universal-workflow-fault-campaign.json`
 - `architecture/universal-workflow-capability-policy.json`
-- `.github/workflows/public-ops-bootstrap.yml`
+- `.github/workflows/.ops-bootstrap.yml`
 
 ### Tests
 
@@ -2938,7 +2925,7 @@ Owner: Buildchain web-surface maintainers
 
 ### Contracts
 
-- `.github/workflows/public-release-web.yml`
+- `.github/workflows/.release-web.yml`
 
 ### Tests
 

package/architecture/build-orchestration.json

@@ -3,7 +3,7 @@
   "configurationAuthority": "buildchain.toml",
   "ordinaryInputs": ["config-path"],
   "backbone": ".github/workflows/.build.yml",
-  "facade": ".github/workflows/build.yml",
+  "facade": ".github/workflows/.build-candidate.yml",
   "jobs": [
     "plan",
     "build-native",