bridge at 2× and 4× rates (follow-up 2.2) and the rational engine's plan draft

[tap]

What this changes

Two commits, the next two items of PLAN.md's "Next" entry, in the order the family plan sequences them:

1. 698af12 — bridge serves the pair at 2× and 4× rates (follow-up 2.2). ratio_traits<D, K> gains a rate scale K ≤ 2 (K = 1 is 88.2 ↔ 96 kHz, K = 2 is 176.4 ↔ 192); every Hz value is the base pair's times 2^K, L and M unchanged. basic_phase_table and basic_converter carry K through to design_prototype<D, K>, which scales the profile's passband edge with the pair. New aliases converter_to_96k / converter_to_88k2 / converter_to_192k / converter_to_176k4 with _q15 and _q31 forms. The profile table states each passband edge as a fraction of the pair's lower rate; the stopband edge is the output Nyquist, so one profile serves every K. The C ABI stays at K = 0 until a consumer asks. Charter prose updated in bridge/PLAN.md (§1, §9), bridge/README.md, bridge/CLAUDE.md, ratio.h, the family PLAN.md (2.2 marked done, the section-2 row) and README.md.
2. 68fe752 — rational/PLAN.md, v0.1 draft for review. The reviewed-plan deliverable: charter, decisions R1–R12, the generated 14 × 14 coverage matrix (all 182 ordered pairs with their chains and the 2.1 arithmetic for the hard cases), layout, three-leg test strategy, milestones M0–M6, non-goals, risks, and ten open questions for the maintainer (§9). Every number marked est. is a harris/Kaiser estimate owed a measurement; nothing is implemented.

Why

2.2 is the follow-up the migration deferred: a 2×-rate design could not even be expressed (a 36 kHz passband threw "bad profile"), and the family plan sequences it before rational, whose cross-family chains compose bridge at k = 1 and 2. The plan's claim — power-of-two scaling is exact in IEEE double and kaiser_beta depends only on the dB, so the scaled pair is the same table — is now pinned rather than asserted. The rational draft is where the maintainer's decisions on §9 are needed before M0 lands in DspTap; its matrix is also what answers the 2.1 rows the family plan left to it.

Verification

• Pinned by test (bridge/tests/test_design.cpp, test_converter.cpp): RateScaledTraitsAreThePairTimesTwoToTheK (the Hz values and L/M at K = 1, 2, as static_asserts), RateScaleIsBitIdentical (every direction × profile at K = 1 and 2 equals K = 0 coefficient for coefficient, exact double ==), RateScaledEconomyMeetsSpecAtItsOwnRates (the K = 2 design measured at 176.4/192 kHz against its spec), BadProfilesThrow at every K, and RateScaledConvertersAreTheBaseMachine (output, outputs_for/frames_needed and latency bit-exact against the base converter in float, Q15 and Q31, both channels, transient included).
• Host battery 172 / 172 under clang -Werror with both TAP_SR_*_WERROR; scripts/tidy.sh clean; pre-commit clean.
• The shipped K = 0 path is unchanged: the instruction-count gate run --exact against the committed baselines is +0 on all 51 measurements (Hexagon, M55, M33; both engines), on the local toolchains that match the baselines to the instruction. Per-function attribution on Hexagon shows every hot-path function (process_walk, process, the table and converter constructors) counting identically under its new mangled name.
• One thing found on the way. The first cut held the scaled edge in a local inside design_prototype; that re-allocated registers around the per-branch normalization loop and moved the construction count by one instruction per phase on Hexagon (−147 down, +160 up, economy workloads) and by one per workload on M55, with every hot-path function identical. Reading the edge at each use restored +0 everywhere; the comment in design.h records why.
• The rational draft is prose; its numbers are labelled est. and owed to M2/M4.

Notes for the reviewer

• Not a contract change. No documented contract point moves: K = 0 is the same table, schedule and codegen (the ratchet is exact), and the new aliases and the K parameter are additive. No pin moved, no notebook affected.
• The direction enumerators keep their up_to_48k / down_to_44k1 names at every K; K says which rates the frames carry. Renaming them would be a D7-scale API change for no behavior and is not proposed.
• Open questions in rational/PLAN.md §9 that shape the engine most: (1) bridge placement in 48 → 88.2 — the family plan's illustrative row vs the lowest-k rule, at 62 % of the MACs; (2) fewer stages when the MAC search wins by under 10 %; (4) chain<> in DspTap, below both engines.
• Merge method as before (merge commit), so each commit stays bisectable.

🤖 Generated with Claude Code

https://claude.ai/code/session_015VR1VC4SDGxHZQQsQvPBaA

---

Generated by Claude Code