BT-0: gunbc build gunbc — commanded exact build through the emitted CLI

[briansrls]

What

gunbc build <program> reaches the exact product-build operation through the installed generated
CLI carrier. The modeled row owns the verb, operand, and realization; committed main.rs delegates
through RetainedCliHost and contains no Build arm.

BT-0P also closes the two blockers exposed by the first commanded cold build: a materialized source
tree has no ambient Git checkout from which build.rs can derive version identity, and the producer
and consumer previously interpreted one relative answer path against different roots.

Why

gunbc.devboot.build carried the intended production/reuse protocol but had no production consumer.
The first real cold invocation reached its cargo producer and then refused: the materialized tree had
no .git, while src/v1/stage0/build.rs correctly refused to stamp provenance it could not observe.
The same run exposed a response-coordinate defect in which CheckoutIndexToPrefix succeeded under
the scratch repository while the reader searched under the caller root. These were latent blockers,
not evidence of a successful production path; BT-0P repairs both before BT-0 can claim cold success.

CLI construction and guarantees

• CliArmRealization now drives the installed carrier. The former independent arm renderers are
  deleted, and a known operation with no realization refuses.
• AdmittedBootstrapOperationIdentity is a closed coproduct with one inhabitant. Runtime selection
  uses the qualified whole-declaration identity and refuses partial declarations.
• --dry-run build refuses before publishing a request or creating a receipt or artifact.
• Receipt names combine process identity with a per-process atomic sequence. The artifact path is
  derived from that receipt identity, so there is one uniqueness authority.
• The emitted dispatch signature and retained caller cross the declared main.rs divergence
  boundary. The §4b row records the compile-time mitigation and the structural trigger: derive both
  contracts from one authority.

Authority placement

Three facts have three homes:

• Interface—verbs, operands, options, and modeled local fields: gunbc.cli_dispatch_surface.
• Rust realization—finite, deterministic selection of a legal collision-free binding:
  extdeps.languages.rust.emit.
• Product policy—the __gunbc_dispatch_executor_ prefix: gunbc data passed to the generic allocator.

The first draft put Rust realization in the product-interface authority. Review caught that
ownership defect; the functions moved once rather than being copied. Both closure directions remain
clean: src/v1 does not reach v2.*/gunbc.devboot, and dag/ does not import v1.*.

BT-0P: provenance and answer coordinates

The build subject remains keyed by the existing Git tree object id, not by a commit. The injected
build identity is derived from that same tree_oid and rendered as tree:<existing GitObjectId wire>—for SHA-1, tree:sha1:<hex>. It adds no build-key axis. build.rs validates a supplied
materialized-tree identity, consumes it without consulting Git, refuses an invalid supplied value
instead of falling back, and retains the ordinary ambient-checkout arm. One build-script control
proves valid injected identity without Git; another proves invalid injected identity refuses rather
than falling back. A clean/dirty ambient control uses the same build-script executable and changes
only worktree state: the clean clone reports bare 40-hex commit identity and the dirty clone reports
the identical hex plus -dirty.

The answer repair makes writer and reader consume one exact derived output coordinate. The defect
was root relativity erased into a string: exchange_out_dir produced a caller-root-relative path,
while materialize_ref_tree handed it to a scratch-repository CheckoutIndexToPrefix operation.
Git therefore succeeded at a different location and the reader later substituted
ArtifactNotRetrievable for the producer's actual refusal. The adjacent client_repo_dir prose
already knew the roots differed; the distinction was not load-bearing in the type. The repaired
failure-fidelity control requires ProducerRefusedRequest with the producer's exact cause.

One adjacent finding remains outside BT-0P: extdeps.git.object_store says the Git object-id wire
renderer belongs at the GitObjectId authority, but render_git_object_id_wire actually lives in
gunbc.merge_admission_subject. Build identity now makes that misplacement load-bearing as a
build-identity-to-merge-admission dependency edge. Relocating the renderer is the repair; this PR
does not create another spelling. The separate git.oid.v1.* subject-digest atom is deliberately
unchanged because it is part of the artifact-cache key.

Generated carrier ownership and generation role

