@kungfu-tech/buildchain 3.0.9-alpha.8 → 4.0.0-alpha.0

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

@@ -343,11 +343,6 @@ JIT SecureString under `/kungfu/burst/macos/`, then runs GitHub Actions Runner
 2.336.0 for exactly one job. The runner archive is pinned to the official
 macOS ARM64 SHA256. No GitHub, signing, notarization, publication, SSH, or
 static AWS credential is admitted to the instance.
-The provider provenance step explicitly disables artifact-signing request
-sealing for these qualification jobs, so consumer signing declarations cannot
-turn a runner-profile smoke or full qualification into a signing-authority
-dispatch. All other Buildchain lanes retain the default fail-closed signing
-declaration behavior.
 
 The instance uses the exact retained Amazon EC2 macOS AMI, IMDSv2, an encrypted
 delete-on-termination root volume, no inbound security-group rule, and the
@@ -357,21 +352,13 @@ job must exercise the full native lifecycle.
 
 AWS imposes a 24-hour minimum Dedicated Host allocation. The contract therefore
 keeps the one host for at least 24 hours even if all three jobs finish earlier.
-At the recorded USD 0.65 hourly rate, the minimum commitment is USD 15.60. A
-30-hour fail-closed ceiling is USD 19.50, below the dedicated
+At the recorded USD 0.6498 hourly rate, the minimum commitment rounds to USD
+15.60. A 30-hour fail-closed ceiling rounds to USD 19.49, below the dedicated
 USD 25 budget. A ten-minute reaper terminates an expired campaign instance and
 retries host release after the minimum allocation and Apple scrub constraints
 allow it. Budget notifications at 80% and 95% invoke the same card-scoped kill
 switch.
 
-The launch controller defaults to `us-east-1` and admits only `us-east-2` as a
-capacity fallback. The regions use mutually exclusive control-plane stacks and
-one shared USD 25 Budget covering Virginia `HostUsage:mac2` and the AWS catalog
-identity `USE2-HostUsage:mac2` for Ohio. A requested region, availability zone,
-stack, and Budget must agree before allocation, and the controller checks both
-regions against one global Host and instance ceiling; no other region is
-accepted.
-
 Qualification requires three trusted exact-source one-job JIT runs on the one
 host, including at least one full run, plus proof that:
 
@@ -385,47 +372,17 @@ 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
-campaign. It has five explicit mutation modes:
+campaign. It has three explicit mutation modes:
 
 - `launch-campaign` binds the exact repository source, AMI, availability zone,
-  tagged Dedicated Host, and reusable instance. Before paid allocation it
-  verifies the exact AWS account, disabled GitHub workflow, complete control
-  plane stack, AWS-dimension-filtered USD 25 Budget, 80% and 95% SNS
-  subscribers, and zero pre-existing Mac capacity. Because AWS does not expose
-  a DryRun parameter for `AllocateHosts`, it requires an allowed IAM policy
-  simulation for the exact tagged allocation before the real call, then a
-  successful `RunInstances` DryRun before launching the instance.
-- `rehydrate-instance` creates a replacement instance on the one already-paid,
-  empty campaign host after an interrupted or failed instance lifecycle. It
-  rechecks the exact account, disabled workflow, Budget, source, host identity
-  and allocation time, zero runner residue, zero active JIT instances, and no
-  other active Mac host in either admitted region. It then requires a
-  successful same-host `RunInstances` DryRun and never calls `AllocateHosts`.
+  tagged Dedicated Host, and reusable instance. It rejects pre-existing Mac
+  capacity and requires successful `AllocateHosts` and `RunInstances` DryRuns
+  before either real call.
 - `run-job` binds one queued exact-source GitHub job to the existing campaign
   host and instance. It writes the repository JIT configuration through a
   mode-0600 temporary file into a distinct SSM SecureString, sends only the
   credential-free bootstrap through SSM, and removes the parameter plus runner
   registration if command delivery fails.
