# Roadmap — where it goes next

> Last verified: 2026-08-02 against commit `cd8144e`. Populated by phase 5 of the
> [documentation clean-up chain](../../archive/clarify-chain/README.md).

A **proposal**, not a commitment. The ordering is reasoned and can be overruled; what is not negotiable is
that every item traces to a `BL-###` in [status/backlog.md](../status/backlog.md), so nothing here was
invented — it was triaged first, in phase 4.

**This page marks its own judgement calls.** Two kinds of claim appear below: **recorded** (came from
`backlog.md`, `CLAUDE.md`, `DEPLOY.md`, or a `product/` decision — check the source, not this page's
reasoning) and **proposed** (this phase's own synthesis — the ranking, the grouping into units, the sizing).
Where the two could be confused, it's labeled.

## The four documents

| File | Answers | Ordered? |
| --- | --- | --- |
| [pre-launch.md](pre-launch.md) | What must be true before real money moves | Yes — but it's a **gate**, not a priority list. Everything in it blocks launch; none of it is optional |
| [next-up.md](next-up.md) | What to build next, and why that and not something else | Yes — 5 units, sequenced by the principle below |
| [deferred.md](deferred.md) | What's deliberately not being built, and what would change that | No — a record, picked up by its own trigger, not a schedule |
| [tech-debt.md](tech-debt.md) | What's getting more expensive the longer it waits | No — each item has its own trigger; not a queue |

---

## The sequencing principle

**Recorded** — stated in the phase brief that produced this roadmap, not derived by this phase:

> The product's own promise is trust-first and money-holding. So the order is (1) anything that makes a
> *money or trust* flow lie to a user, (2) anything that makes a built flow unusable, (3) anything that makes
> a mocked flow real, (4) new surface area.

This principle was given, not derived — it isn't this phase's invention. **Applying it to the actual 262 open
backlog items** — which item is a "lie" versus merely "unusable," which five units to carve out of 86 major
items, how to size each — **is this phase's proposal**, in [next-up.md](next-up.md).

## The proposed order — **this phase's proposal**

| # | Unit | Category | Closes (blockers) | Size |
| --- | --- | --- | --- | --- |
| 1 | [Nurse verification stops lying about status](next-up.md#unit-1--nurse-verification-stops-lying-about-verification-status) | 1 — trust lie | BL-010 | L |
| 2 | [Checkout stops lying about money and time](next-up.md#unit-2--checkout-and-the-payment-window-stop-lying-about-money-and-time) | 1 — money lie | BL-006 | M |
| 3 | [Admin RBAC: give seeded admins the claim the code checks for](next-up.md#unit-3--give-the-seeded-admins-the-claim-the-code-already-checks-for) | 2 — unusable | BL-001, BL-002 | M |
| 4 | [De-mock refunds and BNPL](next-up.md#unit-4--de-mock-refunds-and-bnpl-onto-the-server-thats-already-built) | 3 — mocked→real | BL-007, BL-008, BL-009 | L |
| 5 | [De-mock nurse payouts](next-up.md#unit-5--de-mock-nurse-payouts-including-the-one-action-with-no-ui-at-all) | 3 — mocked→real | BL-012, BL-016 | L |

**One tension, stated plainly rather than hidden:** unit 3 (RBAC) has zero prerequisites and unlocks more
downstream work than any other single item — 11 of 14 business areas, per
[implemented.md](../status/implemented.md#cross-cutting-the-rbac-finding). A reader who weighs "unlocks the
most" above "is technically a lie versus merely unusable" would be right to run it first. It's ranked third
here because the stated principle was applied literally. **This is exactly the kind of call this document
exists to make visible and overridable** — see [next-up.md](next-up.md) for the full reasoning per unit,
including two strong candidates (patient/care records, partner-center) that didn't fit the 3-5 slot cap and
are named as the next two in line.

Running in parallel with all five, on its own track: everything in [pre-launch.md](pre-launch.md). None of it
is feature work, so none of it competes with the units above for the same engineering time in the same way —
but none of it is optional before real users arrive, regardless of which unit above ships first.

## What we're not doing, and why — pointer

The standing answer to "what are we not doing" is [deferred.md](deferred.md): **51 items** (43 recorded as a
themed group in `backlog.md`, 8 more filed by severity elsewhere but also carrying deferred status), each with
the trigger that would pull it forward, plus the **8 unbuilt product tables** named individually. None of them
were re-decided here — phase 5's job was to record them faithfully, not re-litigate phase 4's or `product/`'s
calls. The one exception: [BL-245](../status/backlog.md#deferred-43)'s own trigger named this phase directly
("phase 5 verification pass"), so it was executed rather than deferred again — see
[decisions.md](../status/decisions.md) for the finding.

## One item already known for `pre-launch.md` — **recorded**, from root CLAUDE.md and DEPLOY.md

The repo **contains live credentials on purpose** — a deliberate pre-launch trade for a demo deployment,
documented in [root CLAUDE.md §6](../../CLAUDE.md) and [DEPLOY.md](../../DEPLOY.md). Before onboarding real
users those values must be rotated and the secret half moved out of git.

One value is load-bearing and must **never** be rotated in place: `Seams:FieldEncryption:Key` and `:HashKey`
decrypt every encrypted column and derive the `PhoneHash` every login looks up. Changing them without a
migration locks every account out — [pre-launch.md §1](pre-launch.md#1-rotate-the-committed-credentials)
spells out what that migration actually requires, since "never change it" and "never be able to change it"
are different problems.

## How to use this page

Pick the next piece of work from the table above, or from [pre-launch.md](pre-launch.md) if a launch date is
what's driving the decision. If neither fits, [tech-debt.md](tech-debt.md) names what's quietly getting more
expensive, and [deferred.md](deferred.md) names what's already been decided against — check there before
proposing something new, since it might already have a recorded reason and a trigger.
