The planner minted an empty Spark schedule unconditionally: the observation carries its projection, the rows become an axis product, and the artifact stops answering for a plan it never made (P0-C3, dry)

[gunbai-bot]

Worker attestation

• Title describes the change rather than the session or branch.
• This body summarizes what changed and why.
• Tests and their results are recorded below.
• This PR closes the SPARK-PAIR-0 P0-C3a program step; it does not close a GitHub issue.
• The branch commit history is accounted for, including two merges from main and the regenerated projections.
• No secrets, credential material, or large binaries are committed.

Summary

SPARK-PAIR-0 P0-C3a makes one sealed observation transaction own every Spark serving probe capture, typed acquisition identity, provenance, projection, and acquisition-coverage receipt. Planning privilege is separated from pure row computation: only an acquired host observation may mint a bound Spark axis, while hermetic projections may exercise computation without crossing into an executable plan.

The generic FleetConverge artifact now consumes that bound axis and is the sole artifact assembler. Its rendered body carries the Spark typed-action marker required by its own apply reader. Post-apply verification acquires a distinct PostApply transaction and refuses unobserved linger rather than planning from a fabricated Boolean.

Two production defects the cut surfaced, both repaired here:

1. Two artifact assemblers, with the correctness wall on only one. spark_serving_fleet_converge_plan_artifact_from_rows assembled a whole FleetConvergePlanArtifact beside the generic fleet_converge_plan_artifact. The only thing it did that the generic one did not was write the # spark-serving-typed-actions: line that fleet_converge_plan_spark_typed_actions_consistency_admits reads and spark_serving_apply_reads_frozen_typed_rows depends on. Once production moved to the generic route, the shipping path emitted plans its own apply reader refuses whenever a Spark row existed. Nothing was red, because every claim reading the marker entered through the Spark-shaped door that had it. The line now lives in the generic assembler; the second assembler is deleted with no callers left.
2. A conjoined slice claim whose red named none of its four facts. Split into four; the split is what localized (1).

The hermetic acquisition fixture is transitively sealed: every function returning a production-accepted capture, request, transaction, provenance or observation carries admit_callers naming its exact consumers. Sealing proved eight functions dead and they are deleted. The wall is proven by a control pair that makes the same call with the same arguments and differs only in whether the roster names the caller.

Fixture states are earned from probe output rather than declared: the unit read echoes the desired unit wire so the content member converges by bytes, the runtime receipt echoes the identity digest the projector compares, the required model digest is the joint across four store legs, and linger's third state comes from a loginctl leg that ran and exited nonzero.

Test plan

Candidate head: 3add770ce1418c530c064b5d5f2d7f7f4155d5ee
Tree: 60f44f57ae343f9f227a22621f676a9547f72009

Eight-entry srv6 matrix, run on the earlier head a44a6a1b (tree 29b5962a): 305/305 PASS. That matrix has NOT been re-run on the current head; what covers the current head is CI, which executed all five jobs on the composed merge-preview tree (below). The matrix is recorded as the historical targeted run it was, not as evidence about 744d69e9.

Each entry is scored as PASS-count against that file's own declared test fn roster, so a truncated or killed entry reads as PASS < roster rather than as silence. rc=0 on all eight.

• observation transaction: 23/23
• full plan: 63/63
• observe: 68/68
• converge slice: 35/35
• model store: 15/15
• cell role: 27/27
• fleet converge plan: 72/72
• fixture admission: 2/2

Generated-artifact assessor (generated_artifact_gate.main): clean, rc=0. The zero is discriminating, not assumed: a control in an isolated detached worktree that perturbs .githooks/pre-commit returns rc=1 with the located finding committed content differs from authority.

This PR performs no fleet mutation. Its canary is one read-only observation of srv5 and srv6, re-executed on this exact head 744d69e9, and again on the composed merge-preview tree, rather than carried. The 34de783 execution below is retained as the historical record it is; the applicability section that follows states why its carry was withdrawn.

CANARY EXECUTION

attempt_identity =
  UnrecoverableInSession {
    missing_field: CanaryRunId,
    reason:
      "The ephemeral harness-generated canary run ID was not retained with
       the surviving execution receipt. Repository, PR-comment, workflow,
       and retained-session searches found no value bound to this exact
       source/tree/binary/report tuple."
  }

receipt_identity =
  ExactExecutionTuple {
    source_commit:
      34de783a9a822d324df54d4cc7dfb516020d38cd,
    source_tree:
      86a9ace9e3b8f40e48e5042b7845587f204b9705,
    observer_entry:
      spark_serving_observe_ci_wet,
    binary_sha256:
      92a695df93aff60e089030ef33923b4b6bb278471939266074678ddf51a41edc,
    report_body_sha256:
      d7951e922ef8fb12a338a0a94051dcd5f90a79571f9382c33b5184b69e756c2b
  }

The observation itself: srv5 and srv6 each observed exactly once with no foreign host; acquired provenance and phase=report on both; one shared fleet attempt with distinct observation-attempt identities; a single credential identity and locus across both hosts; required=23 captured=23 missing=0 duplicated=0; executed=23, transport-refused=0, prerequisite-refused=0; process exit 0.

CANARY APPLICABILITY

carry_required = false

reason =
  NoCarryNeeded {
    note:
      "The observation was re-executed on the exact candidate head, so no
       applicability relation carries a prior execution forward. The block
       this replaces asserted CarriedByStructuralIdentity from 34de783 to
       a44a6a1b; that verdict did not survive the two subsequent merges
       from main and is withdrawn below rather than repaired."
  }

execution_receipt =
  ExactExecutionTuple {
    canary_run_id:
      canary-20260831T202616Z-47796f96a950,
    source_commit:
      3add770ce1418c530c064b5d5f2d7f7f4155d5ee,
    source_tree:
      60f44f57ae343f9f227a22621f676a9547f72009,
    observer_entry:
      spark_serving_observe_ci_wet,
    binary_sha256:
      3a26295c9c269aace078bdeb4aa3505fb562a4ca8ff9fe05ef593ade9c58da06,
    report_body_sha256:
      ae78ec903cc4781af5df54d541eb60cd2f0749e861e9a0341ab309c99201fd6c,
    probed_at:
      2026-08-31T18:55:00Z
  }

verdict = ExactHeadExecution

Second receipt: the COMPOSED tree, not just the head. A head-only receipt
proves the observe route for the branch, not for what actually lands. The wet
observation was therefore re-run a second time against GitHub's merge preview —
the same tree CI adjudicated, confirmed from the job log's checkout line
(HEAD is now at 59cd9388d6 Merge 744d69e9fda... into 0b4366efb8f...).

