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

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

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: self-reviewed
-last_reviewed: 2026-08-17
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -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;
@@ -505,26 +508,16 @@ root still match. A delayed `dequeued` event is ignored when GitHub readback
 shows the same exact PR head is already queued again, so an earlier queue event
 cannot close a newer active Warrant generation.
 
-Buildchain uses the same contract for its own protected dev line through
-`self-ops-dev-delivery.yml`. The manual caller requires the exact PR head and
-semantic source roots, accepts an optional reusable native proof, keeps both
-the durable public selector and explicit runtime input on `v4-alpha`, selects
-`delivery-warrant-mode: required`, and targets GitHub Merge Queue. It does not
-offer an `off` switch: rollback is a reviewed change to this caller, not an
-operator-time weakening of a specific delivery attempt.
-
-`templates/native-dev-delivery.yml` provides the corresponding protected-dev
-consumer workflow. It supports both explicit dispatch and the bounded wake
-event, calls the allowed floating `@v4-alpha` selector, explicitly passes the v4
-runtime ref that locks every delivery job to the same checkout, and keeps the
-native command in the consumer repository rather than inventing
-provider-specific shards. Both callers explicitly bind the queue-admission
-and active-lease status contexts so write/readback fencing uses the same exact
-names. The reusable workflow defaults the explicit runtime input to
-`v4-alpha`; an empty input or any v3 selector fails before the first runtime
-checkout.
-
-This mechanism schedules protected delivery only. It does not serialize local
-development, source-only checks, unrelated channels, release publication, or
-runner provisioning. It never grants authority to enable cloud runner
-campaigns.
+Buildchain uses the same public contract for its protected dev line through
+`self-ops-dev-delivery.yml`. The caller keeps the durable selector on `@v4`,
+requires exact PR source roots, and selects `delivery-warrant-mode: required`.
+The central runtime entry selects and prepares execution code. Explicit transient
+runtime selection can choose a repaired train without changing the persisted
+caller. There is no per-attempt Warrant bypass.
+
+`templates/native-dev-delivery.yml` supplies the corresponding consumer workflow.
+It supports explicit dispatch and the bounded wake event, preserves the native
+command in the consumer repository, and binds queue-admission and active-lease
+status contexts for provider write/readback fencing. Runtime selection follows
+the shared entry precedence; subsequent delivery nodes do not compare Buildchain
+SHAs.

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.

package/docs/engineering-housekeeper.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: reviewed
-last_reviewed: 2026-08-10
+last_reviewed: 2026-09-11
 ---
 
 # Engineering Housekeeper
@@ -29,7 +29,7 @@ their heads are already ancestors of a mainline.
 The reusable entrypoint is:
 
 ```yaml
-uses: kungfu-systems/buildchain/.github/workflows/engineering-housekeeper.yml@v4
+uses: kungfu-systems/buildchain/.github/workflows/public-ops-housekeeping.yml@v4
 ```
 
 The v4 surface is a traceable forward-port of protected v3 merge
@@ -48,7 +48,7 @@ separate plan, Markdown report, and dry-run receipt artifacts:
 ```yaml
 jobs:
   housekeeper:
-    uses: kungfu-systems/buildchain/.github/workflows/engineering-housekeeper.yml@v4
+    uses: kungfu-systems/buildchain/.github/workflows/public-ops-housekeeping.yml@v4
     permissions:
       contents: read
       pull-requests: read
@@ -89,7 +89,7 @@ An unattended scheduled caller can set both values in committed policy.
 ```yaml
 jobs:
   housekeeper:
-    uses: kungfu-systems/buildchain/.github/workflows/engineering-housekeeper.yml@v4
+    uses: kungfu-systems/buildchain/.github/workflows/public-ops-housekeeping.yml@v4
     permissions:
       contents: write
       pull-requests: write
@@ -127,8 +127,8 @@ continue.
 | `stale-pull-request-label`  | string  | empty                       | Empty keeps pull requests report-only; non-empty permits labeling, never closure. |
 | `max-actions`               | number  | `20`                        | Positive global apply limit.                                                      |
 | `artifact-retention-days`   | number  | `30`                        | Retention for plan, report, and receipts.                                         |
