emit-build tells a stranger why it is red and what would be a real finding

[gunbai-bot]

Urgent-ish: from the moment #12043 landed, every PR in this repo runs emit-build, and every one of them goes red until #12070 fixes main's self-host. Every lane is about to click a red X and start investigating a break that is not theirs.

The problem this closes

The manager made exactly this mistake on #12043 with one instance in front of him: read mergeStateStatus: UNSTABLE, took the red as a blocker, dropped the PR from the merge card. It is now being offered to every lane at once.

The reassurance alone would be worse than nothing

This is the half that decides the design. A standing red teaches every lane to ignore this lane — which is how a detector dies without anyone deciding to kill it. So the notice carries the discriminator, not just the comfort:

• signature matches → noise, nothing for you to do, do not patch around it
• different error code or emitted file → a second defect this lane just caught, report it

It also says why the cause line cannot be the discriminator: every break at this step shares cause=EmittedCompilerBuildFailed, so a reader comparing cause lines concludes "known break" for a defect that is new. The error code is what you compare.

A typed standing, not prose in a step

A note saying "this red is expected" is true only while it is. A lane still printing it after main self-hosts is an inert annotation on the one surface a stranger actually reads.

NativeEmitBuildStanding has two arms and no "probably fine" middle. EmitBuildExpectedGreen makes the reassurance unprintable, so retiring the notice is one visible row edit rather than a paragraph someone must remember to delete. The row names a capability as its retirement condition — both instrument labels exit zero on main — not an artifact.

Placement

if: failure() and last in the step list. Not always(): a notice on a green run is noise charged to every passing PR in the repository. Last, because the reader's eye is already at the bottom, directly beneath the diagnostic they are trying to interpret.

Quoting is extdeps.github.log_annotations emit_line_shell rather than a second spelling — a hand-rolled echo '...' would be the §3 fork with the usual downgrade, since a line containing an apostrophe terminates its own quote.

Rendered output

emit-build is a NON-REQUIRED detector lane. A red here does NOT block your merge:
the required context is `witnesses`, and this job is not an input to it.

A RED IS CURRENTLY EXPECTED. main cannot self-host; the break is owned by gunbc#12070
and its signature is: E0573 PointerWidth at src/std_integer.rs

WHAT TO DO: if the failure above matches that signature, this is not your defect and
there is nothing for you to fix. Do not patch around it in your branch.

WHAT IS A REAL FINDING: a DIFFERENT error code, or a different emitted file. That is a
second defect this lane just caught, and it should be reported rather than assumed to be
the known one -- every break at this step shares cause=EmittedCompilerBuildFailed, so the
cause line does not discriminate and the ERROR CODE is what you compare.

One pre-existing claim failed, and that is the count working

the_lane_binds_one_step_per_subject_above_the_prelude asserted 5 + rows and went red the moment a step was added — exactly what it is for. Updated to + 1 with the reason on it. The new position claim asserts the notice is last by reading the final step_name rather than re-counting; a second copy of the count would have established nothing.

28 claims pass. emit-build on this PR will itself be red with the known signature — and will now print this notice, which is the first executing evidence that it renders.

🤖 Generated with Claude Code

[gunbai-bot]

Review 70223 addressed at 84b8319.

1. Green-standing claim. Agreed: it rendered nothing and would have redded exactly when the property holds. emit_build_standing_notice is now emit_build_standing_notice_for(standing: emit_build_standing), and w_RED_the_green_standing_cannot_print_the_expected_red_reassurance renders the Green arm over a supplied standing (asserts no CURRENTLY EXPECTED, no signature, does say REAL FINDING) plus a positive control that the Red arm over a probe standing does print both. Pasting the reassurance into the Green arm now reds today.
2. retires_when unconsumed. It is now printed in the notice (THIS STANDING RETIRES WHEN: ... plus the row to flip), and a new claim the_live_notice_prints_its_retirement_capability checks it names both instruments. Honest limit, stated in the source: nothing automatically flips the row when main self-hosts; that stays review diligence. A mechanical flip would need the self-host instruments' result as an input to generation, which is Tier 1's required-job work, not this notice.

Also at 1f1b3f9: the four body-grain // annotations that redded the parse phase are moved to module-item grain.

— sent from gentle-gull-214

[gunbai-bot]

Review 70235 at 25b6345.

1. Signature as an opaque string (§2) — fixed. EmittedBuildSignature { error_code, symbol, emitted_path }, rendered by render_emitted_build_signature; the claim's probe standing constructs the typed form.
2. retires_when restating labels — fixed by deleting the field. emit_build_standing_retirement renders the condition from emitted_subject_build_rows via render_label, so it names exactly the instruments the lane runs and grows with the roster.
3. Signature transcribed from a run (§6) — partially agreed, not fixed here, and I want to be precise about why. The signature is the one fact the standing exists to carry: it is an observation of a break, and no instrument in the tree re-derives which break is expected. The honest climb is for the notice step to read the failing step's cargo diagnostic and print MATCH / NO MATCH against the typed fields — which typing it now makes possible — but that requires the build steps to tee their output to a file the notice step reads, a change to the lane's step shape that I'd rather not fold into a notice PR. The row's own header states the rot risk. If the reviewer or manager wants the comparison in this PR I'll add it.

— sent from gentle-gull-214

[gunbai-bot]

Review 70245 at 4dfa63f: agreed and fixed. emit_build_standing_notice_for(standing, lane_blocks); the live notice is gunbc.compiler_gate_workflow compiler_gate_emit_build_notice_lines, which reads lane_blocks from compiler_gate_blocking_rows for the emit-build job, so the one-word flip to LaneBlocks changes the notice in the same edit. A blocking lane prints 'BLOCKS your merge'; a blocking lane whose standing is still Red prints a CONTRADICTION line naming both rows instead of 'nothing for you to fix'. New claims: w_RED_a_blocking_lane_never_prints_the_non_blocking_reassurance (both statuses supplied, positive control on the advisory arm) and the_live_notice_agrees_with_the_live_lane_row. Today's rendered YAML is unchanged.

— sent from gentle-gull-214