Scope the phi rule to the records that declare it

[gHashTag]

Refs #2762, #2787

The catalog gate applied the GoldenFloat generating rule

e = round((bits - 1) / phi^2),   m = bits - 1 - e

to every record labelled cluster=GoldenFloat. That cluster holds four families on two axes, and 41 of the gate's 43 findings were the rule being applied to two of them.

The records say so themselves, in the field the gate parses

bnf8   standard="... control for TNF8; width rule 1+E+M=N;
                 exponent sized for range not phi"
tnf8   standard="... e is 3 balanced-ternary TRITS not bits (4.75 bits
                 equivalent); width rule 1+Et+M=N"
gft8   standard="... GOLDEN RATIO axis: E_t = round((N-1)/phi^2)"

The split is the data's, not mine. The file's own prose says it ten lines above the flagged rows: "NOT the golden-ratio family … Four formats, two axes."

And the numbers corroborate it twice: every bnf/tnf catalog e and m equals the constants in the spec its source= names (17 of 17), and every bias is a closed form of that same e — (3^e−1)/2 for tnf and gft, 2^(e−1)−1 for bnf (22 of 22). A mistyped exponent would strand its bias; none is stranded.

What changed

The three φ checks now run where a record declares rule=phi-ratio, added to 30 records. A GoldenFloat-cluster record without one is counted and named in a single loud finding — a skip nobody counts is the shape this gate exists to refuse.

tnf8 satisfies the φ rule and is deliberately not marked: at 8 bits the range-sized and φ ladders coincide, and encoding a coincidence at one width as a design decision is how a catalog acquires a second wrong rule.

	before	after
catalog gate	109 records, 43 findings, 42 unexpected	109 records, 3 findings, 2 unexpected
GATE FAILURES	42	2

The ratchet from #2784 demanded the re-bless on its first real improvement:

! GATE FAILURES fell 42 -> 2 (-40) -- re-bless to pin the lower number

The two that remain are real: getter-parity (109 records, 83 getters) and the new gf-rule-unstated (17 records naming no rule).

Four corrections to my own first reading

An adversarial audit was run against this reading, and it corrected me:

• I said 42 findings — it is 43, of which 42 unexpected
• I said zero findings on gf*/gft* — gfternary does produce one, from a different check
• I said two families — the repository's taxonomy is four on two axes
• I said bnf/tnf e-values "do not look rule-derived at all" — they are derived, by a documented rule that is not this one. My logarithmic curve-fit was a red herring.

And one finding I was wrong to dismiss: tnf16 records phi_distance=0.086, the value for m=9, while the record and its spec say m=11 → 0.0417. Genuinely stale under the catalog's own convention. Not corrected here — it is numeric data, and this PR changes classification only. Filed as #2787.

cargo test --no-fail-fast     2437 passed, 0 failed
suite --ratchet               RATCHET: CLEAN, exit 0
check_catalog_integrity.py    exit 0
check_catalog_count.py        exit 0
check_seal_coverage.py        exit 0 (catalog re-sealed)
check_specs_generate.py       exit 0
check_elab_ratchet.py         exit 0
parse-conform                 24/24

🤖 Generated with Claude Code

[gHashTag]

Superseded by a rebase onto master, which moved under this branch while it was open (another session landed #2785 and #2789). Reopened as a fresh branch rather than force-pushing this one.