The Resolution: Fixing, Approving, and Publishing In short: Separate the accidental change from the intended one, fix the accident, approve the intention through CI, and let the pipeline calculate the version. The baselines are regenerated in the container — never on a laptop. The evidence is unambiguous: the actions are off screen and the touch targets shrank. Now the part no gate can do — working out which of three edits was the mistake. Reading the diff properly Three changes went in together: Change Intended? Effect --- --- --- → Yes — the ticket Taller rows, bigger targets Removed No — tidying Width becomes 100% + padding → overflow Removed No — tidying Children cannot wrap → compress and clip The padding stays. The two removals were wrong, and they were wrong for the same reason: both declarations looked redundant in isolation and were load-bearing in combination with . That last block is the real fix. The original change tried to get taller touch targets indirectly , by adding padding to a parent. The rule from Chapter 6 states the requirement directly: on touch devices, the target is at least 44px. It cannot be undone by an unrelated layout change, and it does not affect mouse users at all. Leave a comment on the two restored lines. Somebody will try to tidy them again: The visual change is still real The fix restores the layout, but the rows are genuinely taller now — that was the point. Nine visual tests will still fail, correctly, because the component no longer looks like the v1.0.0 baseline. This is the intentional half, and it goes through the approval path from Chapter 8: label the pull request , and CI regenerates the baselines in the pinned container . Two details matter here. Never regenerate baselines locally. A developer's machine renders fonts differently from the Linux container, so locally-generated baselines would silently drift and every subsequent comparison would be against the wrong reference. This is the rule from Chapter 8, and it is the single most common way a visual suite gets abandoned. Never regenerate everything. is scoped to the affected project. A blanket across the workspace would accept every difference as the new truth — including, potentially, a real regression in that happened to land in the same pull request. That is how a visual gate gets quietly disabled while still appearing to run. The bot pushes a commit containing only the new PNGs, and the developer reviews it as images. Green The API diff reports no surface change, and the visual change was approved, so the ship-or-hold rule from Chapter 8 calculates a patch . Consumers can take it without reading anything. The human review The merge button is available. It is not automatic — the gates established that it is safe , and a person still decides whether it is right . What the reviewer is now looking at, having been freed from everything above: Is the right amount of padding, or is enough? Is the right minimum for gloved hands, or should it be larger? Do the new baseline images look like what design asked for? Is the comment on the restored declarations clear enough to stop the next person? Four judgement calls, none of which a machine can make. That is the split this course has argued for since Chapter 2: automate the objective, spend human attention on the rest. Approved. Merged. The publish The release notes, following Chapter 9's structure: v1.0.1 — drop-in upgrade > > Larger touch targets in rows for tablet users. No API changes. Estimated effort: 5 minutes — your visual baselines for the grid will need > re-approving, since rows are now taller. Run your snapshot update job. 🐛 Fixes Grid rows are easier to tap on touch devices. Row padding increased and > action buttons now have a 44px minimum height on coarse pointers. Reported by > the warehouse operations team. That note tells a consumer exactly one thing they have to do, and how long it takes. What actually happened here Trace it back. A developer made a small, well-intentioned change containing a subtle box-model error that no linter could catch and no unit test could see. A container with a real browser found it, seven minutes after the push. An accessibility rule found that the change achieved the opposite of its goal. The merge was blocked without anyone having to say no. The developer got an image, not a bug report. The intentional half was approved deliberately, in the right environment. The version was calculated from evidence. No dispatcher ever saw it. No tanker waited. Nobody was heroic. The system worked, quietly, which is what a good system looks like from the inside — you mostly do not notice it. "But I thought updating baselines was just accepting the new screenshots" Mechanically it is one command, so it gets treated as a formality — a checkbox between you and a green build. That framing is what quietly kills a visual suite. Updating a baseline is not accepting an image. It is redefining what correct means for every future pull request.…