SUPERSEDED — the composed-tree receipt below was taken against merge preview
59cd9388 whose head-parent was the previous head. main advanced to eced9d24,
which conflicted DESIGN.md; that merge is now in this branch and the head moved,
so the preview changed and this block is retained as history rather than as current
evidence. The exact-head receipt above IS current. Re-running the composed-tree
observation costs no head move and no CI restart, so it can be re-taken on request
against whatever preview is current at the moment of merge.

CANARY, COMPOSED TREE (SUPERSEDED — see note above)

canary_run_id = canary-20260831T195020Z-7083b85f17f9
subject       = merge-preview refs/pull/9763/merge
merge_commit  = 59cd9388d65ebd3e18e77569c9892d1d8b63cf1d
merge_tree    = 4440edfaebc1db85da03e8ed802c405f116b338c
base_parent   = 0b4366efb8f4e6f3d2224e94d210fe6500323376
head_parent   = 3add770ce1418c530c064b5d5f2d7f7f4155d5ee
binary_sha256 = 4f1618f523cb5caaf988b8169a1b9c952ecd67375e4fe84d3d3423d60597f02f
exit          = 0

verdict = ComposedTreeExecution

Same predeclared criteria, all passed: srv5=1 srv6=1 with 0 foreign; acquired and
phase=report on both; required=23 captured=23 missing=0 duplicated=0 and
executed=23 transport-refused=0 prerequisite-refused=0 on both; one fleet-attempt
with distinct per-host observation-attempt; one credential identity; model_tag=20b
digest 17052f91… on both. The harness additionally asserts both parents, so a
refreshed merge preview refuses rather than silently scoring a different tree.

This closes the gap a head-only receipt leaves: main commits reachable only through
the base parent — including #9813, which touches the evaluation substrate that runs
this entry — are inside the tree this observation executed.

The honest boundary, stated rather than implied. The composed tree is a function
of main, so this receipt is exact for 4440edfa and is retired by any main advance
that changes the merge preview. It is not, and cannot be, a claim about a tree that
does not exist yet. A per-merge-preview wet receipt cannot be made permanently
current while main advances faster than the merge cycle; what it can do, and does
here, is pair the wet evidence to the exact tree the dry evidence adjudicated.

This receipt is bound to the head this PR currently carries, so it is not a carry
argument and has no intersection premise to be invalidated by a moving main. Any
further merge from main produces a new head and a new tree, which retires this
receipt and re-opens the same obligation.

Withdrawn: the previous applicability block. It asserted
canary_execution_component_intersection = [] and
verdict = CarriedByStructuralIdentity for candidate a44a6a1b. Measured at the
current head, that intersection is not empty. Changed since a44a6a1b and on or
beside the wet route: dag/extdeps/posix/shell_command_language.dag (remote-command
quoting), src/v2/std/text.dag, src/v2/extdeps/languages/bash.dag and
bash_command_fold.dag, dag/extdeps/ollama/capability.dag (support catalog
[20b] to [20b, 120b]), dag/gunbc/ollama_model_resolution.dag, and in the seed
src/v1/stage0/src/cli_run/entry_resolve.rs and resolved_graph_cache.rs. The
block is replaced rather than corrected, because re-running removes the need for a
carry instead of arguing one.

Withdrawn: the grain label. That block named
dag_comparison_grain = ResolvedDeclarationDependencyClosure. The instrument was
not a resolved dependency closure — it was a conservative lexical declaration
reachability over-approximation over fn/func/data/type with an
identifier-names-declaration edge rule. The label overstated the instrument. It is
recorded here as withdrawn rather than silently dropped, since the mislabel is
independent of the staleness and would otherwise recur.

Subject unchanged, checked at this head.
spark_serving_desired_model_ref is still ollama_gpt_oss_20b_model_ref, and
ollama_model_support_row_for selects by model identity rather than catalog
position, so appending the 120b row cannot move the selection. The appended row is
therefore not a subject change. A later change that rewires the desired ref or its
resolution to 120b would be one, and would require its own wet execution.

Acceptance, measured on this receipt — every criterion below was written down
before the run produced output, and a partial pass was pre-committed to count as a
failure:

criterion	result
process exit	0
binary sha256 pre/post invocation	identical
host sections	srv5=1, srv6=1, 0 foreign
provenance	acquired x2
phase	phase=report x2
coverage, both hosts	required=23 captured=23 missing=0 duplicated=0
outcome, both hosts	executed=23 transport-refused=0 prerequisite-refused=0
fleet attempt	one value across both
observation-attempt	distinct per host
credential identity	one value, 01c65fe99aeb7b24
model	model_tag=20b digest=17052f91… on both

This PR still performs no fleet mutation; the canary remains one read-only
observation of srv5 and srv6.

SupersededHistoricalExecution: an earlier canary ran on 05c0dddaac400d49ef78ea677634cc50564344b9 (tree bcb150be…, attempt canary-20260831T075026Z-cab81106e375, binary-sha256=45ab012e…, report-body-sha256=b7ba142f…) and passed, as did one on 689a3c38ce2787c28a9aaf892303d132c1c89fe5. None of them is the authoritative receipt for this candidate, and the 34de783 tuple is now superseded too: the authoritative receipts are the exact-head execution canary-20260831T202616Z-47796f96a950 on 744d69e9 and the composed-tree execution canary-20260831T195020Z-7083b85f17f9 on merge-preview 59cd9388, both recorded above. Full receipt and ephemeral harness text for the earlier run: issue comment 5475049785.

[gunbai-bot]

SPARK-PAIR-0 P0-C3, the dry observation-to-plan bridge. No host mutation.

The two independent breaks

fleet_converge_plan_cli passed observed_spark: [], and the generic artifact set spark_serving_typed_actions: scheduled_rows_empty() unconditionally. Fixing either alone changes nothing, which is why the Spark axis was inert in production even though the planner already knew how to plan it.

This PR closes the second and makes the first possible. It does not close the first — see the end.

One observation, one producer

SparkServingHostObservation carried only the reporting facts, so the planner could not be fed from it. The two routes available instead were both wrong the same way: parse the human receipt back into members, or run a second observation for planning. The second is the one that looks harmless — it's only more probes — and it's the one that silently joins a unit's content read at one moment with its enablement read at another. Two facts about one machine taken from two observations are not an observation of that machine.

The carrier now holds the projection, produced by the same probe transaction. Because it is sole_constructor, there is no way to obtain one whose projection came from a different observation than its readback.

The mint derives the observation from the readback but takes the projection. That asymmetry is deliberate: the observation is a pure function of the readback, so deriving it removes an authorable disagreement; the projection is a function of four more probes this type does not carry and cannot re-run, so a mint claiming to derive it would be fabricating them.

Rows are a fact about an observation, not about an artifact

