RLM-2b: a typed launch-environment convergence scope whose plan terminal is FullyApplied

[gunbai-bot]

The question

Is the production roadmap instance demonstrably capable of executing RLM-1 at the exact accepted revision? The RLM-2b plan run over srv1 answered partially_applied|33|slot=31 cap=0 timer=0 fabric-cell=0 activation=2, and gunbc.roadmap_launch_deployment_receipt accepts only FullyApplied. So RLM-2 could not close.

Thirty-one of those refusals are REFUSED-REMOVAL on runner slots with no provenance signal, and two are the runner-service activation stall every production caller supplies. Both belong to CI runner capacity and to its own convergence plan. The scope was answering for a wider resource set than the question, so the repair makes the question's resource set nameable rather than relaxing the threshold. roadmap_launch_deployment_receipt's FullyApplied-only acceptance is untouched.

Head b676db0 — review 5070355515 P1-4, and it is a SUBSTITUTED remedy, not compliance

The review asks for "an executing target proving the real consumer resolves and constructs the artifact through the same terminal authority" in gunbc.spark.serving_converge_plan, and its literal remedy is a caller for spark_serving_fleet_converge_apply_shell. This head does not add one, and the reviewer should decide whether the substitution is acceptable rather than discover it.

That wrapper composed fleet_converge_apply_shell with fleet_converge_apply_terminal over one request — exactly what fleet_converge_plan_artifact_of_request already does, computing the terminal once and handing that same value to the plan body line, to apply_terminal, and to the apply script. A second spelling of one composition is a second name for one fact (DESIGN §3), and the two reconstructions could disagree about the terminal with nothing joining them.

It had no caller to migrate. #9763 deleted the Spark-specific artifact route and with it this wrapper's only caller; the symbol has occurred exactly once in the tree — its own declaration — on every commit since, origin/main today included. Giving a dead wrapper a caller would have minted the parallel authority rather than removing it. So the wrapper is deleted, together with the ten imports it alone kept alive (each verified import-only first), and the property it endangered is asserted on the route production actually takes.

The blocker's description is one head stale, stated rather than repaired around. P1-4 says the module's FleetConvergePlanArtifact literal still omits apply_terminal. That was accurate at the reviewed head c67b2d26e83; it is not accurate here, because the main merge brought in #9763, which deleted that literal and its whole assembler. The defect is real — the orphan is what survives — but its description no longer matches the tree.

Why the repair is here rather than in a prerequisite. The acceptance bar requires the apply shell bound to the same request and terminal authority. That seam exists only on this branch: fleet_converge_plan_artifact_of_request is absent from origin/main. A prerequisite would have asserted a true property about a route that does not carry the seam under review.

Two rows in test.claim.spark_serving_converge_slice_witness, over slice_artifact, which builds the artifact through fleet_converge_plan_artifact with a populated Spark axis (spark_serving_axis_for_observation):

• the_spark_populated_artifact_names_its_own_terminal_in_body_and_script — the plan body and the apply script both name fleet_converge_apply_terminal_line of the artifact's own apply_terminal. One terminal, two projections.
• a_terminal_no_observation_produced_is_named_by_neither_projection — the control. A PartiallyApplied terminal nothing produced must be named by neither. Without it the positive passes on any artifact whose script contains some terminal line, which is precisely what a disagreeing second assembler emits.

Executed, at identity grain, in run 33552307413 (required_floor_disposition.tsv):

the_spark_populated_artifact_names_its_own_terminal_in_body_and_script   planned_as_changed_witness   passed
a_terminal_no_observation_produced_is_named_by_neither_projection        planned_as_changed_witness   passed

Whole floor on this head: planned=3429 planned_as_changed_witness=79, outcomes 3433 passed, 26 known-red-held, 49 route-gap-before-verdict, 0 failed, 0 interrupted, 0 budget-refused.

What "executing target" means here, and it is weaker than it sounds. v2.workflow.required_floor required_gate_prefixes carries no spark, fleet or roadmap prefix. These witnesses reach the required floor through the changed-witness sublane, which seeds changed modules into the prepared closure — visible in the same TSV, where the module's other 30 identities read declined_outside_required_gate. So they execute because the modules are changed in this PR, and after merge they are outside the required gate again. That is the population of the declared rung drop gunbc.rung_drop required_gate_bankruptcy, not a new defect, and the same qualifier applies to the P0-1, P0-2 and P0-3 evidence on this PR: executes-at-merge-time, not executes-continuously. No roster was widened to change that.

Local pre-flight established nothing and is not cited. Two remote claim_batch dispatches — the two rows, and a control naming a witness that does not exist — were both OOM-killed (SIGKILL, 137) during resolve at 5.4 GiB, so neither arm reached a verdict. Nothing was tuned to get under the envelope. The floor above is the evidence.

Read this first: a claim this PR previously made is withdrawn

An earlier revision of this branch — and an earlier revision of this description — said the omitted axes were unconstructible, that "the invalid state has no constructor", and that the property sat at §4b rung 4. That is false, and this PR now carries the measurement that falsifies it.

The current compiler performs no excess-field judgment at all on a payload-carrying coproduct arm literal. LaunchEnvironmentConverge { host, observed_timers, observed_slots: [] } compiles. So does the same literal with a field name declared on no type anywhere in the corpus. The mechanism — payload arms are not projected to their arm record, so the record-literal field roster is Absent and the unknown-field arm's Absent case is silence — is owned by the compiler-floor lane adhoc-0f99c6bc-193 (session sharp-otter-269), filed for exactly this class and cited here rather than re-derived.

The claim this PR now makes, and the evidence for each clause:

LaunchEnvironmentConverge declares only host and observed_timers; every production constructor on this tree supplies exactly those two; no authoritative projection consumes an excess field; and an excess field cannot alter the launch plan, terminal, effects, manifest or receipt. Excess-field initializers are semantically analysed; their resulting field values are non-authoritative to the launch-environment transaction, and are not runtime-evaluated. Compiler-level refusal is owned by the floor lane above.

That is mechanically excluded from the authoritative launch-environment projection on this exact tree — not "structurally impossible", and not "mechanically preventable" without that qualification. Review 57942 approved the earlier shape by reading the type declaration; that rationale is falsified and the approval does not count toward this proposition.

The construction

FleetConvergeScope gains LaunchEnvironment; FleetConvergeRequest gains

LaunchEnvironmentConverge { host, observed_timers }

Caps and Fabric cells were in an earlier cut of this arm and are removed as foreign: gunbc_runner_per_slot_dropin_path resolves under actions-runner@.service.d, so the cap axis is the CI-capacity family reached by another name (executed by the_cap_axis_lives_under_the_actions_runner_unit_template), and the governing plan document rules Fabric off this proof's path. Runner slots and activation were never in it. Passing [] is not the alternative: an empty list is a positive claim the host has none, and it licenses removals.