-- `rebind-campaign` repairs the source of an allocated but unused campaign
-  without buying another host. It requires the workflow to remain manually
-  disabled, the replacement source to be a strict descendant on the same
-  campaign ref, and every prior matching run to contain zero jobs and zero
-  artifacts. It also requires no registered JIT runner, SSM parameter, or
-  bootstrap evidence and verifies the one exact host, instance, and encrypted
-  volume. The operation updates only those resources' source tags and the
-  existing GitHub ref, emits a zero-allocation receipt, and compensates back to
-  the prior source if the ref update or readback fails. It never calls
-  `AllocateHosts`, `RunInstances`, or workflow dispatch.
-- `rebind-campaign-after-failure` advances that same host and instance only
-  after the operator confirms the complete prior run-id inventory. Every named
-  run must be terminal with conclusion `failure`, all of its jobs must be
-  complete, and both GitHub artifacts and S3 bootstrap evidence must still be
-  present. The replacement source must remain a strict descendant on the same
-  ref, the workflow must be disabled, the next-source evidence prefix must be
-  empty, and runner plus SSM residue must be zero. The old evidence is retained
-  and included in the rebind receipt; the operation changes only the existing
-  source ref and resource tags, with the same compensated rollback and zero
-  allocation boundary as an unused-campaign rebind.
 - `close-campaign` refuses execution before the provider's 24-hour minimum,
   verifies the encrypted delete-on-termination root volume, removes scoped JIT
   residue, terminates the exact instance, and requires a `ReleaseHosts` DryRun
@@ -435,17 +392,8 @@ campaign. It has five explicit mutation modes:
 
 Every execute mode requires the exact source SHA and campaign id to be repeated
 through `--confirm-source-sha` and `--confirm-campaign-id`. `run-job` also
-requires `--confirm-run-id`; `launch-campaign` additionally requires the
-expected workload account through `--account-id`. `rebind-campaign`
-additionally repeats the prior source, host, and instance identities and
-requires `--confirm-zero-allocation`. `rehydrate-instance` additionally repeats
-the existing host and replaced instance identities and requires
-`--confirm-no-host-allocation`. Omitting `--execute` emits a deterministic plan
+requires `--confirm-run-id`. Omitting `--execute` emits a deterministic plan
 without changing AWS or GitHub state.
-`rebind-campaign-after-failure` additionally requires matching
-`--terminal-failure-run-ids-json` and
-`--confirm-terminal-failure-run-ids-json` arrays so an unobserved or newly
-created run fails closed before any tag or ref mutation.
 
 ## Provider lifecycle
 

package/docs/cli-reference.md

@@ -299,18 +299,7 @@ buildchain dev pr-admit --repository <owner/repo> --branch <dev/vN/vN.M> --pull-
 - Syntax:
 
 ```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
-```
-
-### `buildchain dev proof classify-native`
-
-- Help: `buildchain dev proof classify-native --help`
-- Canonical id: `dev`
-- Options: `--json`, `--output`
-- Syntax:
-
-```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
+buildchain dev proof <source|verify-source|classify|replay|integration|verify-integration> [--output <file>] [--json]
 ```
 
 ### `buildchain dev proof integration`
@@ -321,18 +310,7 @@ buildchain dev proof <source|verify-source|classify|native|verify-native|classif
 - Syntax:
 
 ```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
-```
-
-### `buildchain dev proof native`
-
-- Help: `buildchain dev proof native --help`
-- Canonical id: `dev`
-- Options: `--json`, `--output`
-- Syntax:
-
-```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
+buildchain dev proof <source|verify-source|classify|replay|integration|verify-integration> [--output <file>] [--json]
 ```
 
 ### `buildchain dev proof replay`
@@ -343,7 +321,7 @@ buildchain dev proof <source|verify-source|classify|native|verify-native|classif
 - Syntax:
 
 ```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
+buildchain dev proof <source|verify-source|classify|replay|integration|verify-integration> [--output <file>] [--json]
 ```
 
 ### `buildchain dev proof source`
@@ -354,7 +332,7 @@ buildchain dev proof <source|verify-source|classify|native|verify-native|classif
 - Syntax:
 
 ```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
+buildchain dev proof <source|verify-source|classify|replay|integration|verify-integration> [--output <file>] [--json]
 ```
 
 ### `buildchain dev proof verify-integration`
@@ -365,29 +343,7 @@ buildchain dev proof <source|verify-source|classify|native|verify-native|classif
 - Syntax:
 
 ```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
-```
-
-### `buildchain dev proof verify-native`
-
-- Help: `buildchain dev proof verify-native --help`
-- Canonical id: `dev`
-- Options: `--json`, `--output`
-- Syntax:
-
-```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
-```
-
-### `buildchain dev proof verify-native-reuse`
-
-- Help: `buildchain dev proof verify-native-reuse --help`
-- Canonical id: `dev`
-- Options: `--json`, `--output`
-- Syntax:
-
-```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
+buildchain dev proof <source|verify-source|classify|replay|integration|verify-integration> [--output <file>] [--json]
 ```
 
 ### `buildchain dev proof verify-source`
