Declare the rung drop for the witness floor leaving the required gate (#11742)

[gunbai-bot]

What this adds

One gunbc.rung_drop row, witness_floor_off_the_required_gate, plus its enrolment in gunbc.rung_drop.roster and the regenerated docs/design-rung-drops.md. No behaviour changes.

Why

gunbc#11742 replaced the emitted witnesses.yml with gunbc.compiler_gate_workflow, cutting the required check to cargo build --release -p v1-compiler --bin gunbc on a GitHub-hosted runner. The decision is not in question here — the fleet was stalled at ~100 self-hosted runner-minutes per push on ~45 runners with queues reaching 49 minutes, and this row records the cost rather than arguing it.

What was missing is the declaration. DESIGN §4b(3) admits a lowered rung only with previous rung, temporary rung, reason, bounded population and restoration trigger, rostered under gunbc.rung_drop; #11742 touched no row and not docs/design-rung-drops.md. The repo already carries a dozen floor_cut_* drops, so "floor capability removed → declared row" is the established pattern, and this is the largest such cut.

Why the module header is not sufficient

compiler_gate_workflow's header carries the ruling, the measurement and a capability-shaped dissolve-on condition, and it is a good header. The problem is that the trigger is self-erasing: its condition ends by deleting the module that carries it, so on the day the gate is restored the only written record of what was lost would be removed by the act of restoring it. A drop is retired by its trigger and by nothing else, so a trigger that vanishes when satisfied cannot be checked afterwards by anyone asking what the gate used to hold.

Shape of the row

TypedDeclaration (the arm new drops use), so all five fields are typed rather than prose:

• mechanically preventable → mitigatable, DeletedWithoutReplacement
• population at four phases, not one — the enrolled witness population, namespace-wave-admission, generated-artifact, the regen fixed point, and the parse sweep. A row naming only "the floor" would understate what left the merge path.
• restoration trigger at capability grain — the gate again plans and executes the enrolled population on the landing revision at a cost the fleet carries — with three named non-retirements, because each is the plausible mistake: re-emitting the old workflow without the preparation repair, a faster floor that is still off the merge path, and deleting the stopgap module.

The trigger also records the measurement that makes preparation the right target: on run 35462055101 the 4,185 claims executed in 53 seconds, while strict-preparation of 3,197 modules took 14.3 minutes and reach probes 11 minutes.

Verification

tools.docs_projection_gate regen run locally (it OOMs a BuildBuddy runner at rc=137 — the VM is below the corpus working set). Diff is 6 insertions: the roster import and list entry, and 4 lines of projection. The other two projections that gate writes — docs/design-failure-modes.md and docs/onboarding.md — came back byte-identical, so the regen disturbed nothing else.

Two rendering defects were caught by reading the regenerated output rather than the source, and fixed: a doubled full stop where my field duplicated the renderer's own, and commas inside population entries that dissolved the join(pop, ", ") into an unreadable run-on.

🤖 Generated with Claude Code