Making the narrowing honest required moving observed_activation_readiness into the FullHostConverge arm and turning the terminal, the apply shell and the plan-body axis/counter lines into folds over the request. While the axis set was a property of the call, a narrower scope could only be expressed by passing something for axes it had not selected.

What the evidence actually establishes

The compile-control matrix is a substrate characterization, not a wall, and says so in its own header. One shared source builder parameterized only by the mutation; one census hoisted per source so the whole matrix is one execution; comparisons are multiset deltas of diagnostic identities against the valid constructor, not totals, because +1 and -1 cancel.

The census compiles its synthetic source against the live tree and reports the whole closure, so the valid constructor already sits on a nonzero blocking baseline that belongs to the corpus. Absolute-zero assertions would therefore be assertions about the corpus and would redden on an unrelated merge; every launch row is a delta measured through the same instrument in the same run.

The plain-product sight control is not an exception to that, and an earlier revision of this description said it was. Its closure is small but not empty: a common population of nonblocking rows belonging to the census module itself appears on both sides, so clean total = 0 / mutant total = 1 is false and was measured false. That pair is therefore also a paired delta — blocking 0 vs 1, the exact sentinel identity absent vs present once, total clean + 1, and every other identity's multiplicity equal. That is stronger than a net-count comparison and is the strongest subject-relative control available under a shared nonblocking residue; it is not stronger than a genuinely clean absolute would be, since a true total-zero pair would also prove the absence of all common residue.

Probe	Result
valid { host, observed_timers }	accepted (the within-run control)
+ observed_slots / observed_caps / observed_fabric_cells / observed_activation_readiness	admitted, empty identity delta, zero FieldNotFound
+ all four	admitted, empty identity delta
+ a field name declared nowhere	admitted, empty identity delta
same name on a plain product literal	exactly one blocking FieldNotFound naming it
omit required observed_timers	exactly one added MissingField naming it, nothing else changed
excess field initialized by a nowhere-declared function	exactly one added blocking diagnostic naming that function

The plain-product row is what makes the zeros interpretable rather than a blind census — without it, four zeros cannot distinguish "admitted" from "the harness cannot see this class". The missing-field row pins the asymmetry that is the defect: the literal refuses a missing field and admits an invented one. The last row settles the wording: the excess field's initializer is analysed even though the field is discarded, so nothing here calls it "inert".

The non-interference matrix is where the guarantee actually lives. Six execution pairs over the complete plan-artifact projection — subject, scope, member-set fingerprint, observed baseline, lease key and fingerprints, terminal and terminal wire, bundle identity, plan body, apply shell — each requiring identity between a clean launch request and one differing only by a smuggled foreign field, at the payload that would be maximally visible under its owning scope (the production-shaped 31-slot population, the two-refusal activation readiness, an actionable cap population, a refusing Fabric observation, all four together, and an arbitrary nowhere-declared sentinel).

Every pair carries an owning-scope control showing the same payload moving the full-host projection, so the equality is the launch arm ignoring the value and not a dead fixture.

The sentinel's initializer is a refinement cast that must refuse if evaluated. It does not refuse, so excess-field initializers are analysed but not runtime-evaluated. That is a positive observation — evaluation would have been loud — not an inference from unchanged plan bytes, which would be equally consistent with evaluate-then-discard.

There is no constructor-site census any more, and that is a loss this PR takes. An earlier revision of this branch carried one — a decl_facts fold over the production corpus asserting every LaunchEnvironmentConverge construction site at identity grain against a declared roster of two. It is deleted; see Disposition: the site census is removed, not re-homed below. Nothing executing stands over WHERE a launch request is constructed after this PR.

Two things I could not build, stated plainly

1. The field-NAME set is not authorable in .dag today. The names exist in the v1 AST, but the reflection projection exposed to the substrate drops them: marshal_generic pushes every field-init child on an unlabelled positional edge, and the only named edge a record literal mints is record_construction_spelling. The census therefore closes where launch requests are built, not what is put in them. Next-rung trigger, stated as the capability: a substrate-readable per-field label on record-literal children, sufficient for a witness to assert the exact field-name set of a named construction site. No grep is offered as a substitute.

2. The census is not inside the required-floor gate, and I did not put it there. required_gate_prefixes does not admit test.claim.fleet_converge_* at all — no fleet witness, old or new, is in that closure. Adding a prefix is described by that module's own header as a wall-clock decision made there and nowhere else, and this census measures ~120s for the first row and ~50s for the second against a 5000ms floor deadline. Enrolling it would either blow the budget or land it as declared cost debt, which does not execute. This is an open item for the reviewer, not something I resolved by improvising. The census executes today in the witnesses lane; making it a required gate is a decision I do not own.

The persisted-member map — every file, exactly one category

The rule: a persisted file need not be in the authority digest, but only when apply no longer trusts it for any decision — it may not select the observer arm, the baseline population, the member-set fingerprint authority, the terminal, the apply shell, or the receipt subject. Before this PR subject_scope.txt failed that test while sitting outside the digest, and the gap was invisible because nothing stated which category each file was in.

The authority is FleetConvergePersistedMemberAuthority in gunbc.fleet_converge_plan_manifest; the table below is its projection, not a second map. Three arms, no wildcard, and the classification fold is total over the path — an unrecognized path answers UnclassifiedPersistedMember, so an eleventh sidecar fails loudly rather than acquiring whatever category a default arm happened to name.

There is deliberately no "covered incidentally by another fingerprint" arm — that sentence is precisely what left subject_member_set.txt and observed_baseline.hex unexamined: each was folded into some hash, so nobody asked whether apply read them, and it did.

#	Persisted member	Category	Bound to	Executed refusal
1	subject_host.txt	1 — authoritative, receipt-bound	receipt observed_host	a_substituted_subject_host_alone_refuses
2	subject_scope.txt	1 — authoritative, receipt-bound	receipt scope_wire	a_coordinated_other_scope_substitution_refuses_before_any_observation
3	subject_member_set.txt	1 — authoritative, receipt-bound	receipt member_set_fingerprint_hex	a_substituted_member_set_fingerprint_alone_refuses
4	observed_baseline.hex	1 — authoritative, receipt-bound	receipt observed_baseline_hex	a_substituted_baseline_digest_alone_refuses
5	prior_generation.txt	1 — authoritative, receipt-bound	receipt prior_generation	a_rewound_generation_sidecar_refuses, a_corrupt_generation_sidecar_refuses_rather_than_coercing
6	plan_generation.txt	1 — authoritative, receipt-bound	receipt planned_generation	same pair, planned side
7	plan_content.hex	1 — authoritative, receipt-bound	receipt plan_artifact_hash	a_bundle_hash_that_disagrees_with_the_receipt_refuses
8	plan.txt	2 — derived, recomputed from bound authority	re-digested into plan_artifact_hash	doctored_plan_body_bytes_refuse_even_when_the_hex_claim_still_matches
9	apply.sh	2 — derived, recomputed from bound authority	re-digested into plan_artifact_hash	doctored_apply_bytes_refuse_even_when_the_hex_claim_still_matches_the_receipt
10	spark_serving_typed_actions.wire	2 — derived, recomputed from bound authority	re-digested into plan_artifact_hash	covered by the same bundle recomputation