@@ -398,18 +354,7 @@ buildchain dev proof <source|verify-source|classify|native|verify-native|classif
 - Syntax:
 
 ```text
-buildchain dev proof <source|verify-source|classify|native|verify-native|classify-native|verify-native-reuse|replay|integration|verify-integration> [--output <file>] [--json]
-```
-
-### `buildchain dev two-phase`
-
-- Help: `buildchain dev two-phase --help`
-- Canonical id: `dev`
-- Options: `--branch`, `--expected-head`, `--native-command`, `--native-proof`, `--pull-request`, `--repository`, `--warrant-result`
-- Syntax:
-
-```text
-buildchain dev two-phase --repository <owner/repo> --branch <dev/vN/vN.M> --pull-request <n> --expected-head <sha> --warrant-result <file> [--native-proof <file>] [--native-command <command>]
+buildchain dev proof <source|verify-source|classify|replay|integration|verify-integration> [--output <file>] [--json]
 ```
 
 ### `buildchain dev warrant cancel-queued`
@@ -420,7 +365,7 @@ buildchain dev two-phase --repository <owner/repo> --branch <dev/vN/vN.M> --pull
 - Syntax:
 
 ```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
+buildchain dev warrant <submit|select|heartbeat|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
 ```
 
 ### `buildchain dev warrant close`
@@ -431,7 +376,7 @@ buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-que
 - Syntax:
 
 ```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
+buildchain dev warrant <submit|select|heartbeat|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
 ```
 
 ### `buildchain dev warrant heartbeat`
@@ -442,7 +387,7 @@ buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-que
 - Syntax:
 
 ```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
+buildchain dev warrant <submit|select|heartbeat|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
 ```
 
 ### `buildchain dev warrant observe`
@@ -453,18 +398,7 @@ buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-que
 - Syntax:
 
 ```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
-```
-
-### `buildchain dev warrant qualify`
-
-- Help: `buildchain dev warrant qualify --help`
-- Canonical id: `dev`
-- Options: `--branch`, `--execute`, `--json`, `--output`, `--repository`
-- Syntax:
-
-```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
+buildchain dev warrant <submit|select|heartbeat|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
 ```
 
 ### `buildchain dev warrant recover`
@@ -475,7 +409,7 @@ buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-que
 - Syntax:
 
 ```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
+buildchain dev warrant <submit|select|heartbeat|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
 ```
 
 ### `buildchain dev warrant select`
@@ -486,7 +420,7 @@ buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-que
 - Syntax:
 
 ```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
+buildchain dev warrant <submit|select|heartbeat|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
 ```
 
 ### `buildchain dev warrant submit`
@@ -497,7 +431,7 @@ buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-que
 - Syntax:
 
 ```text
-buildchain dev warrant <submit|select|heartbeat|qualify|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
+buildchain dev warrant <submit|select|heartbeat|recover|close|cancel-queued|observe> --repository <owner/repo> --branch <dev/vN/vN.M> [--execute] [--output <file>] [--json]
 ```
 
 ## `diagnostics`
@@ -1377,11 +1311,11 @@ buildchain lifecycle
 
 - Help: `buildchain lifecycle run --help`
 - Canonical id: `lifecycle`
-- Options: `--artifact-name`, `--artifact-path`, `--cwd`, `--manifest-path`, `--process-summary`, `--required`, `--summary-path`
+- Options: `--artifact-name`, `--artifact-path`, `--cwd`, `--manifest-path`, `--platform-id`, `--platform-name`, `--process-summary`, `--required`, `--summary-path`
 - Syntax:
 
 ```text
-buildchain lifecycle run <stage> [--cwd <dir>] [--required] [--artifact-name <name>] [--artifact-path <path>]... [--manifest-path <path>] [--summary-path <path>] [--process-summary <json>]
+buildchain lifecycle run <stage> [--cwd <dir>] [--required] [--artifact-name <name>] [--artifact-path <path>]... [--platform-id <id>] [--platform-name <name>] [--manifest-path <path>] [--summary-path <path>] [--process-summary <json>]
 ```
 
 ## `log`
