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

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-11
 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.
 
@@ -168,14 +170,14 @@ replace them.
 | How do ephemeral GitHub-hosted runners share exact dependency or compiler caches without fixed-runner affinity? | [`cli.md`](cli.md#commands) | use/verify | preview |
 | How do I validate an unreleased Buildchain runtime train while keeping `@v3`? | [`runtime-train-validation.md`](runtime-train-validation.md) | use | stable |
 | How do v4 consumers keep floating selectors while proving exact runtime and lock identity? | [`reusable-build-surface.md`](reusable-build-surface.md#v4-floating-consumer-admission) | verify/use | preview |
-| How can a trusted v4 run use a transient exact runtime and resume sealed Stage Capsules after a floating ref moves? | [`v4-runtime-ref-resume-authority.md`](v4-runtime-ref-resume-authority.md) | use/verify | preview |
+| How does the public entry select a runtime and recover with a repaired train? | [`runtime-entry.md`](runtime-entry.md) | use/verify | preview |
 | How do I automatically qualify alpha candidates and publish the newest non-revoked qualified candidate at a fixed window? | [`stable-candidate-patrol.md`](stable-candidate-patrol.md) | use | preview |
 | 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 |
@@ -212,7 +214,7 @@ replace them.
   [`reusable-build-surface.md`](reusable-build-surface.md#artifact-transfer-relay).
 - **local Git checkout cache / self-hosted source transport** ->
   [`reusable-build-surface.md`](reusable-build-surface.md#locked-source-checkout-cache).
-- **runtime train validation / temporary `buildchain-ref` override** ->
+- **runtime train validation / temporary `runtime-ref` override** ->
   [`runtime-train-validation.md`](runtime-train-validation.md) and
   [`reusable-build-surface.md`](reusable-build-surface.md).
 - **consumer workflow feedback / automatic Buildchain GitHub issues** ->

package/docs/auditable-demo.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: self-reviewed
-last_reviewed: 2026-08-05
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -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@v4
     with:
       source-ref: ${{ github.sha }}
       binary-artifact-name: ${{ needs.exact-binary.outputs.artifact-name }}
@@ -215,7 +215,7 @@ non-symlink, executable file inside the exact checked-out consumer source.
 
 The Gate:
 
-- checks out the exact consumer source and exact called-workflow SHA;
+- prepares the selected execution runtime and checks out the exact consumer source;
 - resolves and downloads one exact same-run GitHub Artifact;
 - invokes the checked-in adapter by argv, never as an evaluated shell string;
 - rejects undeclared adapter outputs, symlinks, invalid UTF-8, invalid scene or
@@ -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@v4
     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`
@@ -1840,11 +1818,11 @@ buildchain paper preflight [--cwd <dir>] [--offline] [--json]
 
 - Help: `buildchain paper resume --help`
 - Canonical id: `paper-resume`
-- Options: `--buildchain-ref`, `--cwd`, `--execute`, `--json`
+- Options: `--cwd`, `--execute`, `--json`, `--runtime-ref`
 - Syntax:
 
 ```text
-buildchain paper resume [--cwd <dir>] [--buildchain-ref <ref>] [--execute] [--json]
+buildchain paper resume [--cwd <dir>] [--runtime-ref <ref>] [--execute] [--json]
 ```
 
 ### `buildchain paper scaffold`
@@ -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,132 @@
+---
+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-11
+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.1`; 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 consumes the same public floating entry as other repositories. The
+entry selects one runtime through the shared runtime entry; every business
+action and module comes from that selection, independently of the entry SHA.
+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/controller-evidence.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-07-14
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -80,7 +80,7 @@ Reusable workflows expose these outputs:
   `controller-receipt-digest`, and `controller-receipt-status`.
 
 Final aggregation uses `always()`. A required missing stage, required missing
-evidence, invalid digest, source/runtime mismatch, or missing receipt cannot be
+evidence, invalid digest, source mismatch, or missing receipt cannot be
 reported as qualifying green. `aggregateControllerReceipts()` reports an
 explicit `receipt-missing` status when a plan has no receipt.
 

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

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: self-reviewed
-last_reviewed: 2026-08-11
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -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
@@ -128,15 +128,15 @@ the rendered bytes. Concurrent qualification progress therefore fails closed
 and is recomputed by the next patrol instead of attaching a declaration to the
 wrong candidate.
 
-The separately permissioned `settle` job checks out the exact Buildchain runtime
-commit used by `observe`, re-runs the exact observation, and compare-and-swap
+The separately permissioned `settle` job prepares the entry-selected runtime,
+re-runs the exact observation, and compare-and-swap
 checks the selected SHA, prior controller root and Release Cut root before any
 write. With no active managed candidate, it reads the candidate tree and creates
 one rooted Release Cut before it creates one branch named from
 the target branch and the first 12 characters of the full source SHA. An
 existing branch must point to the same full SHA or the run fails. With one
-active managed candidate, it validates the candidate ref, tree, Alpha base and
-runtime before returning that same SHA to every checkout/build consumer. It only
+active managed candidate, it validates the candidate ref, tree and Alpha base
+before returning that source SHA to every checkout/build consumer. It only
 updates the machine-readable state marker when a new dev observation or hold
 receipt must be persisted. Repeated events and rapid dev progress cannot create
 another candidate PR or another heavy candidate build. Foreign human-authored