@kungfu-tech/buildchain 3.0.2 → 3.0.3-alpha.1

package/docs/cli.md

@@ -1,3 +1,21 @@
+---
+status: active
+period: ongoing
+theme: buildchain-cli
+doc_type: technical-reference
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: A
+review_state: unreviewed
+last_reviewed: 2026-07-31
+ai_provenance:
+  model_family: GPT-5
+  product: Codex
+  generated_at: 2026-07-31
+  invisible_context: not asserted
+---
+
 # Buildchain CLI, npm Package, and Toolkit API
 
 Buildchain is published as the public npm package
@@ -76,6 +94,8 @@ import { collectReadmeBadgeFacts } from "@kungfu-tech/buildchain/readme-badges";
 import { verifyReleasePassport } from "@kungfu-tech/buildchain/release-passport";
 import { verifyGitHubArtifactAttestationEvidence } from "@kungfu-tech/buildchain/github-artifact-attestation";
 import { createReleasePropagationPlan } from "@kungfu-tech/buildchain/release-propagation";
+import { verifyPublicationReproducibility } from "@kungfu-tech/buildchain/publication-reproducibility";
+import { collectPaperStatus } from "@kungfu-tech/buildchain/paper";
 import { planReleaseLineBootstrap } from "@kungfu-tech/buildchain/release-line-bootstrap";
 import { collectPublicSurfaceReverseAudit } from "@kungfu-tech/buildchain/public-surface-audit";
 import { createBuildchainLayoutDiscovery } from "@kungfu-tech/buildchain/buildchain-layout";
@@ -101,6 +121,70 @@ with the exact signer/source policy and then verifies the retained bundle,
 predicate, platform manifest, Passport, and Buildchain evidence locally. See
 [`github-artifact-attestation.md`](github-artifact-attestation.md).
 
+### Governed paper lifecycle
+
+`buildchain paper` is the unified operator surface for a paper repository. Its
+eight subcommands return versioned JSON contracts with `--json`:
+
+```bash
+buildchain paper scaffold --package @kungfu-tech/paper-example \
+  --repository kungfu-systems/paper-example
+buildchain paper migrate --json
+buildchain paper preflight --offline --json
+buildchain paper bootstrap npm --json
+buildchain paper build --json
+buildchain paper alpha --json
+buildchain paper status --json
+buildchain paper resume --json
+```
+
+The safety and authority boundary is explicit:
+
+- `scaffold` plans a 14-file, no-overwrite repository shape by default; add
+  `--write` to create only missing files.
+- `migrate` plans the five Buildchain-owned control-file changes needed by an
+  existing paper repository. Add `--write` only after reviewing exact old and
+  new digests; paper content and publication configuration are never rewritten.
+- The scaffolded `.buildchain/paper/provisioning-authority.json` binds both
+  caller workflow byte digests, their exact reusable-workflow SHA, the runtime
+  SHA, contract-lock bytes, npm registry and trusted-publisher coordinates, and
+  the repository Actions/generated-write policy under one digest. A floating
+  Buildchain ref cannot change release policy after that authority is accepted.
+- `preflight` separates local readiness from readiness for external mutation.
+  `--offline` skips live GitHub and npm observations without treating them as
+  local failures. Live readiness requires default workflow permissions `read`,
+  Actions pull-request approval disabled, and GitHub App or equivalent narrow
+  generated-write credential metadata.
+- `bootstrap npm` always performs npm pack and publish dry-runs first. A real
+  public bootstrap requires both `--execute` and
+  `--confirm-public-package <exact-name>`, uses only the official npm registry,
+  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`),
+  not its `.github/workflows/` repository path.
+- `build` plans the two-clean-build reproducibility proof. Add `--execute` to
+  create and verify the sealed publication bundle.
+- `alpha` plans or opens the protected Alpha pull request; it never merges,
+  publishes, or advances a floating ref.
+- `status` reports only evidence found in the repository or external
+  observations. It never infers a later lifecycle state from an earlier one.
+- `resume` plans or dispatches the repository's thin release workflow; the
+  protected workflow remains the release authority.
+
+The ordered evidence states are `scaffolded`, `governed`, `admitted`,
+`bootstrapped`, `trust-bound`, `content-ready`, `artifact-sealed`,
+`package-published`, `alpha-complete`, `staging-visible`, and
+`production-visible`. A state can be `satisfied`, `not-reached`, `blocked`, or
+`unknown`; consumers must not collapse those distinctions.
+
+The corresponding Node surface is
+`@kungfu-tech/buildchain/paper`. Planning and status functions are read-only;
+`writePaperScaffold()` and `writePaperMigration()` are the bounded local
+writers, and
+`executePaperNpmBootstrap()` preserves the same confirmation boundary used by
+the CLI.
+
 `buildchain layout` is the stable machine question for repository layout. Tools
 such as Shifu should call it instead of copying `.buildchain/` path constants:
 
@@ -249,9 +333,9 @@ branch action, and initial version before any GitHub mutation happens:
 
 ```bash
 buildchain release line open \