@@ -2046,17 +1980,6 @@ buildchain release-tail init --declaration <json-or-path> [--state <path>]
 buildchain release-tail plan --declaration <json-or-path> [--output <path>]
 ```
 
-### `buildchain release-tail rehearse`
-
-- Help: `buildchain release-tail rehearse --help`
-- Canonical id: `release-tail`
-- Options: `--capsule`, `--capsule-root`, `--environment-json`, `--evidence`, `--mode`, `--state`
-- Syntax:
-
-```text
-buildchain release-tail rehearse --capsule <path> --capsule-root <absolute-path> --mode <simulate|replay> --state <path> --evidence <path> [--environment-json <json-or-path>]
-```
-
 ### `buildchain release-tail status`
 
 - Help: `buildchain release-tail status --help`

package/docs/cli.md

@@ -49,7 +49,7 @@ Consumers should pin the exact Buildchain version that was validated in their
 repository. When dogfooding a fresh Buildchain release immediately after it is
 published, pnpm may block the install through a minimum release-age policy. In
 that case, add a temporary package/version-specific `minimumReleaseAgeExclude`
-entry, such as `@kungfu-tech/buildchain@3.0.0`, and remove it once the package
+entry, such as `@kungfu-tech/buildchain@4.0.0`, and remove it once the package
 has aged past the normal policy window. Do not replace that with a broad
 registry or scope-wide exclude. Paper scaffold and migration maintain the
 exact current entry in `pnpm-workspace.yaml` before refreshing the lockfile.
@@ -110,7 +110,7 @@ import publicSurfaceAudit from "@kungfu-tech/buildchain/site/public-surface-audi
 
 Use `dist/site/manual-registry.json` to find the packaged operating manuals and
 their SHA-256 digests. Use `dist/site/buildchain-contract.json` to verify the
-floating-ref contract world for a runtime such as `@v3`.
+floating-ref contract world for a runtime such as `@v4`.
 
 For exhaustive lookup, use the generated references rather than scanning this
 conceptual guide:
@@ -386,9 +386,9 @@ branch action, and initial version before any GitHub mutation happens:
 
 ```bash
 buildchain release line open \
-  --major 3 \
+  --major 4 \
   --minor 1 \
-  --source-ref release/v3/v3.0 \
+  --source-ref release/v4/v4.0 \
   --json
 ```
 
@@ -401,9 +401,9 @@ reconciliation succeeds, and opens the first dev-to-alpha channel PR:
 
 ```bash
 buildchain release line open \
-  --major 3 \
+  --major 4 \
   --minor 1 \
-  --source-ref release/v3/v3.0 \
+  --source-ref release/v4/v4.0 \
   --write \
   --json
 ```
@@ -994,10 +994,10 @@ even when the bundle hash has been refreshed.
 maintainer opens or merges a channel PR:
 
 ```bash
-buildchain release --dry-run --target-ref alpha/v3/v3.0
-buildchain release --dry-run --target-ref release/v3/v3.0 --sha <verified-sha>
-buildchain release dry-run --target-ref publish-gate/major --source-ref release/v3/v3.0
-buildchain release explain --target-ref alpha/v3/v3.0 --json
+buildchain release --dry-run --target-ref alpha/v4/v4.0
+buildchain release --dry-run --target-ref release/v4/v4.0 --sha <verified-sha>
+buildchain release dry-run --target-ref publish-gate/major --source-ref release/v4/v4.0
+buildchain release explain --target-ref alpha/v4/v4.0 --json
 ```
 
 This is a Buildchain-level dry-run, not an npm dry-run. It explains the legal
@@ -1012,7 +1012,7 @@ Pass `--json` for a machine-readable plan.
 for the publish transaction state:
 
 ```bash