gunbc_cli_dispatch_generated.rs is a synthesized non-module product. Its producer ownership is
declared in gunbc.regen_affected_set as an aggregate generated product owned by
v1.compiler.emit_rust; it is not a BootstrapEdge, because that would also remove the emitter
from regen_generation_inputs/regen_generation_role_modules and silently narrow future emitter
edits.

Neither pre-existing generation-role arm was true. AggregateGenerationInput would assert that the
carrier bytes feed the next generation; they do not. AggregateNonSeedGeneratedOutput would derive
OutsideSeed; lib.rs embeds the carrier in the seed. Because construction was available, this PR
adds AggregateGenerationSubject rather than declaring a rung drop.

Enrolled evidence proves independently that the emitter remains a GenerationInput producer, the
carrier is a GenerationSubject, the carrier is SeedEmbedded, it is absent from bootstrap product
paths, and its owner path occurs exactly once. The real host join through
convergence_surface_roles and convergence_plan_from_model proves that
PromoteGenerationInputs defers it, InstallSeedCompatibilityCut plans it with its seed-compatible
closure, and PublishNonSeedOutputs does not plan it.

Interpreter Optional divergence found here

The allocator claims' first execution exposed that interpreter first, last, get, and lookup
disagree with the OptionalOf result shape already declared by std.algebra; map_get is the
positive control. This PR does not repair that shared seam. It enrolls
test.claim.cli_dispatch_surface.interpreter_first_returns_the_modeled_optional as the sole new
expected red and records a capability-grain §4b trigger, including builtin parameter
cardinality/coercion.

The population and dispositions are an operator-authored roster in PR #9785's
docs/plans/first-optional-divergence-census.md. That document explicitly calls itself the roster
producer; there is no executable/enrolled census symbol that re-derives it today. At
final-candidate composition, if the interpreter Optional divergence is still live, the
expected-red row remains enrolled and held. If a complete repair has landed and the exact
discriminator passes, the row is retired by its recorded trigger and the claim stays enrolled as
an ordinary passing regression control. The scheduling hold is not the row's trigger.

The required-floor history's 21→20 held-count change is fully accounted at identity grain. Main
#9710 retired
test.claim.declared_type_inhabitance_direct_call_witness.w_kernel_numeric_at_the_peano_nat_is_refused
by its recorded trigger and enrolled the renamed arrival
w_kernel_numeric_at_the_peano_nat_is_admitted_through_its_homomorphism; the arrival passes, as do
all 12 claims in self_host_peano_literal_operator_realization_witness_test. Departure, arrival,
and roster retirement occurred together; nothing became unenrolled.

The previously inert clean_version_identity_is_the_exact_commit fixture was also incomplete for
product-built artifacts: its commit-only premise is in tension with gunbc.devboot.subject, which
deliberately forbids a bare commit SHA as a build-key axis. BT-0P adds arm-specific materialized-tree
and ambient-checkout controls instead of treating that fixture as coverage.

Regeneration and exact evidence subject

The authoritative acceptance subject will be one serialized landing candidate:

• candidate commit: <FINAL_CANDIDATE_COMMIT>
• root tree: <FINAL_ROOT_TREE_OID>
• merge parents: <BT_HEAD> + <PINNED_MAIN>
• pinned main: <PINNED_MAIN>

Every final receipt below must name that commit and root tree. The cold/warm subject is keyed by the
exact root tree OID, so any tracked-path change—including a workflow-only change—creates a different
subject. An old cold receipt cannot prove production of the new tree, and warm reuse must follow
production of that same subject. No hand-maintained dependency list computes applicability for the
other arms either. Consequently no earlier arm is merge-authorizing evidence for a later tree.

Guarded landing checklist

The acceptance subject is the root tree T, not the candidate commit identity. An earlier
revision of this section claimed a squash merge "synthesizes a different commit/tree after
acceptance". That is too broad and is corrected here: because this PR deliberately excludes the
commit SHA from the materialized-tree build subject, a different landed commit is expected and
harmless. Only a different landed tree is inadmissible.

different commit: expected and harmless
different tree:   inadmissible

The retained landing predicate is therefore three conjuncts, and the landed commit may be a
two-parent merge commit or a one-parent squash-shaped commit:

the accepted subject is tree T
AND the landing operation may succeed only against pinned base M
AND the landed commit has tree T

