Cause 2's forcing function was about to vanish: record the executed false-green as a typed stall row

[gunbai-bot]

[gunbai-bot]

This is main's breakage, not this diff's. Investigated rather than re-run, since a re-run over the same base reproduces it.

The failing job's step signature:

Required CI: witnesses lane (parse, witness floor)   FAIL
Upload the floor's admission roster                  FAIL  (no files found)
Upload the expected-red roster join                  FAIL  (no files found)
Upload the long-home storage agreement               FAIL  (no files found)
Upload the floor's per-claim cost receipt            FAIL  (no files found)

Four roster uploads finding no files is the specific signature of the floor refusing at strict-preparation — the ledger is never written because the prepared subject cannot be built. It is not a witness failing; it is zero witnesses executing. deep-dove-394 measured six consecutive main runs in this state, with eleven commits landed behind it.

Cause is b20ac7ad44f (#9397), which renamed grant_duration_seconds → grant_duration_bound_seconds and made it partial, missing its consumer in dag/product/fabric/contention.dag. Five repair sites, and the repair is open as #9488.

This PR adds one GuaranteeStall row to an existing .dag carrier. It was verified through the same parse sweep CI runs: 4194 files parse-clean, the only finding being contention.dag. A single data row in a carrier that already holds two siblings of the same type cannot produce a strict-preparation refusal.

No action here. This will go green once #9488 lands; re-running before that only reproduces main's refusal.

— sent from snappy-dove-250

[briansrls]

This standing is superseded by the measured parser carrier and must not merge as written.

ParseWithTableResult already carries OccurrenceTransport; the parser stamps the declared field-type node as a TypeOccurrence. The fact is therefore not OutsideTheLadder, not capped at StructurallyImpossible, and not blocked on choosing between moving storage to type_annotation or selectively traversing inferred. The missing relation is produced and discarded before declaration_index consumes the parse result.

Reframe the row (or replace it in the reader repair) as ProducerAvailableConsumerUnwired: namespace-wave removal/binding must consume the parser-issued authored-reference transport, joining OccurrenceTransport.references to its index by exact OccurrenceId. The trigger must explicitly refuse Node-span/name reconstruction and traversal of inferred. Keep the separate parser-storage cleanup as a discriminator-first GuaranteeStall; it is not this namespace-wave blocker.

The executed false-green remains valuable evidence. The present cause, ceiling, blocker, bounded population, and next-rung trigger assert a design question that has already been answered, so this is a false machine-consumed authority row despite green CI and provider review.

[gunbai-bot]

Closing this PR. Its row describes a defect that no longer exists, and I am the one who let it go stale.

#9504 landed on main at 2026-08-27 18:48. I amended this row at ~22:45 — nearly four hours later — against a branch whose last merge of main predated it, and never re-measured. A review approved the amendment at 22:5x, praising it for "an executed RED". That approval read the row's prose; the tree says otherwise.

Measured against origin/main, not against this branch:

• record_from_module takes a fourth parameter transport: &Rc<OccurrenceTransport>, and both call sites pass fill.occurrence_transport
• authored_type_references_from_transport reads transport.references and filters to OccurrenceCategory::TypeOccurrence
• membership_bound_through chains record.referenced with record.authored_type_references and asks both

So every one of the four population members I named as not ingesting the transport now ingests it. The row's current: OutsideTheLadder — justified on the grounds that "the live consumer still emits a false-green deletion disposition" — is false.

The forcing function is already enrolled, which is the part that settles closure rather than amendment. §4b(4) requires a climb to keep its discriminating evidence, and #9504 kept it: a_removed_import_whose_name_survives_only_as_a_declared_field_type_is_not_reported_unused. Executed on the merged tree just now:

test a_removed_import_whose_name_survives_only_as_a_declared_field_type_is_not_reported_unused ... ok
test result: ok. 32 passed; 0 failed

The measurement this row existed to preserve is a passing regression control in the tree. A stall row beside it would be a second authority for one fact (§3) asserting the opposite of what the fact is.

Why closing beats amending again. An amendment would have to say the class is closed — which is a stall row with no stall, i.e. a row whose only content is that it has no content. Worse, it is machine-consumed: it sits in all_guarantee_stalls and is folded by every_stall_is_below_its_ceiling. A row asserting a live gap that is closed is exactly the false diagnosis the operator's review warned against minting, arrived at from the opposite direction.

The mechanism, since it is the reusable part. I measured the call sites on my own worktree and read a three-parameter record_from_module, concluded the transport "is sitting at the call site and simply isn't passed in", and dispatched a work item on it. sleek-koi-379 reported back that the brief was satisfied before it was written. Every reading I took was accurate about my branch and false about main. This is the same class I spent the session naming in other people's work — a correct measurement of the wrong subject — and the branch/main axis is the one I did not vary.

The genuinely open remainder is not this row: referenced still walks the tree for the variant-pattern constructor head, because MatchPattern::VariantPattern.name is a raw String and ConstructorOccurrence is stamped nowhere in the parser. That is a parser ruling, not unbuilt work, and it belongs in its own item rather than under a stall row that misdescribes its neighbour.

— sent from snappy-dove-250