-  --major 2 \
-  --minor 10 \
-  --source-ref release/v2/v2.9 \
+  --major 3 \
+  --minor 1 \
+  --source-ref release/v3/v3.0 \
   --json
 ```
 
@@ -264,9 +348,9 @@ reconciliation succeeds, and opens the first dev-to-alpha channel PR:
 
 ```bash
 buildchain release line open \
-  --major 2 \
-  --minor 10 \
-  --source-ref release/v2/v2.9 \
+  --major 3 \
+  --minor 1 \
+  --source-ref release/v3/v3.0 \
   --write \
   --json
 ```
@@ -284,7 +368,9 @@ import {
   assertPublicSurfaceReverseAudit,
 } from "@kungfu-tech/buildchain/public-surface-audit";
 
-assertPublicSurfaceReverseAudit(collectPublicSurfaceReverseAudit({ root: process.cwd() }));
+assertPublicSurfaceReverseAudit(
+  collectPublicSurfaceReverseAudit({ root: process.cwd() }),
+);
 ```
 
 `buildchain kfd` is the product-facing KFD namespace. Schema commands expose the
@@ -398,7 +484,10 @@ The event protocol is JSONL and is also available from the SDK:
 ```js
 import { createBuildchainLogger } from "@kungfu-tech/buildchain/logging";
 
-const logger = createBuildchainLogger({ source: "user", component: "native-build" });
+const logger = createBuildchainLogger({
+  source: "user",
+  component: "native-build",
+});
 logger.mark("configure.ready", { phase: "configure" });
 ```
 
@@ -530,6 +619,24 @@ buildchain publication-artifact manifest \
   --json
 ```
 
+Run the fail-closed clean-room gate before Alpha or release admission:
+
+```bash
+buildchain publication-artifact reproducibility \
+  --source-sha "$(git rev-parse HEAD)" \
+  --promote \
+  --json
+```
+
+The command checks two independent clones of the exact commit, isolates caches,
+derives `SOURCE_DATE_EPOCH` from Git, and compares every declared artifact,
+source bundle, publication evidence file, npm package file, and actual npm
+tarball. It writes
+`.buildchain/publication/reproducibility-receipt.json`. Only a byte-identical
+build using the digest-pinned `latex-docker` toolchain is qualifying.
+`--allow-unpinned-toolchain` exists for local diagnostics and never changes the
+receipt's `qualifying` field.
+
 Generate the Buildchain-owned npm paper package contents from declared
 publication facts:
 
@@ -629,7 +736,7 @@ buildchain collect github-release \
   --kfd-2-claim-json .buildchain/kfd/kfd-2/release-claims.json \
   --kfd-3-prebuild-witness-json .buildchain/kfd/kfd-3/collaboration-interface.prebuild.json \
   --kfd-3-artifact-verify-cmd "kungfu agent verify --json" \
-  --release-extra-json '{"channel":"release","targetRef":"release/v2/v2.3"}' \
+  --release-extra-json '{"channel":"release","targetRef":"release/v3/v3.0"}' \
   --output-dir .buildchain/release-passport
 ```
 
