What was measured
Two runs, same command version, produced two different Storybook organisations:
run 1 badge-main · card-profile-main · card-with-badge · icon/interface/User2 4 story files
run 2 badge-main · card-profile-main/{composed,disabled,parts,root,states} 7 story files
· icon/interface/User2
An earlier take also produced screenshot.png where another produced screenshot.generated.png, from the same command version.
Nothing documents what the organisation should be, so each run invented one.
The cause is not style, and this is the useful part
Run 2's five-way split was forced by the ticket slicing. Each slice needed its own filtered test_command, so each got its own story file. That is the same root cause as the eight stale snapshots the build hit: the narrower the per-slice seam, the more the story files fragment.
So this issue and the cross-slice-seam issue are two ends of one problem. Fixing the seam design removes the pressure that split one component five ways.
What the Consumer decided
The maintainer compared both Storybooks side by side and chose run 1's. That is being recorded as an ADR in the Consumer, ADO 43018, with taxonomy COMPONENTS/… and ICON/….
This issue is the plugin half: how does a Consumer's organisation decision reach /specs and /tickets, so that a run does not invent a third one?
Blocked by
ADO 43018 in DXP-DesignSystem. No native link exists across trackers — check it before starting.
The open question
Is this a config.yaml value, a convention in the Consumer's design-conventions doc, or something the contract itself carries?
Full evidence: docs/research/2026-08-31-dlc-run-2-findings.md.
What was measured
Two runs, same command version, produced two different Storybook organisations:
An earlier take also produced
screenshot.pngwhere another producedscreenshot.generated.png, from the same command version.Nothing documents what the organisation should be, so each run invented one.
The cause is not style, and this is the useful part
Run 2's five-way split was forced by the ticket slicing. Each slice needed its own filtered
test_command, so each got its own story file. That is the same root cause as the eight stale snapshots the build hit: the narrower the per-slice seam, the more the story files fragment.So this issue and the cross-slice-seam issue are two ends of one problem. Fixing the seam design removes the pressure that split one component five ways.
What the Consumer decided
The maintainer compared both Storybooks side by side and chose run 1's. That is being recorded as an ADR in the Consumer, ADO 43018, with taxonomy
COMPONENTS/…andICON/….This issue is the plugin half: how does a Consumer's organisation decision reach
/specsand/tickets, so that a run does not invent a third one?Blocked by
ADO 43018 in
DXP-DesignSystem. No native link exists across trackers — check it before starting.The open question
Is this a
config.yamlvalue, a convention in the Consumer's design-conventions doc, or something the contract itself carries?Full evidence:
docs/research/2026-08-31-dlc-run-2-findings.md.