Two rows the contended surface had been holding: the diagnostic absorber, and a frontier that outlived its own trigger

[gunbai-bot]

Both were derived and written days ago and deliberately not filed: the roster was a
hand-authored membership tail, so every append collided in one merge region and filing
would have added to the population being cited as evidence that the surface had to
change. gunbc#10822 removed that surface -- membership is now read from the row
directory -- so an append is a new file and never an edit to a shared tail. Filed in
the order the lane recommended: the compiler defect first, so the new mechanism proves
itself on real content rather than on a smoke row.

CONSUMPTION, checked by execution rather than asserted: both identities appear in
expected_design_failure_modes_md with NO registration edit anywhere -- no import
line, no list entry, no roster. That is the derived membership working, and it is the
executed evidence that gunbc#10822's capability is live rather than merely landed.

unresolved_name_is_reported_as_a_decidability_verdict
A reference that failed to resolve is reported in a category that presupposes it
resolved. Two ends, one mechanism: the advisory end WIDENS to a true-sounding
"undecidable position"; the blocking end FABRICATES, putting an unresolved callee's
authored name into a type-equality verdict as though it were a type. The second is a
false statement about the program -- section 5's fabricated plausible output -- and
sits below the section 4b floor.
The measurement is the argument: a controlled A/B over one corpus moved the
generic-formal reason from 59 to 6,231 while three neighbouring diagnostic classes
stayed INVARIANT. The honest arm for an unresolved formal exists and fired ZERO times
in both arms, because the name it tests is read from authored source and so survives
a failed lookup. Pre-existing; a supply change made it loud rather than causing it.

declared_frontier_outlives_the_firing_of_its_own_trigger
A declaration admitted under section 3c as consumed-by-a-named-later-consumer,
whose trigger is then satisfied BY OTHER MEANS, becomes dangling without any edit to
itself. The specimen is this lane: gunbc#10836 declared a frontier whose trigger was
roster membership becoming derived, and gunbc#10822 landed exactly that while the
declaration was in review. It is not the stale-claim class -- the frontier's sentence
stayed accurate, so re-reading the claim against its premise finds nothing wrong --
and not the unsatisfiable-trigger class, which is its opposite: satisfaction is what
stranded it.
The row records that a reviewer's requirement to move the trigger OUT of a pull
request body and into the tree beside the declaration is the only reason the firing
was discoverable at all, and names the next rung: a typed frontier carrier a fold can
read, so a frontier whose capability has landed refuses instead of waiting to be
noticed.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01GwvzQ3SQoWWDgHkAeffMeF

🤖 Generated with Claude Code

https://claude.ai/code/session_01GwvzQ3SQoWWDgHkAeffMeF

[gunbai-bot]

#10842's RED IS MINE, IT IS NOT THE STALE-ADMISSION CLASS, AND IT IS A GAP IN #10822 THAT ONLY
A ROW-ADDING CHANGE CAN HIT. I am the first append since the restructure, so I am the first to
find it.

WHAT FAILED, exactly: the floor itself is CLEAN (verdict=FloorClean, unexpected_failures=0,
3549 executed). The lane failed at phase namespace-wave-admission:
adjudication BLOCKING phase=namespace-wave-admission
cause=2 unadjudicated delta(s), 0 stale admission(s), 0 consumed admission(s)
The two deltas ARE my two row files, and their disposition is the discriminating part:
ExplicitlyEvaluatedZeroDelta membership roster -> AUTO-ADMITTED
"reached by a name this module authors"
NewPoolCoincidenceResolution binding roster::recurring_failure_mode_roster
<my row> -- base {} -> head {} REFUSED
So the MEMBERSHIP edge auto-admits and the BINDING refuses, on the same two files.

BASELINE CHECKED FIRST, because a correlated red is a hypothesis and not a finding: sibling
open PRs at the same base are SUCCESS on required-witnesses-floor (10843, 10841, 10840, 10849).
Mine is the only FAILURE. So this is my diff, and I am not going to call it someone else's.

THE ANALYSIS, AND IT IS WHY I THINK THE CLASSIFICATION IS WRONG RATHER THAN MY ROWS BEING BAD.
The interlock records that AuthoredReferenceResolution was SPLIT OUT of
NewPoolCoincidenceResolution on 2026-08-27 precisely to separate "the target grew a name this
module was already reaching for" (coincidence, cause elsewhere) from "this module's own author
wrote what resolves a name it was already spelling" (the repair the wall exists to want). THE
STATED DISCRIMINATOR IS THE MODULE'S OWN SOURCE.
gunbc.recurring_failure_mode.roster NO LONGER HAS AN AUTHOR. Since #10822 it is GENERATED --
ensure_derived_recurring_failure_mode_roster reads the row directory -- so its source is
DERIVED FROM THE VERY FILES BEING ADDED. Its binding to my row is not a coincidence in the
pool; it is the mechanical consequence of the file existing, which is exactly what #10822
built. The membership arm already reaches that conclusion and auto-admits with "reached by a
name this module authors". The binding arm applies a discriminator that assumes a human author
and gets the opposite answer on the same fact.
Consequence, stated plainly: after #10822 an append is a new file and nothing else -- EXCEPT
that it now requires an operator-authored namespace admission. The merge-region collision was
removed and a gate refusal took its place. That is cheaper and far better, but it is not free,
and nobody has hit it until now.

WHAT I AM NOT DOING: authoring the admission. The interlock says operator-authored, and I will
not hand-admit a wall refusal about my own diff -- that is the escape-hatch shape whatever the
merits.

ESCALATING, because the fix is one of two and neither is mine: (a) author the two admissions
for #10842 and let the class recur on every future row, or (b) treat a DERIVED module's binding
to a newly-present source file as AuthoredReferenceResolution rather than
NewPoolCoincidenceResolution, which closes it for every future append. I recommend (b) and I
would take (a) only as an interim with (b) as its trigger.
#10842 stays red until that is answered. Nothing else of mine is affected.