fix(templates): hold the height budget at every width, not three samples

[scheemunai]

The defect

The contract samples 390, 768 and 1440. All three sit at widths where these templates are compact: 390 is inside the mobile compaction, 768 is past the wide breakpoint, and nobody looked at the band between. There, the compaction had ended and the wider layout had not begun — full desktop spacing inside a still-narrow single column.

template	before	after
research-brief	3258 @550	2818 @320
report	3247 @490	2830 @320
postmortem	2961 @320	2818 @320
service-health	3140 @320	2734 @370
case-study	2860 @320	2644 @370
project-status	2879 @320	2823 @550
metrics-dashboard	2573 @320	2601 @320

Zero widths over 2,900 across 320–1920, swept in 10px steps with window.innerWidth asserted at every step.

The fix, at the layout

• The compact spacing scale now starts where the layout actually changes (44rem / 62rem) rather than at 34rem, so it covers the band. The type compaction stays at 34rem, where the measure needs it.
• A narrow band below 23rem tightens spacing and returns measure to the column. At that width the height is wrapping, not spacing — narrowing the gutters bought 74px where another spacing cut bought 7.
• Leading is untouched. 1.5 is the WCAG 1.4.12 baseline and is the wrong thing to spend on a height budget.

Sampled widths did not move

	390	768	1440
report	2744	2662	2660
research-brief	2687	2094	1970
postmortem	2673	2396	2133
case-study	2528	2115	1937
metrics-dashboard	2287	1662	1300
project-status	2672	2505	1907
service-health	2581	2470	2283

One exception, downward: research-brief at 768 drops 2626 to 2094, because its layout breakpoint is 62rem so the band fix covers 768 as well.

Two things the sweep found that were not reported

• metrics-dashboard overflowed horizontally — 16px at 320, 6px at 330. An auto-fit minmax floor wider than the content box cannot shrink. Guarded every floor >= 14rem across all seven with minmax(min(<floor>,100%),1fr), rather than fixing only the one that failed today.
• service-health was over at 320-340 and was not in the reported set.

No content removed

Byte budgets held by deleting declarations that restate a value already inherited from a wider block, and by removing three passages that restated each other — the closing block's first sentence repeated the h1, and the legend's trailing line repeated both the legend items above it and the per-strip counts beside it. All seven within 18,432 bytes.

Verification

• 10px sweep, 320 to 1920, innerWidth asserted per step; a mismatch aborts rather than records.
• Rendered and inspected at the two former peaks (research-brief@550, report@490).
• dupselscan clean — no duplicate selectors introduced.

Co-Authored-By: CRHQ noreply@crhq.ai

🤖 Generated with Claude Code

[scheemunai]

Parked pending the 2,900 re-derivation — not abandoned.

The orchestrator has halted height work across the corpus: 14 of 19 templates exceed the 3,000 fail line at some width, and the threshold was derived from measurements at 390/768/1440 — three widths at which every one of these had already been compressed to fit it. Compressing sixteen documents to satisfy a number that sixteen documents violate is the harm the 400px floor was rejected to avoid.

So this PR's height work waits for the number.

One piece of it did not need to wait, and is now #31: metrics-dashboard scrolls sideways below 336px. Horizontal overflow is a defect at any threshold — nobody chooses to scroll sideways — and the fix is one line. It was trapped in here behind a policy question, which is the "hard half makes the easy half look blocked" pattern, so I split it out. #31 is height-neutral for six of seven templates and carries no threshold assumption.

If the re-derived limit lands somewhere this branch still helps, it rebases cleanly. If the answer is that documents should be allowed to be tall at 320px, this should be closed rather than merged — the changes here buy height that may not need buying.

[scheemunai]

Prose restored. Rendered content on this branch is now byte-identical to main for all seven templates — every change here is CSS.

The chain you identified ran exactly as you describe: the CSS fix added bytes, the byte cap bound, and three passages came out of service-health to make room. Restoring them puts the branch 175 bytes over the 18,432 cap.

That overage is the point. It is the honest price of the mid-width fix, and it belongs visible on the branch rather than paid for in deleted sentences — because the number this PR is held against is being re-derived, and whoever re-derives it should be able to see what the current one costs in another currency.

postmortem needed no restoration; its trims were guidance comments, not rendered prose. But it sat at 10 bytes of margin, which is a worse property than the 2,961px it was bought with — a soft, arguable, reader-invisible overage converted into a hard one-edit-from-breaking constraint.

State of the two branches:

#31	overflow only. 0 non-minmax changed lines. Height-neutral for 6 of 7. No threshold assumption. Merge whenever.
#30 (this)	height work only, now with no prose cost. Over the byte cap by 175. Held.

If the re-derived height limit lands somewhere this work is unnecessary, close this rather than merge it. If it lands somewhere the work is needed, the byte cap needs re-deriving too — those 175 bytes do not go away, they just move to whichever number is softer.

[scheemunai]

Closing, not merging — the condition written on this PR has been met.

From the comment above: "if the re-derived answer is 'documents may be tall at 320', it should be closed rather than merged — the changes here buy height that may not need buying."

The re-derivation landed (Template size limits — what they are for, and which to keep): the height gate is retired because nobody ever sees a template at its full height — the gallery preview is bounded at 612px and the artifact a reader receives is the agent's rewrite, not the template. So the sub-390 mass this branch compresses is not defective, and the work here buys nothing.

The 175-byte overage goes with it. That is the right outcome: the price I made visible is what showed the fix was not worth paying. Had I left it hidden in three deleted sentences, this branch would have looked free and might well have merged.

The three breakpoint cliffs it also contained were split out and merged as #32.