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

package/docs/MAP.md

@@ -8,12 +8,13 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-09-11
+last_reviewed: 2026-09-20
 ai_provenance:
   model_family: GPT-6
   product: Codex
-  generated_at: 2026-09-10
-  invisible_context: not asserted
+  generated_at: 2026-09-20
+  visible_context: Current consumer contract and release and recovery manuals.
+  invisible_context_boundary: No unobserved hosted qualification or external consumer migration.
 ---
 
 # Documentation Map
@@ -28,13 +29,19 @@ running artifact), *use* (consume / extend) - and a **status**:
 - `stable` - current and holds.
 - `draft` - exists, rough or incomplete.
 - `to write` - planned; the material exists but is not yet a single doc.
-- `retired` - intentionally not part of the active Buildchain v3 surface.
+- `retired` - intentionally not part of the active consumer surface.
+
+The current consumer contract is the shared normal/recovery caller pair plus
+schema-2 TOML. Start with [Getting started](getting-started.md),
+[Release governance](release-governance.md), and [Attempt recovery](bootstrap-recovery.md).
+The mechanism documents below also describe internal components and historical
+qualification; their implementation ports are not additional consumer APIs.
 
 ## Start by Role or Intent
 
 | Role or intent | First entry | Then |
 | --- | --- | --- |
