You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
crates/perry-ext-* is not covered. Its sibling gate gc_store_site_inventory.pydoes cover them — iter_scan_roots() globs crates/perry-ext-*/src explicitly — so the two audits disagree about what counts as first-party runtime code.
How it surfaced
While clearing #7259 the ratchet baseline reported a stale entry:
handle-floor | crates/perry-stdlib/src/http.rs: baseline says 11, found 0 — lower it to 0
crates/perry-stdlib/src/http.rs no longer exists: #6826 (refactor(http): merge server implementation into HTTP extension) moved it into crates/perry-ext-http/. The 11 sites were not fixed — they moved out of the gate's field of view. They are still there:
This is the "the gate runs but its subject never did" failure mode from CLAUDE.md: the audit is green on those files because it never reads them.
Scope
Running the existing rules over crates/perry-ext-*/src (113 files) finds:
rule
sites
files
handle-floor
10
5
band-literal
8
4
handle-floor is ratcheted, so those 10 can be recorded as known debt in one baseline regeneration. band-literal is not ratcheted — it is governed by the line-substring allowlist, so all 8 would hard-fail until each is individually audited and either rewritten through addr_class or given a justified allowlist entry.
That per-site audit is why this was not folded into #7259: mislabelling one is worse than leaving it uncovered, and #7259's job was to get lint green without weakening either gate.
Suggested fix
Audit the 8 band-literal sites in crates/perry-ext-* individually (rewrite through value::addr_class, or allowlist with a real justification).
Add crates/perry-ext-*/src to SCAN_ROOTS — ideally via the same glob shape gc_store_site_inventory.py already uses, so a NEW perry-ext- crate is covered automatically rather than needing a script edit.
Regenerate the ratchet baseline to record the 10 handle-floor sites.
scripts/addr_class_inventory.pyscans only two roots:crates/perry-ext-*is not covered. Its sibling gategc_store_site_inventory.pydoes cover them —iter_scan_roots()globscrates/perry-ext-*/srcexplicitly — so the two audits disagree about what counts as first-party runtime code.How it surfaced
While clearing #7259 the ratchet baseline reported a stale entry:
crates/perry-stdlib/src/http.rsno longer exists: #6826 (refactor(http): merge server implementation into HTTP extension) moved it intocrates/perry-ext-http/. The 11 sites were not fixed — they moved out of the gate's field of view. They are still there:This is the "the gate runs but its subject never did" failure mode from CLAUDE.md: the audit is green on those files because it never reads them.
Scope
Running the existing rules over
crates/perry-ext-*/src(113 files) finds:handle-floorband-literalhandle-flooris ratcheted, so those 10 can be recorded as known debt in one baseline regeneration.band-literalis not ratcheted — it is governed by the line-substring allowlist, so all 8 would hard-fail until each is individually audited and either rewritten throughaddr_classor given a justified allowlist entry.That per-site audit is why this was not folded into #7259: mislabelling one is worse than leaving it uncovered, and #7259's job was to get
lintgreen without weakening either gate.Suggested fix
band-literalsites incrates/perry-ext-*individually (rewrite throughvalue::addr_class, or allowlist with a real justification).crates/perry-ext-*/srctoSCAN_ROOTS— ideally via the same glob shapegc_store_site_inventory.pyalready uses, so a NEWperry-ext-crate is covered automatically rather than needing a script edit.handle-floorsites.handle-floor | crates/perry-stdlib/src/http.rs | 11line (already removed in lint: addr_class_inventory fails on main — 2 real ratchet regressions plus a stale allowlist substring #7259's regeneration).Related