# Roadmap — where it goes next > Last verified: 2026-08-02 against commit `cd8144e`. Populated by phase 5 of the > [documentation clean-up chain](../_plan/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.