Row production and artifact assembly were fused, so reaching Spark rows meant calling the Spark-specific artifact builder — which brings its own timers, caps, observed_slots: [] and an unobserved fabric population. Grafting that beside the generic artifact would have created two subjects, two baselines, two leases and an arbitrary winner. spark_serving_scheduled_rows_for is extracted instead, and both the slice helper and the generic artifact derive from it.

Every refusal is preserved. The four unobserved guards — unit, enablement, activity, linger — each name a probe whose silence would otherwise read as the member is absent, and absence is what makes membership_reconcile plan an addition. An extraction keeping only the happy path would have converted four fail-closed walls into four writes against states nobody measured.

The substrate refused my first design, and it was right

I first had the artifact call the row producer directly. That closed an import cycle — gunbc.fleet_converge_plan → gunbc.spark.serving_converge_apply → gunbc.spark.serving_converge_plan already runs the other way. Artifact assembly consumes already-planned axis products (timer, cap, slot, fabric, activation plans); the Spark schedule is one more of them, not an exception this module reaches down to compute. The rows are now a parameter.

The artifact's Optional carried a fact that cannot happen

It answered Absent when content_hash_of_value didn't return the Fnv1a64 arm — an absorbing arm in the narrowing direction, since an unrecognised hash became "there is no plan artifact", which every caller reads as nothing to converge. The Spark builder repaired exactly this in its own copy and this one was left behind. content_hash_atom dissolves it, and the outcome becomes a typed sum carrying the refusal that actually exists.

Two smaller repairs found on the way

• The linger probe argv was authored twice, once per transport — a §3 fork, free to drift the first time loginctl's interface moves. One home now.
• serving_converge_slice_wet collapses the three-valued SparkServingObservedLingerState into a Bool, turning "the probe did not answer" into "linger is off". The new reader keeps LingerUnobservedState distinct — which is what stops an unmeasured property entering the observed member list.

Receipts (srv6)

spark_serving_full_plan_witness_test        EXPECTED=49  PASSED=49  FAILED=0
fleet_converge_plan_witness_test            EXPECTED=66  PASSED=66  FAILED=0
spark_serving_observe_witness_test          EXPECTED=68  PASSED=68  FAILED=0

Control — restoring scheduled_rows_empty() in the artifact:

PASS the_extracted_row_producer_plans_real_work_from_an_observation
PASS the_extracted_row_producer_still_refuses_an_unobserved_linger
PASS extraction_did_not_change_what_the_slice_artifact_plans
FAIL the_generic_artifact_carries_the_schedule_it_is_handed

Only the claim exercising that path reds. The other three stay green because they test the row producer, whose behaviour the mutation doesn't touch — reported that way rather than trimmed, because a control that reds everything usually means the claims are one claim wearing four names.

What this does not close

fleet_converge_plan_cli still passes an empty schedule. Wiring the real Spark observation into the plan CLI needs the fleet SSH credential context, which the plan CLI does not currently materialise. That is the remaining C3 break, alongside the canonical typed persistence (encode/decode byte-identity, tamper refusal) which is not started. Both are named rather than implied.

— sent from eager-pike-541

[gunbai-bot]

Fixed in a02bff23261. The finding was correct — and it caught a stale intermediate state rather than a design mistake, which is worth being precise about since it changes what the fix is.

What happened. The mint went through two shapes in this branch. It first took a finished projection parameter, and I changed it mid-work to take the four probe observations instead, because the projection-parameter form reopened the exact class #9754 had just closed one field over: nothing stopped a caller pairing srv5's readback with a projection built for srv6. Two hosts, one carrier, disagreeing — same defect, different field. The fixture was left on the old shape when the mint moved, which is what you found.

The fix is the one you named, with one refinement. ho_from now threads honest *Unobserved sentinels:

runtime: RuntimeMaterializationAbsent
store: ModelStoreAbsent
observed_unit: { state: UserUnitStateUnobserved,
                 enablement: UserUnitManagerUnobserved,
                 activity: UnitActivityUnobserved }
linger: LingerUnobservedState

and projection_unobserved() is dropped, as you said. The refinement: the fixture can no longer state a host for the projection at all, because the mint derives it from readback.host. That is the provenance property the reshape was for — a fixture that could still name a host would have preserved the disagreement the change exists to remove.

Receipts — srv6, a8a05baa1f6101ddfaf318e05bfa996adc74761f, clean tree, 0 untracked, denominators derived from source:

spark_serving_full_plan_witness_test    EXPECTED=49  TERMINAL=49  PASSED=49  FAILED=0
fleet_converge_plan_witness_test        EXPECTED=66  TERMINAL=66  PASSED=66  FAILED=0
spark_serving_observe_witness_test      EXPECTED=68  TERMINAL=68  PASSED=68  FAILED=0

expected = terminal = passed on all three.

One thing landed since you reviewed, from a parallel read: the artifact took observed_spark and the schedule as two independent parameters, so a caller could hand it members from one observation and rows planned from another. observed_spark feeds the observed baseline, and the baseline is what apply re-checks to decide the plan still applies — so that disagreement would have been invisible at exactly the moment it mattered. They are now one SparkServingAxisProduct, sole_constructor, minted only by the row producer. Same class as the two above; third instance in this area.

— sent from eager-pike-541

[gunbai-bot]

Back to draft despite the approval. A parallel review found four things the approval did not, and one of them is an overstatement in my own commit message. Recording them here rather than merging.

1 — my "one observation, one producer" claim is not structural yet (blocking). The mint now takes probes rather than a projection, which closes the type-level splice. But the production path underneath does not actually run one producer:

• in spark_serving_observe_host_via_locus, the reporting readback goes through spark_serving_probe_leg_via_locus while the projection helpers invoke the other spark_serving_probe_leg path — one returned carrier combining two executor paths;
• is-active is read once for the readback and again inside the user-unit projection;
• the runtime materialization receipt is read for the readback and again by the runtime-root observer.

They may reach the same account in a given run, but nothing establishes it. The honest wording for what this PR currently does is "the readback and projection are constructed during one enclosing function call" — not "one typed probe transaction owns every capture." My commit message claims the latter. That is rung inflation and I am not shipping it under that description. The repair is a per-host probe transaction carrier owning host, locus, and one capture per probe, with reporting, account, observation and projection all projecting from it.

2 — the axis product needs to be a disposition, not a pair (blocking). SparkServingAxisProduct binds members to rows, which was the right direction, but it cannot distinguish a genuinely non-Spark subject from an unobserved one, and it has no arm for a Spark-axis refusal. spark_serving_axis_product_unobserved() currently launders all three into empty-members-plus-empty-rows. It needs NotApplicable / Refused / Planned arms with the host bound from the observation.

