create mvp path

mvp/blockers.md

@@ -0,0 +1,121 @@
+# Blockers — what has to be fixed before this is a real product
+
+Two different kinds of "blocker" here, and both matter:
+
+- **A. The product itself is broken** — a real user would hit a wall or be shown wrong information, with or
+  without real money involved.
+- **B. The launch gate** — things that must be true before a real stranger with real money is allowed to touch
+  this, even on a day when part A is fully fixed.
+
+Effort is a rough size, not a schedule: **S** = small/contained, **M** = a real but bounded piece of work,
+**L** = a project of its own.
+
+---
+
+## A. The product is broken or unusable
+
+### Admin can't do anything
+- **No admin account can perform a single real admin action.** Every super-admin/finance account gets
+  "access denied" on every real admin screen — approving a nurse, moderating a review, processing a refund,
+  running a payout batch, managing tickets, all of it. The permission system only recognizes one hardcoded
+  role name that nothing ever actually assigns. *(Effort: M)*
+- **On top of that, no demo account holds even that hardcoded role**, so fixing the permission bug alone
+  still leaves nothing to test it with out of the box. *(Effort: S, bundled with the item above)*
+
+  *Why this matters more than it looks: a large share of the other items below — nurse verification,
+  reviews, refunds, payouts, ticket handling — are gated behind this one fix. Fixing admin access is the
+  single highest-leverage thing on this list.*
+
+### Payments
+- **A card payment can never actually complete.** The test/demo payment page redirects to a page that
+  doesn't exist. Nothing about the money logic itself is wrong — it's the very last step, handing off to a
+  real payment provider, that isn't connected. *(Effort: M)*
+- **The 30-minute payment countdown can lie.** Booking deadlines are stored without a timezone, so the timer
+  a customer sees can silently show hours more time than they actually have, and expire while they still
+  think they're fine. *(Effort: S)*
+- **Installment (buy-now-pay-later) payments don't work at all.** No installment plan is ever actually set up
+  behind the scenes, so every attempt fails immediately. *(Effort: S–M, two related issues)*
+- **Refunds are demo-only today.** The refund screens read fake, disconnected sample data; turning that off
+  today would show a refund of the wrong amount (off by a factor of 100) for any real cancellation.
+  *(Effort: M)*
+
+### Trust — nurse verification
+- **A nurse's verification badge does not reflect reality.** The verified/unverified status shown to
+  customers and to the nurse herself comes from a fake demo layer, not the real, already-working
+  verification data underneath. A genuinely verified nurse can show as unverified everywhere in the app, and
+  vice versa — silently hiding the real "you're not searchable yet" warning a nurse needs to see.
+  *(Effort: L)*
+
+### Patient records & visit notes
+- **Everything a nurse writes about a visit, and everything a family sees about a patient's care plan, is
+  fake demo data.** Nothing typed in today is actually saved, and the real backend behind this expects
+  slightly different data than the screens send — so simply "turning the mock off" would break on day one.
+  *(Effort: M)*
+
+### Nurse pay
+- **A nurse's earnings/payout screens show fake numbers**, hiding four features that already work for real
+  underneath. There's also no button anywhere to actually run the "send the money" step — the one
+  irreversible action in the whole payout process has no interface at all — and the "paid" status shown to a
+  nurse can be wrong (it's set as soon as a payout is linked, not when it's confirmed to have gone through).
+  *(Effort: M)*
+
+### Partner / business-center accounts
+- **The whole "partner business center" section is fake, with zero real account matching.** Any signed-in
+  user who opens it resolves to the same one fake center regardless of who they are, and several of its core
+  pages (its own booking list, its own settlement report) don't exist on the server at all yet. This matters
+  more than it sounds — see [forgotten-features.md](forgotten-features.md) for why the business plan leans on
+  this feature specifically. *(Effort: L)*
+
+### Search
+- **Search results aren't de-duplicated nurses — they're raw pricing-option rows.** One nurse with 3 services
+  in 3 areas shows up as "9 nurses." The trust information on a result card is also fake, and a nurse who
+  isn't verified yet can still be opened directly and shown as "verified" if you know her profile link.
+  *(Effort: M)*
+
+### Data safety
+- **Editing a saved home address can silently wipe out the recipient's name and phone number** on every save,
+  because the edit form never collects those fields but the save action clears them anyway. *(Effort: S)*
+
+### Booking lifecycle
+- **A booking whose remaining visits get automatically marked "missed" can get stuck forever** and never
+  reach a state where the nurse can actually be paid for the visits she did complete. The "today's visits"
+  list nurses see is also unfiltered — it shows a nurse's entire history, not just today. *(Effort: M)*
+
+### Reviews
+- **A real review can never actually go live.** It gets submitted and saved correctly, but the approval step
+  that would publish it sits behind the broken admin-access problem above, so nothing ever gets un-stuck.
+  *(Effort: S once admin access is fixed)*
+
+### Catalog / pricing
+- **Outside of the developer's own local setup, there are zero service categories or pricing options
+  configured at all**, and there is no admin page to add them — only direct database editing. Deployed as-is,
+  every "choose a service" screen collapses to a nearly useless two-step form. *(Effort: M)*
+
+---
+
+## B. Before a real stranger's real money touches this
+
+These hold regardless of whether every item in section A gets fixed first.
+
+1. **Rotate every credential currently committed to the codebase** — the database password, both encryption
+   keys, and the API keys for SMS/maps/banking-lookup/bot services. This is a deliberate, known trade made to
+   ship a demo fast; it must be undone before onboarding real users. One of these — the key that encrypts
+   personal data like phone numbers and addresses — can't just be swapped; changing it requires re-encrypting
+   everything already stored under the old one first, so treat that specifically as its own small project,
+   not a quick config edit.
+2. **Turn off developer/debug mode on the live site.** Right now, the deployed site runs in a mode meant for
+   local development. The single biggest consequence: **anyone who knows a person's phone number can read
+   their login code directly from a public link** and sign in as them. This has to be closed before real
+   strangers can reach the site.
+3. **Get real legal review of the Terms of Service and Privacy Policy.** They currently ship as placeholder
+   text behind a visible "draft" banner.
+4. **Finish the real e-invoicing (مودیان) hookup.** The invoice data and tax math are already correct; the
+   actual government-facing integration that registers each invoice isn't wired up yet, and the business plan
+   calls this required, not optional, scope.
+5. **Obtain "e-namad" certification.** This is a business/paperwork step, not a code change — but a monetized
+   Iranian website legally cannot get a real payment gateway without it, so nothing in item 6 below or in the
+   card-payment blocker above can go fully live until this exists.
+6. **Build a real bank-transfer system for paying nurses.** Every other "fake" system in the app (SMS, maps,
+   card payments, identity checks) already has a real version written and just needs real credentials to
+   switch on. Paying nurses is the one exception — there is no real version yet at all. Even after everything
+   else on this page is fixed, **nurses still can't actually be paid** until this is built from scratch.