@@ -880,9 +987,9 @@ Buildchain's own npm package is published from
 `.github/workflows/buildchain-ref-promotion.yml`, inside the same publish
 transaction that promotes release refs:
 
-- `v2.0.13-alpha.0` publishes to npm with dist-tag `alpha`.
-- `v2.0.13` publishes to npm with dist-tag `latest`.
-- moving refs such as `v2`, `v2.0`, and `v2.0-alpha` do not match the publish
+- `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
   workflow and do not publish.
 
 The promotion workflow uses npm Trusted Publishing through GitHub Actions OIDC.

package/docs/consumer-issue-reporting.md

@@ -1,3 +1,21 @@
+---
+status: active
+period: ongoing
+theme: buildchain-consumer-issue-reporting
+doc_type: technical-reference
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: A
+review_state: unreviewed
+last_reviewed: 2026-07-31
+ai_provenance:
+  model_family: GPT-5
+  product: Codex
+  generated_at: 2026-07-31
+  invisible_context: not asserted
+---
+
 # Consumer Issue Reporting
 
 Buildchain ships a first-class issue reporting surface for consumer workflows.
@@ -34,7 +52,7 @@ The recommended pattern is:
     summary: "Buildchain reusable build failed before artifact finalization"
     failure-code: reusable-build-failed
     diagnostics-path: .buildchain/artifacts/diagnostics.json
-    buildchain-ref: ${{ inputs.buildchain-ref || 'v2' }}
+    buildchain-ref: ${{ inputs.buildchain-ref || 'v3' }}
 ```
 
 ## Behavior