Landing must be guarded at the ref update, so that it refuses if main no longer equals the
pinned base <M>. Immediately before landing, record and prove all three admission conjuncts:

1. git rev-parse <LANDED>^{tree} equals the tested <T>.
2. git merge-base --is-ancestor <M> <LANDED> succeeds. The explicit lease can authorize a
   non-fast-forward update, so ancestry is an independent requirement.
3. The ref update atomically requires remote refs/heads/main == <M> via exactly:
   git push --force-with-lease=refs/heads/main:<M> origin <LANDED>:refs/heads/main.

The bare --force-with-lease form is forbidden because its expectation may come from a moved
remote-tracking ref. A plain non-forced push is also insufficient because it tests ancestry rather
than equality with the reviewed base.

A squash-shaped landing is admissible, and does not require the tested two-parent commit C to
land. The exact equivalent is a precomputed one-parent commit S built from the named tree and
parent — tree(S) == T, parent(S) == M — actuated through the same lease. That preserves linear
history, the exact tested tree, and the atomic stale-base refusal together.

What is NOT admissible is an ordinary unguarded GitHub squash under this repository's present
configuration. GitHub's squash computes a new integration tree against whatever the base branch
currently is; its merge API can pin the PR head SHA but does not compare the base SHA, and this
repository's required-status rule is loose (strict_required_status_checks_policy: false) and
role-bypassable, so nothing supplies the missing old-base predicate. The failure sequence is then:
the packet proves T, main advances M -> M', GitHub integrates against M', main receives T',
and the post-hoc comparison reports T' != T — after an unaccepted tree is already published and
consumable by other automation. That cannot be repaired by regenerating afterwards: a regeneration
produces yet another tree and never establishes that the published T' satisfied cold production,
warm reuse, failure fidelity, reversal, the ambient control, or the floor at the moment it became
main. A post-landing tree(origin/main) == T check is required after any admissible mechanism,
but it is an audit of a guarded actuation and never a substitute for the guard.

Qualifying mechanisms, any one of which supplies the missing predicate: a merge queue whose
merge-group candidate runs the complete acceptance packet; strict non-bypassable up-to-date status
checks carrying the final BT evidence; a fleet-wide hold covering the packet and the merge; or
operator-authorized direct CAS to the precomputed squash commit S. Ordinary squash under the
present configuration is not one of them.

Direct ref actuation requires explicit operator authorization in every case. A general permission to
merge one's own PRs through ordinary policy does not authorize replacing GitHub's PR merge operation
with a direct ref update. If no qualifying mechanism is authorized, stop at the merge boundary.

Final regeneration evidence to fill without changing the source head:

• produced-seed bootstrap transcript, generation by generation: <FINAL_G0_TO_FIXED_POINT>
• confirmation that the produced candidate v1_compiler_emit_rust.rs contains the carrier producer
  symbols before the generation that creates the carrier: <FINAL_PRODUCED_EMITTER_CHECK>
