bug(unic-archon-dlc): nothing steers a Consumer's story and control organisation, so each run invents one

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.

Read docs/research/2026-08-31-dlc-run-2-findings.md, then check ADO 43018 in DXP-DesignSystem before starting. Trace how the Consumer's organisation decision could reach /specs and /tickets, and resolve whether it belongs in config.yaml, the Consumer's design-conventions doc, or the contract. Done means runs follow the recorded organisation instead of inventing one.