@@ -73,7 +91,7 @@ const result = await reportBuildchainIssue({
   token: process.env.BUILDCHAIN_ISSUE_TOKEN,
   summary: "Native artifact manifest is incomplete",
   failureCode: "native-manifest-incomplete",
-  buildchainRef: "v2",
+  buildchainRef: "v3",
   diagnosticsPath: ".buildchain/artifacts/diagnostics.json",
 });
 ```

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

@@ -8,12 +8,12 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: self-reviewed
-last_reviewed: 2026-07-27
+last_reviewed: 2026-07-29
 ai_provenance:
   model_family: GPT-5
   product: Codex
-  generated_at: 2026-07-27
-  visible_context: Existing Buildchain stable-candidate source locks, Kungfu exact-source Alpha preflight, Dev Patrol, and repository release governance.
+  generated_at: 2026-07-29
+  visible_context: Existing Buildchain source locks, Kungfu exact-source Alpha preflight, Dev Patrol, repository release governance, and the consumer-owned settlement renderer threat model.
   invisible_context_boundary: No credentials, private logs, or private configuration were used.
 ---
 
@@ -77,13 +77,27 @@ exact same-SHA evidence, it may set `settlement-authorized: true` and
 alias for settlement authorization.
 
 Repositories whose promotion policy requires a machine-readable PR declaration
-can pass it through `pull-request-body-prefix`. Buildchain prepends that trusted,
-repository-owned text only when it creates the candidate PR and preserves it
-when later controller observations update the managed state marker. Keep the
-declaration source-controlled in the caller workflow and update it whenever the
-qualified development delta changes its release or architecture settlement.
-Buildchain rejects a prefix that attempts to inject its managed controller
-marker.
+can pass static text through `pull-request-body-prefix`. When the declaration
+depends on the exact qualified delta, use `pull-request-body-prefix-renderer`
+instead. It names a repository-relative Node.js file in the consumer checkout.
+The read-only `observe` job checks out the selected SHA with credentials disabled,
+runs the renderer with a reduced environment, and requires it to write UTF-8 text
+to `BUILDCHAIN_CHANNEL_PATROL_PR_BODY_PREFIX_OUTPUT`. The renderer also receives
+the selected SHA plus source and target branch names. It may derive a declaration
+from the exact checkout and `origin/<target-branch>` without receiving the
+promotion token.
+
+Static and rendered prefixes are mutually exclusive. A renderer failure, path
+escape, source-SHA mismatch, empty or oversized result, invalid UTF-8, or managed
+controller-marker injection fails before the write-permission job can run. The
+rendered bytes are retained with the read-only observation artifact and passed
+to `settle` as a job output, so the candidate PR is created with the correct
+declaration on its first write. Buildchain preserves that repository-owned text
+when later observations update only the managed state marker. Before any write,
+`settle` also requires its fresh observation to select the same SHA that produced
+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 re-runs the exact observation before
 any write. With no active managed candidate, it creates one branch named from

package/docs/github-governance-authority.md

@@ -8,11 +8,11 @@ confidence: high
 sensitivity: public
 evidence_grade: B
 review_state: unreviewed
-last_reviewed: 2026-07-24
+last_reviewed: 2026-07-31
 ai_provenance:
   model_family: GPT-5
   product: Codex
-  generated_at: 2026-07-24
+  generated_at: 2026-07-30
   limits: Live GitHub state and account recovery remain provider-controlled and must be re-audited.
 ---
 
@@ -75,16 +75,19 @@ protection. Inspecting only one layer is insufficient because an applicable
 bypass or weaker update path in another layer can invalidate the effective
 policy.
 
+When an admitted default development branch uses GitHub merge queue, its
+candidate-source, queue-lease, and final build checks are one exact authority
+set. The queue lease may remain intentionally unbound while workflow-produced
+checks retain their GitHub Actions App binding; strictness must match the live
+queue ruleset.
+
 ## Repository and plan admission
 
-The 2026-07-24 baseline contains 16 managed repositories: 13 public and three
-private. Public repository names are versioned in the descriptor. Private
-repository names are never emitted in public evidence; their identities are
-represented by stable roots derived from the GitHub provider repository ID,
-independent of the governance policy root. This prevents a policy revision from
-changing repository identity or creating a circular admission dependency. A
-newly discovered repository or target ref is non-authoritative until explicitly
-admitted.
+The 2026-07-30 baseline contains 16 managed public repositories. The descriptor
+sets `managedVisibilities` to `public`; private repositories are outside the
+managed-zone inventory and do not produce governance receipts. Public
+repository names are versioned in the descriptor. A newly discovered public
+repository or target ref is non-authoritative until explicitly admitted.
 
 The descriptor also versions every active public merge target. The full audit
 evaluates one receipt per authoritative target rather than assuming the default
@@ -94,19 +97,11 @@ which case it is non-qualifying. Retained historical channels and generated
 per-release publish-gate refs are not silently deleted or promoted to current
 authority; they require an explicit registry revision before they can qualify.
 
-For an admitted private repository, the active target set is the current
-default branch plus existing alpha/release siblings on the same version line.
-Its required-check bindings remain non-qualifying until their sanitized binding
-roots are sealed into the private identity entry after supported native
-protection exists.
-
 Public repositories can qualify on supported Free, Team, or Enterprise
-enforcement. Private repositories and organization-wide rules require Team or
-Enterprise capability. On an unsupported plan they remain explicitly
-`non-authoritative-plan-capability-required` and publication-ineligible. The
-verifier does not replace missing native enforcement with CI or documentation,
-and the implementation never makes a private repository public as a
-workaround.
+enforcement. Organization-wide rules require Team or Enterprise capability.
+The verifier does not reinterpret an excluded private repository as qualifying,
+replace missing native enforcement with CI or documentation, or make a private
+repository public as a workaround.
 
 ## Read-only audit
 
@@ -148,12 +143,10 @@ allow the exact publication transaction audit to resolve required check runs
 and merged pull-request review lineage. Omitting either read permission makes
 the transaction evidence incomplete and therefore non-qualifying.
 
-The output is sanitized. Public repositories retain their public identity.
-Private repositories expose only an identity root, visibility class, target
-ref, sanitized required-check bindings and fact roots, and a qualifying or
-non-qualifying decision. Tokens, cookies, recovery material, private
-CODEOWNERS bytes, raw permission payloads, and credential-bearing URLs are
-never included.
+The output is sanitized. Managed public repositories retain their public
+identity. Excluded private repositories produce no receipt or diagnostic.
+Tokens, cookies, recovery material, private CODEOWNERS bytes, raw permission
+payloads, and credential-bearing URLs are never included.
 
 ## Mutation and rollback boundary
 
@@ -206,8 +199,8 @@ buildchain github-governance rollback \
 
 For an admitted exact target, classic branch protection can also be compiled
 directly from the authority descriptor. This mode preserves both App-bound
-checks and intentionally unbound check contexts such as Kungfu alpha's
-`build`, rather than guessing a provider App identity.
+checks and intentionally unbound check contexts such as Kungfu release's
+legacy `build`, rather than guessing a provider App identity.
 
 ```bash
 buildchain github-governance protection-policy-plan \