• whole-population / RenderEveryModule, zero content drift: <FINAL_ZERO_DRIFT>
• source-authority population from
  v1.compiler.emit_rust.emit_emitted_population_manifest, reached through
  v1.compiler.emit_rust.emit_rust_selected: <FINAL_DECLARED_PATHS> total,
  <FINAL_SRC_MIRRORS> src/* mirrors, <FINAL_ADJUDICATED> adjudicated, plus declared-divergent
  main.rs; Cargo.toml is a declared path but not a Rust mirror
• identity join from every manifest row to its filesystem path: <FINAL_FILE_SET_EQUALITY>

The current pre-final observation is 151 declared paths = Cargo.toml + 150 src/* mirrors, with
149 adjudicated plus declared-divergent main.rs. It is a prior observation, not a value to copy
into the final packet.

Development and preflight receipts — not merge authorization

Head 3ea80ffaae154a81ac1f1bf08b1632ca2d8ab2fb is pre-final diagnostic evidence only.

• GitHub Actions run 33392133259 passed all five jobs. Required floor: 3246 planned/executed/
  terminal, 3177 passed, 20 known-red-held, zero failed/interrupted,
  known_red_now_passing=0, non_verdict_unenrolled=0, FloorClean. Claim-grain disposition shows
  both allocator controls, bootstrap admission, aggregate ownership, and all three stage-boundary
  claims passed; the interpreter Optional discriminator was known-red-held. Workspace-wide clippy
  executed and passed.
• Whole-population RenderEveryModule reported
  first_generation_equal=true planned=149 executed=149 adjudicated=149, with declared-divergent
  main.rs excluded.
• Shipped binary sha256
  9c6aa3f24586dc6b69b4ce906456aab424f2f5b9a921e710431abbdb9c2ba5c1.
• Cold preflight: client and producer exited 0 for root tree
  0f6d54f67229113ac8f26bc4c70f0025fbd88801; receipt token
  fnv1a64-f70c8b201ac4ed79, reused=false, artifact digest
  b350a078aefb967a1dcda6d2f8d5d3900e81097d038a010a59be9fc37687431f. Independent digest
  matched, the artifact executed, and --version reported gunbc tree:sha1:<that tree oid>.
• Warm-after-cold preflight used the identical subject, no producer process, reused=true, and the
  same digest. It was not a preseeded substitute.
• Failure-fidelity preflight used a distinct subject and a controlled missing cargo executable.
  Producer and client exited 1; the client returned ProducerRefusedRequest preserving the exact
  producer cause, never ArtifactNotRetrievable.
• Realization-reversal preflight changed only the Build row to
  CliKnownOperationNoRealization. The reversed tree reached zero drift after generation 1 named
  gunbc_cli_dispatch_generated.rs and gunbc_cli_dispatch_surface.rs, and generation 2 reported
  first_generation_equal=true planned=149 executed=149 adjudicated=149. The identical
  gunbc build gunbc argv exited 2 with the exact qualified-operation refusal; a fresh-directory
  census found only redirected stdout/stderr, with zero request, receipt, or artifact files.
  Restoration named the modeled surface in generation 1 and the carrier in generation 2; generation
  3 returned to zero drift at 149/149/149. Source and mirrors match HEAD; the restored carrier
  sha256 is 8594598fb25b3739323a229be172fb8e8e4eeeac85e882e84675852310aeed9d
  and the restored binary sha256 is the preflight binary digest above.
• Ambient-checkout preflight compiled the exact-head build.rs once and ran that same executable
  in a fresh clone at root tree 0f6d54f67229113ac8f26bc4c70f0025fbd88801. Clean emitted
  GUNBC_BUILD_IDENTITY=3ea80ffaae154a81ac1f1bf08b1632ca2d8ab2fb; after changing only
  one tracked file, dirty emitted the identical commit plus -dirty. Both stderr streams were empty.

All five arms in this section are diagnostic only and cannot be promoted into final evidence.

Earlier focused receipts remain corroboration only: workspace-wide dry-run semantics measured the
same argv and exported cache root at 0 effect files in Hermetic mode versus 70 in Wet mode; Build
dry-run showed identical refusal bytes at emitter, installed-carrier, and runtime grains; allocator
collision and receipt/PID isolation controls each selected and passed one non-vacuous test.

Final acceptance receipts — fill on the serialized candidate

• exact-head CI, all jobs, claim-grain disposition, workspace-wide clippy executed, and terminal
  non_verdict_unenrolled: <FINAL_CI>
• real shipped-binary --help, --version, Build dry-run no-effect, and semantic Run dry-run:
  <FINAL_BINARY_CONTROLS>
• BT-0C cold from a tree with no .git: production command, exact tree identity, returned bytes,
  independent digest, execution, and tree-tagged version: <FINAL_COLD>
• warm on that exact subject: same digest, reuse receipt, no second cargo production:
  <FINAL_WARM>
• controlled producer refusal preserved as ProducerRefusedRequest, never artifact retrieval:
  <FINAL_FAILURE_FIDELITY>
• realization-only reversal: identical argv refuses, publishes no request, creates no receipt or
  artifact, and initiates no producer work; restore returns the original carrier bytes and green:
  <FINAL_REVERSAL_AND_RESTORE>
• ambient checkout control, clean and dirty arms: <FINAL_AMBIENT_BUILD>

Hand-Rust residue

The exact new production residue is modeled at declaration identity in
gunbc.bootstrap_operation_seed_growth:

• v1_compiler.cli_run.run_bootstrap_dag_operation
• v1_compiler.cli_run.bootstrap_invocation_receipt_path
• v1_compiler.main.RetainedCliHost

The CliDispatchHost for RetainedCliHost impl is recorded as uncitable until std.decl_ref gains
impl-block identity. The current 86-file outside-manifest candidate set and its 3/83 leading-banner
diagnostic are pre-final observations and will be re-derived on the serialized candidate. The
repeated total of 86 across changing trees is coincidence from offsetting population deltas, not
evidence that the population was stable. This diagnostic is not a theorem that every generator
emits a banner, and the declaration roster does not depend on it.

Worker attestation

• Title describes the change.
• Body records the authority placement, corrected defects, and pre-final evidence honestly.
• Final serialized-candidate placeholders above are filled from measured transcripts.
• The ready flip occurs without changing the tested source tree.
• No unexpected commits, secrets, credentials, or large binaries are staged.

Generated-surface output-neutrality receipt

gunbc run --source-root dag --source-root src/v2 --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet regenerated the full generated set on the composed branch and left no worktree diff. As an independent untouched-projection control, docs/design-rung-drops.md was blob-identical to origin/main at a845ea5ecb9596df7c8a57b2aa81d9555901b47b. The shipped-consumer regression test shipped_build_command_reaches_the_generated_dispatcher executes the built binary, requires the generated dispatcher’s exact typed refusal, and is enrolled through the required rust-unit-tests all-targets job.

Shipped-consumer planted-revert receipt

The generated-dispatch consumer control was exercised in both directions. Restoring the pre-routing private-parser main.rs and executing shipped_build_command_reaches_the_generated_dispatcher produced RED: Clap returned status 2 with unrecognized subcommand 'build' rather than the generated dispatcher refusal. Restoring the current main.rs made the identical test PASS. The exact refusal text is deliberately load-bearing: a wording change must update this control intentionally, because matching only status 2 would accept both the generated dispatch path and Clap’s unrelated usage-error path.

[briansrls]

TECHNICAL-ONLY REVIEW at exact head ecfcc7435e1d5a86d7718a93749e8d3f26b8d53e — not merge authorization.

I find no new source/content blocker beyond the previously accepted exact subject d11ea319b74917f992f2c612ea605f5429e2d5e9. The branch-authored program is unchanged after that subject: the intervening commits are main integrations, with the three generated-projection conflicts resolved by regenerating from the composed authorities rather than by choosing a side. The exact-head required build then established first_generation_equal=true, planned/executed/adjudicated 150/150/150, declared-divergent only main.rs, and generated-artifact 35/35 adjudicated with 35 matches, zero drift/absence/unadjudicated. The full exact-head workflow is green.

So this PR is technically suitable to become a merge-queue entry without restarting its substantive investigation.

It is not a landing candidate now. Those receipts were produced for composition with pinned base 373b8d11a13d5fdae56b7db7a9e2cc83672fc1cc; current main is c4e498652fcf5522200a118079c50586349b38c2. The observed change between two consecutive base reads proves that a human check followed by an ordinary GitHub merge does not implement the required predicate. MERGEABLE/CLEAN and zero textual conflicts do not transfer the receipts to the new composed tree.

Landing remains HOLD until one qualifying mechanism constructs and tests the actual candidate and atomically refuses stale base: preferably a commissioned merge queue whose merge-group commit runs the complete acceptance packet, or an explicitly operator-authorized exact-tree/base-CAS actuation. On a queue route, enqueue this head and let base movement rebuild/retest the merge-group candidate; do not treat this review or the green PR-head run as permission for ordinary auto-merge.

[briansrls]

FRESHNESS ADDENDUM to technical-only review 5083921844: while completing that review, main advanced again from c4e498652fcf5522200a118079c50586349b38c2 to 7810e68b3ea12d29ad811a2f2a0e1023f0dcd241. The earlier comment's named c4e49865 was current when observed and is already historical. This does not alter the technical-content verdict; it further demonstrates that a human-observe-then-merge sequence cannot maintain the base-equality predicate. The HOLD is against every ordinary merge path until a merge-group candidate or atomic expected-base actuation supplies it.