Parent: #588 — step 1 of 8.
Problem
Visual testing cannot find a single component in any current library. The harness being ported discovers specs with a flat read of the specs directory, keeping any child that holds an api.yaml. Under ADR-096 the children are components/ and compositions/, neither of which holds one, so discovery returns nothing. It still works against exactly one library, and only because that library is the last one in the pre-ADR-096 flat layout.
Contract resolution has the matching problem: it looks only under the React tree's components directory, which no composition will ever be under, and derives the directory name by capitalizing the first character rather than the way the emitters name it.
Separately, baselines are stored under a flat key. A component and a composition sharing a name is legal — the version assembler already keys the two kinds separately for exactly this reason — so a flat key silently overwrites one kind's baseline with the other's.
This is step 1 because nothing downstream can be validated until discovery works, and because it establishes the keying every later step writes against. Doing it later means rewriting all of them.
Potential solution(s)
- Spec discovery and contract resolution both go through the layout seam, which is documented as the only thing that knows the layout — after two divergent filters preceded it and a third kind had nowhere to go.
- Baseline, render and diff trees all key by kind before key, and the report carries the kind per entry.
- The harness's own workspace-resolution module is deleted rather than ported:
storybook/workspace.ts already resolves root, specs, data sources, emitted trees and scaffold state.
Acceptance criteria
Case data
Notes
Depends on nothing. Blocks every other step in #588.
Parent: #588 — step 1 of 8.
Problem
Visual testing cannot find a single component in any current library. The harness being ported discovers specs with a flat read of the specs directory, keeping any child that holds an
api.yaml. Under ADR-096 the children arecomponents/andcompositions/, neither of which holds one, so discovery returns nothing. It still works against exactly one library, and only because that library is the last one in the pre-ADR-096 flat layout.Contract resolution has the matching problem: it looks only under the React tree's components directory, which no composition will ever be under, and derives the directory name by capitalizing the first character rather than the way the emitters name it.
Separately, baselines are stored under a flat key. A component and a composition sharing a name is legal — the version assembler already keys the two kinds separately for exactly this reason — so a flat key silently overwrites one kind's baseline with the other's.
This is step 1 because nothing downstream can be validated until discovery works, and because it establishes the keying every later step writes against. Doing it later means rewriting all of them.
Potential solution(s)
storybook/workspace.tsalready resolves root, specs, data sources, emitted trees and scaffold state.Acceptance criteria
Case data
Notes
Depends on nothing. Blocks every other step in #588.