Your "what next?" has no answer because Mockup Lab is organised around its own nouns (units, screens, takes, boards), while the questions you bring are the ones Design Studio already answers: how the product opens, the loop, the paths a player takes, and the screens those paths need. Peregrine has all four, fully generated and approved. The proposal is to make that experience model the project's living spine. Design Studio produces it. The project owns it. Mockup Lab keeps it true to the app as mockups arrive and screens get built, and "what next" becomes that spine's own gaps.
What exists today, side by side
Design Studio: Peregrine's session (835383E3)
First Contact: 6 beats, from "No Test, No Verdict" to "Load Your Own Ammo", each naming the screen it happens on. Core Loop: The Pull → The Act → The Payoff → The Deposit, with investment the strongest node and the trigger the weakest. Task Flows: 4 critical paths, and each of their 17 steps names its screen, which answers "how does a player get around". Screen Registry: 18 screens in Core, Important and Secondary tiers, including The Training Ground, The Wager, The Lineup (Game) and Beat the Shakedown. Mockups: 18 approved, one per registry screen, linked by id.
Mockup Lab: Peregrine's registry
30 units and 47 screens, seeded from filenames. It has 5 flows and 7 links (today's placement). It holds the files in docs/mockups/, their takes and states, and built status. It shares no data with Design Studio. A grep of Mockup Lab for any Design Studio type returns nothing, and Design Studio's mockups never reach docs/mockups/.
The handoff was meant to give the project its spine
At handoff, Design Studio stages firstContact.json, coreLoop.json, taskFlows.json and screenRegistry.json plus every mockup, and the prompt tells the build session to copy them into the project's .claude/experience/ and .claude/mockups/. For Peregrine they sit staged in ~/.claude/handoffs/D4A154F9…/. They were never copied, and taskFlows.json is missing from the staging. Mockup Lab was then built without knowing any of this existed.
Only one link in its chain is a real id
Mockup → screen is by id. Flow step → screen is free text, and only 8 of the 17 step screens match a registry name exactly ("Warm Return Home / The Gallery" matches nothing). No registry entry's flow reference matches a real flow name. Any spine built on this needs a one-time, reviewed resolution of names to ids.
The proposed shape
1 · One spine, owned by the project
The project keeps .claude/experience/{firstContact,coreLoop,taskFlows,screenRegistry}.json, the files the handoff already writes, in Design Studio's own schema. Design Studio produces them. Mockup Lab reads and writes them from then on. A project that never went through Design Studio gets the same four files generated from its spec and mockups, so every app has the same spine.
2 · Mockup Lab opens on the same movements, re-entrant
Tabs for First Contact · Core Loop · Task Flows · Screens, then Boards, in Design Studio's grammar. Every card arrives filled in, each has a revise bar, and there's a "Next:" stepper and an "N of M reviewed" count. It is not a one-way wizard: an app in development keeps returning to any of them.
3 · A screen is a registry entry, carrying its takes
Screens are Design Studio's registry entries with their Core, Important and Secondary tiers. Each one carries what Mockup Lab already knows how to hold: takes (docs/mockups/ files and Design Studio's mockup), variants, states and built status. Units remain as a grouping tag ("game: Lineup") and stop being the top-level navigation.
4 · Task Flows are the map of how a player moves
Each step points at a screen by id, set once through a reviewed resolution of today's names. Ways in follow from the flows: step N's screen leads to step N+1's, and "Shares steps with" joins flows together. Hand-added links remain for routes no flow covers, such as the Training hub's tiles. A board renders a flow as its screens in order.
5 · A new mockup asks: which screen, and which step?
Placement answers against the registry and the flows instead of inventing structure. The Glass That Never Broke becomes "a new take on The Lineup (Game)? a step in The Daily Sport?" and not a free-floating screen.
6 · "What next" is the spine's own gaps
A step with no screen. A screen with no take. A screen no flow reaches. A file in docs/mockups/ that belongs to no screen. A core screen that isn't built yet. Each gap names its fix, and fixing it closes it. This replaces the readiness strip's fixed checklist.
What happens to what's already built
Kept as is: the frame contract and declaring states; boards and the renderer; the cohesion review and canon; the placement reading (pointed at the spine); new takes; cost labels; all of Phase 0's fixes.
Reshaped: Mockup Lab's own registry of units and screens gets reconciled into the spine's registry entries. The readiness strip becomes the gap list. Screen links mostly derive from flows. The Registry and Boards tabs fold into the movements.
The honest cost: Peregrine's 47 Mockup Lab screens have to be reconciled with Design Studio's 18. Many match directly (Case Board, The Wager, Beat the Shakedown, Undercover Gauntlet). Some are real screens Design Studio never had (the Acts, individual games). A few are takes of the same screen. That's one reviewed pass, shaped like the seeding review you've already used.
Decisions for you
Where the spine lives
Recommended: the project's .claude/experience/ files. They're the destination the handoff already targets, they're owned by the repo, and Mockup Lab can edit them. Alternatives: read Design Studio's session live, which clashes with its locked, branch-to-edit phases after handoff; or copy Design Studio into Mockup Lab's registry, which keeps two schemas and the drift you have now.
Whose names win when the two registries disagree
Recommended: Design Studio's entries are the frame, with Mockup Lab screens mapped onto them as takes, and added as new entries where Design Studio never had them. The Lineup (Game), for example, would collect Round View and Behind Glass as its takes or states, or you'd mark them as genuinely separate screens.
After handoff, who edits the experience?
Recommended: Mockup Lab, for apps in development. Design Studio stays the pre-build tool, and its session becomes history. Branching from it after handoff would fork away from the project's living copy.
Risks
This is the third reshuffle of Mockup Lab's navigation
Worth doing only if the spine is right. That's why this page comes before any code. A sketch you can click through should come next, before building.
Design Studio has no units
Peregrine's 21 games matter as a grouping. A unit tag on each registry entry covers it, but Design Studio's own views wouldn't show it.
Name resolution is the weak joint
8 of 17 steps match by name today. The one-time resolution has to be reviewed, not assumed, or the flows will point at the wrong screens with confidence.
Final review
The direction is well founded. You named the structures that work. The data already exists for Peregrine, fully approved. And the handoff was designed to put exactly this in the project, which explains why the parallel registry felt like data entry: it was rebuilding by hand, from filenames, what Design Studio had already generated. The weakest part is the reconciliation, 47 screens against 18, with weak name joins, and the plan stands or falls on that review being quick to get through. The work since Phase 0 keeps its value: states, boards, placement and cohesion all attach to registry entries as cleanly as they attach to Mockup Lab's screens.
High on the direction, and lower on the cost of reconciling Peregrine and on whether re-entrant movements feel as clear as Design Studio's one-way pass. A clickable sketch would settle that second question cheaply.