Billing donut row, three in a row where three fit (#913) - Manual Test Plan

Field	Value
Branch / PR	feat/913-billing-donut-row
Environment	admin portal, apps/admin on :3001, Billing tab
Build flags / config	none
Build (commit)	see PR
Tester
Date

What was actually wrong

Overview dropped to a single column at 1024 while Reports stayed at three. The cause is a CSS source-order conflict: .billing-charts-grid--3up sets three columns, and a later rule at equal specificity gives the BASE class grid-template-columns: 1fr at max-width: 1024px. Later wins, so the variant looked correct in the file and never applied. .role-cards-grid--3col had the mirror problem, declared twice with the later repeat(3, 1fr) winning.

Underneath that, the breakpoints keyed off the VIEWPORT while the grid lives in a column the 310px sidebar has already narrowed: a 1024px window leaves the row 666px.

A wrong measurement I published, and the correction

An earlier version of this plan and its commit claimed the third donut was being CLIPPED off-screen at 1024, 1180, 1280 and 1440. Three of those four were false, and the retraction that followed over-corrected: one is real.

The false part came from an offline harness whose mock card held a fixed-size ring beside a non-shrinking legend, producing a 414px minimum. The real card has no such floor: below a certain width the legend moves UNDER the ring, and the card shrinks cleanly to 254px with the value and the full legend still readable. So nothing was clipped at 1180, 1280 or 1440.

But Reports IS clipped at 1024, measured on the deployed build by driving the portal to that tab. There the container is 666px, repeat(3, 1fr) asks for three tracks, and three cards at their 254px floor plus gaps need 794px, so the row overflows by about 128px into .admin-main's overflow-x: hidden.

Reports on the shipped build	412	1024	1280	1440	1920
columns	1	3	3	3	3
card	316	254	281	334	494
third donut	visible	CLIPPED	visible	visible	visible

With the fix applied on the same live page: 1024 becomes 2 columns at 301px, all visible, and 1280 stays 3 columns at 281px. So the fix resolves the one genuine clipping case and preserves everything else.

The derived number was about 40% too high, and every conclusion resting on it was wrong in the same direction. Measured on the deployed page by pinning the row to a fixed width and walking it down:

Row width	Card	Content overflow
1100	351	fits
980	311	fits
860	271	fits
800 and below	254	fits (card stops shrinking)

The first fix was also a regression. A 356px floor produced two columns at 1440 where the shipped build correctly shows three. Caught by measuring the deployed app against the harness rather than trusting the harness.

Two corrections in opposite directions on one claim, which is the thing to notice: the harness overstated the problem (three widths that were fine), and my retraction then understated it (one width that was not). Both were resolved the same way, by driving the real page.

Behaviour, measured on the real component

Candidate floors applied to the live page, three donuts, columns/card width:

Floor	412	1024	1280	1440	1920
254 (shipped)	1 / 316	2 / 297	3 / 275	3 / 329	3 / 489
280	1	2	2	3	3
300	1	1	2	3	3
356 (first attempt)	1	1	2	2	3
shipped today (buggy)	1	1	2	3	3

254 is the only candidate that improves on today at every width and regresses at none: it fixes the 1024 stacking, and adds three-across at 1280.

Three at 412px remains impossible: the container is 364px, so a second column would need 508px.

Setup / preconditions

• Run the admin portal and sign in; open Billing.
• Have both Overview (At a glance) and Reports (vendor / service / SKU) reachable, with data in each.
• Resize by viewport width, not by zoom: the grid keys off the container, and zoom changes both together in a way that hides the effect.

Scenarios

1. Three donuts in a row on a large monitor

• Goal: the comparison the section is headed for is possible without scrolling.
• Steps:
  1. Open Billing at a window width of 1920 or wider.
  2. Look at At a glance (Monthly / Yearly / Total).
  3. Switch to Reports and look at the vendor / service / SKU donuts.
• Expected: three donuts side by side in both sections, all three fully visible, legends readable.

Result:    [ ] pass   [ ] fail   [ ] blocked
Actual:
Evidence:   (screenshot)
Follow-up:

---

2. Nothing is ever cut off at any width

• Goal: confirm the grid never exceeds its container. (An earlier draft claimed the third donut WAS being clipped on the shipped build; that was a bad measurement and is corrected above. This scenario guards against introducing it.)
• Steps:
  1. Set the window to 1024 wide. Look at Reports.
  2. Repeat at 1180, 1280 and 1440.
  3. Repeat all four widths on Overview.
• Expected: at every width, every donut rendered is fully visible. Where three do not fit, you see two or one, never a third card sliced off at the right edge.
• Verify: no horizontal scrollbar appears, and no card's right edge sits past the content area.

Result:    [ ] pass   [ ] fail   [ ] blocked
Actual:
Evidence:   (screenshot at 1024 and 1440)
Follow-up:

---

3. Overview and Reports agree at every width

Measured headlessly on the deployed build for both sections; this scenario is a human confirmation rather than the only evidence. Reports at 1024 was the one genuine clipping case and is the width to look at first.

• Goal: the two sections stop diverging, which is the reported symptom.
• Steps:
  1. At each of 900, 1024, 1280, 1440 and 1920, note the number of donuts per row on Overview.
  2. Note the same on Reports at the same widths.
• Expected: the counts match at every width.

Result:    [ ] pass   [ ] fail   [ ] blocked
Actual:
Evidence:
Follow-up:

---

4. A phone stacks cleanly

• Goal: it holds at the width she actually reads on.
• Preconditions: 412px wide viewport (device emulation is fine).
• Steps:
  1. Open Billing at 412px.
  2. Scroll through At a glance and the Reports donuts.
• Expected: one donut per row, each full width, legend beside the ring and readable, nothing cut off horizontally, no sideways scrolling of the page.
• Note: three across is impossible here and was not attempted. The container is 364px, and a second column alone would need 508px.

Result:    [ ] pass   [ ] fail   [ ] blocked
Actual:
Evidence:   (screenshot)
Follow-up:

---

5. Nothing else on Billing moved

• Goal: regression check on the surrounding page.
• Steps:
  1. On Billing, check the metric cards row, the provider cards, and the non-donut charts at 1440 and at 412.
• Expected: unchanged from before. Only the donut rows were touched.

Result:    [ ] pass   [ ] fail   [ ] blocked
Actual:
Evidence:
Follow-up:

Notes

Where the numbers come from, and which ones to trust. The final figures were measured on the deployed admin portal with the real component. An offline harness was used first, rendering the real container chain with the real stylesheets but a MOCK donut card, and it is the reason this plan briefly carried a false clipping claim and a fix that regressed 1440.

The harness was right that the component is only wrong in place, and wrong about the component itself. A harness that reproduces the container and substitutes the content answers a question about the container; it cannot tell you what the content will do, and it will state its answer just as confidently either way. Where a conclusion depends on how the real thing behaves, the real thing has to be in the picture.