# Flows — what is implemented, and how to test it

> **Populated by phase 3 — not yet written.** It is the biggest phase in the chain (2–4 sessions).
> Until then the closest things are [manual-testing-plan.md](../../dev/post-phase/manual-testing-plan.md)
> and [RUNBOOK.md](../../dev/post-phase/refinement/RUNBOOK.md) — both partly stale, see below.

One file per **user-meaningful journey**, not per screen. Each answers three questions and no others:
what it does, what is real versus mocked, and the exact steps to walk it against a running stack.

This page becomes the **status table** — every flow, one row, with its `Last verified` date. It is the
page you check before believing anything else in `docs/`.

## Planned contents

| File | Covers |
| --- | --- |
| `testing-setup.md` | Bring-up, demo accounts, the seeded world, OTP retrieval, reset, troubleshooting |
| `<flow>.md` × ~23 | One per journey — the candidate list is in [phase 3](../_plan/phase-3-flow-atlas.md) |

## Before writing testing-setup.md

Four contradictions land squarely on the bring-up story, and phase 3 has to settle them rather than
copy either source. All are logged in [_plan/open-contradictions.md](../_plan/open-contradictions.md):

- **C-1** — `manual-testing-plan.md` still tells you to set crypto keys via `dotnet user-secrets`, which
  was removed in `5885280`. **`RUNBOOK.md` is already correct on this**; only the one file is stale.
- **C-3** — the API listens on `http://localhost:5002`, not `https://`, in 18 places' worth of prose.
- **C-4** — the `dotnet dev-certs https --trust` step therefore has nothing to trust.
- **C-5** — `RUNBOOK.md` starts a **local** SQL Server in Docker; the committed dev config points at a
  **remote** one. These are not the same world: the remote DB is already seeded, a fresh local one is
  not, and its data is encrypted under keys that must match exactly.

Pick one bring-up path, verify it end to end, and say plainly what the other one was.