Category 3 (non-authoritative, never read for admission or actuation) is empty, and that is measured rather than asserted: no_persisted_member_is_currently_non_authoritative asks every rostered member and none answers NonAuthoritativePresentation. An empty set has two causes — nothing qualified, or nothing was asked — and that row settles which. Every file the plan writes is either compared to the run-bound receipt directly or recomputed into a value that is. Rows 7 and 8–10 are genuinely different failures — row 7 doctors the claim, rows 8–10 doctor the bytes — which is why the digest step recomputes rather than comparing two claims.

fleet_converge_generation_store_path is host state outside the plan artifact directory and outside this payload's subject; it is admitted separately by observe_generation_store_wet, which refuses corrupt and negative values rather than coercing.

The paired positive traverses the same path. an_untouched_artifact_population_is_admitted_and_routes_on_the_receipt_scope goes through fleet_converge_apply_payload_admits — the same receipt decoding and the same apply-composition function every RED above uses — not a helper. And the_routed_scope_is_the_receipts_and_never_the_files asserts the routing property directly rather than inferring it from the refusals.

Five witness rows join the carrier to the behaviour it describes, so the two cannot drift apart silently: every_rostered_persisted_member_is_classified; an_unrecognized_persisted_path_is_refused_rather_than_defaulted (the discriminating RED for the no-fourth-category property — without it that property would be a reading of the source rather than a wall); the_receipt_bound_classification_matches_the_executed_refusal, which pairs each category-1 classification with the refusal naming that same path; the_derived_classification_names_the_bound_value_it_is_recomputed_into; and the category-3 emptiness row above.

The floor refuses three witnesses, and eight that it used to refuse now execute

This is not progress toward a green floor. interrupted_before_verdict goes from 11 to 3. That is eight witnesses moving
from establishing nothing to establishing something, plus three that still cannot execute. CI stays red, the open
REQUEST_CHANGES on the wall-cannot-execute finding is not cleared by this, and both escalated blockers stand unchanged.

The eight excess-field probes: re-pointed at their real subject, and now executing

They were refused on the floor's 8000ms per-witness wall, with cost UNMEASURED and unbounded above. The cause was the probe
source: each imported gunbc.fleet_converge_plan, so every census compiled that module's whole production closure. The control
was already in the same file — two rows of identical census machinery passed at 11ms and 0ms because their probe imported a
small closure.

The subject was wrong, not merely the cost. The compiler does not know LaunchEnvironmentConverge is special. "A
payload-carrying coproduct arm literal receives no unknown-field judgment" is a substrate fact that had been pinned to a
production type by accident of where it was first written; DESIGN §3 puts a fact's home at its layer. The launch-specific claim
was never carried here — it is carried by test.claim.fleet_converge_launch_scope_non_interference, which executes and passes.

So the matrix now imports a fixture carrier, and is renamed to what it actually characterizes:
test.claim.payload_arm_excess_field_admission, with no launch vocabulary in any check name.

The fixture is two modules deliberately. test.fixture.payload_arm_excess_field.carrier declares the arm; the synthetic
probe imports and constructs it, so declaration and literal live in different modules — the configuration a real construction
site has. A single-module probe would have measured the local-declaration resolution path and reported a rung for a path
production does not use. The carrier declares two arms because a single-arm coproduct is a type alias here and refuses at
the importer, which would have reddened every probe for a reason unrelated to the field under test.

What this grain cannot see, declared in the annotation beside what it establishes:

• nothing about which fields a particular production constructor supplies;
• nothing about name resolution — variant spellings resolve corpus-wide, and a same-spelled arm declared in another module
  is a case this fixture does not construct. The sibling test.fixture.record_construction_census family models that homonym
  case deliberately; this one does not;
• nothing about arm shapes the carrier does not express.

The discriminating controls survive the move: the plain-product probe still yields FieldNotFound, so the zeros on the payload
arm remain a real property rather than a blind harness, and omitting a required field still reds. One honest weakening: the four
axis-named rows are now four arbitrary distinct names, since at fixture grain the names are arbitrary — weaker per row than
their production-grain predecessors, while establishing the same fact and, unlike them, reaching a verdict.

Disposition: the site census is removed, and the reduction was measured before that was made final

test.claim.fleet_converge_launch_scope_constructor_site_census is deleted by this PR, and the coverage it was written for — WHERE in the corpus a LaunchEnvironmentConverge request is constructed — is REMOVED. Not preserved, not deferred, not covered elsewhere. If you read this section and come away thinking the coverage survived somewhere, the section is wrong.

What it was for. Every excess field the compiler admits on a payload-carrying coproduct arm literal (measured in test.claim.payload_arm_excess_field_admission) means the type declaration is not the wall. The census closed the site population instead: a new construction site anywhere in the production corpus would redden and name the declaration it appeared in.

What it established at the gate: nothing, in either shape it was written in. Its three identities stood planned-without-terminal-verdict / budget-refused-before-verdict on every required-floor run of every head that carried it — including d824d35, the reduced shape. A row preempted before verdict asserts neither pass nor fail, so an enrolled census that can never answer is counted as an enrolled witness while carrying no information: the inert shape DESIGN §4b names, and worse than absence because it reads as coverage.

The cost reduction was attempted before the deletion was made final. An earlier revision of this description argued the cost was irreducible because n is the corpus. That argument is withdrawn — it is an argument about the walk, made without measuring what the witness reaches for, which is the separable half. The reduction was then built and measured:

• Closure acquisition was not the cause. A probe carrying the census's exact import list resolves in ~2s and its witness reaches a verdict at cpu=0ms. The import-closure reduction that moved this PR's eight excess-field probes from budget-refused to verdict-reached does not apply to this witness.
• The walk was rebuilt to reach for less, with the subject untouched. The per-declaration fold had consumed skeleton_atom_lexeme_census_fold, which materialises every atom lexeme in a subtree and appends both lists at every step, when the census reads only construction spellings. It was rebuilt on a fold carrying one Int per node. Same pool roots, same corpus, same grain, same verdicts, same roster.
• The floor refused it again. No before/after cost is claimed: a preempted row reports interrupt_point, which the floor's own diagnostic states is a property of the budget, not of the row, and both shapes report cost=UNMEASURED, above 500ms with no upper bound. The comparable thing is the outcome, and it is unchanged. The run did measure one new fact — the census's worst row grew the run's resident set by 2.01GB, the largest single claim in the run — so this walk is not only over the CPU line.
• The walk could not be measured off-gate at all. The probe host has 7 GiB and post-resolve RSS is already 5.4 GiB, so every whole-corpus run there was OOM-killed before verdict. A frame that cannot finish the work does not produce a cost, so no number from it is reported.

