The Interception: Watching the Gates Do Their Job In short: Ninety seconds of green, then a container with a real browser renders the grid at 800px and finds 38,000 pixels in the wrong place. The merge button greys out and the developer gets an image showing exactly what they broke. The pull request is open. The pipeline starts. Stage 1: the quick checks (94 seconds) Chapter 8 ordered the gates by cost, so the cheap ones run first. Everything green, exactly as the previous lesson predicted. The API diff is worth noting: it correctly reports no change, because no input, output, selector, or CSS custom property moved. It is doing its job; this is not the kind of change it exists to catch. If the pipeline stopped here, the poisoned code would merge. Stage 2: visual regression (4m 12s) The visual job runs in the pinned container from Chapter 8 — same image, same fonts, same rendering as the baselines captured in the previous lesson. Playwright launches headless Chromium, builds Storybook, and walks every story at every configured width. This time there is a real layout engine. It resolves , adds the padding to a 100% width, refuses to wrap because is gone, and pushes past the container's right edge. The camera fires. Two things in that output are worth reading carefully. The 1280px story passes. At full desktop width there is enough room to absorb the 48px overflow, so the component looks fine. This is exactly the point from the previous lesson — a developer checking the component in Storybook at default width would have seen nothing wrong. It is the 800px and 400px stories that catch it, and those exist because Chapter 6 made the component container-query-driven and Chapter 8 said to snapshot the breakpoints. The ratio is 0.11. The threshold is . This is not a marginal call about anti-aliasing — it is fifty-five times over, because an entire column of the layout moved. Chapter 8's argument about not setting the threshold to zero holds: a real structural break is never close to the line. Stage 3: accessibility (2m 48s) Running in parallel, finds something the developer will find ironic. The ticket was to make touch targets bigger. Because the row refuses to wrap and the children compress to fit, the buttons got shorter , not taller. The change achieved the opposite of its purpose, and the gate says so in one line. This is a good example of why the gates are worth having separately: the visual gate says "this looks different", and the accessibility gate says "and here is a concrete, named way in which it is worse." Stage 4: blocked Branch protection greys out the merge button. Nobody has to remember to say no. Note the asymmetry from Chapter 8: the visual gate offers an escape hatch and the accessibility gate does not. A visual change can legitimately be intended; a new WCAG violation cannot. What the developer sees The pipeline uploads the Playwright report as an artefact, and a bot comments on the pull request: > 🛑 Hold — 2 gates failed Visual (9 failures) — largest diff at 11.0% (threshold 0.2%) Accessibility (1) — : approve button is 88 × 18px, minimum is 24 × 24 > > Download the visual report · Full logs Opening the report gives three images side by side: Left — baseline v1.0.0. A row with tanker id, driver, volume, and two buttons at the right. Right — this pull request. The same row, taller, with the right-hand portion cut off. No buttons. Centre — the diff. A solid red block covering the right third of the row. The developer does not need to be told what is wrong. They can see it. Where the cost landed Without gates With gates --- --- --- Found by A dispatcher in a warehouse CI, 7 minutes after push Found when After a production deploy Before merge Diagnosis Work backwards from "the page is broken" An image, in the PR People involved Support, on-call, two teams One developer Time to fix A morning, plus a hotfix release Ten minutes Tankers delayed Some None Cost of the check — 7 minutes of CI The last row is the one to keep. Seven minutes of a container's time, on this pull request and every other, in exchange for the entire rest of the column. What no gate caught Worth being honest about, because the next lesson depends on it. Nothing in this pipeline understood why the change was made. No gate knows the ticket was about touch targets. No gate could tell you that removing was the mistake and increasing the padding was correct — it reports that the output is different and worse, not which of three edits caused it. A human still has to read the diff, understand the box model, and separate the intended change from the accidental one. That is the next lesson, and it is the part that does not automate. "But I thought nine failing tests meant something was badly wrong" Nine red tests looks alarming, and the instinct is to read the count as a severity signal — nine problems, or one very big one. It is neither. It is one defect, observed nine times. The visual suite renders every story at every width in every t…