docs/usecases.md

Use Cases

Clean product one-liner: this repo should answer “what is the shipped control product, what slice does the work belong to, and what is the next bounded move?”

First Product Slice

Use case	Input	Output
migration brief	source registry + hotgraph	one destination recommendation
control scorecard	local benchmark artifacts	one layered scorecard
runtime split plan	shell/kernel/workbench candidates	one move matrix
conversational API pack	control language + graph state	one front-door contract
orchestrator UX pack	API contract + operator tasks	one operator surface brief
quickstart pack	source summaries + use cases	one operator-facing brief

Acceptance bar

The first slice passes if a user can:

1. run the hotgraph builder
2. inspect one summary file
3. answer where a new piece of work should live
4. place that work into one local product slice
5. generate one bounded control packet from that answer

What not to do

• do not merge the source repos physically first
• do not build a UI first
• do not treat raw docs as the reasoning surface
• do not add another giant runtime here
• do not treat benchmarks, API, or orchestrator UX as secondary