@@ -241,7 +234,7 @@ branch; unrelated rules and conditions are preserved in place.
 ```bash
 buildchain github-governance ruleset-policy-plan \
   --repository kungfu-systems/buildchain \
-  --branch alpha/v2/v2.14 \
+  --branch alpha/v3/v3.0 \
   --ruleset-id 19518955 \
   --snapshot-output ruleset-rollback.json \
   --plan-output ruleset-rollout.json

package/docs/lifecycle-protocol.md

@@ -1,6 +1,24 @@
+---
+status: active
+period: ongoing
+theme: buildchain-lifecycle-protocol
+doc_type: technical-reference
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: A
+review_state: unreviewed
+last_reviewed: 2026-07-31
+ai_provenance:
+  model_family: GPT-5
+  product: Codex
+  generated_at: 2026-07-31
+  invisible_context: not asserted
+---
+
 # Lifecycle Protocol
 
-Buildchain uses `.buildchain/buildchain.toml` as the v2 repository configuration format.
+Buildchain uses `.buildchain/buildchain.toml` as the v3 repository configuration format.
 The file is optional for simple JavaScript repositories, but it is the preferred
 way to describe release version state and lifecycle commands when a project is
 not a plain pnpm, npm, or yarn workspace.
@@ -10,7 +28,7 @@ For compatibility, Buildchain still reads a legacy root `buildchain.toml` when
 `.buildchain/` layout so all Buildchain-owned local state lives under one
 directory.
 
-Only TOML is supported in v2. YAML, JSON, and JavaScript config files are not
+Only TOML is supported in v3. YAML, JSON, and JavaScript config files are not
 loaded.
 
 ## Minimal File

package/docs/migration-inventory.md

@@ -1,9 +1,28 @@
+---
+status: historical
+period: 2026-07
+theme: buildchain-v2-migration-inventory
+doc_type: migration-inventory
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: A
+review_state: unreviewed
+last_reviewed: 2026-07-31
+ai_provenance:
+  model_family: GPT-5
+  product: Codex
+  generated_at: 2026-07-31
+  invisible_context: not asserted
+---
+
 # Buildchain v2 Migration Inventory
 
-This inventory records the buildchain v2 action surface. Buildchain v2 is the
-monorepo source of truth for active Kungfu repository workflows, the active
-reusable build workflow, and the three GitHub Actions that are still part of
-Buildchain's reusable contract.
+This historical inventory records the Buildchain v2 consolidation boundary.
+Buildchain v3 is now the active monorepo source of truth for Kungfu repository
+workflows, reusable build workflows, and Buildchain-native actions. The v2
+names below preserve the migration decisions that v3 inherited; they are not a
+current runtime baseline.
 Standalone `workflows` and `action-*` repositories are historical rollback
 anchors, not active Buildchain migration targets.
 
@@ -111,7 +130,7 @@ older standalone action repository.
 | `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 |
 
-## Stable v2 Refs
+## Current v3 Refs
 
 - Actions: `kungfu-systems/buildchain/actions/<name>@v3`
 - Reusable workflows: `kungfu-systems/buildchain/.github/workflows/<workflow>.yml@v3`

package/docs/observed-evidence-patrol.md

@@ -8,11 +8,11 @@ confidence: high
 sensitivity: public
 evidence_grade: A
 review_state: unreviewed
-last_reviewed: 2026-07-21
+last_reviewed: 2026-07-30
 ai_provenance:
   model_family: GPT-5
   product: Codex