-| `buildchain-repository`     | string  | `kungfu-systems/buildchain` | Runtime source repository.                                                        |
-| `buildchain-ref`            | string  | `v4`                        | Runtime ref; trusted qualification may pass a train or exact SHA.                 |
+| `runtime-ref` | string | empty | Transient runtime selected by the central entry; otherwise use the lock or entry default. |
+| `contract-lock` | string | empty | Optional consumer-relative contract lock path. |
 
 Stable outputs are `plan-root`, `report-receipt-root`, optional
 `branch-receipt-root` and `pull-request-receipt-root`, `action-count`,

package/docs/github-artifact-attestation.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-07-24
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -37,7 +37,7 @@ Passport have been sealed and uploaded. It downloads those files as data and
 never checks out or executes consumer source.
 
 The attester checks out only
-`actions/github-artifact-attestation` from an exact Buildchain commit. It
+`actions/build/artifact/github-attest` from an exact Buildchain commit. It
 rejects a floating Buildchain ref, a different caller repository, a different
 source SHA, a different workflow run, a non-Linux platform manifest, or a
 subject digest absent from the Release Passport.
@@ -137,9 +137,8 @@ permissions:
 
 jobs:
   promote:
-    uses: kungfu-systems/buildchain/.github/workflows/release-candidate-promote.yml@<exact-buildchain-v3-runtime-sha>
+    uses: kungfu-systems/buildchain/.github/workflows/public-release-promote.yml@v4
     with:
-      buildchain-ref: <exact-buildchain-v3-runtime-sha>
       github-release: true
       release-passport: true
       github-artifact-attestation-policy-json: .buildchain/release-candidate/payload/<artifact>/policy.json
@@ -147,14 +146,14 @@ jobs:
 ```
 
 Promotion binds the policy into the Passport, stages only digest-matching data,
-calls the exact v3 signer, verifies the provider identity a second time, and
+calls the public signer entry, verifies the provider identity a second time, and
 publishes immutable bundle, predicate, verification, evidence, and receipt
 assets beside the release artifact. A same-name Release asset with different
 bytes is rejected instead of overwritten.
 
 Low-level callers may call the reusable attester directly after their Passport
-job. Both the reusable workflow ref and `buildchain-ref` use the same exact
-40-hex signer-bootstrap commit and fail closed if the provider identity differs:
+job. The public entry selects the execution runtime through the same contract as
+build and release. Provider signer identity and subject digests remain mandatory:
 
 ```yaml
 jobs:
@@ -166,9 +165,8 @@ jobs:
       attestations: write
       contents: read
       id-token: write
-    uses: kungfu-systems/buildchain/.github/workflows/github-artifact-attestation.yml@<exact-signer-bootstrap-sha>
+    uses: kungfu-systems/buildchain/.github/workflows/public-release-artifact-attestation.yml@v4
     with:
-      buildchain-ref: <exact-signer-bootstrap-sha>
       evidence-run-id: ${{ github.run_id }}
       source-sha: ${{ github.sha }}
       subject-artifact-name: linux-release
@@ -191,10 +189,9 @@ custom predicate, and Buildchain evidence root:
 
 The reusable workflow runs that same exact signer/source verification
 immediately after `actions/attest` and before it finalizes or uploads evidence.
-Passing a different `buildchain-ref` than the commit used to invoke the reusable
-workflow therefore fails in the signer job, not only during later consumption.
-The policy additionally retains the distinct Buildchain runtime SHA that
-created the build and release evidence.
+The provider signer commit identifies the workflow that issued the attestation.
+The selected execution runtime is separate provenance and may differ. Subject,
+signer and evidence-root verification does not compare entry and runtime SHAs.
 
 ```bash
 buildchain verify github-artifact-attestation \

package/docs/github-governance-authority.md

@@ -8,7 +8,7 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-07-31
+last_reviewed: 2026-09-11
 ai_provenance:
   model_family: GPT-5
   product: Codex
@@ -125,9 +125,9 @@ buildchain audit github-governance \
 ```
 
 Protected merge and publication consumers verify the receipt against the exact