3 — the artifact's Refused arm is now inert. After the content_hash_atom repair, fleet_converge_plan_artifact always constructs Ready. Nothing produces Refused, because the function receives concrete ScheduledRows rather than the row-planning verdict. That is a permanently-green arm carrying no information — worse than absent, since it will be cited as coverage. It gets a real producer via finding 2, or it goes.

4 — my linger claim is not established. The argv fork is genuinely closed. But the slice still contains spark_serving_linger_enabled_from_stdout -> Bool? and I added the three-valued reader on the observation path without replacing the slice's Boolean path. So "the slice collapsed unobserved to disabled" is a claim I have not demonstrated. I will run a discriminating control through the actual slice — absent probe, nonzero exit, malformed stdout — and either fix the slice or retract the defect claim and describe what actually changed.

What stands: the row-production extraction, keeping all four unobserved walls, the content_hash_atom dissolution, the argv centralization, and the scheduled_rows_empty() mutation control.

This PR becomes P0-C3a and does not claim the C3 exit receipt.

— sent from eager-pike-541

[gunbai-bot]

Retracting finding 4 — the defect I claimed does not exist.

I checked the slice's actual flow rather than reasoning from the presence of -> Bool?, and all three unobserved cases already refuse before reaching the Boolean translation:

• TypedArgvExecRefused → wet-applied-readback-refused <reason>
• post.success == false (nonzero exit) → wet-applied-readback-refused exit=… stderr=…
• malformed successful stdout → spark_serving_linger_enabled_from_stdout returns Absent, and the observation arm sets observed_linger: LingerUnobserved, typed_row_count: 0, verdict: "observation-refused stdout=…"

So the slice never turns "the probe did not answer" into "linger is off". It refuses with zero planned rows, which is the correct behaviour and was already the behaviour on pre-PR main. The Absent arm is disposed of as a refusal, not translated.

What I got wrong and why. I saw a three-valued type (SparkServingObservedLingerState) being fed from a Bool? decoder and inferred the collapse from the shape, without following the control flow to see that the third value is handled earlier by refusing outright. That is the same mistake I have been calling out in reviews — asserting a property from a type signature instead of from execution — applied to my own diff.

The honest description of what this PR actually changes on the linger axis is therefore narrower than my commit message says:

• the linger probe argv had two spellings, one per transport, and now has one home (this part stands — it is a real §3 fork);
• a three-valued reader is added for the unified observation producer, which is a new consumer that needs it, not a repair of the slice.

The commit message and PR body will be corrected to say that, and the "turning 'the probe did not answer' into 'linger is off'" sentence removed. It described a defect that isn't there.

— sent from eager-pike-541

[gunbai-bot]

This branch was silently reverting #9704, and the review credited that as a clean deletion. Rebuilt in d4257b68630.

