The Poisoned Pull Request: A Regression That Passes Every Test In short: Three lines of CSS, a genuinely good intention, and every dispatch action pushed off the right edge of the screen. Every unit test passes, because none of them can see a pixel. A ticket arrives on Tuesday afternoon. Warehouse staff use the dispatch grid on tablets, often wearing gloves, and the rows are too tight to hit reliably. That is a real accessibility problem — the rule from Chapter 6 exists precisely for it. The ticket is correct and the fix is worth making. The change A developer opens the grid's stylesheet: They increase the padding for bigger touch targets. While in there, they tidy up two declarations that look redundant — because a global reset "probably handles it", and because rows are not supposed to wrap anyway: Every individual decision is defensible. Bigger padding was the ticket. Removing an apparently redundant declaration is normal tidying. Nobody is being careless. What actually happens Three changes compound. Without , the element reverts to . now means the content area is 100% of the parent — and the padding is added on top of that. With (1.5rem) on each side, the row's total width is now . The row overflows its container by 48 pixels. Without , the row falls back to , so the flex children refuse to move to a second line. They compress until they hit their minimum content size, and then they overflow. on the actions container pushes it to the far end of the row — which is now 48 pixels past the right edge of the visible area. The result: the "Approve" and "Reject" buttons are rendered outside the grid's clipping boundary. On a tablet in the warehouse, they simply are not there. A dispatcher cannot approve a milk delivery. The tanker waits. The tests all pass The developer is conscientious. They run the suite first. Every assertion is true. The row element exists. The button exists. Its text is "Approve". This is Chapter 8's blind spot, arriving in a real scenario. The test environment — jsdom or happy-dom under Vitest — has no layout engine . It parses HTML and runs JavaScript. It does not compute box models, does not resolve , does not lay out flex containers, and does not know that anything has a width. on that button returns zeroes. There is no viewport for it to be outside of. The test was never wrong. It answers "is the button in the DOM?" — and the button is in the DOM. It is simply somewhere no human can reach. The other checks that miss it Check Result Why --- --- --- Unit tests ✅ Pass No layout engine TypeScript build ✅ Pass No TypeScript changed ESLint ✅ Pass No boundary or API rule involved Stylelint ✅ Pass is a valid token — the values are all legal API diff ✅ Pass No input, output, or token changed Code coverage ✅ 94% CSS is not instrumented Stylelint deserves a note. Chapter 6's rules catch hardcoded hex codes and off-scale spacing. This change uses , which is a legitimate token used correctly. There is no rule violation here — the CSS is well-formed, tokenised, and idiomatic. It is just wrong. That is what makes this bug a good test of the system: it is not sloppiness, and no linter can be written to catch it, because the mistake is in the interaction of three declarations rather than in any one of them. The commit An honest commit message describing the intent accurately. Where this ends without gates In an ordinary review, a senior engineer opens the pull request. The diff is a stylesheet: three lines, one changed value, two removals. No logic. Unit tests green. Coverage up. "LGTM." The pipeline publishes — a patch, correctly, because nothing about the API changed. The dispatch dashboard picks it up on its next deployment. Warehouse dispatchers open the grid on their tablets. The approve buttons are gone. Tankers queue at the collection centre while somebody files a support ticket describing the symptom, and an engineer spends a morning working backwards from "the dispatch page is broken" to a declaration in a different repository. That is the failure this whole course exists to prevent. Why this bug is representative Real production regressions in shared UI rarely look like bugs. They look like this: Small. Three lines. Well-intentioned. It fixes a genuine accessibility complaint. Locally correct. Every value is a valid token used properly. Invisible in a diff. You would have to simulate a box model in your head, in the specific container the component ends up in. Only wrong in context. The component in isolation at full width looks fine. It breaks inside the dashboard's constrained grid. That last point matters. If the developer had opened Storybook and looked at the component, they might have seen nothing wrong — at full width there is room for the overflow. The break needs the real container. What should catch it Only two things could have, and both are in your pipeline: Visual regression at a realistic width , which renders in a browser with an actual layout engine and compares against the…