-repository, target base ref, policy root, freshness window, and exact
-Buildchain verifier source revision. Non-dry-run publication does not trust a
-caller-supplied JSON hash: it mints a bounded token for the dedicated read-only
+repository, target base ref, policy root and freshness window. The selected
+runtime revision is recorded as provenance, without a downstream SHA comparison.
+Non-dry-run publication does not trust a caller-supplied JSON hash: it mints a bounded token for the dedicated read-only
 governance auditor GitHub App, recollects live provider state with the exact
 Buildchain runtime, requires the resulting single-repository/single-target
 audit to qualify, and consumes that independently generated receipt. Missing

package/docs/kfd-support.md

@@ -111,7 +111,7 @@ uses KFD-1 for its runtime contract, release-passport schemas, packaged docs,
 Node exports, workflows, actions, and site-consumption facts.
 
 For Buildchain itself, the source registry lives in
-`packages/core/buildchain-kfd-claims.js` and is projected to
+`packages/core/adoption/buildchain-kfd-claims.js` and is projected to
 `dist/site/kfd-claims.json`. Release promotion binds that registry to exact
 source and artifact hashes in the release passport.
 

package/docs/lifecycle-protocol.md

@@ -205,7 +205,7 @@ git diff --check
 `lifecycle.check` is the repository-owned source-acceptance gate. It should
 validate the checked-out source revision without entering the build, artifact,
 or release lifecycle. Consumers can run it on GitHub-hosted Linux through
-`.github/workflows/check.yml@v3` with `mode: source`; the reusable workflow runs
+`.github/workflows/public-build-check.yml@v3` with `mode: source`; the reusable workflow runs
 only `lifecycle.install` and `lifecycle.check`. The default `mode: verify`
 continues to run `lifecycle.install` and `lifecycle.verify` for existing callers.
 Both executed stages receive `BUILDCHAIN_CHECK_MODE=source` or
@@ -246,7 +246,7 @@ disabled by default.
 ```yaml
 jobs:
   source-acceptance:
-    uses: kungfu-systems/buildchain/.github/workflows/check.yml@<exact-sha>
+    uses: kungfu-systems/buildchain/.github/workflows/public-build-check.yml@<exact-sha>
     with:
       mode: source
       source-proof-reuse: true
@@ -290,7 +290,7 @@ node scripts/write-publish-evidence.mjs
 """
 ```
 
-When `actions/promote-buildchain-ref` runs with `publish-transaction: "true"`,
+When `actions/release/promotion/ref` runs with `publish-transaction: "true"`,
 the publish stage receives the transaction identity plus the resolved publish
 contract:
 
@@ -336,7 +336,7 @@ any publish transaction side effect.
 
 ## Promotion Semantics
 
-`actions/promote-buildchain-ref` consumes `version.files`, `lifecycle.verify`,
+`actions/release/promotion/ref` consumes `version.files`, `lifecycle.verify`,
 and optionally `lifecycle.publish`.
 
 The verify stage runs after Buildchain has applied the generated version-state
@@ -390,7 +390,7 @@ Buildchain preserves the platform-default shell for compatibility.
 ## Migration Preflight
 
 Heavy repositories can validate their Buildchain declaration before they are
-ready to run the real build. `actions/validate-config` checks that
+ready to run the real build. `actions/build/lifecycle/validate` checks that
 `.buildchain/buildchain.toml` parses, configured version-state files exist, configured
 version keys are strings, and required lifecycle stage names are declared.
 For web-surface repositories it also validates `project`, `channels`, `deploy`,
@@ -402,7 +402,7 @@ build and the first migration milestone is to prove the release metadata and
 lifecycle protocol without consuming build runners.
 
 ```yaml
-- uses: kungfu-systems/buildchain/actions/validate-config@v3
+- uses: kungfu-systems/buildchain/actions/build/lifecycle/validate@v3
   with:
     require-version-state: "true"
     require-lifecycle-stages: "install,build,verify"
@@ -412,7 +412,7 @@ Web-surface repositories can use the same action without requiring version
 state:
 
 ```yaml
