tabletoplisted

# Tabletop (use-case exercise) **Goal:** walk one concrete journey the way a user lives it and record every point where the documentation, the CLI, a hook, a gate or CI disagree. Tests assert expectations someone already had; a tabletop walks the composition and asks, at each step, whether what the doc says matches what happens. **Input:** a scenario slug from `docs/internal/METHOD/TABLETOP-SCENARIOS.md`, or a free-text use case — slugify it (`^[a-z0-9]+(-[a-z0-9]+)*$`) and supply the five fields yourself. **Evidence only.** A tabletop never modifies the repository: no edits, no commits, no generated files, no `--fix`, no issue opened mid-walk. A step that would write is executed as `--dry-run` or described and left unrun. --- ## Step 1 — Open the scenario State, before walking: **persona**, **starting state**, **goal**, **the docs the user would read** (real paths), **the exit criterion**. Pin the tree: `git rev-parse HEAD`. ## Step 2 — Walk the journey in character Narrate each step in the first person as the persona — what they want, what they type, what they see. At every step do all three: - **(a) Execute** what is safely executable read-only or dry-run: `arbiter <cmd> --dry-run`, `<cmd> --help`, rendering a template with the project's config, reading the doc the user would read, running an existing check. Never a mutating command. - **(b) State the promise** — quote what the documentation says happens here, with `path:line`. - **(c) Record observed vs pro