What happened
/tickets gave every slice its own test_command, filtered by story file name — CardProfileMain.parts, CardProfileMain.root, CardProfileMain.disabled and so on — precisely so each command would exercise only its own slice.
Consequence: a slice that changes a shared component's classes invalidates every earlier slice's snapshot, and no per-slice filtered command can see it. Eight stale snapshots were sitting at HEAD when the seventh slice started — three from parts, three from root, two from disabled — because an earlier slice had added hover and focus classes to the card root and never re-ran its siblings.
The author's own summary: "the narrower I made the seam, the blinder it got."
It surfaced only because a later slice happened to run a broad enough check.
What the validation does and does not do
The Nyquist map validates that every issue has a test_command. Nothing checks whether the set of commands can see a cross-slice regression. A complete set of individually-correct commands can be collectively blind, and this run produced exactly that.
The second consequence, in the Consumer
The same pressure fragmented the Storybook organisation — one component split into five story files so each slice could filter on one. See the output-organisation issue; they are two ends of one problem.
The open question
Should a slice's test_command be allowed to be narrow at all, or should the narrow command be an addition to a broad one that always runs? And what would a validation of the set rather than each member actually check?
Full evidence: docs/research/2026-08-31-dlc-run-2-findings.md.
What happened
/ticketsgave every slice its owntest_command, filtered by story file name —CardProfileMain.parts,CardProfileMain.root,CardProfileMain.disabledand so on — precisely so each command would exercise only its own slice.Consequence: a slice that changes a shared component's classes invalidates every earlier slice's snapshot, and no per-slice filtered command can see it. Eight stale snapshots were sitting at
HEADwhen the seventh slice started — three from parts, three from root, two from disabled — because an earlier slice had added hover and focus classes to the card root and never re-ran its siblings.The author's own summary: "the narrower I made the seam, the blinder it got."
It surfaced only because a later slice happened to run a broad enough check.
What the validation does and does not do
The Nyquist map validates that every issue has a
test_command. Nothing checks whether the set of commands can see a cross-slice regression. A complete set of individually-correct commands can be collectively blind, and this run produced exactly that.The second consequence, in the Consumer
The same pressure fragmented the Storybook organisation — one component split into five story files so each slice could filter on one. See the output-organisation issue; they are two ends of one problem.
The open question
Should a slice's
test_commandbe allowed to be narrow at all, or should the narrow command be an addition to a broad one that always runs? And what would a validation of the set rather than each member actually check?Full evidence:
docs/research/2026-08-31-dlc-run-2-findings.md.