-- uses: kungfu-systems/buildchain/actions/validate-config@v3
+- uses: kungfu-systems/buildchain/actions/build/lifecycle/validate@v3
   with:
     require-lifecycle-stages: "build,verify"
 ```
@@ -587,7 +587,7 @@ The lifecycle protocol is also the command source for the reusable build
 surface. `.github/workflows/.build.yml` runs `lifecycle.install`,
 `lifecycle.build`, and `lifecycle.verify` by default, while allowing callers to
 override each stage with explicit workflow inputs. The underlying
-`actions/run-lifecycle` action can be used directly by repositories that need a
+`actions/build/lifecycle/run` action can be used directly by repositories that need a
 custom workflow but still want Buildchain's lifecycle and deterministic manifest
 contract.
 

package/docs/migration-inventory.md

@@ -52,7 +52,7 @@ surface. New publish integrations should use `.build.yml`, `buildchain.toml`,
 Release templates that previously performed direct publishing or deployment are
 now fail-closed when retained for compatibility discovery. They do not call
 legacy publish actions, `npm publish`, or deploy providers directly. Callers must
-migrate to `release-candidate-promote.yml@v3` or a project-owned
+migrate to `public-release-promote.yml@v3` or a project-owned
 `lifecycle.publish` command behind a publish-gate source lock, so floating
 `@v3` consumers cannot bypass source-lock drift protection.
 
@@ -62,7 +62,7 @@ fixes before stable promotion should add `buildchain-channel: auto` plus
 `buildchain-alpha-contract-lock-path` and
 `buildchain-stable-contract-lock-path`. Keep one common promotion declaration;
 do not duplicate alpha and stable jobs or call
-`.release-candidate-promote.yml` directly.
+`.release-promote.yml` directly.
 
 Buildchain also keeps the workflow-file layout transition declarative in
 `.buildchain/promotion-shell-routing.json`. Stable `v2.14.13` contains the hidden
@@ -88,7 +88,7 @@ because the action is part of that retired path.
 | --- | --- |
 | `action-approve` | retired GitHub issue/PR helper; use repository-native GitHub automation |
 | `action-batch-pull-request` | retired PR orchestration helper; not part of the Buildchain reusable contract |
-| `action-bump-version` | replaced by Buildchain release-line scripts and `actions/promote-buildchain-ref` |
+| `action-bump-version` | replaced by Buildchain release-line scripts and `actions/release/promotion/ref` |
 | `action-check-format` | replaced by project-owned `lifecycle.verify` commands |
 | `action-find-dependencies` | retired in workflows v2 or backed by retired Airtable/dependency/collaborator/purge mechanism |
 | `action-generate-download-page` | retired product page generator; model as project-owned lifecycle/deploy work if needed |
@@ -126,9 +126,9 @@ older standalone action repository.
 
 | Buildchain path | Purpose |
 | --- | --- |
-| `actions/promote-buildchain-ref` | governance-closed Buildchain release ref promotion |
-| `actions/run-lifecycle` | lifecycle command execution and deterministic artifact manifest generation |
-| `actions/validate-config` | `buildchain.toml` version-state and lifecycle preflight without executing lifecycle commands |
+| `actions/release/promotion/ref` | governance-closed Buildchain release ref promotion |
+| `actions/build/lifecycle/run` | lifecycle command execution and deterministic artifact manifest generation |
+| `actions/build/lifecycle/validate` | `buildchain.toml` version-state and lifecycle preflight without executing lifecycle commands |
 
 ## Current v3 Refs
 

package/docs/next-development-transition.md

@@ -20,9 +20,9 @@ ai_provenance:
 # Next-development Transition
 
 This document is generated from
-`packages/core/next-development-transition.js` and
-`packages/core/next-development-controller.js` and
-`packages/core/next-development-projection.js`. Edit those sources and run
+`packages/core/release/next-development-transition.js` and
+`packages/core/release/next-development-controller.js` and
+`packages/core/release/next-development-projection.js`. Edit those sources and run
 `node scripts/generate-next-development-guidance.mjs`; direct edits fail the
 projection drift check.
 
@@ -118,7 +118,7 @@ remain audit evidence and never become durable selectors.
 From a normal Buildchain checkout:
 
 ```sh
-node scripts/next-development-transition.mjs materialize --cwd . --input <request.json>
+node packages/core/release/commands/next-development-transition.mjs materialize --cwd . --input <request.json>
 ```
 
 The command prints a rooted plan and performs no write by default. `--write`