What happened. I squashed with git reset --soft origin/main && git add -A. My working tree was based on an older main. reset --soft moved HEAD to the newer origin/main while keeping the older tree, so git add -A staged the deletion of every file main had gained in the interim. Main had advanced to 2afe322f774 — FABRIC-CI: add shared wet-gate evidence interlock (#9704) — so my commit deleted that PR's files and reverted two more:

dag/gunbc/instruments/fabric_ci_evidence.dag                    -265
dag/gunbc/instruments/fabric_ci_evidence_projection_fixture.dag  -14
tools/fabric_ci_evidence_calibration.sh                          -82
tools/fabric_ci_evidence_driver.sh                               -27
dag/gunbc/witness/witness_floor_workflow.dag                      -84
src/v2/workflow/floor_cost_debt.dag                           reverted

None of that is mine. The git grep fabric_ci_evidence check reported empty precisely because the deletion was complete and self-consistent — it confirmed the revert was tidy, not that it was intended. A diff that reverts someone else's merged work is coherent by construction, which is why "drops cleanly" could not distinguish it from the real thing.

Rebuilt from current main, taking only the nine files I actually authored:

9 files changed, 456 insertions(+), 99 deletions(-)

No fabric_*, no witness_floor_workflow, no floor_cost_debt.

Receipt — srv6, d4257b68630dbaf4e9d855daadf868d5a8487742, tree aabfc6e1a67, clean, 0 untracked:

spark_serving_full_plan_witness_test    EXPECTED=49  TERMINAL=49  PASSED=49  FAILED=0
fleet_converge_plan_witness_test        EXPECTED=66  TERMINAL=66  PASSED=66  FAILED=0
spark_serving_observe_witness_test      EXPECTED=68  TERMINAL=68  PASSED=68  FAILED=0

One correction to this review. It repeats "The linger three-valued fix removes a real Bool→enum truncation." That claim is mine and I retracted it in the comment above before this review ran. The slice already refuses on all three unobserved cases — transport refusal, nonzero exit, malformed stdout — before any boolean translation, setting LingerUnobserved with zero planned rows. The argv de-duplication is real; the truncation was not. Flagging it so the retraction doesn't get overwritten by a review quoting my own error back at me.

This stays draft: the probe-transaction and axis-disposition findings from the parallel review are still open, and the commit message now states them as known-not-done rather than claiming the rung.

— sent from eager-pike-541

[gunbai-bot]

Axis disposition landed, three annotations corrected — and I hit the recut bug a second time

First, the process failure, because it happened again and the protocol is the point. Preparing this update I typed git reset --soft origin/main && git add -A out of habit — the exact primitive I had just been told to stop using. Main had advanced from 2afe322f774 to b60fc7dd61e, and the index immediately staged 1,725 paths. I caught it before committing, reset back to c31cc43c8e4, and redid it properly.

That near-miss produced a useful measurement: six of my nine files overlap with paths main changed since my base. So even a correct nine-path allowlist would not have been enough — copying my snapshots over those six would have silently reverted main's edits inside files that are legitimately mine. The safe primitive is a real 3-way merge, not a file copy, which is also this repo's stated preference for integrating main.

Recut receipt

old_base    2afe322f774        old_head  c31cc43c8e4
new_base    b60fc7dd61e5bae6b8c2e493e87815a116d4e7a5
result      5942842fc01e5bea718806c18ec2c3d8db939b49
tree        72c2a757a789239b51746ee8ba242e5497ae7a6f
paths main changed since old base: 1725
overlap with my authored set:      6   (resolved by 3-way merge, not copy)
unexpected paths: 0     deletions: 0     clean: yes     untracked: 0

Complete name-status: nine M, nothing else.

Three annotations corrected

The commit message told the truth while the source still told the superseded story — which is the "annotation as evidence" trap this codebase is otherwise careful about.

1. serving_observe.dag claimed "one physical observation attempt owns the probe results". Replaced with the honest interim standing: readback and projection are assembled during one enclosing per-host call, but their captures are not yet owned by one typed probe transaction — is-active and the runtime receipt are each probed twice, and the via-locus path mixes executor adapters.
2. The linger annotation still asserted the slice collapse I had retracted. Now states what the decoder actually is (the canonical three-valued reader for the new consumer) and records explicitly that it does not repair the slice, which already refuses all three unobserved cases.
3. serving_execution_schedule.dag claimed only the row producer could mint the axis — while the module exposed a standalone spark_serving_axis_product_unobserved() that falsified it.

The axis is now a disposition, and the empty mint is deleted

SparkServingAxisNotApplicable { host }
SparkServingAxisRefused      { host, cause }
SparkServingAxisPlanned      { host, observed_members, rows }

A pair of lists could not distinguish a non-Spark subject from a refused observation from an observed host owing no writes — it answered all three with empty-members-plus-empty-rows, which is an absorbing fallback in the input to a converge. The host travels in the arm, so it cannot disagree with the observation that produced it.

The artifact's Refused arm now has a real producer. A SparkServingAxisRefused propagates instead of being laundered into an empty schedule. That arm was permanently green before — worse than absent, since it reads as coverage.

Receipts — srv6, 5942842fc01e, tree 72c2a757a78, clean, 0 untracked

spark_serving_full_plan_witness_test    EXPECTED=55  TERMINAL=55  PASSED=55  FAILED=0
fleet_converge_plan_witness_test        EXPECTED=66  TERMINAL=66  PASSED=66  FAILED=0
spark_serving_observe_witness_test      EXPECTED=68  TERMINAL=68  PASSED=68  FAILED=0

Two controls, killing different claims:

A — a refusal launders into an empty plan (the old pair behaviour): only a_refused_axis_refuses_the_artifact_instead_of_planning_nothing reds.

B — baseline reads an empty population regardless of the axis: only the_artifact_baseline_moves_with_the_observed_spark_population reds.

Neither substitutes for the other.

Still open, still draft

The probe-transaction carrier is not built, so "one transaction owns every capture" remains false and the source now says so. That is the next piece.

— sent from eager-pike-541

[chatgpt-codex-connector]

💡 Codex Review

gunbc/dag/gunbc/spark/serving_converge_slice_wet.dag

Line 577 in a44a6a1

observed_linger: LingerObserved { enabled: linger_enabled },

Preserve unobserved linger in refused reports

When the ProbeLinger capture exists but its transport is refused, exits nonzero, or returns malformed output, the transaction still reaches this function and spark_serving_projection_linger_enabled returns false; wrapping that value in LingerObserved therefore renders observed_linger=no even though linger was never observed. This defeats the existing distinction between disabled and unobserved on artifact-refusal paths and can mislead consumers of the wet receipt; derive a typed observed/unobserved state rather than converting the projection to a Boolean here.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[gunbai-bot]

HOLD — do not merge yet. The CANARY APPLICABILITY block in this body is stale and now asserts a verdict that is not established at this head. This is an author-raised defect, not a review finding; the five approvals were all cast against this body.

The block states:

candidate_commit = a44a6a1b12a37b104e14de0b3fefce8ec746db86
candidate_tree   = 29b5962a618e8fcacea1ca2ff73a65dfef1efa0c
canary_execution_component_intersection = []
verdict = CarriedByStructuralIdentity

Head is now 32e2dcc — two further merges from main (ce01e18, 32e2dcc) since that candidate. Measuring the delta a44a6a1..32e2dcc, the intersection is not empty. Files changed since the asserted candidate that lie on or beside the canary route:

dag/extdeps/posix/shell_command_language.dag   remote-command quoting
src/v2/std/text.dag                            text carriers used by that quoting
src/v2/extdeps/languages/bash.dag              bash conversion
src/v2/extdeps/languages/bash_command_fold.dag
dag/extdeps/ollama/capability.dag              support catalog, [20b] -> [20b, 120b]
dag/gunbc/ollama_model_resolution.dag          desired-model resolution
src/v1/stage0/src/cli_run/entry_resolve.rs     entry-resolution substrate
src/v1/stage0/src/resolved_graph_cache.rs      serving representation the old route could consult

So canary_execution_component_intersection = [] is not true at this head, and verdict = CarriedByStructuralIdentity does not hold. The receipt still correctly identifies the binary that ran (92a695df…, on source 34de783 / tree 86a9ace9); what is false is the applicability claim carrying that execution to the current candidate.

A third defect, independent of the staleness: dag_comparison_grain = ResolvedDeclarationDependencyClosure names a grain the instrument does not have. It is a conservative lexical declaration-reachability over-approximation — identifier-names-declaration edges over fn/func/data/type — not a resolved dependency closure. Under DESIGN section 4b that mislabel is rung inflation on the instrument itself.

Disposition I am taking: re-establish the receipt at this exact head rather than repair the carry argument. Re-running the read-only two-host observation on 32e2dcc discharges the whole carry question by removing the need for a carry, and — decisively — a body edit does not change the head, so the new receipt stays valid against this SHA, no CI re-run and no review staleness. Building the extensional-equivalence proof instead would require committing witness code, which moves the head and re-opens the same gap against the new SHA.

I will replace the applicability block with the execution receipt for 32e2dcc, or report here if the observation cannot be obtained.

[gunbai-bot]

HOLD LIFTED — the applicability gap is discharged by re-execution, not by a repaired carry argument.

The read-only two-host observation was re-run on this exact head. Head did not move: a body edit changes no SHA, so this receipt is bound to the commit the PR actually carries.

canary-run-id       canary-20260831T173013Z-114592d57094
source-commit       32e2dcc7bcbf80d6438ab03cde30354a17e537ca
source-tree         5ffaab022248fadd01eca2a31a7dbddab3ecb037
observer-entry      spark_serving_observe_ci_wet
binary-sha256       a432efaa778f09f38b361329b08852028b6060672441c8fb29310e842ce620cd
report-body-sha256  a30f7631447fb721757270419e6c15823c007a25043a829cadfa81a472b50d60
probed-at           2026-08-31T17:33:27Z
exit                0

Acceptance criteria were written down before the run produced any output, with a partial pass pre-committed to count as a failure. All of them pass: srv5=1 srv6=1 sections and 0 foreign; acquired and phase=report on both; required=23 captured=23 missing=0 duplicated=0 and executed=23 transport-refused=0 prerequisite-refused=0 on both; one fleet-attempt across both with distinct per-host observation-attempt; one credential identity 01c65fe99aeb7b24; model_tag=20b digest=17052f91 on both; binary sha256 identical before and after invocation.

Body updated in three places: the applicability block is replaced by the exact-head receipt, the summary sentence no longer says the canary was carried, and the SupersededHistoricalExecution note no longer names 34de783 as authoritative.

Two things withdrawn on the record rather than silently dropped:

1. The carry verdict. canary_execution_component_intersection = [] was false at this head.
2. The grain label. dag_comparison_grain = ResolvedDeclarationDependencyClosure named a grain the instrument did not have; it was a conservative lexical declaration-reachability over-approximation. That mislabel was independent of the staleness and would have recurred.

One fact checked at this head and worth stating because it decides whether this was a refactor or a subject change: spark_serving_desired_model_ref is still ollama_gpt_oss_20b_model_ref, and ollama_model_support_row_for selects by model identity rather than catalog position, so appending the 120b row cannot move the selection. A later change rewiring the desired ref to 120b would be a subject change and would need its own wet execution.

Standing limitation, stated so it is not discovered later: this receipt is bound to 32e2dcc / tree 5ffaab02. Any further merge from main produces a new head and retires it. If main advances before merge, the observation must be re-run rather than re-argued.

No source churn was involved — no commit, no new SHA, no CI re-run, and the existing approvals are still against the code they reviewed.

[gunbai-bot]

Addressing review 57915 (dashboard-only, REQUEST_CHANGES). One finding fixed, one respectfully disputed with a measurement.

FINDING 1 — missing import. FIXED in 0599a8a, but the mechanism claim is wrong and I want that on the record rather than quietly accepting it.

The observation is correct: dag/gunbc/spark/serving_execution_schedule.dag matched SparkServingUserUnitActivityAddress at four sites without naming it in the import block, and peer modules list it explicitly. It is now listed.

The claim that this "breaks name resolution for four binding rows" is not correct. I measured it before changing anything, by running the module through the real compiler:

gunbc run --source-root dag --source-root src/v2 \
  --entry dag/gunbc/spark/serving_execution_schedule.dag \
  --function spark_serving_address_establishes

Before the fix, that reached EVALUATION and failed with CallContractMismatch: missing required argument address. A call-contract mismatch is raised after resolution and typechecking, so reaching it is positive evidence that the module resolved. Variant names resolve corpus-wide in this substrate; the import block is hygiene and convention, not the binding mechanism. After adding the import the same command produces the identical diagnostic, which is the control: the change moved hygiene, not resolution.

That distinction matters beyond this line. If a missing import really did break resolution, the compiler floor would already be red on main for every module in this shape, and the remedy would be a corpus-wide census rather than one line. Recording the mechanism honestly is what keeps the next reader from deriving the wrong remedy.

FINDING 2 — advisory, empty ScheduledRows mint. This does not exist in the current file. ScheduledRows is sole_constructor with exactly one mint, scheduled_rows_from_frozen_schedule, which takes a frozen schedule. There is no empty mint beside it. The file records its own history on this point:

"So the arms are distinct and the empty mint is deleted rather than kept beside them."

The empty mint the review describes was removed earlier in this same PR; the advisory appears to be reading a superseded state. The nearby empty-looking construction is SparkServingScheduleRowsProjected { rows: [], direction: SparkServingSchedulableEmpty }, which is a different type and a deliberate typed empty-disposition arm, not a ScheduledRows bypass. No change made.

ALSO IN 0599a8a, and not from this review — a defect that only exists because of composition with main. #9824 added a target field to AdmissionSubject::Binding. Our two SPARK-PAIR-0 P0-C3a admission rows predate it, so git merged both sides with no conflict and the tree did not compile: E0063 missing field target, twice. The value is verified rather than copied from our own row label — spark_serving_linger_probe_words is declared in dag/gunbc/spark/serving_observe.dag, whose module line is gunbc.spark.serving_observe.

Wet canary re-executed on the new head, all predeclared criteria passed:

canary-run-id       canary-20260831T181650Z-f156688c9802
source-commit       0599a8a21a82f350faa2b0b426b79eb1adc66085
source-tree         579a314cfb00a26103ac04a0cc4fb3f974e55f14
report-body-sha256  b4ebc223494ecf3ac7f4af0814a6c2c985132d90e1f6de441ed34ad477e03f8d
exit                0

srv5=1 srv6=1 with 0 foreign; acquired and phase=report on both; required=23 captured=23 missing=0 duplicated=0 and executed=23 transport-refused=0 prerequisite-refused=0 on both; one fleet-attempt with distinct per-host observation-attempt; one credential identity; model_tag=20b digest=17052f91 on both.

STANDING ISSUE the operator should see. main advanced to f87b9eb while this canary was running, and the branch now re-conflicts on docs/design-ledgers.md. Measured: 9 of the last 40 main commits touch that generated artifact, 4 in the last 6 hours. Each re-merge moves the head, which retires the wet receipt and forces another observation plus a fresh CI cycle. I am NOT starting another merge-and-canary round on my own initiative until CI on 0599a8a reports, because two of my recent local greens were not evidence and I would rather spend the next canary on a tree whose build is actually proven.

— sent from eager-pike-541

[gunbai-bot]

Re-established after merging main. Head is now 744d69e.

Sequence, and why each step was needed rather than churn:

CI proved the previous head green before I spent another fleet observation. All five checks on 0599a8a came back completed/success with none skipped or neutral, which is what established that the two composition repairs actually work — the AdmissionSubject target field and the explicit variant import. I held the merge until that reported, because a red there would have been confounded by merging main on top of it.

Then main was merged (97b010a). docs/design-ledgers.md conflicted again and was resolved by REGENERATION from the merged .dag authorities, never by hand. The union was verified before staging with an instrument checked for discrimination: main-only lines 1, lost 0; ours-only lines 2, lost 1. The single dropped line is Census identity digest: ce69956ca7a9de96, and it is a supersession rather than a loss — main #9828 (census_identity_digest is a set identity) removed that line from the projection, so it is absent from main as well. Both sides now agree; only our pre-merge tree still carried it.

The rebuild proves it reached the real compiler: Compiling v1-compiler then Finished. That check exists because an earlier local build in this session reported exit 0 while never recompiling the lib, and I reported that as a green when it was not evidence.

Wet canary re-executed on this exact head, all predeclared criteria passed:

canary-run-id       canary-20260831T185255Z-fc5eefffccf8
source-commit       744d69e9fdabed724deea80d320120be9cf6e20f
source-tree         71d45ff4030c52febb2ef9bcb06b6704a26a692f
binary-sha256       9920ba524a74c3db4e283b44689fe4cc5235303720062fa9bce23ac28108c903
report-body-sha256  2822443bd1ffff64a15cc6833a58ea37907d296364be22434141ec86fa3650e3
exit                0

srv5=1 srv6=1 with 0 foreign; acquired and phase=report on both; required=23 captured=23 missing=0 duplicated=0 and executed=23 transport-refused=0 prerequisite-refused=0 on both; one fleet-attempt with distinct per-host observation-attempt; one credential identity; model_tag=20b digest=17052f91 on both. The PR body applicability block now carries this tuple.

On the race that has been retiring these receipts: main has advanced twice more since this merge, to 0b4366e, and the branch STILL MERGES CLEANLY against it — so this receipt is not retired and no further observation is required. Measured rate for anyone deciding how long that holds: 9 of the last 40 main commits touch docs/design-ledgers.md, about one per 90 minutes.

CI is running on 744d69e. I am not merging (standing operator policy).

— sent from eager-pike-541

[gunbai-bot]

Correction: my rebuttal of the advisory in review 57915 was WRONG, and I am withdrawing it. Review 57931 is an APPROVE and asked for nothing, but checking its scheduled_rows_empty() citations is what exposed my error, so it goes on the record here rather than being left to stand.

WHAT I SAID, and why it was false. I wrote that the empty-ScheduledRows mint "does not exist in the current file" and that ScheduledRows "has exactly one mint, scheduled_rows_from_frozen_schedule". That is not true. It is declared exactly where review 57915 said it was:

dag/gunbc/spark/serving_execution_schedule.dag:851
fn scheduled_rows_empty<Row>() -> ScheduledRows<Row> { ScheduledRows { rows: [] } }

How I got it wrong is worth naming because it is a repeatable method error, not a typo. I grepped ScheduledRows, read the region around lines 670-711, found an annotation reading "the empty mint is deleted rather than kept beside them", and concluded the file had no empty mint. That annotation is about a DIFFERENT construct — an earlier standalone empty-members-plus-empty-rows product — and the mint that does exist sits 140 lines below the region I read. I generalized a file-wide absence from a sampled region, then asserted it against a reviewer who had the line number right. The reviewer was more correct than I was and I told them otherwise.

WHAT IS ACTUALLY TRUE, having now read the whole thing. The mint exists and carries its own §5 argument, which I find persuasive:

"It is not a bypass: the wall exists to stop rows being handed over in an
 order nobody derived, and an empty list has no order to get wrong -- there
 is no sequence it could be the wrong one of. The mint takes no rows for
 exactly that reason, so it cannot be used to smuggle a populated list past
 the fold."

That is a real answer to the sole-constructor objection rather than a restatement of it: the constructor is total in its output but takes no input capable of carrying the hazard the wall exists to stop.

The two production call sites are both honest, though not for the reason review 57931 gives:

• fleet_converge_plan.dag:2470 is on the SparkServingAxisNotApplicable arm. Clean, exactly as described.
• fleet_converge_plan.dag:2680 is NOT on that arm. Its enclosing function is fleet_converge_allocation_store_plan_artifact, a non-Spark plan builder, where an empty spark_serving_typed_actions is the honest value because an allocation-store plan has no Spark serving actions. The conclusion holds; the arm attribution does not. Flagging it so the next reader does not inherit a citation that a later edit would silently invalidate.

No code change. The mint is defensible on its own annotation and both call sites are legitimate; changing it now would be churn against a considered design, and I have no finding that survives contact with the file.

The standing lesson I am carrying out of this: a region read is not a file read, and "does not exist" is a claim about a whole corpus that a sampled grep cannot support. I should have run the declaration-site grep — ^fn scheduled_rows_empty — before disputing a reviewer who had given me an exact path.

— sent from eager-pike-541

[gunbai-bot]

Two acceptance defects were raised against this PR. Both are now closed — one by execution, one by edit — and I am registering one substantive disagreement about the standard as stated.

DEFECT: the body named three different candidates. Fixed. The test-plan heading no longer calls a44a6a1 the candidate. The 305/305 srv6 matrix is explicitly re-attributed as a historical targeted run on a44a6a1 that has NOT been re-run on the current head, with CI named as what actually covers the current head. The narrative and the superseded-execution note both now point at 744d69e. Remaining a44a6a1 mentions are deliberate historical references inside the withdrawn-carry narrative. Five green jobs do not make stale candidate claims true, and the packet should not have been left contradicting itself.

DEFECT: the wet receipt covered only the branch head, not what actually lands.

Half of the premise behind this was wrong and is worth correcting for the record: the composed tree was never unevidenced. This workflow does not test the branch head. actions/checkout carries no explicit ref, so a pull_request event checks out refs/pull/N/merge, and the job log says so in its own words:

HEAD is now at 59cd9388d6 Merge 744d69e9fda... into 0b4366efb8f...
git checkout --force refs/remotes/pull/9763/merge

All five green jobs, required-witnesses-floor included, executed on 59cd938 / tree 4440edfa. So main commits reachable only through the base parent — including #9813, which touches the evaluation substrate this entry runs on — are already inside the tree the DRY evidence adjudicated. The real gap was narrower: the WET observation.

That gap is now closed by execution rather than argument:

canary-run-id  canary-20260831T195020Z-7083b85f17f9
subject        merge-preview refs/pull/9763/merge
merge-commit   59cd9388d65ebd3e18e77569c9892d1d8b63cf1d
merge-tree     4440edfaebc1db85da03e8ed802c405f116b338c
base-parent    0b4366efb8f4e6f3d2224e94d210fe6500323376
head-parent    744d69e9fdabed724deea80d320120be9cf6e20f
exit           0

Same predeclared criteria, all passed. Built in a detached worktree at that exact commit with the build proven to reach the compiler. The harness asserts BOTH parents, so a refreshed merge preview refuses rather than silently scoring a different tree. This cost no head move and no CI restart, which is why it was worth running rather than negotiating.

THE DISAGREEMENT, stated so it is not silently adopted. "Admissible for the current merge-preview tree" is not a satisfiable acceptance standard. The merge preview is a function of main, and main advanced three times while this work was in progress (0b4366e, 4897391, 3170945). Any wet receipt for a merge preview is retired by the next main commit, so under that standard no PR touching a wet route is ever merge-ready except by freezing main or by merging inside the gap. DESIGN section 5 is explicit that you check whether a wall is attainable before demanding it, and that "never" is the trap that lets a ratchet pose as a wall.

So the body states the boundary rather than implying a permanence I cannot deliver: this receipt is exact for 4440edfa and is retired by any main advance that changes the preview. What it achieves is pairing the wet evidence to the exact tree the dry evidence adjudicated — strictly stronger than a head-only receipt, and the strongest honest claim available.

If the operator holds that merge requires a wet receipt for a preview current AT THE MOMENT OF MERGE, that is a scheduling constraint rather than something I can discharge by working harder: freeze main, or merge inside the window. It is precisely the coupling a mechanized extensional-equivalence instrument would break, and that instrument still has no program identity.

— sent from eager-pike-541

[gunbai-bot]

main advanced to eced9d2 and conflicted DESIGN.md. Merged, regenerated, pushed. Head is now 3add770.

DESIGN.md is a generated artifact (check-attr merge: generated-artifact) and was resolved by REGENERATION, never by hand. Union verified before staging this time: main-only lines 1, lost 0; ours-only lines 1, lost 0. Nothing dropped from either side. Note GitHub reported mergeable=MERGEABLE mergeStateStatus=CLEAN throughout, computed against a stale base — the branch genuinely conflicted. That false green has now misreported this PR three separate times today; it should not be used as the merge signal.

Wet canary re-executed on the new head, all predeclared criteria passed:

canary-run-id       canary-20260831T202616Z-47796f96a950
source-commit       3add770ce1418c530c064b5d5f2d7f7f4155d5ee
source-tree         60f44f57ae343f9f227a22621f676a9547f72009
report-body-sha256  ae78ec903cc4781af5df54d541eb60cd2f0749e861e9a0341ab309c99201fd6c
exit                0

The composed-tree receipt in the body is now marked SUPERSEDED rather than silently left standing: its merge preview had the previous head as parent 2. It can be re-taken on request, and cheaply — a merge-preview observation costs no head move and no CI restart.

A STRUCTURAL POINT FOR THE OPERATOR, because this is now the fourth wet observation this PR has spent and none of them was retired by a defect.

The measured loop: generated artifacts on this branch conflict with main roughly every 90 minutes (9 of the last 40 main commits touch docs/design-ledgers.md; DESIGN.md is the same class). Resolving a conflict necessarily moves the head. Moving the head retires the wet receipt AND restarts a ~40 minute CI cycle. During that cycle main advances two or three more times, so the next conflict frequently lands before the window closes. The binding constraint is not my cycle time and not the fleet observation — both are about ten minutes. It is the gap between CI going green and a human merging.

Two things would close it, neither of which is mine to do:

1. GitHub auto-merge on this PR. It merges the instant required checks pass, which collapses the green-to-merge gap to nearly zero and wins the race by construction. I am not enabling it because enabling it is gh pr merge --auto, and the standing policy is that I do not run gh pr merge in any form. This needs an explicit operator decision.

2. The mechanized extensional-equivalence instrument, which decouples "merge main" from "spend a wet fleet observation" so that a re-merge costs only CI. It still has no program identity and I am not inventing one.

Absent either, the honest expectation is that this PR merges when someone merges it promptly on a green, and that any delay past roughly ninety minutes will likely require another regenerate-and-re-observe round. I will keep doing those rounds, but they are not converging toward anything — each one is a fresh coin flip, not progress.

— sent from eager-pike-541

[gunbai-bot]

Addressing review 57946. Two findings fixed, one disproven — and the third is disproven by executing the gate that owns it rather than by argument. Head is now 6a17153.

FINDING 1 and FINDING 2 — FIXED, though the stated mechanism is not the defect.

There is no predicate/walker dissolution rule in DESIGN. The only occurrence of "predicate" is section 4b, "does not lift arbitrary predicates to proof", which is about rung honesty and not about Bool-returning matches. And there was no canonical fold or query surface over SparkServingProbeOutcome to route through: I checked, and none exists, so the remedy as written would have had me author a surface ahead of its consumers — the shape gunbc.spark.cell_role explicitly deleted when it removed spark_host_offerable_for_training for having exactly one caller.

But the instinct was right, and there was a real defect at both cited lines. It is section 6 bare-minimum-cost, not a query-surface violation:

serving_observation_transaction.dag built three counters as THREE length(filter(...)) passes over one capture list, each filter invoking its own exhaustive match over the same closed outcome. Three traversals and three matches for one question. That is the copied-accumulator shape DESIGN says is ALWAYS fixed regardless of realized n, precisely because n tracks the probe roster and "n is small here" is not time-stable. It is now one fold, bound once at the use site, with the match still exhaustive so a fourth outcome arm fails to compile rather than being silently counted as neither. The three predicates are deleted.

serving_observed_members.dag asked an existence question as length(filter(...)) > 0, building the whole filtered list before comparing. It now uses any, which short-circuits. I had initially written this off on the grounds that no List-level any existed; that was a too-narrow grep on my part — any comes from v2.std.algebra and is used over Lists in gunbc.rust_item_scan.

Behaviour preserved by execution rather than inspection: observation-transaction roster 23/23 PASS, observe roster 68/68 PASS, including changed_capture_outcomes_move_the_line_the_report_emits, which is the discriminating claim for outcome counting.

FINDING 3 — NOT FIXED, because the required receipt already exists and the roster gate proves it.

The finding says two admission rows were added "without the required checkable hand-Rust receipt". The receipt exists. NAMESPACE_TRANSITION_ADMISSIONS is already rostered as a hand-authored declaration at dag/gunbc/namespace/namespace_wave_admission.dag, module_path v1_compiler.namespace_wave_admission, and that justification explicitly contemplates exactly this case:

"PR #9436 CHECKABLE HAND-RUST RECEIPT (review 56812). The 53 exact
 transition admissions are DATA consumed by the already-rostered
 NAMESPACE_TRANSITION_ADMISSIONS declaration; they add no compiler
 function, type, or admission mechanism."

I did not resolve this by reading and preferring an interpretation. I took the finding seriously, confirmed the item IS in the gate population — const is in rust_item_keywords(), so a modified const is a changed hand item and "it is only data" is not itself an exemption — and then authored a new SeedGrowthJustification module and enrolled it. Executing gunbc.seed_growth_admission seed_growth_roster_well_formed_gate_holds then returned FALSE, because seed_growth_roster_has_duplicate_keys() detected my row as a duplicate of the existing one. Removing my module returns TRUE. That is a discriminating pair, run in both directions:

with my added row     -> gate false (duplicate key)
without my added row  -> gate true

So the receipt requirement is already satisfied, and attempting to satisfy it a second time was itself the section 3 violation the gate exists to refuse. The prescribed fix would have manufactured the defect. My new module is deleted and the roster edit reverted; the tree carries neither.

Wet canary re-executed on the new head, all predeclared criteria passed:

canary-run-id       canary-20260831T212052Z-389a498ad8ca
source-commit       6a17153a8a65d50fac1b1c332368c55f308aaaea
source-tree         4f01104ea8ac7ac09ebbc079c0bedcd5b01b14a7
report-body-sha256  ae42e61f5bb8b3a65bcfab0b593c124708b3cfcbc73865ac6d64d8b48630b8a9
exit                0

main also advanced to a12a115 during this and conflicted docs/design-ledgers.md again; merged and regenerated, union verified before staging (main-only 1 lost 0; ours-only 2 lost 1, the dropped line being the CI-bankruptcy rung-drop row whose subject is present on all three sides with main text winning).

— sent from eager-pike-541