hamid
6.1 KiB
Roadmap — where it goes next
Last verified: 2026-08-02 against commit
cd8144e. Populated by phase 5 of the documentation clean-up chain.
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, 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 | 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 | What to build next, and why that and not something else | Yes — 5 units, sequenced by the principle below |
| 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 | 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.
The proposed order — this phase's proposal
| # | Unit | Category | Closes (blockers) | Size |
|---|---|---|---|---|
| 1 | Nurse verification stops lying about status | 1 — trust lie | BL-010 | L |
| 2 | Checkout stops lying about money and time | 1 — money lie | BL-006 | M |
| 3 | Admin RBAC: give seeded admins the claim the code checks for | 2 — unusable | BL-001, BL-002 | M |
| 4 | De-mock refunds and BNPL | 3 — mocked→real | BL-007, BL-008, BL-009 | L |
| 5 | De-mock nurse payouts | 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. 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 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. 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: 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's own trigger named this phase directly
("phase 5 verification pass"), so it was executed rather than deferred again — see
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 and 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
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 if a launch date is what's driving the decision. If neither fits, tech-debt.md names what's quietly getting more expensive, and 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.