-| First-time repository adopter | [Golden Path](getting-started.md) | [Lifecycle Protocol](lifecycle-protocol.md) only when the generated defaults need changes |
+| First-time repository adopter | [Golden Path](getting-started.md) | [CLI guide](cli.md) for schema-2 product commands and version declarations |
 | CLI operator or agent | [Generated CLI Reference](cli-reference.md) | [CLI guide](cli.md) for concepts and worked examples |
 | Node toolkit developer | [Generated Node API Reference](node-api-reference.md) | [Core package guide](../packages/core/README.md) for recipes |
 | Workflow contributor | [Workflow Catalog](workflow-catalog.md) | [Contribution rules](../CONTRIBUTING.md#workflow-organization) and the [exact registry](../architecture/workflow-taxonomy.json) |
@@ -112,7 +119,7 @@ replace them.
 | How do I install a standalone binary or npm package? | [`install.md`](install.md) | use | stable |
 | How do I run or look up the `buildchain` CLI? | [`cli-reference.md`](cli-reference.md) + [`cli.md`](cli.md) | use | stable |
 | How do I import Buildchain toolkit APIs from JavaScript build code? | [`node-api-reference.md`](node-api-reference.md) + [`../packages/core/README.md`](../packages/core/README.md) | use | stable |
-| How do I initialize a new repository? | [`getting-started.md`](getting-started.md) + [`lifecycle-protocol.md`](lifecycle-protocol.md) | use | stable |
+| How do I initialize a new repository? | [`getting-started.md`](getting-started.md) | use | stable |
 | Why does Buildchain use branch-driven release governance? | [`release-governance.md`](release-governance.md) | why | stable |
 | What freezes the v4 dependency direction, writer authority, complexity budgets, exceptions, and N-1 qualification? | [`../architecture/architecture-constitution.md`](../architecture/architecture-constitution.md) | why/verify | preview |
 | How will Delivery Warrant move from the v3 writer through shadow, v4 read, single-writer cutover, and legacy removal? | [`../architecture/delivery-warrant-shadow-bootstrap-plan.md`](../architecture/delivery-warrant-shadow-bootstrap-plan.md) | why/verify | preview |
@@ -123,19 +130,19 @@ replace them.
 | How does a late macOS signing failure reuse an exact retained v4 Alpha candidate and rerun only the fenced release tail? | [`v4-tail-reseal.md`](v4-tail-reseal.md) | use/verify | preview |
 | How do Rust and JavaScript read the same retained Delivery Warrant traces and emit one semantic projection? | [`v4-canonical-contracts.md`](v4-canonical-contracts.md#shared-delivery-warrant-fixture-runner) | use/verify | preview |
 | How does an explicit caller try the qualified v4 read projection and roll back without moving v3 writer authority? | [`v4-delivery-warrant-read-candidate.md`](v4-delivery-warrant-read-candidate.md) | use/verify | preview |
-| How do protected dev branches and scheduled ready-PR merging work? | [`release-governance.md`](release-governance.md#protected-dev-branches) | use | stable |
+| How do protected development review and merge queues work? | [`release-governance.md`](release-governance.md#protected-dev-branches) | use | stable |
 | How do slow required checks land reliably on a busy dev channel? | [`release-governance.md`](release-governance.md#protected-dev-branches) + [`cli.md`](cli.md#commands) | use | preview |
 | How does the durable fair Dev Delivery Warrant Queue prevent slow-candidate starvation?                                                       | [`dev-delivery-warrant.md`](dev-delivery-warrant.md)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       | use/verify | preview |
 | How are bounded Qualification Leases separated from exclusive merge-group Landing authority? | [`dev-delivery-qualification-landing-adr.md`](dev-delivery-qualification-landing-adr.md) + [`dev-delivery-warrant.md`](dev-delivery-warrant.md) | use/verify | preview |
 | How do I coalesce rapid Dev changes, preserve release runner priority, and retry only transient failed jobs? | [`dev-qualification-patrol.md`](dev-qualification-patrol.md) | use/verify | preview |
-| How do I run daily, weekly, or monthly repository patrols? | [`release-governance.md`](release-governance.md#buildchain-patrol) | use | stable |
+| Who owns event routing, patrol and publication orchestration? | [`release-governance.md`](release-governance.md#consumer-contract) | use | stable |
 | How do I report or safely apply branch and pull-request engineering hygiene? | [`engineering-housekeeper.md`](engineering-housekeeper.md) | use/verify | preview |
 | How does Buildchain decide patch, minor, and major release lines? | [`versioning.md`](versioning.md) | why | stable |
 | What exact branch/tag state machine runs on alpha, release, and major gate? | [`release-flow.md`](release-flow.md) | verify | stable |
 | How does a completed Alpha remain successful while the following development version is prepared? | [`next-development-transition.md`](next-development-transition.md), [`../architecture/decisions/0002-next-development-transition.md`](../architecture/decisions/0002-next-development-transition.md) | verify/use | preview |
 | What did Buildchain migrate or retire from old action repositories? | [`migration-inventory.md`](migration-inventory.md) | verify | stable |
 | What is the active action and workflow source of truth? | [`ownership.md`](ownership.md) | verify | stable |
-| How do I declare version files and custom lifecycle commands? | [`lifecycle-protocol.md`](lifecycle-protocol.md) | use | stable |
+| How do I declare schema-2 version files and product commands? | [`cli.md`](cli.md) + [`getting-started.md`](getting-started.md) | use | stable |
 | How does publish evidence, recovery, and finalization work? | [`publish-transaction.md`](publish-transaction.md) | verify | stable |
 | How are consumer-owned release-tail commands inventoried and replaced by declarative capabilities? | [`release-tail-contract.md`](release-tail-contract.md) | verify | draft |
 | How do I simulate, replay, or explicitly authorize a provider-facing publication rehearsal without creating release authority? | [`v4-publication-rehearsal.md`](v4-publication-rehearsal.md) | use/verify | preview |
@@ -168,14 +175,14 @@ replace them.
 | How do self-hosted runners relay large artifacts through S3 before GitHub artifacts? | [`reusable-build-surface.md`](reusable-build-surface.md#artifact-transfer-relay) | use | stable |
 | How do self-hosted runners reuse local Git checkout caches without weakening source locks? | [`reusable-build-surface.md`](reusable-build-surface.md#locked-source-checkout-cache) | use | stable |
 | 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 I validate an unreleased Buildchain runtime train? | [`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 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 does the retained internal stable-candidate ledger work? | [`stable-candidate-patrol.md`](stable-candidate-patrol.md) | verify | internal |
+| How does the internal web deployment engine separate preview, staging and production authority? | [`web-surface-deployments.md`](web-surface-deployments.md) | verify | internal |
 | 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/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 internal action implementations documented? | [`../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 |
@@ -191,22 +198,23 @@ replace them.
   [`release-governance.md`](release-governance.md) and
   [`release-flow.md`](release-flow.md).
 - **Buildchain self-dogfood / released alpha canary / stable compatibility lane** ->
-  [`release-governance.md`](release-governance.md#buildchain-alpha-self-dogfood).
+  [`release-governance.md`](release-governance.md#buildchain-public-build-self-dogfood).
 - **qualified alpha ledger / scheduled stable selection / hold and revoke** ->
   [`stable-candidate-patrol.md`](stable-candidate-patrol.md).
 - **v3.1 vs v3.2 / when to open a new minor line** ->
   [`versioning.md`](versioning.md).
 - **dry-run / what would happen if this channel PR merges** -> [`cli.md`](cli.md)
   and [`release-flow.md`](release-flow.md).
-- **protected dev branches / scheduled ready-PR merge / daily-weekly-monthly patrol** ->
+- **protected dev branches / normal pipeline / internal orchestration** ->
   [`release-governance.md`](release-governance.md#protected-dev-branches) and
-  [`release-governance.md`](release-governance.md#buildchain-patrol).
+  [`release-governance.md`](release-governance.md#consumer-contract).
 - **Dev qualification coalescing / release-priority runners / failed-job retry** ->
   [`dev-qualification-patrol.md`](dev-qualification-patrol.md).
-- **pnpm / npm / yarn / package-manager adapters** ->
-  [`lifecycle-protocol.md`](lifecycle-protocol.md).
-- **pip / Conan / CMake / custom commands** -> [`lifecycle-protocol.md`](lifecycle-protocol.md)
-  and [`reusable-build-surface.md`](reusable-build-surface.md).
+- **pnpm / npm / yarn / product commands** ->
+  [`cli.md`](cli.md) and [`getting-started.md`](getting-started.md).
+- **CMake / custom product commands** -> [`cli.md`](cli.md) and
+  [`reusable-build-surface.md`](reusable-build-surface.md).
+- **Historical schema-1 lifecycle engine** -> [`lifecycle-protocol.md`](lifecycle-protocol.md).
 - **libnode / native artifacts / self-hosted runner matrix** ->
   [`reusable-build-surface.md`](reusable-build-surface.md) and
   [`../fixtures/libnode-shaped/README.md`](../fixtures/libnode-shaped/README.md).

package/docs/auditable-demo.md

@@ -7,13 +7,14 @@ source_level: local-files
 confidence: high
 sensitivity: public
 evidence_grade: A
-review_state: self-reviewed
-last_reviewed: 2026-09-11
+review_state: unreviewed
+last_reviewed: 2026-09-20
 ai_provenance:
-  model_family: GPT-5
+  model_family: GPT-6
   product: Codex
-  generated_at: 2026-08-02
+  generated_at: 2026-09-20
   invisible_context_boundary: No hidden model build, parameter count, or private corpus is asserted.
+  visible_context: Current two-entry consumer contract and retained internal implementation references.
 ---
 
 # Auditable Demo Pipeline
@@ -25,19 +26,11 @@ two distinct evidence products:
 2. an optional rendered media bundle that can exist only after that exact Gate
    bundle passes.
 
-The public reusable workflow is
-`.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/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
-1080p and 720p rendering, Release Passport construction, content-addressed
-materialization, and the protected README update pull request. No
-product-specific capture, adapter, passport, or materializer is required.
+The internal `.build-demo-adapter.yml` and `.build-demo.yml` components own
+adapter execution and standalone CLI demo qualification. Their artifact, scenario,
+Gate, renderer and materializer ports are runtime implementation details.
+Consumers use the shared normal/recovery pair and do not copy a separate demo
+workflow or pass artifact handoff parameters into consumer YAML.
 
 ## Declarative Standalone Binary Scenarios
 
@@ -108,39 +101,14 @@ It retains ANSI terminal bytes with the real PTY read timestamps, verifies
 declared stdout and JSON file facts, enforces the total deadline while a step is
 running, and removes the disposable workspace before emitting evidence.
 
-Both manual validation and alpha or release refreshes call the same reusable
-workflow. Manual callers select Gate-only or full rendering and can explicitly
-request a materialization PR. Release callers select full rendering and the
-same materializer automatically; there is no separate release-only recording
-implementation. Publication requires a dedicated update token and target
-branch. The token is an explicit bounded capability, while actor identity,
-first-party/System classification, KFD compliance, Product System metadata,
-package metadata, registry history, scans, and generated evidence grant no
-authority.
-
-```yaml
-jobs:
-  demo:
-    needs: exact-binary
-    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 }}
-      binary-artifact-digest: ${{ needs.exact-binary.outputs.artifact-digest }}
-      scenario-path: .buildchain/auditable-demo.json
-      renderer-image: ghcr.io/kungfu-systems/build-images/demo-renderer@sha256:RENDERER_DIGEST
-      render-media: true
-      render-failure-advisory: false
-      media-profile: responsive-web-delivery-v1
-      materialize: true
-      materialize-base-ref: dev/v1/v1.0
-    secrets:
-      DEMO_UPDATE_TOKEN: ${{ secrets.DEMO_UPDATE_TOKEN }}
-```
+Internal callers select Gate-only or full rendering under the same capture and
+materialization contracts. An admitted materialization capability, independent
+Gate result and exact retained bytes remain necessary for any write. Product
+metadata and generated evidence do not grant mutation authority.
 
-Buildchain recursively consumes this surface in
-`.github/workflows/self-build-demo-dogfood.yml` using its own exact standalone binary
-and the beginner bootstrap scenario in `.buildchain/auditable-demo.json`.
+Buildchain retains its scenario in `.buildchain/auditable-demo.json`. The former
+standalone self-demo caller is retired. Existing media is historical evidence;
+a source or document change does not regenerate or qualify that media.
 
 ## Authority Boundary
 

package/docs/bootstrap-recovery.md

@@ -1,50 +1,59 @@
 ---
 status: active
 period: ongoing
-theme: bootstrap-recovery-distribution
-doc_type: manual
+theme: consumer-attempt-recovery
+doc_type: technical-reference
 source_level: local-files
 confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-09-09
+last_reviewed: 2026-09-20
 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.
+  generated_at: 2026-09-20
+  visible_context: Schema-2 consumer contract, pipeline and recovery entries, and internal release implementations.
+  invisible_context_boundary: No unobserved hosted publication or external consumer migration is claimed.
 ---
 
-# 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`.
+# Consumer recovery
+
+A current consumer keeps the generated `buildchain.yml` and
+`buildchain-recover.yml` beside `.buildchain/buildchain.toml`.
+[Initialize the consumer](getting-started.md) to obtain both caller files from
+the same Buildchain package. No consumer-owned recovery implementation, copied
+JavaScript closure or additional bootstrap workflow is required.
+
+## Normal execution
+
+`buildchain.yml` invokes `public-ops-pipeline.yml` through the published channel.
+The runtime owns event routing, source qualification, publication and durable
+attempt records. Product install, build and verification commands belong in TOML.
+
+## Recover an interrupted attempt
+
+Open the generated **Buildchain recovery** workflow and provide its exact
+`attempt`. If execution requires a repaired runtime, provide the optional
+`runtime-ref` for that recovery. The caller invokes `public-ops-recover.yml`.
+Keep the durable caller on its published floating channel; the repair selector
+is transient and does not replace the attempt's original source or material.
+
+Recovery reads retained records and provider state before issuing remaining
+effects. It preserves published bytes and immutable history. A successful build
+or a green dispatch alone does not prove publication or terminal settlement.
+
+The recovery form does not accept request JSON, Discussion/run/transaction
+selector combinations, replacement artifacts or provider commands. Retained
+historical formats are decoded by runtime-owned readers.
+
+## Retired bootstrap distribution
+
+The earlier copied bootstrap recovery workflow and `.buildchain/bootstrap-recovery/`
+implementation are historical distribution artifacts. They are not part of the
+schema-2 consumer contract and must not be added to new consumers. Internal
+bootstrap components and their qualification tests may retain this material for
+implementation validation; that does not make it a consumer API.
+
+See [Release discussions](release-discussions.md) for immutable record ownership
+and [Release governance](release-governance.md) for the human release flow.

package/docs/cli-reference.md

@@ -968,7 +968,7 @@ buildchain infra-contract ...
 - Syntax:
 
 ```text
-buildchain init [--cwd <dir>] [--type package|native|web-surface|infra-contract|publication-artifact|anchored-package] [--force] [--package-manager pnpm|npm|yarn] [--runner-preset <preset>] [--artifact-name <name>]
+buildchain init [--cwd <dir>] [--type npm|binary|paper|package|native|publication-artifact|anchored-package] [--force] [--package-manager pnpm|npm|yarn] [--runner-preset <preset>] [--artifact-name <name>]
 ```
 
 ## `inspect`
@@ -1737,39 +1737,6 @@ buildchain paper
 buildchain paper agent verify [--cwd <dir>] [--offline] [--json]
 ```
 
-### `buildchain paper alpha`
-
-- Help: `buildchain paper alpha --help`
-- Canonical id: `paper-alpha`
-- Options: `--cwd`, `--execute`, `--json`, `--source-ref`, `--target-ref`
-- Syntax:
-
-```text
-buildchain paper alpha [--cwd <dir>] [--source-ref <ref>] [--target-ref <ref>] [--execute] [--json]
-```
-
-### `buildchain paper bootstrap npm`
-
-- Help: `buildchain paper bootstrap npm --help`
-- Canonical id: `paper-bootstrap-npm`
-- Options: `--confirm-public-package`, `--cwd`, `--execute`, `--json`
-- Syntax:
-
-```text
-buildchain paper bootstrap npm [--cwd <dir>] [--execute] [--confirm-public-package <name>] [--json]
-```
-
-### `buildchain paper build`
-
-- Help: `buildchain paper build --help`
-- Canonical id: `paper-build`
-- Options: `--cwd`, `--execute`, `--json`
-- Syntax:
-
-```text
-buildchain paper build [--cwd <dir>] [--execute] [--json]
-```
-
 ### `buildchain paper fleet audit`
 
 - Help: `buildchain paper fleet audit --help`
@@ -1814,17 +1781,6 @@ buildchain paper migrate [--cwd <dir>] [--write] [--json]
 buildchain paper preflight [--cwd <dir>] [--offline] [--json]
 ```
 
-### `buildchain paper resume`
-
-- Help: `buildchain paper resume --help`
-- Canonical id: `paper-resume`
-- Options: `--cwd`, `--execute`, `--json`, `--runtime-ref`
-- Syntax:
-
-```text
-buildchain paper resume [--cwd <dir>] [--runtime-ref <ref>] [--execute] [--json]
-```
-
 ### `buildchain paper scaffold`
 
 - Help: `buildchain paper scaffold --help`
@@ -1833,7 +1789,7 @@ buildchain paper resume [--cwd <dir>] [--runtime-ref <ref>] [--execute] [--json]
 - Syntax:
 
 ```text
-buildchain paper scaffold --package <name> --repository <owner/repo> [--write] [--json]
+buildchain paper scaffold --repository <owner/repo> [--package <name>] [--write] [--json]
 ```
 
 ### `buildchain paper status`