sec(gate): assert the detector floor has not fallen behind the loaded list (BACKLOG #1368, SEC-04)

[wshallwshall]

Built by Builder 2. Landed by the Lander. Four files, +261/-1. Zero files under messagefoundry/.

The gap

MEFOR_MIN_DETECTORS catches the token list dropping below the floor. Nothing asked whether the floor had fallen behind the list -- and a floor of 7 against a list of 40 is satisfied by any 7 detectors surviving, so the gate goes green while guarding almost nothing. New --assert-floor-fresh mode, wired into the forbidden-content job.

The spec deviation, ruled

The master test plan's SEC-04 row specifies a flat 80% ratio. This ships a different rule, deliberately, and the owner has now ruled in favour of it: absolute small-N, ratio above.

The literal spec would have reddened the gate on its first real run with nothing wrong. Measured against the live list: names 87.5% and estate 92.9% pass a ratio; site_prefixes is 1 of 2, which is 50%, and fails one. Growth from 1 to 2 always scores 50%, so at that size a ratio measures the section's size rather than the floor's staleness.

Constants read from the commit rather than from the handover:

scan_forbidden.py:1033   _SMALL_SECTION_MAX = 4
scan_forbidden.py:1036   _MAX_ABSOLUTE_LAG  = 1
scan_forbidden.py:1038   _MIN_FLOOR_RATIO   = 0.8
scan_forbidden.py:1066   if loaded <= _SMALL_SECTION_MAX:   <- the absolute arm, small-N only

The author flagged one ambiguity in the relayed wording -- absolute everywhere versus absolute-for-small-N with the ratio kept above it. They shipped the latter, which is what the Dispatcher approved and what the arithmetic argues for. The code's own comment at :1051 states it: "TWO RULES, BECAUSE ONE SHAPE DOES NOT FIT BOTH SIZES." If the owner meant the former it is a one-constant change and does not warrant holding the branch.

No floor is raised here

The live list is inside the shipped rule today. The author declined to raise a security threshold on the strength of one day's list, and says plainly that nobody should inherit that decision from a builder. Raising it stays a separate, owner-facing call.

Two safety properties, checked

The new step is guarded on MEFOR_MIN_DETECTORS, not on the secret. Only the secret-present branch exports it, so fork PRs and structural-only runs skip it. It must not run against the synthetic example set, which populates every section and would fail freshness on a contributor's machine.

No token content anywhere -- code, tests, ledger row or commit message. Every figure is a count or a mode marker, both of which the gate already prints to CI logs. I checked the diff for literals independently: zero hits.

Lander verification

ahead of origin/main    1        behind    1 (the codeql merge_group fix)
merge-tree vs main      exit 0 (clean)
diff                    4 files, 261 insertions(+), 1 deletion(-)
files under messagefoundry/    0
'+## 1368' in the ledger diff  1

Before the push, git branch -r --contains 136c11ba8 named only the private rescue ref. Two remotes, and a count-based check reads that as already pushed.

Author's verification: ruff clean, 50 tests passing, 38 definitions with no duplicate names, 9 new tests confirmed present by name, the assertion run end-to-end against the real floors (exit 0) and shown to fail on three separate drift shapes each naming its own section.

Deliberately not wired

branch-leak-scan.yml pins the same floor and is untouched. Same rule, different job, and it deserves its own decision rather than being swept in.

Not armed

This touches a security workflow. Required approvals are 0.

Generated with Claude Code

[wshallwshall]

Held for the owner, and I want to be explicit that this reverses what I told builder-2 twenty minutes ago.

I named this one as next and held a queue slot for it. Then I looked at the diff: it adds a new step to .github/workflows/security.yml, which is a required-context producer, and that step introduces a new failure mode — scan_forbidden.py --assert-floor-fresh.

An hour before that I told builder-1 that a CI workflow file is squarely the owner's CI-gating category and that #1296 would be held for exactly that reason. Landing this one while holding #1296, 628, 634 and 635 would make the hold turn on which PR I happened to look at closely.

Nothing here is failing on its merits. The rebase is verified: merge-tree clean, and a heading set-difference against main shows nothing lost and exactly one row added (#1368). The change itself is well argued — a floor only constrains a list while it stays near it, and the comment says so plainly.

It is a category call about the file, not a doubt about the change. It joins 628, 634, 635 and 636 unarmed.

Sequencing consequence: 631 no longer consumes the appender slot, so 633 is next in that group.