Stop two roadmap_page witnesses rendering an emit rejection as an empty string

[gunbai-bot]

Second row of the refusal-as-empty-string lane. Sibling of #9038, independent of it — cut from clean main, not stacked.

The defect — RefusalErasure, both subforms in one file

Both rows flattened the rejection and then pattern-matched the result:

let h = match try_serialize_html_source(node: ...) {
  EmitOk { html: page } => page
  EmitRejected { reason: _ } => ""
}
string_contains(s: h, pattern: "class=\"program-progress\"") && ...

SentinelCollapse. So "the page could not be emitted" and "the page rendered the wrong thing" produce the same false, with opposite repairs — one sends you to the emitter, the other to the presentation model. EmitRejected carries a reason, and the flatten throws it away.

Why these two went first — VacuousNegative

Their negative conjuncts are vacuously true on the empty string:

• !string_contains(active_html, "finish-line-accepted")
• !string_contains(h, "class=\"finish-line-progress\"")
• !string_contains(h, "class=\"finish-line-claim\"")

On any emit rejection those cannot fail. They were decoration — permanently green, carrying no information, and cited as coverage. A row that is partly incapable of failing is worse than one that is absent (DESIGN §4b).

The assertions now run inside the EmitOk arm; EmitRejected returns false on its own.

Both rows keep a positive anchor inside the success arm (4 positives in the finish-line row, 2 in the daily row), which is what makes the repair meaningful: a success arm holding only negatives would still be decoration, merely unreachable by a refusal. It is also why the mutant control below can go red at all — it mutates a positive conjunct, and a negative-only row would have stayed green under that mutation and told me nothing. The finish-line row nests two emits, so its second match sits inside the first arm rather than beside it.

Evidence, both directions

green   PASS witness_finish_line_variants_render_from_fixture
        PASS witness_daily_leads_operational_not_narrative

red     one assertion mutated (program-progress -> program-progress-MUTANT):
        BUILD_EXIT=0
        FAIL witness_daily_leads_operational_not_narrative
        PASS witness_finish_line_variants_render_from_fixture   <- positive control, same run

The unmutated sibling passing in the mutant run is what makes the red load-bearing: it is the assertion failing, not a broken harness. BUILD_EXIT=0 is there because an earlier attempt at this control ran with a deleted target/ and produced no FAIL line at all — an instrument that never ran looks exactly like a witness that passed.

Evidence limit — read this before treating a green check as coverage

dag/test/claim/long/ is a declined home. The floor discovers these witnesses and folds none of them, so CI will never execute either row, in either direction, however green this PR looks. The remote claim_batch run above is the only evidence that exists for this file.

How to find this class in any row: mutate a conjunct and see if the row notices

The cheapest test for a decorative assertion needs no census, no naming convention, and no reading of the producer:

Mutate a conjunct the row claims to assert. If the row stays green, that conjunct is decoration.

It generalizes past this class to any witness. Applied here it is what makes the red below load-bearing — and note which conjunct was mutated: a positive one. A row carrying only negative assertions would have stayed green under any mutation of them, because !contains("", X) holds for every X, and it would have reported nothing while looking like a passing test.

That gives the two halves of this class, which have to be stated together:

• SentinelCollapse — a refusal and a valid empty result share one value (""), so two facts with opposite repairs arrive as one. Here: EmitRejected { reason: _ } => "" threw away a reason the variant carries.
• VacuousNegative — an assertion that an empty value satisfies permanently, so it can never fail. Here: three !string_contains(...) conjuncts.

They compound. A reviewer who learns only "add a positive anchor" will pass a row whose anchor is present but unreachable — which is exactly what these two rows were. Their positives were correct and always had been; the flatten fed them "" before they could run. The missing-anchor rule and the refusal-arm repair are one wall approached from two directions, and a row needs both to be worth anything.

Rung, stated honestly

This is mechanically preventable at this seam, not structurally impossible. No algebraic-data-type rule can make deliberate erasure unspellable — a caller can always write a total match returning "". The claim is therefore the flattening has no spelling in these two rows, not RefusalErasure is now unwritable. Next-rung trigger: constraining the eliminators at the API seam so no caller can obtain artifact text from a refusal.

A second collapse survives one level in, named here rather than left for a reader to find: HtmlEmitResult is EmitOk { html: String }, so "emitted nothing" and "emitted content" remain the same value inside the success arm. Splitting that (a RenderedFragment with an explicit empty variant) is the real construction fix and is deferred: EmitOk is referenced 78 times across 26 files including production modules, so it is a shared-authority change needing its own decision, not a rider on a witness cleanup.

What this does not reach

The same file has 11 EmitRejected => "" sites, not 2. The other 8 are in shared render helpers — authority_page_html, empty_doc_html, depth_chain_html, bold_title_html, dispatch_doc_html_for, dispatch_doc_html_for_with_merged, blocked_dispatch_workspace_html, parity_row_html — which absorb the rejection before any witness sees it, so every caller inherits the conflation. Those are the root; these two are leaves. The helper repair changes the return type to HtmlEmitResult so the flattening has no spelling, and lands separately (with the forked twin in roadmap_row_witness_test.dag, which is deleted rather than converted — it has one caller and does nothing but flatten).

🤖 Generated with Claude Code

https://claude.ai/code/session_014oG2tMMAxgZeAQxDjvNsFm

[gunbai-bot]

The witnesses red is main's, not this PR's, and cannot be closed from this branch.

required-ci: floor refused: subject=f6e5e6a4134205f0 modules_resolved=3847 modules_excluded=4
dag/gunbc/runner_slot_provision.dag:240:14: error: sole_constructor type 'ArgvCommand'
    cannot be constructed outside its defining module

• This PR changes one file: dag/test/claim/long/roadmap_page_witness_test.dag.
• The offending construction is on main verbatim — ArgvCommand { argv: [...] } at runner_slot_provision.dag:240, from Runner slot membership becomes fleet-converge's third member family, plan and apply #8992.
• It refuses at strict-preparation, before the fold, so zero witnesses executed in this run.

gunbc#9031 carries the seal fix; re-run after it lands rather than repairing anything here.

Note the second-order point, which matters for how this PR is read: even once that seal break clears, dag/test/claim/long/ is a declined home — the floor discovers these witnesses and folds none of them. So a green witnesses check on this PR will still not mean these two rows ran. The evidence for them is the remote claim_batch run recorded in the description (green, plus a discriminating red with a same-run positive control), and that remains the only evidence that exists for this file.

— sent from bold-raven-901