hamid/baya-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

cleanup phase 5

Browse Source
This commit is contained in:
hamid
2026-08-02 18:33:43 +03:30
parent cd8144e653
commit e2db97392a
9 changed files with 818 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/roadmap/index.md
+79 -18
View File
@@ -1,27 +1,88 @@
# Roadmap — where it goes next
> **Populated by phase 5 — not yet written.** Phase 5 depends on phase 4: you cannot sequence work
> that has not been reconciled into one backlog.
> 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/index.md), so nothing is
scheduled that was not first triaged.
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.
## Planned contents
**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.
| File | Covers |
| --- | --- |
| `next-up.md` | The next 3–5 units of work, each spec'd enough to start |
| `deferred.md` | Recorded, each with the trigger that pulls it forward |
| `tech-debt.md` | What must be paid before scale, and what deferring it costs |
| `pre-launch.md` | The hard gate before real users touch this |
## The four documents
## One item already known for `pre-launch.md`
| 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.
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** change: `Seams:FieldEncryption:Key` and `:HashKey` decrypt
every encrypted column and derive the `PhoneHash` that every login looks up. Rotating them locks every
account out.
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.