A CORRECTION TO THIS ISSUE'S OWN PLAN, first, because the plan was wrong in
a way that would have cost the acceptance case.
#4208 recommended widening `kind` past `css | sym` to carry the form, calling
the denominator the deeper win and a migration the price. Two things:
1. THE MIGRATION IS NOT NEEDED. The issue says density "is computed from
stored rows and `shape_form` only runs on read". `canon_density` does
`select(CodeShape)...scalars().all()` and filters to the directory in
PYTHON; `signature` is a stored column; `canon_form(siblings, ...)` on the
next line already derives form from those rows. Bucketing the denominator
costs a list comprehension.
2. WIDENING `kind` WOULD BREAK MILESTONE #2793's ACCEPTANCE CASE. If `kind`
separated `fn` from `async-fn`, density would bucket them apart — which
does silence #4204's four `def` helpers, as claimed. Apply it to a
hand-rolled SYNC `confirmDanger` in a directory where an async confirm
helper is canon: the canon leaves the candidate's denominator, nothing
dominates, no flag. That is the flag the milestone exists to produce, and
it is the same inversion the first form gate made, one layer down.
So option 1 is not expensive-but-right, it is wrong; and option 2 (compare
meaning) is not the interim, it is the only lever. `confirmDanger` beside an
async confirm helper and `is_registered` beside a service unit are identical
at every structural level — same family, same form contradiction, same
density. They differ only in whether the candidate does the canon's JOB, and
no signature carries that.
WHAT THIS SHIPS is the part that is right and provable: an honest
denominator. `comparable_siblings` narrows the count to rows whose family
does not contradict the candidate's, using `families_conflict` — the same
predicate the gate uses, so the count and the verdict cannot drift into
disagreeing about what comparable means. "372 judged siblings" stops counting
a dataclass, a constant and an async service unit as three comparable things.
NARROWED BY FAMILY, NOT FORM, for the reason above: `fn` beside `async-fn`
stays a fair question. An unreadable sibling STAYS COUNTED — dropping it
would shrink `judged`, raise the share, and fire the check more on the
directories it can read least. Every unknown-form decision in this module
goes that way.
Density is now per candidate rather than per kind, cached on (kind, form).
TWO BUGS THIS CHANGE HAD, both caught before CI and both pinned:
- I passed a FAMILY where `families_conflict` reads a FORM, so
`shape_family("callable")` returned "" and the narrowing was a silent
no-op that still read as applied. The regression guard deliberately uses a
callable: `type` is both a form and a family name, so testing with it
proves nothing and the bug hides.
- My new `_Row` in the test file shadowed the one already there — same
fields, different `snippet_id` default — silently breaking three passing
`canon_form` tests. Reused the existing class. A duplicate definition
quietly changing a neighbour's meaning is this file's own subject.
The residue test's docstring said separating the four needs "widen `kind` or
a comparison of meaning". Corrected: they are not alternatives.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01821k5B3Ysecp9fNYs92Kuy
bvandeusenandClaude Opus 5
04775c3496