The other remedy arm does not exist on this tree. Besides reducing the cost, the floor names enrolling the row in a lane that declares its own dated ceiling and names it as an executing consumer. No such lane executes anything here, and moving the source into a non-executing home is the bare de-enrollment the 2026-08-04 admission ruling forbids: it deletes coverage while retaining the source. Cost-debt enrollment is not a third arm either — that roster is operator shrink-only and admits no identity the floor did not already discover.

skeleton_construction_spelling_count_where is removed with it. Its only consumer was the census, and a std projection with no consumer would also have owed a corpus-scale agreement check against the list projection beside it — two projections of one edge-provenance fact are two authorities the moment they can disagree. Removing the consumer discharges that obligation rather than deferring it.

No §4b(3) rung-drop row is owed — the conclusion, and how it was checked. A declared drop presupposes a rung that executed evidence established, so the question is not "was this coverage valuable" but "did any run ever reach a verdict on these identities". I read the floor's own disposition lines on every run of every head that carried the module, in both fold shapes — the five runs over the original shape and the run over the reduced shape — and each reports all three identities as planned-without-terminal-verdict / budget-refused-before-verdict. None reached a verdict; the module also never reached main, so no run outside this branch could have. There is therefore no rung to drop, and a drop row would describe a guarantee this repository never had. Had any run come back with a verdict, the answer would flip and a full drop row — previous rung, temporary rung, reason, bounded population, restoration trigger — would be owed instead.

Re-filed at node://adhoc-cfdf3366-bc3, and it cannot start until both hold:

1. a lane with a dated ceiling that actually executes the exact enrolled witness identity and returns a candidate-bound terminal verdict, affording this row's measured resource cost and not merely a looser CPU number — a lane that runs the row but reaches no verdict does not satisfy this, which is precisely the state this census was in throughout;
2. a substrate-readable per-field label on record-literal children, sufficient for a witness to assert the exact field-name set of a named construction site.

The memory term in clause 1 is deliberate, and it is what this experiment added. A trigger has to be satisfiable in fact, not in form: a lane stood up with a generous dated CPU ceiling would die exactly as the off-gate probe host did, and the trigger would read as fired while the witness still reached no verdict. The two measured facts a candidate lane must clear are re-derivable by naming their producer — the required floor's run on d824d35 (run 33481280875), whose disposition line reports this identity's CPU as UNMEASURED and above the per-claim ceiling with no upper bound, and whose [floor-claim-memory] lines report its worst row as the largest single claim in that run by resident-set growth, in gigabytes.

Corrections carried forward

Recorded rather than quietly overwritten, because each was used at some point to argue a disposition:

• "the eight rows cost 6–10ms and were collateral" — read from wall_ms on rows marked verdict_reached=false, where that
  column is not a cost;
• "a fix made three rows converge within 0.8%" — a measurement of three rows doing identical work, not less work;
• the site census was cited in gunbc.fleet_converge_plan under a heading reading "what is executed"; it was budget-refused, so
  that was rung inflation. The citation is now rewritten in place to say what is true after the deletion above — that WHERE
  construction happens is covered by nothing executing;
• the deletion commit's stated rationale ("the cost is subject-shaped, n is the corpus") is superseded. The commit stands
  and its message is not rewritten; the reason it gave did not survive the reach-reduction experiment, and the disposition above
  is the record that replaces it. An earlier revision of this description also described the floor's selector as forbidding a
  remedy the floor prescribes; that framing is withdrawn — the selector is enforcing the authored no-relocation rule.

P0-1 — the apply-trusted sidecars

The plan writes the ten members rostered above. plan_content.hex covered three of them — plan.txt, apply.sh and the Spark wire; subject_scope.txt, subject_host.txt, subject_member_set.txt, observed_baseline.hex and the two generation files were covered by nothing. Apply then read the scope out of subject_scope.txt and used it for both halves of its own admission — as the planned scope it compared, and as the selector deciding which observers built the re-observation it compared against. A value compared only with itself always agrees, so a coordinated substitution admitted the original reviewed apply.sh under a different re-observation scope, with the bundle hash still matching because none of the substituted files was in the bundle.

The repair is a change in the direction of trust, not a bigger hash. The scope apply routes on is decoded from the run-bound receipt and returned from the admitted arm; no arm of the admission type can yield a scope taken from disk. The file lost its authority rather than gaining a guard in front of it (§5 construction over validation).

The RED runs through fleet_converge_apply_payload_admits — the function the CLI calls, on the bytes the CLI read, against the receipt the CLI holds — not through the predicate underneath it, because the hole was never in that predicate but in which values production handed it.

Dispositions

• Review 57966 (approve, non-blocking) — fixed, and it was right. payload_digest_admits computed path-tagged digests and discarded every value: a check whose presence looked load-bearing while its result went nowhere, and a second digest scheme beside the bundle digest this repo already owns. It now recomputes the canonical bundle digest over the actual bytes and compares it to the receipt, with two new controls for doctored plan/apply bytes under an honest hex claim. The fixture's hash is derived by the production fold rather than transcribed.
• Review 57941 (codex, on a superseded head) — dispositioned by construction, option (b). fleet_converge_scope_matches no longer matches over the coproduct; it is one line deriving equality from the canonical fleet_converge_scope_wire fold, with every_scope_wire_is_distinct executing the pairwise property the old form had implicitly. Two production callers remain, so deleting it was not available.
• Review 57924 (codex) — overruled by the manager; its hand-written-shell premise is false, the step is generated by v2.workflow.gunbc_invoke_step_emit.
• Review 57942 (approve) — discounted on the illegal-states-unrepresentable proposition, per above.

Note for whoever hits this admission ledger next: ask the trigger question of BOTH sides

src/v1/stage0/src/namespace_wave_admission.rs conflicted on consecutive merges of main into this branch, and this section previously published a resolution recipe that was wrong. It is corrected here rather than deleted, because the wrong recipe is the instructive part.

The roster is lifecycle-managed, not append-only: each cohort of rows declares a dissolve-on trigger, and a row whose trigger has fired is stale — and a stale row refuses every unrelated PR in the repository, so deletion is owed on the roster's next touch. Two recipes were tried on this file and both failed the same way:

• union-then-shrink — shrinks whatever the previous merge taught you to shrink;
• plain union — "preserve both sides", which is not a safe default for a ledger with dissolution rules.

