Plans and start prompts for every milestone; SPEC v0.2

PLAN-<id>.md for U1, U2, M1, M2a, M2b, M2c-dev, M2c-pi, M3, M4, M5, M6,
M7a-M7f, M8, M9, M10, M11, each with the eleven fixed sections, and a
start prompt per plan in prompts/ plus prompts/README.md (dependency
order and parallel waves).

SPEC v0.2: owner answers D-001 (development-first, M2c split into
M2c-dev and M2c-pi, Gitea registry), D-002 (local backups deleted once
on Drive), D-003 (Splitwise CSV format, English and Swedish variants,
category mapping), OQ-1, OQ-2, OQ-4 answered; M1's readings of
ambiguous contract points stated explicitly in §14.3 to §14.5.
HANDOFF §2 lists the plans.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/HANDOFF.md

@@ -9,10 +9,25 @@ Living document, rewritten in place (never a second copy). A new orchestrator se
 - **Bootstrap exception (2026-10-17):** the repository had no commits, so the normal worktree flow could not start. The spec agent created the root commit directly in the main checkout (stray `.DS_Store` files deleted, `.DS_Store` added to `.gitignore`), then branched `agent-spec` there. From now on the normal flow of CLAUDE.md › Orchestration applies.
 
 ## 2. Open work (one line each, with who owns it: agent or owner)
-- Land `agent-spec` (orchestrator).
-- Plans agent: write `PLAN-*.md` and a start prompt per plan in `prompts/` from SPEC §11 (M1, M2a, M2b, M2c, M3, M4, M5, M6, M7a-M7f, M8, M9, M10, M11, U1, U2).
-- UX agent: U1 UX directions (SPEC §13), in parallel with M1. Owner reviews the directions before U2 and before any UI work.
-- Owner: answer SPEC §12 OQ-1 to OQ-4 (needed by M2c and M9).
+- Land `agent-plans` (orchestrator): SPEC v0.2 (D-001 to D-003), one `PLAN-<id>.md` per milestone and a start prompt each in `prompts/`, dependency order in `prompts/README.md`.
+- Plans (SPEC §11.2 v0.2), in dependency order; prompt `prompts/<id>.md`:
+  - M1 Contracts and vectors: landed (`c6df2ab`); `PLAN-M1.md` on record.
+  - U1 UX directions (owner's session, branch `agent-ux`): `PLAN-U1.md`, can start now. Owner then picks a direction.
+  - U2 UX design spec (owner's session, branch `agent-ux`): `PLAN-U2.md`, after U1 and the owner's pick. Owner approves.
+  - M2a Server skeleton and `kvitt-domain`: `PLAN-M2a.md`, ready (needs its open points settled in the brief).
+  - M2b Android skeleton and `:domain`: `PLAN-M2b.md`, ready (needs its open points settled in the brief).
+  - M2c-dev Infra for development: `PLAN-M2c-dev.md`, ready (owner: `gcloud auth login`, `firebase login`).
+  - M3 Server core API: `PLAN-M3.md`, after M2a (decide the M3/M4 recurring-generation coupling first).
+  - M4 Server sync, audit, push, scheduler: `PLAN-M4.md`, after M2a.
+  - M5 Android data layer: `PLAN-M5.md`, after M2b.
+  - M6 Design system: `PLAN-M6.md`, after U2 approved, M2b, and the §9.7 colour spec change.
+  - M7a to M7f Features (onboarding, home and account, expense, settle, analytics, settings): `PLAN-M7a.md` to `PLAN-M7f.md`, after M6, in parallel.
+  - M9 Splitwise importer: `PLAN-M9.md`, after M2a and M4.
+  - M8 App integration: `PLAN-M8.md`, after M3, M4, M5, M7a to M7f, M2c-dev.
+  - M2c-pi Infra on the Pi: `PLAN-M2c-pi.md`, after M8, before M10 (owner: answer OQ-3).
+  - M10 First release: `PLAN-M10.md`, after M2c-pi, M3, M4, M8.
+  - M11 Import history: `PLAN-M11.md`, after M9 and M10.
+- Owner: answer SPEC §12 OQ-3 (needed by M2c-pi only).
 
 ## 3. Owner questions (asked, unanswered)
 - OQ-1 Local container registry address, HTTP or HTTPS, credentials (SPEC §12).

docs/decisions.md

@@ -5,3 +5,6 @@ entry and the old one a strike-through plus a pointer. The spec is updated in th
 
 | # | Date | Decision | Why | Where it lives |
 |---|---|---|---|---|
+| D-001 | 2026-10-17 | Development-first deployment. During development the server runs locally on the owner's M4 Mac (Docker compose `infra/dev/compose.yaml` or `cargo run`) and debug builds pair against it over the home Wi-Fi. M2c splits into M2c-dev (Mac compose stack, Firebase setup, local backup job; runs now) and M2c-pi (Pi provisioning, cert-sync, router forward 8443, Gitea registry and Gitea Actions, Drive backups; after M8, before M10). The registry is Gitea at `http://gitea.lan` (plain HTTP, home Wi-Fi only); the owner provides an example Gitea Actions workflow later. OQ-1 answered; OQ-3 now blocks only M2c-pi. | Owner wants to develop against a local server and defer the Pi. | SPEC §10 (intro, §10.1, §10.3, §10.7), §11.1, §11.2, §11.3, §12, §14.7; PLAN-M2c-dev, PLAN-M2c-pi |
+| D-002 | 2026-10-17 | Backup retention on the Pi: local snapshot files are deleted as soon as their upload to Drive is confirmed (`rclone lsf`), not after 30 days. Drive keeps everything. | Owner's choice; the Pi's disk is small and Drive is the archive. | SPEC §10.9 step 5; PLAN-M2c-pi |
+| D-003 | 2026-10-17 | Splitwise CSV format confirmed from two real exports (OQ-2 answered). English variant header `Date,Description,Category,Cost,Currency,Amelie Bennich,Jacob Hagstedt` (group "hemma", account "Hemma"); Swedish variant header `Datum,Beskrivning,Kategori,Kostnad,Valuta,Jacob Hagstedt,Amelie Bennich` (general group, account "Vardag", about 1750 rows). Member columns differ in order, so the importer reads member names from the header. ISO dates, point decimal, double-quoted fields with commas, trailing empty line then `Total balance` / `Totalsumma`. Payment category `Payment` / `Betalning`. All rows SEK. Swedish category names are mapped through a committed table (unknown names to `other`, counted as a warning). The partner's display name is Amelie. The CSV files stay in `export/` (git-ignored), never committed or quoted. | Real exports differ by Splitwise UI language. | SPEC §10.8, §12; PLAN-M9 (mapping notes), PLAN-M11 |