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

package/docs/MAP.md

@@ -8,11 +8,11 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-09-08
+last_reviewed: 2026-09-10
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-08
+  generated_at: 2026-09-10
   invisible_context: not asserted
 ---
 
@@ -46,6 +46,8 @@ These entrypoints keep common destinations within three meaningful hops:
 README or this map, the role entry, and the normative contract or generated
 reference.
 
+The current repository layout is defined in [Code organization](code-organization.md).
+
 ## Capability Coverage
 
 This package should be usable by an agent from the npm artifact alone. The
@@ -95,7 +97,7 @@ workflow, action, and Node API export also carries a `capabilityGroup`,
 | Node API / package exports | `dist/site/node-api-registry.json`, `dist/site/release-provenance.json` | [`cli.md`](cli.md#node-api-and-package-exports) |
 
 `dist/site/kfd-claims.json` is generated from
-`packages/core/buildchain-kfd-claims.js`. Treat that module and JSON file as the
+`packages/core/adoption/buildchain-kfd-claims.js`. Treat that module and JSON file as the
 source claim registry; this map and the manuals explain those claims but do not
 replace them.
 
@@ -173,9 +175,9 @@ replace them.
 | How do I deploy a site/app preview, staging, or production surface? | [`web-surface-deployments.md`](web-surface-deployments.md) | use | stable |
 | How do I publish observed infrastructure contracts for downstream consumers? | [`infra-contract.md`](infra-contract.md) | use | preview |
 | How do I operate a repeatable, disabled-by-default, budget-fail-closed AWS Windows JIT campaign? | [`aws-us-elastic-runner-burst-plane.md`](aws-us-elastic-runner-burst-plane.md#phase-2-operator-workflow) | use/verify | preview |
-| How do I use the active actions directly? | [`../actions/validate-config/README.md`](../actions/validate-config/README.md), [`../actions/run-lifecycle/README.md`](../actions/run-lifecycle/README.md), [`../actions/promote-buildchain-ref/README.md`](../actions/promote-buildchain-ref/README.md), [`../actions/release-candidate-promote/README.md`](../actions/release-candidate-promote/README.md), [`../actions/report-buildchain-issue/README.md`](../actions/report-buildchain-issue/README.md), [`../actions/github-artifact-attestation/README.md`](../actions/github-artifact-attestation/README.md), [`../actions/macos-credential-island/README.md`](../actions/macos-credential-island/README.md), [`../actions/release-tail/README.md`](../actions/release-tail/README.md); `dist/site/workflow-registry.json#actions` is authoritative for the action inventory. | use | stable |
-| Where are shared build stages maintained? | [build-lifecycle-stage](../actions/build-lifecycle-stage/action.yml), [build-signing-request](../actions/build-signing-request/action.yml), [build-verification-evidence](../actions/build-verification-evidence/action.yml), [build-attestation-policy](../actions/build-attestation-policy/action.yml), [build-agent-hub-evidence](../actions/build-agent-hub-evidence/action.yml), [build-artifact-transfer](../actions/build-artifact-transfer/action.yml); [ownership](../architecture/build-orchestration.json) | contribute | active |
-| How can a consumer workflow report a Buildchain-owned failure back to Buildchain? | [`consumer-issue-reporting.md`](consumer-issue-reporting.md) + [`../actions/report-buildchain-issue/README.md`](../actions/report-buildchain-issue/README.md) | use | stable |
+| How do I use the active actions directly? | [`../actions/build/lifecycle/validate/README.md`](../actions/build/lifecycle/validate/README.md), [`../actions/build/lifecycle/run/README.md`](../actions/build/lifecycle/run/README.md), [`../actions/release/promotion/ref/README.md`](../actions/release/promotion/ref/README.md), [`../actions/release/promotion/candidate/README.md`](../actions/release/promotion/candidate/README.md), [`../actions/governance/incident/report/README.md`](../actions/governance/incident/report/README.md), [`../actions/build/artifact/prepare-attestation/README.md`](../actions/build/artifact/prepare-attestation/README.md), [`../actions/build/artifact/seal-attestation/README.md`](../actions/build/artifact/seal-attestation/README.md), [`../actions/build/credential/macos-island/README.md`](../actions/build/credential/macos-island/README.md), [`../actions/release/tail/settle/README.md`](../actions/release/tail/settle/README.md); `dist/site/workflow-registry.json#actions` is authoritative for the action inventory. | use | stable |
+| Where are shared build stages maintained? | [resolve-build-plan](../actions/build/lifecycle/plan/action.yml), [prepare-build-environment](../actions/build/lifecycle/prepare/action.yml), [run-build-stage](../actions/build/lifecycle/stage/action.yml), [transfer-build-artifact](../actions/build/artifact/transfer/action.yml), [sign-build-artifact](../actions/build/artifact/sign/action.yml), [attest-build-artifact](../actions/build/artifact/attest/action.yml), [finalize-build-result](../actions/build/artifact/finalize/action.yml); [ownership](../architecture/build-orchestration.json) | contribute | active |
+| How can a consumer workflow report a Buildchain-owned failure back to Buildchain? | [`consumer-issue-reporting.md`](consumer-issue-reporting.md) + [`../actions/governance/incident/report/README.md`](../actions/governance/incident/report/README.md) | use | stable |
 | What do the fixture repositories demonstrate? | [`../fixtures/libnode-shaped/README.md`](../fixtures/libnode-shaped/README.md), [`../fixtures/publish-transaction-shaped/README.md`](../fixtures/publish-transaction-shaped/README.md), [`../fixtures/web-surface-shaped/README.md`](../fixtures/web-surface-shaped/README.md), [`../fixtures/publication-artifact-shaped/README.md`](../fixtures/publication-artifact-shaped/README.md) | verify | stable |
 | What license and contribution terms apply? | [`../LICENSE`](../LICENSE) + [`../LICENSE-POLICY.md`](../LICENSE-POLICY.md) | use | stable |
 | What trademark, official-service, and provider-compliance boundaries apply? | [`../TRADEMARK.md`](../TRADEMARK.md) + [`../ACCEPTABLE_USE.md`](../ACCEPTABLE_USE.md) + [`../PROVIDER_COMPLIANCE.md`](../PROVIDER_COMPLIANCE.md) | use | stable |

package/docs/auditable-demo.md

@@ -26,12 +26,12 @@ two distinct evidence products:
    bundle passes.
 
 The public reusable workflow is
-`.github/workflows/.auditable-demo.yml`. It is consumer-neutral: Buildchain
+`.github/workflows/.build-demo-adapter.yml`. It is consumer-neutral: Buildchain
 does not know how a Kungfu, library, service, or application artifact should be
 interpreted. The consumer owns a small checked-in executable adapter.
 
 For standalone binary CLIs, the higher-level first-class surface is
-`.github/workflows/.declarative-auditable-demo.yml`. A consumer checks in only
+`.github/workflows/public-build-demo.yml`. A consumer checks in only
 `.buildchain/auditable-demo.json`, builds and uploads its exact same-run binary
 plus metadata, and passes the producer-owned artifact name and digest to that
 workflow. Buildchain then owns capture, Gate adaptation, independent native
@@ -122,7 +122,7 @@ authority.
 jobs:
   demo:
     needs: exact-binary
-    uses: kungfu-systems/buildchain/.github/workflows/.declarative-auditable-demo.yml@BUILDCHAIN_EXACT_SHA
+    uses: kungfu-systems/buildchain/.github/workflows/public-build-demo.yml@BUILDCHAIN_EXACT_SHA
     with:
       source-ref: ${{ github.sha }}
       binary-artifact-name: ${{ needs.exact-binary.outputs.artifact-name }}
@@ -353,7 +353,7 @@ jobs:
     permissions:
       actions: read
       contents: read
-    uses: kungfu-systems/buildchain/.github/workflows/.auditable-demo.yml@BUILDCHAIN_EXACT_SHA
+    uses: kungfu-systems/buildchain/.github/workflows/.build-demo-adapter.yml@BUILDCHAIN_EXACT_SHA
     with:
       source-ref: ${{ github.sha }}
       source-artifact-name: ${{ needs.build.outputs.artifact-name }}

package/docs/aws-us-elastic-runner-burst-plane.md

@@ -114,7 +114,7 @@ Linux qualification requires:
 - actual incremental AWS spend below USD 49;
 - no idle build and no active cloud residue.
 
-`node scripts/aws-runner-burst.mjs verify-linux --input <snapshot.json>` fails
+`node packages/core/providers/commands/aws-runner-burst.mjs verify-linux --input <snapshot.json>` fails
 closed when cost telemetry is missing/stale or any acceptance predicate is
 false.
 
@@ -275,7 +275,7 @@ All mutating modes require `--execute`, `--confirm-plan-digest`,
 `--confirm-source-sha`. Budget installation and preparation additionally
 require `--confirm-budget-name`. A future paid workload still requires a
 separate exact workflow/run authorization and uses
-`scripts/aws-windows-jit-controller.mjs`; preparation is not paid-launch
+`packages/core/providers/commands/aws-windows-jit-controller.mjs`; preparation is not paid-launch
 authority.
 
 Start by recording one reproducible plan:
@@ -305,13 +305,13 @@ tokens, JIT configuration, or signed URLs in arguments or receipts.
 
 ### Lower-level campaign and launch controllers
 
-`scripts/aws-windows-jit-campaign-core.mjs` owns the pure one-shot ledger
+`packages/core/providers/commands/aws-windows-jit-campaign-core.mjs` owns the pure one-shot ledger
 contract used by the operator and launch controller. Arming creates `CONTROL`
 and `CAMPAIGN#<id>` with `attribute_not_exists` conditions, so DynamoDB refuses
 a second campaign in the same retained state table. There is deliberately no
 clear or re-arm operation.
 
-Every `scripts/aws-windows-jit-controller.mjs --execute` call must provide the
+Every `packages/core/providers/commands/aws-windows-jit-controller.mjs --execute` call must provide the
 same `--account-id`, `--campaign-id`, `--confirm-campaign-id`, `--state-table`,
 and `--confirm-state-table`. Before GitHub JIT material is created, the
 controller verifies the exact provider Budget/dimension filter and proves the
@@ -371,7 +371,7 @@ host, including at least one full run, plus proof that:
 
 ### Phase 3 lifecycle controller
 
-`scripts/aws-macos-jit-controller.mjs` is the operator boundary for the paid
+`packages/core/providers/commands/aws-macos-jit-controller.mjs` is the operator boundary for the paid
 campaign. It has three explicit mutation modes:
 
 - `launch-campaign` binds the exact repository source, AMI, availability zone,

package/docs/binary-distribution.md

@@ -35,7 +35,7 @@ GitHub Release metadata remains deterministic and tag-derived. Exact alpha tags
 as `v2.6.2-alpha.0` are created or updated with `prerelease=true` and
 `make_latest=false`; exact stable tags such as `v2.6.1` are created or updated
 with `prerelease=false` and `make_latest=true`. The sealed publisher uses
-`scripts/ensure-github-release.mjs` before asset upload instead of relying on
+`packages/core/release/commands/ensure-github-release.mjs` before asset upload instead of relying on
 GitHub's default latest-release heuristic.
 
 Each archive is accompanied by:
@@ -114,7 +114,7 @@ node bin/buildchain.mjs collect github-release \
   --tag v0.0.0-local \
   --assets-dir dist/binary \
   --output-dir .buildchain/release-passport
-node scripts/create-release-bundle.mjs \
+node packages/core/publication/commands/create-release-bundle.mjs \
   --assets-dir dist/binary \
   --passport-dir .buildchain/release-passport \
   --output-dir .buildchain/release-passport \

package/docs/bootstrap-recovery.md

@@ -0,0 +1,50 @@
+---
+status: active
+period: ongoing
+theme: bootstrap-recovery-distribution
+doc_type: manual
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: B
+review_state: unreviewed
+last_reviewed: 2026-09-09
+ai_provenance:
+  model_family: GPT-6
+  product: Codex
+  generated_at: 2026-09-09
+  visible_context: Recovery workflows, node implementations, dependency closure generator and isolated consumer tests.
+  invisible_context_boundary: No production recovery campaign or external consumer deployment was performed.
+---
+
+# Consumer-owned bootstrap recovery
+
+The normal entry is `public-ops-bootstrap.yml`. Before depending on it, install
+both recovery artifacts from the same reviewed Buildchain package into the
+consumer repository:
+
+| Package source | Consumer destination |
+| --- | --- |
+| `templates/universal-buildchain-bootstrap-recovery.yml` | `.github/workflows/buildchain-bootstrap-recovery.yml` |
+| Contents of `templates/bootstrap-recovery/` | `.buildchain/bootstrap-recovery/` |
+
+Commit both artifacts together. The second directory contains three composite
+nodes, their complete JavaScript dependency closure, a runtime preparation
+action, package identity and a file digest manifest. It must be tracked even
+when the consumer otherwise ignores `.buildchain/`. Installing the workflow
+alone is incomplete. Do not substitute files from a different package version.
+
+The recovery workflow checks out its own defining consumer commit and invokes
+the prepositioned nodes. Request parsing, independent review and terminal
+receipt verification start without npm dependencies or a published Buildchain
+workflow. Candidate code and its dependencies run only after the consumer-owned
+review boundary admits the exact candidate SHA. Provider execution uses the
+same candidate engine as the primary route. A failure of GitHub itself remains
+an external availability boundary.
+
+The recovery package is generated from the current `actions/workflow/`,
+`actions/runtime/` and `packages/core/` implementations. It contains no separate
+recovery implementation. `pnpm run generate:workflows` regenerates it and its
+admission roots; the normal repository check rejects distribution drift.
+Tests copy only these artifacts into a clean temporary consumer and execute
+request admission without the Buildchain checkout or `node_modules`.

package/docs/cli-reference.md

@@ -35,28 +35,6 @@ Every listed help command is intercepted before dispatch, exits zero, and perfor
 buildchain adopter-delivery
 ```
 
-### `buildchain adopter-delivery archive`
-
-- Help: `buildchain adopter-delivery archive --help`
-- Canonical id: `adopter-delivery`
-- Options: `--input`, `--output`
-- Syntax:
-
-```text
-buildchain adopter-delivery archive --input <json-or-path> [--output <path>]
-```
-
-### `buildchain adopter-delivery bootstrap`
-
-- Help: `buildchain adopter-delivery bootstrap --help`
-- Canonical id: `adopter-delivery`
-- Options: `--input`, `--output`
-- Syntax:
-
-```text
-buildchain adopter-delivery bootstrap --input <json-or-path> [--output <path>]
-```
-
 ### `buildchain adopter-delivery run`
 
 - Help: `buildchain adopter-delivery run --help`
@@ -833,11 +811,11 @@ buildchain facts compatibility verify [--cwd <dir>] [--registry <json-or-path>]
 
 - Help: `buildchain facts module --help`
 - Canonical id: `build-facts`
-- Options: `--cwd`, `--json`, `--legacy-kungfu-buildinfo`, `--module`, `--module-root`, `--output`, `--output-path`, `--version-source`
+- Options: `--cwd`, `--json`, `--module`, `--module-root`, `--output`, `--output-path`, `--version-source`
 - Syntax:
 
 ```text
-buildchain facts module [--cwd <dir>] [--module <id>] [--module-root <path>] [--version-source <id>] [--output <file>] [--output-path <path>]... [--legacy-kungfu-buildinfo <file>] [--json]
+buildchain facts module [--cwd <dir>] [--module <id>] [--module-root <path>] [--version-source <id>] [--output <file>] [--output-path <path>]... [--json]
 ```
 
 ### `buildchain facts verify`
@@ -2270,17 +2248,6 @@ buildchain release-propagation <plan|write-lock|work|entry|pickup> ...
 buildchain release-tail
 ```
 
-### `buildchain release-tail compat`
-
-- Help: `buildchain release-tail compat --help`
-- Canonical id: `release-tail`
-- Options: `--hooks-json`, `--output`
-- Syntax:
-
-```text
-buildchain release-tail compat --hooks-json <json-or-path> [--output <path>]
-```
-
 ### `buildchain release-tail init`
 
 - Help: `buildchain release-tail init --help`

package/docs/cli.md

@@ -211,7 +211,7 @@ The safety and authority boundary is explicit:
   coordinates, and the repository Actions/generated-write policy under one
   digest. A floating Buildchain ref cannot change release policy after that
   authority is accepted.
-- The reusable `check.yml` detects publication-artifact repositories and runs
+- The reusable `public-build-check.yml` detects publication-artifact repositories and runs
   `paper preflight --offline --ci` inside the existing required check context.
   Skipping the local CLI therefore cannot admit a missing entry contract,
   drifted Buildchain-owned surface, unsafe source branch, or wrong PR target.
@@ -226,7 +226,7 @@ The safety and authority boundary is explicit:
   fixes the bootstrap version at `0.0.0-bootstrap.0`, and returns only npm URLs
   observed from command output. Success requires public package readback and
   the exact repository/workflow/environment trusted-publisher binding. For
-  GitHub, the npm coordinate is the workflow filename (`paper-release.yml`),
+  GitHub, the npm coordinate is the workflow filename (`public-release-paper.yml`),
   not its `.github/workflows/` repository path.
 - `build` plans the two-clean-build reproducibility proof. Add `--execute` to
   create and verify the sealed publication bundle.
@@ -712,7 +712,7 @@ buildchain publication-artifact npm-package --json
 This command reads `project.type = "publication-artifact"`,
 `publication.version`, and `[publish] kind = "npm-paper-package"` plus
 `publish.package`; it writes `.buildchain/publication/npm-package` by default.
-The `paper-release.yml@v3` reusable workflow uses the same command before
+The `public-release-paper.yml@v3` reusable workflow uses the same command before
 running the standard npm publish transaction.
 
 The command writes `.buildchain/publication/publication-artifact.json`,
@@ -1030,7 +1030,7 @@ buildchain transaction inspect --version v4.0.1-alpha.2
 
 It reads or locally initializes the durable transaction record and validates
 available publish evidence. Remote durable refs and public Git ref finalization
-remain owned by `actions/promote-buildchain-ref`; the CLI inspection surface is
+remain owned by `actions/release/promotion/ref`; the CLI inspection surface is
 for preflight and recovery reasoning before a maintainer reruns or resumes a
 promotion.
 
@@ -1068,7 +1068,7 @@ transaction that promotes release refs:
 The promotion workflow uses npm Trusted Publishing through GitHub Actions OIDC.
 It runs on a GitHub-hosted runner with `id-token: write`, but it does not
 manually run the release-candidate resolver or promote action. Buildchain's own
-dogfood path calls the declarative `release-candidate-promote.yml` wrapper with
+dogfood path calls the declarative `public-release-promote.yml` wrapper with
 channel, target ref/SHA, PR-stage workflow, artifact, status-check, and passport
 inputs. The wrapper generates the version-state commit, runs
 `lifecycle.verify`, runs `lifecycle.publish`, writes Buildchain publish
@@ -1076,7 +1076,7 @@ evidence, validates that evidence, and only then moves exact tags and floating
 refs.
 
 ```bash
-node scripts/npm-publish-transaction.mjs
+node packages/core/publication/commands/npm-publish-transaction.mjs
 ```
 
 Before the first real release, configure npm Trusted Publishing for:

package/docs/code-organization.md

@@ -0,0 +1,131 @@
+---
+status: active
+period: ongoing
+theme: buildchain-layered-architecture
+doc_type: implementation-guide
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: B
+review_state: unreviewed
+last_reviewed: 2026-09-10
+ai_provenance:
+  model_family: GPT-6
+  product: Codex
+  generated_at: 2026-09-10
+  visible_context: Buildchain 4.1 source, architecture registries and local validation.
+  invisible_context_boundary: No unpublished release or external consumer qualification is claimed.
+---
+
+# Code organization
+
+Buildchain 4.1 uses responsibility layers, then capability directories. The
+reusable workflow is the primary consumer API. This development line is
+`4.1.0-alpha.0`; these changes do not themselves publish an alpha release.
+
+```text
+.github/workflows/                 Consumer APIs and hosted job topology
+  public-*.yml, build.yml           Public reusable contracts
+  .*.yml                           Internal reusable job components
+  self-*.yml                       Buildchain event callers
+
+actions/<capability>/<group>/<operation>/
+                                   Composite or Node action adapter
+  action.yml                       Node inputs, outputs and external actions
+  index.js                         Minimal Node action entry, when needed
+  dist/                            Generated Node action bundle
+
+packages/core/<capability>/         JavaScript business modules and provider IO
+  <responsibility>/                Named business transactions and adapters
+  cli/                             CLI command handlers
+  commands/                        Executable capability tools
+
+crates/buildchain-domain-contracts/ Rust domain decisions and state contracts
+crates/buildchain-host-bridge/      Native Node host boundary
+contracts/                         Public schemas and contract fixtures
+architecture/                      Ownership, topology and enforced budgets
+bin/                               Minimal CLI entry
+scripts/                           Repository generation and verification tools
+tests/                             Behavioral, contract and failure-path tests
+```
+
+The closed capability vocabulary is declared in
+[`code-layout.json`](../architecture/code-layout.json). A workflow owns runner,
+job dependencies, permissions, environments and semantic node order. It does
+not embed business scripts. A composite owns GitHub step composition, including
+checkout, artifact transfer and external actions. JavaScript owns the node's
+business implementation; Rust/WASM retains the existing authoritative domain
+implementations. No JavaScript replacement is permitted for a Rust-owned domain.
+
+Action ownership is declared in
+[`action-taxonomy.json`](../architecture/action-taxonomy.json), including every
+allowed group and operation. The directory has three meaningful levels:
+capability, responsibility group, and reusable operation. It does not contain
+one directory per workflow or one action per old script step.
+
+| Capability                 | Responsibility groups and examples                                                                                     |
+| -------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| `build`                    | Lifecycle, source qualification, artifacts, signing, credentials, gates, standalone binaries, demos and Stage Capsules |
+| `dev-delivery`             | Candidate admission, native execution, Warrant transitions and protected queue landing                                 |
+| `release`                  | Source promotion, candidate recovery, release lines, propagation, resealing and tail settlement                        |
+| `publication`              | Candidate evidence, authority admission, npm, binary publication and terminal settlement                               |
+| `governance`               | Repository audits, incidents, alpha and stable candidate policy                                                        |
+| `providers`                | GitHub credentials and API access, source checkout, AWS access, artifact transfer and signing providers                |
+| `runtime`                  | Exact runtime selection, environment, locked dependencies and toolchains                                               |
+| `observability`            | Controller evidence and immutable evidence retention                                                                   |
+| `paper`, `web`, `adoption` | Product-specific publication, deployment and consumer qualification                                                    |
+| `workflow`                 | Event admission, Bootstrap and the admitted candidate engine                                                           |
+
+For example, `actions/release/line/open` composes shared source, credential and
+line actions. Its JavaScript transaction coordinates line policy and provider
+readbacks through named modules. `actions/providers/github/token` is shared
+where an App token and fallback policy are needed; ordinary JSON parsing is a
+module function, not a separate action.
+
+A Node action has an explicit input/output contract and one named entry API.
+The adapter parses inputs and emits outputs; the core transaction owns ordering,
+validation, failure evidence and recovery. Modules import other modules directly.
+They do not invoke another action bundle or a generic script executor. Where an
+external action requires a separate GitHub step, the composite owns that step;
+pure internal operations stay inside the transaction.
+
+Capabilities already implemented in JavaScript remain explicitly declared as
+such in the state-machine manifest. Moving a file does not qualify a new Rust
+writer or transfer production authority.
+
+The development delivery API has six semantic nodes: source admission,
+reservation, native execution, qualification, settlement, and landing. Its
+actions are grouped under `dev-delivery/candidate`, `dev-delivery/native`,
+`dev-delivery/warrant`, and `dev-delivery/queue`.
+Buildchain invokes this public delivery workflow from the same source commit, so
+its workflow, action paths and runtime modules share one implementation identity.
+The native node runs in separate hosted jobs where the trust boundary requires
+process and credential isolation.
+Dispatch carries exact source-run coordinates and content roots. When the path
+array is omitted, source admission reconstructs the complete Git diff from the
+successful PR run and verifies its source identity root. Later nodes read the
+verified source proof, so large changes do not exceed provider dispatch limits. A semantic node need not mean one runner.
+
+Promotion enters the public workflow through one closed `request-json` contract,
+then QUALIFY, APPLY and SETTLE. Paper owns its publication plan and final receipt;
+the candidate build receipt is an input to that publication proof.
+
+Dependencies point down the layers. Core modules cannot import actions,
+workflows, CLI entries or repository tooling. A moved business implementation
+has one current owner; imports bind directly to that owner. Retired aliases,
+compatibility wrappers, command-hook fallbacks and old execution switches are
+removed. Immutable release and qualification evidence remains historical data.
+
+`pnpm run check:layout` checks the closed directory vocabulary, action registry,
+entry sizes, node budgets, import direction and reachable JSON input fields.
+Workflows allow at most eight steps per job and no inline business scripts;
+composites allow at most 160 implementation lines and only `uses` steps.
+Neither workflow nor composite YAML may contain `run`, `shell`, or
+`with.script`. Node action entries contain at most twelve lines.
+The maintainability and internal architecture gates additionally enforce module,
+function, dependency and test ownership budgets. Required review covers those
+gates as well as their manifests.
+
+After changing an entry or module, regenerate workflows, public references and
+site facts, rebuild Node action bundles, and run `pnpm run check`. Distribution
+and a clean consumer must resolve the same declared implementation files.

package/docs/consumer-issue-reporting.md

@@ -45,7 +45,7 @@ The recommended pattern is:
     owner: kungfu-systems
     repositories: buildchain
 
-- uses: kungfu-systems/buildchain/actions/report-buildchain-issue@v3
+- uses: kungfu-systems/buildchain/actions/governance/incident/report@v3
   if: failure()
   with:
     token: ${{ steps.buildchain-issue-token.outputs.token }}

package/docs/dev-alpha-candidate-patrol.md

@@ -97,7 +97,7 @@ Cut authority for an already-open legacy PR.
 
 ## Reusable workflow
 
-Call `.github/workflows/dev-alpha-candidate-patrol.yml` from a thin repository
+Call `.github/workflows/public-ops-alpha-candidate-patrol.yml` from a thin repository
 workflow. Start with `dry-run: true`. The reusable workflow always runs an
 `observe` job with only Actions/content/pull-request read permissions. Once the
 repository has proven that its two workflow names and branch topology produce

package/docs/dev-delivery-orchestration.md

@@ -0,0 +1,116 @@
+---
+status: active
+period: ongoing
+theme: dev-delivery-orchestration
+doc_type: technical-reference
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: B
+review_state: unreviewed
+last_reviewed: 2026-09-09
+ai_provenance:
+  model_family: GPT-6
+  product: Codex
+  generated_at: 2026-09-09
+  visible_context: Delivery workflows, composite nodes, authority scripts, and structural conservation tests.
+  invisible_context_boundary: No private credentials or unobserved provider execution state.
+---
+
+# Dev delivery orchestration
+
+`public-ops-dev-auto-merge.yml` orchestrates six owned delivery nodes. The
+published `public-ops-dev-auto-merge.yml` entry remains its generated compatibility
+projection, with the same inputs, outputs, job identities, concurrency and
+permissions. Node ownership and the orchestration size budget are declared in
+[`architecture/dev-delivery-orchestration.json`](../architecture/dev-delivery-orchestration.json).
+
+| Node                | Owning composite                                              | Result and continuation                                                                                                                                                                 |
+| ------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Source admission    | [source](../actions/dev-delivery/candidate/admit/action.yml)   | Resolve one runtime SHA; check exact source eligibility; produce the Source Qualification Proof or an explicit failed qualification outcome.                                            |
+| Reservation         | [reserve](../actions/dev-delivery/candidate/reserve/action.yml) | Submit the candidate and select or recover its exact Warrant. A different active owner receives a handoff; an already-qualified owner skips native execution.                           |
+| Native verification | [native](../actions/dev-delivery/native/dispatch/action.yml)   | Execute or reuse native proof, independently seal its transfer, and maintain the durable lease in three distinct hosted jobs.                                                           |
+| Qualification       | [qualify](../actions/dev-delivery/candidate/qualify/action.yml) | Read back provider job boundaries and heartbeat continuity; validate proof and current source/base; atomically qualify the same Warrant.                                                |
+| Landing             | [land](../actions/dev-delivery/queue/land/action.yml)       | Recheck admission and enqueue or directly merge according to the existing policy. Publish artifacts and enforce the final result even after a predecessor fails.                        |
+| Settlement          | [settle](../actions/dev-delivery/warrant/settle/action.yml)   | Settle independently verified native failure, or process a later provider terminal event through `public-ops-warrant-close.yml`. Clear only the exact authority and wake its successor. |
+
+The six nodes describe ownership, not six new runner allocations. Source and
+reservation share the existing admission job. Qualification, native-failure
+settlement and landing share the existing fresh provider finalizer. Native
+execution, sealing and heartbeat retain their separate hosted jobs and original
+provider-visible names. Composite actions do not provide runner or credential
+isolation themselves.
+
+```mermaid
+flowchart LR
+  S[Source admission] --> R[Reservation]
+  R --> N[Native verification]
+  N --> Q[Independent qualification]
+  Q --> L[Protected landing]
+  L -. Provider terminal event .-> T[Settlement]
+  Q -- Verified native failure --> T
+  T -. Wake successor .-> R
+```
+
+## Contracts and authority
+
+Each node receives `request-json`, the typed workflow inputs serialized with
+`toJSON(inputs)`. Nodes use `fromJSON` to retain boolean and numeric semantics;
+`false` must never become a truthy string. Dependent jobs also pass `needs-json`
+with exact admitted outputs and job results. Within a job, explicit scalar
+ports carry predecessor proof roots and step outcomes. These internal ports are
+listed in the ownership contract; no node serializes the entire step context or
+receives secrets inside the request envelope.
+
+The workflow first checks out its own implementation using
+`job.workflow_repository` and `job.workflow_sha`, without persisted credentials.
+Its local composites therefore come from the exact workflow definition, including
+when another repository calls it. Separately, source admission resolves the
+requested Buildchain runtime once. All later runtime checkouts continue using
+that admitted SHA and its rooted selection readback. The implementation checkout
+never replaces the existing runtime selection authority.
+
+The native node's literal `phase` is `execute`, `seal`, or `heartbeat`, selected
+by the fixed owning job. Only the heartbeat invocation receives a provider write
+token. Native and seal retain their original read-only job permissions and
+credentialless execution contracts. The settlement node's `phase` is
+`native-failure` in the verified finalizer or `terminal` in the asynchronous
+close workflow. A queue admission cannot select terminal settlement by itself.
+
+## Failure and recovery
+
+The original `off`, `shadow`, `required`, dry-run, universal-bootstrap,
+proof-reuse, legacy handoff and deferred-landing paths remain in their owning
+nodes. A node boundary does not grant new retry or cleanup authority. Resume
+continues to require the exact candidate, live fence and verified reusable proof
+under the [Warrant contract](dev-delivery-warrant.md).
+
+Reservation and landing receive the parent job's `job.status == 'success'` result explicitly. Their reporting
+runs unconditionally, but mutation cannot run after an earlier node has
+failed. The final result still checks native execution, sealing, heartbeat,
+qualification, exact failure settlement and targeted admission separately.
+Successful enqueue remains an intermediate state: the terminal workflow is
+invoked only when terminal provider evidence is available, possibly in another
+workflow run.
+
+## Verification
+
+`tests/dev-delivery-orchestration.test.mjs` expands only reachable composite
+calls, resolves their predecessor ports, and compares the complete operation
+sequence against hashes of the protected pre-refactor workflows. Normalization
+ignores only YAML separator blank lines, explicit default Bash and optional expression delimiters
+on conditions. Literal body whitespace is preserved. Commands, guards, artifacts, public contracts and job boundaries
+remain part of the comparison. Negative tests change a provider command and
+remove a proof guard to prove that the conservation check rejects both.
+
+Existing source-admission and credential-boundary tests inspect that expanded
+call graph. Additional checks enforce six owned nodes, bounded orchestration,
+exact implementation checkout, phase routing, token separation and unconditional
+failure reporting. This static and unit evidence does not claim that every
+provider failure or cancellation has been reproduced in a hosted run.
+
+The node contract also caps each composite and their combined line count, so
+extracting steps cannot hide an unbounded implementation behind a thin entry.
+Release topology reads the same reachable call graph; facade regeneration
+preserves the node-owned source even with `--fresh`, while frozen terminal
+facade semantics remain verified.

package/docs/dev-delivery-qualification-landing-adr.md

@@ -231,7 +231,7 @@ skipped, nonterminal, or cross-PR predecessors.
 - Generated references: [`cli-reference.md`](cli-reference.md) and
   [`node-api-reference.md`](node-api-reference.md).
 
-The existing public `dev-pr-auto-merge.yml` reusable workflow remains the
+The existing public `public-ops-dev-auto-merge.yml` reusable workflow remains the
 single-flight v1 controller and does not advertise v2 Landing guarantees.
 Bounded v2 is a separate opt-in controller contract built from the public CLI,
 Node API, and schema; merely calling the v1 reusable workflow never enables or

package/docs/dev-delivery-warrant.md

@@ -28,6 +28,9 @@ advances the ref without force. The transition receipt binds the expected old
 state root; a competing controller receives a visible non-fast-forward failure
 instead of a second authority claim.
 
+The [six-node orchestration](dev-delivery-orchestration.md) documents workflow
+ownership, cross-node contracts, execution isolation and recovery boundaries.
+
 ## Contract
 
 A submission binds the repository, protected dev line, pull request, semantic
@@ -338,7 +341,7 @@ write-normalize-observe-remutate cycle: `transferRoot`,
 `providerTerminalReadbackRoot`.
 
 Buildchain's tracked self-delivery caller invokes
-`kungfu-systems/buildchain/.github/workflows/dev-pr-auto-merge.yml@v4-alpha`.
+`kungfu-systems/buildchain/.github/workflows/public-ops-dev-auto-merge.yml@v4-alpha`.
 The durable selector remains the floating alpha channel, the repository keeps
 matching `.buildchain/contract-lock.json` (`v4`) and
 `.buildchain/alpha-contract-lock.json` (`v4-alpha`), and a train runtime may be
@@ -399,7 +402,7 @@ native proof or reuse authority. Phase-less native candidates remain invalid.
 
 ## Workflow rollout and rollback
 
-The reusable `dev-pr-auto-merge.yml` supports three explicit rollout modes:
+The reusable `public-ops-dev-auto-merge.yml` supports three explicit rollout modes:
 
 - `off` preserves the previous exact-head admission controller;
 - `shadow` qualifies the source and emits a read-only queue submission plan;

package/docs/dev-qualification-patrol.md

@@ -45,7 +45,7 @@ without consuming the shared native runners.
 
 ## Exact-source and priority contract
 
-Call `.github/workflows/dev-qualification-patrol.yml` from a thin consumer
+Call `.github/workflows/public-ops-dev-qualification-patrol.yml` from a thin consumer
 workflow after the lightweight preflight, Dev Patrol, and declared priority
 workflows complete. Add an offset schedule as recovery for delayed or missed
 GitHub events. Repeated wakeups are idempotent.