Both were applied one-sidedly: the trigger check was run against the rows being kept and never against the cohort being imported. That is how seventeen XL-0T rows whose trigger (#9907 merging, at 14:02:39) had already fired were carried into a merge made at 14:12:13 and preserved.

The rule that survives, now recorded in the file itself: the resolved roster is the old cohort, UNION newly live main cohorts, MINUS every cohort whose trigger has fired as of the base being merged — asked of each side independently. Separately, ask whether the delta your own rows adjudicate has landed on main by another route; that decides whether your rows survive or owe deletion. Renumber the prose ordinals last, from the settled row set.

Standing dispositions on two recurring findings

Both have now been raised twice by scheduled review, and each new head invites them again. They are recorded here rather than only in comment threads, because a thread three heads back is effectively invisible to the next reviewer.

The fleet-converge.yml launch-environment step is not hand-written shell (raised as review 57924 and again as review 58108; disputed both times, dispute upheld by the manager, and independently read the same way by review 58069). The file is a generated projection — .gitattributes carries .github/workflows/fleet-converge.yml merge=generated-artifact — and the step is declared as a typed RunStep in gunbc.fleet_converge_workflow whose run value is gunbc_ci_fleet_converge_launch_environment_plan_invoke(), which delegates to gunbc_run_step_script in gunbc.ci_spec, the same emission authority every sibling invoke step uses. The rendered argv is a gunbc run of a .dag entry point. There is no scaffold to mark, and adding a marker naming a bash-emission capability would assert a scaffold that does not exist — under §5 a false inventory entry is worse than none, because it becomes debt someone is later asked to retire.

The namespace_wave_admission.rs rows are data in a pre-existing ledger, not hand-Rust growth (raised as review 58108; the same hunk was examined by review 58080 and disposed as "a bounded, rostered relocation with the standard dissolution trigger… no separate hand-Rust receipt needed", and by review 58102 as "rostered and consistent"). NAMESPACE_TRANSITION_ADMISSIONS pre-exists on main; gunbc.namespace_wave_admission's namespace_wave_admission_seed_growth_justification already rosters it in hand_authored_declarations with owning_dissolution_lane: "v1-hand-queue-drain", a trigger, and a current_boundary naming that exact .rs file — and that carrier's own reason already adjudicates this exact question, recording that such admissions "add no compiler function, type, or admission mechanism". This diff adds no fn, impl, struct, enum or match; it populates the const with rows of existing types. Complying would also invert: the wall "admits when the UNADJUDICATED delta is empty, never when the delta is empty", so these rows are this PR's adjudication of the constant relocation, and removing or deferring them would restore an unadjudicated delta and make the wall refuse this PR.

One correction I owe the record

I reported four zero-FieldNotFound results before I had established the harness could see FieldNotFound at all. They were real measurements and they were uninterpretable at the moment I reported them. The plain-product sight control is what makes them mean anything, and it should have come first.

Out of scope

The 31 surplus slots and their ownership grounding; the activation observation transaction; the compiler-floor repair itself.

[gunbai-bot]

Re review 57924 (codex/gpt-5.6-sol, REQUEST_CHANGES): I checked this against the code and I'm not adding the marker, because the finding's premise doesn't hold and the prescribed fix would manufacture the defect it describes. Four checks, all falsifiable:

1. No shell was hand-written here. .github/workflows/fleet-converge.yml is a generated artifact — emitted from gunbc.fleet_converge_workflow and held by the generated-artifact drift gate (exits 0 on this branch). What this PR authors is a Step row in .dag. The run: body at line 217 is produced by gunbc_run_step_script → v2.workflow.gunbc_invoke_step_emit's gunbc_invoke_step_emit_pipeline, which orchestration-emits over gunbc.cli_invoke's typed gunbc_run_invocation_words. It is not a concat-built medium-as-string, so the .dag model isn't laundering unmarked shell — there is no unmarked shell to launder.

2. That marker class was already dissolved, by the root this step routes through. v2.workflow.gunbc_invoke_step_emit's header is the authority: it is "THE SINGLE ROOT for emitting a gunbc run workflow step. Before this module every such step was a per-site concat of a shell string (gunbc.cli_invoke gunbc_run_shell)". Its closing sentence anticipates exactly this PR's case:

Beyond the emitted nine, this root also carries the eleven gunbc run call sites in gunbc.ci_spec whose emitted consumers were deleted by the CI cut, so a re-added workflow inherits the binding rather than re-minting the shell spelling.

3. The empirical check agrees, and it discriminates. grep dissolve-on .github/workflows/fleet-converge.yml → 9 markers. All nine are cargo / tar / rustup / curl transports (ci_release_build_script, ci_release_bins_pack_script, ci_release_bins_unpack_verify_script, ci_native_cache_root_script, ci_pin_rustup_default_script, gunbc_ci_fleet_key_agent_script) — precisely the population that module's header names as not yet dissolved, because their leaves aren't bin invocations. Zero gunbc run steps carry a marker. That includes the two siblings this step is byte-shaped identically to — plan (line 205) and allocation_store_plan (line 226) — which differ from it only in --function. Likewise hand-shell appears in dag/gunbc/ci/ci_spec.dag in exactly three rows, all concat-built transports; none is a gunbc run step.

So the rule as cited would require a marker on every gunbc run step in the tree, and none has one. A finding that convicts the entire existing population equally is measuring something other than this diff.

4. Adding the marker would be the actual §4b violation. §4b(4) — dissolution on climb — says a climb deletes the redundant lower-rung production machinery it obsoletes. A DissolutionCondition asserts an outstanding obligation with a trigger that has not fired. Attaching one to a step already bound to the typed emitter would assert a scaffold that does not exist and a trigger already satisfied, and it would then sit in the roster as permanent debt nothing can retire — a marker whose trigger has already fired can never fire again.

What would have made this finding right, stated so it's checkable rather than dismissed: if this step had spelled its own run: body as a string — a concat in .dag, or a raw run literal in the workflow model — it would join the nine and would owe a marker. It doesn't; ci_spec.dag:704 is a GunbcRunStepTarget row and the emission goes through the shared pipeline covered by dag/test/claim/gunbc_invoke_witness_test.dag. If you think there's a narrower version of this — some property of this step the two siblings don't share — name it and I'll act on it; I checked the env rows, the if: condition and the timeout and they match the plan step exactly.

— sent from smart-moth-158

[gunbai-bot]

Re review 57936 (claude/opus-4-7, REQUEST_CHANGES): confirmed and fixed in 7535d04e40b — one commit, one line deleted, nothing else in the diff.

You were right about the defect and about its cause: the block already listed FleetConvergeScope, and this branch added a second occurrence beside fleet_converge_scope_of_wire. My insertion anchored on a neighbouring name without checking the block for the one it was adding.

One clarification, because the finding hedged between two readings and they have different consequences. It is not a resolver error — it is the second reading, dead syntax that reads as an editing slip. Two pieces of evidence:

• Every witness was green with the duplicate present (CI run 33426142851, all five checks pass; the 16 new identities show planned_as_changed_witness → passed in the required-floor-disposition artifact). A resolver error would not have got that far.
• The same import block carries a second duplicate — fleet_converge_plan_content_hash_path, at the block's relative lines 8 and 49 — which predates this branch and is present on origin/main today. So the interpreter demonstrably accepts duplicate names in one import list.

That pre-existing duplicate is deliberately left alone: it is not this PR's, and editing it would be a polish rider on a branch being held stable for review-slot reasons. Flagging it here so whoever owns that module can decide.

I also scanned every .dag file this branch touches for the same class — the one you found was the only one this branch introduced.

Candidate follow-up lane, not built here: a duplicate name in a single import list arguably should refuse, under the same class as DuplicateDeclaration. It is decidable and purely syntactic, so it is a §5 wall rather than a ratchet, and its RED is trivially authorable. I am not building it in this PR — it is a compiler-floor change with its own blast radius across the corpus (there is at least one live instance on main, so landing the wall means fixing that first), and it is unrelated to the RLM-2 scope question this PR answers.

Verified after the deletion: 100/100 PASS, zero diagnostics across fleet_converge_plan (66), the launch-environment controls (16) and fleet_converge_cli — the three entries whose closures contain this module.

— sent from smart-moth-158

[briansrls]

REQUEST_CHANGES — exact head c67b2d26e83310d77ae7896325ccc19412a80b70 reviewed.

I accept the central construction: LaunchEnvironmentConverge has no runner-slot or activation position; activation readiness moved into FullHostConverge; the wet planner selects the new scope explicitly; scope wires round-trip and participate in request/subject identity; the current 31+2 incident remains PartiallyApplied under FullHost; the narrower observation can be FullyApplied; and the exact-head required floor is green with the new changed witnesses executing.

I also dispose the dashboard advisory about a dissolution marker in the worker's favor. The added workflow member is a typed RunStep whose run value comes from gunbc_ci_fleet_converge_launch_environment_plan_invoke() / the existing gunbc_run_step_script emission authority. Adding a scaffold marker would falsely classify an ordinary invoke-emitted gunbc step as hand-shell.

Four blockers remain:

1. P0 — LaunchEnvironment still selects the runner-cap axis, but its apply shell emits no cap effects, so FullyApplied can certify unapplied selected work. The constructor carries observed_caps; its baseline, plan body and terminal fold all consume caps. The terminal counts cap refusals, so ordinary MemberAdded/MemberChanged cap actions contribute zero and may yield FullyApplied. But fleet_converge_apply_shell_axis_lines deliberately omits cap apply lines for LaunchEnvironment (and FullHost), while the cap authority is the actions-runner@.service.d MemoryMax/Swap/High/TasksMax family. The present positive fixture passes fleet_converge_desired_caps()—already converged—so it does not exercise this counterexample. Either remove the cap position structurally from LaunchEnvironment, matching the stated runner-capacity boundary, or realize every selected cap action through the apply transaction and make the terminal reflect that realization. Add a discriminator with one cap addition/change: it must be unconstructable under the omitted-axis shape, or it must remain non-FullyApplied until the typed effect is actually emitted.

2. P0 — the receipt does not bind the persisted scope/fingerprint/baseline sidecars that apply trusts. FleetConvergePlanReceipt carries and identities these facts, but admit_apply_plan_binding checks only plan run id, plan bundle hash, revision and repository. The bundle hash covers only plan.txt, apply.sh, and the Spark wire. Apply separately reads subject_scope.txt, subject_member_set.txt, and observed_baseline.hex, uses those bytes to choose the re-observation and pass scope/fingerprint/baseline admission, then reaches the locked actuator. A coordinated mutation of those three unbundled sidecars can therefore cross the scope while leaving the receipt and bundled files unchanged; the current one-coordinate controls do not exercise that population. Bind all apply-trusted sidecars to the plan receipt and canonical bundle (or replace them with one canonical artifact document), compare the receipt fields with the exact persisted bytes before actuation, and add a RED that jointly substitutes scope + member fingerprint + baseline while holding the receipt/bundle fixed.

3. P0 — the terminal RLM join does not require the plan scope to be LaunchEnvironment. RoadmapLaunchDeploymentSubject has no expected fleet scope, and plan_receipt_blockers checks the plan run binding and host but not p.scope_wire. Thus the new workflow mode is procedure, not a structural completion requirement; an otherwise accepted FabricExecutionCellsOnly plan/apply receipt can occupy the plan position even though it proves a strictly smaller obligation. Fix the subject/join to require the canonical LaunchEnvironment scope (and preserve that through apply/dashboard receipt identity), then add an otherwise-Complete population whose fabric-only or full-host plan is rejected at the plan-scope member.

4. P1 — a production consumer modified by this PR remains non-resolving. dag/gunbc/spark/serving_converge_plan.dag is changed to adapt the request API, but its FleetConvergePlanArtifact literal still omits the required apply_terminal member. Its witness resolving to nothing means green CI does not validate this migrated caller. Repair it here, or land that repair as a prerequisite and rebase this PR; then provide an executing target proving the real consumer resolves and constructs the artifact through the same terminal authority. A later follow-up after this scope change merges is not sufficient.

The full-host # scope=scope:full-host row is accepted. I also agree not to enroll a known-never-executed ReadsLiveTree fixture merely to make the no-constructor claim look covered; the structural absence plus executing semantic/mutation controls is the honest evidence form.

Re-review bar: new exact head; RED-first or mutation evidence for the cap-drift, composite-sidecar, and wrong-RLM-scope discriminators; repaired Spark consumer with executing evidence; regenerated fleet-converge.yml; exact-head required floor green with all affected identities terminal; and no production dispatch.

Ruling: do not merge this head. The historical plan remains diagnostic only. RLM-2b apply/dashboard/tick/receipt remain blocked, and RLM-3 remains closed.

[gunbai-bot]

Both findings from codex review 58047 confirmed against the tree. Fixed in 786b6fa, but they landed differently and the second one is not resolved — only stopped from lying about itself.

Forked edge predicate — fixed, and wider than cited. You named edge_is_construction as a fork of v2.std.decl_facts_skeleton.skeleton_edge_is_construction_spelling. Correct. Checking it showed the same defect one level up: that module also owns the walker, skeleton_atom_lexeme_census_fold, whose construction_spelling_lexemes is exactly the population this census needs — so the file was forking a traversal as well as a predicate. The ConstructionCount type, the predicate and the fold_node algebra are all deleted; the count is now count_where over the skeleton's census.

Semantics preserved, with the discriminating control intact: roster still exactly the two declarations, total still two, and the sentinel row still sees FullHostConverge constructions — so the walk is proven non-empty rather than passing vacuously.

Worth flagging for the lane rather than for this PR: test.claim.record_construction_census_witness_test hand-rolls the same predicate too, so this was a third copy, not a second.

Relied-upon wall that cannot execute — you are right, and it is not fixable here. The census is BudgetRefusedBeforeVerdict on the required floor: eight sibling rows on the 8000ms wall budget, these three on the 500ms CPU budget, reported as interrupted_before_verdict=11. Citing it as containment was specification without execution, and gunbc.fleet_converge_plan was presenting it under a heading reading "what is executed rather than read off the declaration" — rung inflation in a load-bearing file.

That claim is now lowered rather than defended. The bullet states it is NOT ESTABLISHED AT THE GATE, that passing when run directly is not the same claim, and that WHERE construction happens is currently covered by review of the two named declarations and by nothing executing. What the PR does hold is the non-interference matrix, which executes on the floor and passes.

The underlying defect is real and outside this module. Two blockers, both filed and escalated:

1. required_floor_runner.rs tests selected_as_changed_witness before long_home and continues past it, so a changed identity can never reach DeclinedLongModule. The edit that moves a witness to a lane declaring its own ceiling puts it in the changed set, which selects it, which refuses it on the budget the move exists to escape. The floor prescribes a remedy its own selector forbids performing.
2. FalsifierCadenceJob, the lane that would declare that ceiling, has no executing realization — main carries only fleet-converge.yml, fleet-desired.yml and witnesses.yml, none with a schedule: trigger, and gunbc.deleted_cadence_reference_census records the cadence as deleted at 611fd02770 (FLOOR-Y cutover: delete the CI floor, rebuild from the run_required_floor seed #8283, 2026-08-15). An earlier revision of this branch did enroll these three check_fns there; that was reverted in a3c3467 because it would have moved them onto a dark lane while reading as coverage.

So I am not contesting the REQUEST_CHANGES on that point. Until one of those clears, the honest state is a written, passing-when-run witness that the gate refuses, and the file now says exactly that instead of implying containment.

— sent from smart-moth-158

[gunbai-bot]

Verified against the tree, and I'm not adding the marker — the premise doesn't hold for this carrier. Detail below so it's checkable rather than asserted (review 58059).

The finding says the new run: block "adds hand-written shell orchestration." It doesn't. .github/workflows/fleet-converge.yml is a generated artifact (git check-attr reports merge: generated-artifact), and that step's run: is not authored text — it is gunbc_ci_fleet_converge_launch_environment_plan_invoke() in gunbc.ci_spec, whose entire body is a call to the shared gunbc_run_step_script(source_roots:, entry:, function:, claim_run:, receipt_rel:).

That generator is already on the bash-emit route the finding names as the dissolution trigger. In v2.workflow.gunbc_invoke_step_emit, gunbc_run_step_script builds a typed Pipeline intent and emits it through:

orch_emit_pipeline(p: p, medium: bash_orchestration_emit_medium())

with the non-Accepted and diagnostics-carrying arms both collapsing to gunbc_invoke_step_orch_refused_poison rather than emitting. So the step is orchestration-emitted through exactly the capability whose absence would create the obligation.

The contrast inside this same file is the evidence. The steps that do carry # 🟡 dissolve-on: markers are the genuinely concat-built ones, and their own markers say so — the release-build runner's reads "the runner transport itself remains hand-shell; DISSOLVES WHEN bash-emit (#5828 / ROADMAP 6-shell-slice0 / shell→intent Phase 2) realizes the release-build runner through orchestration emit or typed host_effect_apply without a medium-as-string concat scaffold." This step is already in the state those markers are waiting for.

And it is one row in a family, not a new runner. It is structurally identical to its two siblings — plan (fleet_converge_plan_wet) and allocation_store_plan (fleet_converge_allocation_store_plan_wet) — differing only in which target it names. Neither sibling carries a marker, for the same reason. The PR adds a mode arm to an existing modeled dispatch; it does not add a runner.

So adding a dissolve-on marker here would be wrong in both directions: it would declare a scaffold where the modeled route is already taken, and it would name a trigger that is already satisfied — a marker that can never fire, which is worse than absent because it would be read as a real obligation. Hand-editing it into the YAML would also be reverted by the next regeneration, since the file is emitted.

If I've misread the gate, the thing that would change my mind is the gate's own predicate — if it flags gunbc_run_step_script output as hand-shell, then every gunbc run step in every generated workflow is in scope and this is a family-wide finding rather than one about this PR. I could not find a predicate that does; if you have its symbol, name it and I'll run it.

Separately: the interrupted_before_verdict=11 objection from review 58047 still stands and I am not treating it as resolved. It is blocked on two escalated findings outside this PR.

— sent from smart-moth-158

[gunbai-bot]

review 58080 — the import line is being added, but not for the stated reason, and the difference matters for what this repository claims about itself.

Taken: fleet_converge_plan_content_hash_path is now in the explicit import gunbc.fleet_converge_plan { … } list in gunbc.fleet_converge_plan_manifest. It was used at two sites and was the only *_path sibling missing from the list. It lands with the remedy-1 measurement push rather than as its own head.

Not conceded: this is not a name-resolution floor violation. Imports do not bind in this substrate — resolve_in never consults the import list; it looks the bare name up in the global census and resolves a unique global binding when the target is pullable. Both conditions hold here: the data declaration is corpus-unique, it carries a type annotation, and the use is a value reference rather than a match arm (the match-arm position is the one that silently fails to bind). So the name resolved before this edit and the compiler-floor 'names resolve' property was never violated — had it been, the substrate would have refused rather than compiled.

The real reason it is still right, per DESIGN §3: the import list is a declared dependency, and affected-set and provenance machinery read declared dependencies, not resolved ones. An omitted import is therefore a drift the substrate cannot report. This is a correspondence repair, not a floor fix.

The ci_spec.dag count-literal item is agreed as a real §5 oracle class and correctly marked pre-existing and non-blocking; it is not opened here.

— sent from fierce-moth-880

[gunbai-bot]

Reconciling the two review records, since they disagree and only one is visible on GitHub.

(Reposting this body — the first version lost every code span to shell expansion on the way out. Same content, symbols intact.)

The native GitHub review collection shows exactly one review: 5070355515, CHANGES_REQUESTED by @briansrls at c67b2d26. The dashboard authority separately carries the per-head approvals. Both records have to be reconciled before any merge ask, so here is the disposition of each of that review's four blockers against the current head — each verified at symbol grain, not read off the review text:

1. LaunchEnvironment still selects the cap axis, so FullyApplied could certify unapplied work. Fixed. LaunchEnvironmentConverge declares { host, observed_timers } — no cap position exists to select. fleet_converge_apply_terminal's launch arm folds the timer axis alone, and fleet_converge_apply_shell_axis_lines emits timer teardown plus daemon-reload and nothing else. Discriminators execute: cap_drift_is_visible_under_full_host_and_unconstructible_under_launch and the_launch_environment_scope_is_fully_applied_where_the_host_scope_is_not.
2. The receipt does not bind the apply-trusted sidecars. Fixed by changing the direction of trust rather than widening a hash: the scope apply routes on is decoded from the run-bound receipt, and gunbc.fleet_converge_plan_manifest compares the persisted scope, member-set fingerprint, host and baseline bytes against it before actuation. The joint RED you asked for executes: a_coordinated_other_scope_substitution_refuses_before_any_observation.
3. The RLM join does not require the plan scope to be LaunchEnvironment. Fixed. rlm_required_plan_scope() is checked against the plan receipt's scope_wire, with three executed REDs — full-host, fabric-cells and allocation-store plans each refused from the RLM plan slot — plus the undecodable-wire row.
4. The Spark consumer does not resolve. Fixed. spark_serving_fleet_converge_apply_shell now takes the FleetConvergeRequest and derives its terminal from fleet_converge_apply_terminal, one authority instead of eight loose families; three spark witnesses consume it.

Two things this head also carries which were not in that review, so they are not hidden inside the four above:

• the constructor-site census is deleted — that coverage is removed, not preserved, on measured evidence after the cost reduction was attempted and the required floor refused it again;
• the persisted-member roster gained a per-identity uniqueness wall, with a mutation control, after a duplicate entry slipped past every existing row in it.

@briansrls — this is a request to re-review or dismiss review 5070355515, whichever you prefer. I have deliberately not dismissed it myself: it is your review, and a worker dismissing the reviewer's own record to clear its own merge path is the kind of escape hatch DESIGN §5 refuses. Nothing here is a merge request; that call is the operator's.

— sent from fierce-moth-880

[gunbai-bot]

Both findings in review 58108 are declined, each verified against d0545220 rather than answered from the earlier disputes — though both points have also been adjudicated on this PR before (review 58059's hand-shell finding was disputed and the dispute upheld; review 58080 examined the same Rust hunk and concluded it is "a bounded, rostered relocation with the standard dissolution trigger… no separate hand-Rust receipt needed").

1. fleet-converge.yml:217 is a generated projection, not hand-written shell. The YAML is emitted, and the step it renders is a typed RunStep in gunbc.fleet_converge_workflow:

fn fleet_converge_launch_environment_plan_step() -> Step {
  RunStep {
    name: …, id: Present { value: "launch_environment_plan" },
    run: gunbc_ci_fleet_converge_launch_environment_plan_invoke(),

and that run value is not authored text either — gunbc.ci_spec's gunbc_ci_fleet_converge_launch_environment_plan_invoke delegates to gunbc_run_step_script(source_roots:, entry:, function:, claim_run:, receipt_rel:), the shared emission authority every sibling invoke step in this workflow uses (gunbc_ci_fleet_converge_allocation_store_plan_invoke is the adjacent one). The rendered argv is a gunbc run invocation of a .dag entry point, which is the opposite of shell implementing semantics expressible in .dag.

So there is no scaffold to mark. Adding a scaffold marker naming a "bash-emission capability" would classify an ordinary invoke-emitted gunbc step as hand-shell, which is a false receipt — and under §5 a marker asserting a scaffold that does not exist is worse than none, because it would be cited as an inventory entry. If the objection is instead that gunbc_run_step_script itself should not render argv as text, that is an objection to the shared emission authority and to every step in every generated workflow, not to this diff, and it is not resolvable inside this PR.

2. The hand-Rust receipt for namespace_wave_admission.rs exists, on-carrier, and this diff adds no declaration to it. gunbc.namespace_wave_admission carries namespace_wave_admission_seed_growth_justification: SeedGrowthJustification, whose hand_authored_declarations list already names NAMESPACE_TRANSITION_ADMISSIONS (with TransitionAdmission, AdmissionSubject, admission_subject_matches, and the rest) as DeclarationRefs. The carrier's shape is exactly the receipt the finding asks for: reason (the operator's 2026-08-26 ruling), owning_dissolution_lane: "v1-hand-queue-drain" as RoadmapNodeId — a named lane and roadmap row — trigger (a two-step deletion keyed to a per-module declaration record landing as a .dag carrier), and current_boundary, which names src/v1/stage0/src/namespace_wave_admission.rs explicitly.

What this diff does to that file is add rows to an already-rostered declaration and remove a duplicate ledger paragraph. It declares no new type, no new function, and no new constant, so it does not widen hand_authored_declarations and does not move current_boundary. A roster whose entire purpose is to adjudicate namespace deltas cannot be populated without writing rows into it; requiring a fresh seed-growth receipt per row would make the mechanism unusable while its own justification, lane and trigger stand unchanged.

Two further facts I verified at d0545220 after writing the above, both of which sharpen rather than replace it.

The workflow file is declared generated, not merely described that way: .gitattributes:17 carries .github/workflows/fleet-converge.yml merge=generated-artifact. Reviewing it as its own authority is the standing hazard on this path — this is the third time the hand-shell reading has been raised on this lane (review 58059 raised it and it was disputed and upheld; review 58069 independently reached "the projection of the .dag workflow model, not hand-shell authority").

And finding 2 inverts if complied with. Filtering this branch's whole diff to that file for added fn /impl /struct /enum /match lines returns empty — no Rust logic is added; the const is populated with two rows of pre-existing types. More decisively, the module's own doctrine at line 12 states the wall "admits when the UNADJUDICATED delta is empty, never when the delta is empty". Those two rows are the adjudication of this PR's constant relocation. Deleting them, gating them behind a separate receipt, or deferring them to a ROADMAP row would restore an unadjudicated delta and the wall would then refuse this PR. The finding asks for the removal of the thing that makes the change admissible.

Nothing is being pushed for either item. If the reviewer holds either finding, the disagreement is about the shared emission authority (item 1) or about whether adding a row to a rostered constant counts as seed growth (item 2) — both of which are decisions above this PR, and I would rather have them ruled on than paper over with a marker or a receipt that asserts something untrue.

— sent from fierce-moth-880

[gunbai-bot]

This is the third raise of this finding (review 57924, review 58059, now review 58108/58239), and it is dispositioned in the PR body under Standing dispositions on two recurring findings — that section exists precisely so this does not cost another round trip. I am not re-litigating it here; the short form:

.github/workflows/fleet-converge.yml is a generated projection, declared as one (.gitattributes carries … merge=generated-artifact). The cited step is a typed RunStep in gunbc.fleet_converge_workflow whose run value comes from gunbc_ci_fleet_converge_launch_environment_plan_invoke(), which delegates to gunbc_run_step_script in gunbc.ci_spec — the shared emission authority every sibling invoke step in that workflow uses. The rendered argv is a gunbc run of a .dag entry point. There is no hand-authored shell carrier to mark, and a marker naming a bash-emission dissolution trigger would assert a scaffold that does not exist; under §5 a false inventory entry is worse than none, because it becomes debt someone is later asked to retire.

The prior raises were disputed with the same evidence and the disputes were upheld by the lane manager; review 58069 and review 58216 independently read the same file as "the projection of the .dag workflow model, not hand-shell authority" and "a step in the existing generated YAML" without reference to our argument.

If the reviewer disagrees, the disagreement is with gunbc_run_step_script — the authority that renders argv as text for every generated workflow step in this repository — and not with this diff. That is a ruling above this PR, and I would rather it be ruled than papered over with a marker that misdescribes the carrier.

— sent from fierce-moth-880