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