-buildchain transaction inspect --version v3.0.1-alpha.2
+buildchain transaction inspect --version v4.0.1-alpha.2
 ```
 
 It reads or locally initializes the durable transaction record and validates
@@ -1039,9 +1039,9 @@ Buildchain's own npm package is published from
 `.github/workflows/buildchain-ref-promotion.yml`, inside the same publish
 transaction that promotes release refs:
 
-- `v3.0.3-alpha.0` publishes to npm with dist-tag `alpha`.
-- `v3.0.2` publishes to npm with dist-tag `latest`.
-- moving refs such as `v3`, `v3.0`, and `v3.0-alpha` do not match the publish
+- `v4.0.3-alpha.0` publishes to npm with dist-tag `alpha`.
+- `v4.0.2` publishes to npm with dist-tag `latest`.
+- moving refs such as `v4`, `v4.0`, and `v4.0-alpha` do not match the publish
   workflow and do not publish.
 
 The promotion workflow uses npm Trusted Publishing through GitHub Actions OIDC.

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

@@ -13,7 +13,7 @@ ai_provenance:
   model_family: GPT-5
   product: Codex
   generated_at: 2026-08-11
-  visible_context: Buildchain v3 Release Train and Release Cut contracts, existing source locks, exact-source Alpha preflight, Dev Patrol, cancelled duplicate runs, protected auto-merge policy, repository release governance, and the consumer-owned settlement renderer threat model.
+  visible_context: Buildchain v4 parity of the proven v3 Release Train and Release Cut contracts, existing source locks, exact-source Alpha preflight, Dev Patrol, cancelled duplicate runs, protected auto-merge policy, repository release governance, and the consumer-owned settlement renderer threat model.
   invisible_context_boundary: No credentials, private logs, or private configuration were used.
 ---
 
@@ -39,7 +39,7 @@ head, selected SHA, and count of skipped newer commits. This makes a slow native
 verification lane live under continuous development without silently treating
 an unqualified head as releasable.
 
-Before any new selection, the v3 controller now resolves the open managed PR and
+Before any new selection, the v4 controller now resolves the open managed PR and
 validates its embedded authoritative Release Train. If one exists, the frozen
 Release Cut wins: Candidate Patrol does not scan for or retain a newer qualified
 candidate. It returns the cut's exact candidate commit, candidate tree,
@@ -59,14 +59,6 @@ controller then compares the selected SHA to the exact Alpha head before it can
 be eligible, so a bounded scan cannot turn a commit outside the promotion
 ancestry into a candidate.
 
-Generated next-development version preparation is not a product candidate. The
-observer skips both the signed `chore(release): prepare ...` commit and its
-two-parent integration commit. When later product work becomes qualified, the
-nearest preparation becomes a reservation: Patrol reads every path changed by
-that preparation at both exact SHAs and requires identical Git blob identities.
-A missing or stale reserved path blocks selection before the Release Cut and
-therefore before any heavy candidate build.
-
 The decision is `kungfu-buildchain-channel-candidate-decision/v1`. It records the
 source and target branches and SHAs, comparison distance, workflow paths, run
 identities and attempts, completion times, URLs, policy, and a canonical decision
@@ -88,7 +80,7 @@ The companion state is
 - `stale`: the available exact-SHA evidence pair is outside policy age; or
 - `blocked`: qualification or reconciliation failed closed.
 
-New v3 states embed the complete `kungfu-buildchain-release-train/v1` record.
+New v4 states embed the complete `kungfu-buildchain-release-train/v1` record.
 `held` states include a rooted `kungfu-buildchain-release-train-hold/v1`
 receipt with the expected cut and observed coordinates. Dev movement alone is
 not an allowed supersession cause. Legacy markers remain readable by the core

package/docs/dev-delivery-warrant.md

@@ -1,5 +1,5 @@
 ---
-status: accepted
+status: draft
 period: ongoing
 theme: dev-delivery-warrant
 doc_type: technical-reference
@@ -7,7 +7,7 @@ source_level: local-files
 confidence: high
 sensitivity: public
 evidence_grade: A
-review_state: self-reviewed
+review_state: unreviewed
 last_reviewed: 2026-08-11
 ai_provenance:
   model_family: GPT-5
@@ -38,14 +38,10 @@ and retained enqueue time.
 
 Selection is deterministic FIFO plus aging with bounded priority. Priority may
 reorder queued work, but it cannot preempt the active Warrant. Exactly one
-candidate receives a `provisional` leased Warrant containing a fencing token,
-lease generation, expected-old state root, expiry, and the complete exact
-source binding. It reserves the next protected-dev landing before expensive
-native shards start, but it is not GitHub Merge Queue admission authority.
-Heartbeat extends only that generation. Native proof success atomically
-upgrades the same token and generation to `qualified`; only then may enqueue
-begin. Expiry recovery rejects the old token, retains queue age, and returns
-the candidate to selection.
+candidate receives a leased Warrant containing a fencing token, lease
+generation, expected-old state root, expiry, and the complete exact source
+binding. Heartbeat extends only that generation. Expiry recovery rejects the
+old token, retains queue age, and returns the candidate to selection.
 
 A terminal event may cancel a candidate before selection without minting a
 Warrant. This transition is limited to an exact non-active queued candidate and
@@ -77,28 +73,23 @@ That lane outranks not-yet-leased ordinary work, but never preempts or rewrites
 an active Warrant; unrelated, conflicted, mismatched, or fabricated claims fail
 closed before selection.
 
-## Three proof authorities
+## Split proof authority
 
-Source Qualification Proof is created from the cheap source-acceptance gate. It
-binds the semantic source, exact source head and patch/tree intent, plan,
-affected closure, dependencies, toolchain, covered paths, and exact acceptance
-evidence. Ready state and approval are established before provisional
-selection.
+Source Qualification Proof is independent of the moving dev base. It binds the
+semantic source, exact source head and patch/tree intent, plan, affected
+closure, dependencies, toolchain, covered paths, and shard evidence.
 
-Native Qualification Proof is separate. It binds semantic source and patch,
-plan, affected closure, dependency graph, toolchain, covered paths, native
-shard evidence, and the exact dev base used by the native composition. Before
-reuse, the consumer classifies the dev delta:
+Before reuse, the consumer classifies the dev delta:
 
-- unchanged semantic roots plus an unrelated fully attributed base delta reuse
-  native qualification and run only a cheap Project Cut replay. GitHub's `behind`
+- unchanged roots plus an unrelated attributed delta reuse source
+  qualification and run only a cheap Project Cut replay. GitHub's `behind`
   state is accepted only when a rooted replay proof binds the exact current
   protected base, unchanged PR head and source patch, replay tree, required
   context roots, and a qualified `project.cut.merge-queue-admission/v1`
   receipt;
-- an overlapping delta reruns affected native shards or the full native plan;
+- an overlapping delta reruns the affected source shards;
 - an unknown graph or changed source, plan, closure, dependency, or toolchain
-  root fails closed to full native qualification.
+  root fails closed to full source qualification.
 
 Integration Delivery Proof is separate and cannot be cached across candidates.
 It binds the exact current dev base, replay tree, GitHub `merge_group` head and
@@ -122,17 +113,6 @@ buildchain dev warrant submit --repository owner/repository \
 buildchain dev warrant select --repository owner/repository \
   --branch dev/v4/v4.0 --execute
 
-buildchain dev proof native --branch dev/v4/v4.0 \
-  --qualified-base <sha> --affected-paths-json '["packages/native"]' ...
-
-buildchain dev proof classify-native --source-proof native-proof.json \
-  --current-base <sha> --graph-known true --changed-paths-json '[]' ...
-
-buildchain dev warrant qualify --repository owner/repository \
-  --branch dev/v4/v4.0 --fencing-token <root> --lease-generation 1 \
-  --native-proof native-proof.json \
-  --native-reuse-decision native-reuse-decision.json --execute
-
 buildchain dev warrant cancel-queued --repository owner/repository \
   --branch dev/v4/v4.0 --candidate-id <root> --pull-request 123 \
   --expected-source-head <queued-sha> --observed-source-head <event-sha> \
@@ -140,10 +120,17 @@ buildchain dev warrant cancel-queued --repository owner/repository \
   --evidence-root <terminal-event-root> --execute
 ```
 