-  generated_at: 2026-07-21
+  generated_at: 2026-07-30
   invisible_context_boundary: No credentials, private logs, or unpublished evidence values are included.
 ---
 
@@ -30,15 +30,28 @@ binds one `snapshot.id` to two byte-identical JSON files:
   `dogfood-evidence/snapshots/<snapshotId>.json`;
 - a mutable last-known-good alias such as `dogfood-evidence.json`.
 
+The bundle may also declare up to 16 derived mutable projections under
+`publication.projections`. Each projection declares its artifact-relative
+`source`, bounded destination `key`, exact `sha256`, `contentType`, and
+`cacheControl`. This supports static HTML such as `dogfood/index.html` without
+changing the existing immutable/latest JSON contract.
+
 Buildchain verifies both file digests and snapshot identities before receiving
 production authority. Apply then performs this order:
 
 1. conditionally create the immutable key with `If-None-Match: *`;
 2. read the immutable key back and verify its declared SHA-256 metadata;
-3. record the previous latest metadata as the rollback pointer;
-4. atomically replace the latest object;
-5. read latest back and verify the same snapshot and digest;
-6. invalidate only the declared viewer paths.
+3. record preceding version metadata for every declared mutable key;
+4. write and read back each derived projection in manifest order;
+5. atomically replace the latest object;
+6. read latest back and verify the same snapshot and digest;
+7. invalidate only the declared viewer paths.
+
+Projection-enabled publication requires bucket versioning before replacing an
+existing mutable key. If a later projection, latest update, or invalidation
+fails, Buildchain restores preceding object versions in reverse order and
+removes newly introduced declared projection keys. Rollback never lists the
+bucket and never touches keys outside the manifest.
 
 Any generator, schema, digest, immutable-key, provider, or read-after-write
 failure leaves the previous latest object in place. A colliding immutable key
@@ -58,6 +71,8 @@ review gate for steady-state refreshes. Its policy should allow only:
 
 - `s3:GetObject` and `s3:PutObject` on the exact latest key;
 - the same actions on the exact immutable snapshot prefix;
+- for projection-enabled bundles, `s3:GetObjectVersion` and bounded
+  `s3:DeleteObject` on the exact declared mutable keys;
 - `cloudfront:CreateInvalidation` on the one distribution.
 
 It must not receive bucket-wide delete, list, repository write, GitHub PR, or
@@ -76,9 +91,10 @@ fallback.
 
 ## Rollback and recovery
 
-Every receipt records the previous latest snapshot id, digest, ETag, and S3
-version id when available. Rollback regenerates a bundle whose latest file is
-the selected immutable snapshot and republishes it through the same validator;
-operators do not edit or delete immutable history. If CDN invalidation fails
-after latest advances, rerunning the same bundle is idempotent and repairs edge
-convergence.
+Every receipt records the previous latest and projection snapshot ids, digests,
+ETags, and S3 version ids when available. A projection transaction rolls back
+automatically when a later mutable step or CDN invalidation fails. Operators
+can also regenerate a bundle whose latest file is the selected immutable
+snapshot and republish it through the same validator; immutable history is
+never overwritten or deleted. Legacy bundles without projections retain their
+existing idempotent rerun behavior when CDN invalidation alone fails.

package/docs/ownership.md

@@ -1,8 +1,26 @@
+---
+status: active
+period: ongoing
+theme: buildchain-ownership-and-migration
+doc_type: technical-reference
+source_level: local-files
+confidence: high
+sensitivity: public
+evidence_grade: A
+review_state: unreviewed
+last_reviewed: 2026-07-31
+ai_provenance:
+  model_family: GPT-5
+  product: Codex
+  generated_at: 2026-07-31
+  invisible_context: not asserted
+---
+
 # Ownership And Migration Rules
 
 ## Source Of Truth
 
-Buildchain v2 workflow and action design lands in this repository. Standalone
+Buildchain v3 workflow and action design lands in this repository. Standalone
 `workflows` and `action-*` repositories are historical rollback anchors.
 Buildchain only ships the native action surface required for config validation,
 lifecycle execution, and release ref promotion.