-`heartbeat`, `qualify`, `recover`, `close`, `settle`, `cancel-queued`, and `observe` use the same durable authority.
+`heartbeat`, `recover`, `close`, `settle`, `cancel-queued`, and `observe` use the same durable authority.
 Warrant-scoped mutations require the exact fencing token and lease generation.
 `close` also requires a rooted terminal evidence object.
 
+On the v4 preview line, `observe` alone has an explicit `--read-mode v4`
+candidate. It requires a retained exact semantic-diff qualification and source
+binding, invokes an effect-disabled Rust state projection, retains parity
+evidence, and returns the existing v3 observation shape. The default and
+rollback mode is `v3`; mutation commands ignore the read switch. See
+[`v4-delivery-warrant-read-candidate.md`](v4-delivery-warrant-read-candidate.md).
+
 Proof commands create, verify, classify, and compose the two proof layers:
 
 ```sh
@@ -155,67 +142,15 @@ buildchain dev proof replay-proof \
 buildchain dev proof integration --warrant-result warrant.json ...
 ```
 
-## Bounded-concurrency shadow qualification
-
-The production queue remains single-flight. A separate effect-disabled shadow
-planner can replay the same deterministic candidate order with a bound of one
-or two lanes. It does not issue, renew, supersede, close, or persist a Warrant;
-it cannot enqueue a pull request; and its output explicitly carries no
-production or rollout authority.
-
-Each lane binds the exact queue root and generation, protected-base head,
-source head, projected-base root, Project Cut, approval, required checks,
-status, and lease evidence. An active production candidate must additionally
-match its current fencing token and lease generation. A queued shadow lane must
-not carry either. Stale evidence, an occupied native queue, cross-lane evidence
-aliasing, shared conflict keys, or an incompatible projected base fails closed.
-A failure in one lane remains visible without converting or concealing the
-other lane's result.
-
-The planner and aggregate qualification command consume immutable JSON files:
-
-```sh
-buildchain dev warrant shadow-plan --input observation.json \
-  --max-concurrency 2 --output shadow-plan.json
-
-buildchain dev warrant shadow-qualify --input qualification-input.json \
-  --output shadow-qualification.json
-```
-
-Both commands reject `--execute`. Qualification reports compare explicit
-thresholds for sample count, eligible overlap, projected queue-wait benefit,
-additional runner cost, ambiguity, and false positives. A `proceed` result is
-only evidence for a separate reviewed rollout decision; it never changes the
-live Warrant schema, queue state, merge-queue policy, or protected branch.
-
 ## Workflow rollout and rollback
 
 The reusable `dev-pr-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;
-- `required` persists the submission, selects a provisional Warrant, runs or
-  reuses semantic native proof under heartbeat, atomically qualifies the same
-  fence, and refuses GitHub enqueue unless the immutable queue commit, state root, active Warrant, and
-  selected candidate all pass exact readback validation. Immediately before
-  enqueue, the controller also rereads the current protected state ref and
-  verifies the active candidate, fencing token, generation, pull request, and
-  exact head. A previously valid result is not authority after terminal
-  closeout. Re-running qualification for the same selected head may regenerate
-  timestamped proof bytes, but it retains the immutable active Warrant and its
-  originally selected proof instead of rewriting or rejecting that attempt.
-  Each candidate also retains the exact successful source workflow run. If a
-  controller discovers that another candidate owns the active Warrant, a
-  configured consumer workflow is dispatched immediately for that exact PR,
-  head, and source run; the candidate is not left waiting for a patrol cron.
-
-The required controller checks the protected base again after native work. A
-disjoint attributed delta reuses the proof. Overlap or unknown attribution
-triggers one automatic revalidation on the latest base; continued overlap,
-native failure, cancellation, semantic head movement, or an unrecoverable merge
-conflict closes the exact fence. The next queued candidate is notified through
-the `buildchain-dev-delivery-wake` repository event. If cancellation prevents
-cleanup, lease expiry recovers retained queue age and mints a new fence.
+- `required` persists the submission, selects the Warrant, and refuses GitHub
+  enqueue unless the immutable queue commit, state root, active Warrant, and
+  selected candidate all pass exact readback validation.
 
 Consumers should deploy `shadow` first, inspect receipts, then change their
 protected caller to `required`. Rollback is a reviewed caller change back to
@@ -225,22 +160,15 @@ merged candidate (or accepts explicit evidence for another terminal outcome),
 then closes only the current fencing generation. The separate queued
 cancellation reusable workflow cannot close an active generation; it advances
 the state ref only when the caller's complete terminal binding and expected-old
-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.
+root still match.
 
 Buildchain uses the same contract for its own protected dev line through
 `buildchain-dev-delivery.yml`. The manual caller requires the exact PR head and
-semantic source roots, accepts an optional reusable native proof, pins the runtime to the caller commit, selects
+all native/source proof roots, pins the runtime to the caller commit, 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.
 
-`buildchain init --type native` generates the corresponding protected-dev
-consumer workflow. It supports both explicit dispatch and the bounded wake
-event, uses the same reusable controller, and keeps the native command in the
-consumer repository rather than inventing provider-specific shards.
-
 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