SPEC v0.3: orchestrator resolutions of the plans' open points

Records D-004 and D-015 to D-025: shells and ownership, server seams
(router middleware, rate_limit layer, tasks::start, AuditWriter and PushQueue
traits, next_occurrence_date in kvitt-domain, M3 owns recurring generation,
M4 lands after M3), OpenAPI parsed-value equality, feature convention and
strings, empty fake scenario and resolveRange exception, shared ledger rows and
editor fields in :core:design, no bundled font, pruning at 04:00, development
infrastructure as M2c-dev built it, M2c-pi allowances, release keystore,
production import procedure. Plans and prompts close their open points;
HANDOFF rewritten to the real state; CLAUDE.md: implementation agents never
edit SPEC.md or docs/decisions.md.

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

docs/HANDOFF.md

@@ -3,42 +3,41 @@
 Living document, rewritten in place (never a second copy). A new orchestrator session reads CLAUDE.md, then this.
 
 ## 1. Where things stand
-- `main` at `8bef22a` (root commit "Scaffold: agent starter kit (seeded from Ebb)"). No gate yet: neither `android/` nor `server/` has a project.
-- Branch `agent-spec` (on top of `main`, not landed): `SPEC.md` v0.1, filled `CLAUDE.md`, Gradle files moved to `android/`, tool scripts adjusted.
+- `main` at `c885aba` (M2c-dev) on top of `5e1be38` (plans, prompts, SPEC v0.2); after this docs change lands, `main` also carries SPEC v0.3 (branch `agent-spec3`). Landed: M0 spec, M1 contracts and vectors (`c6df2ab`), M2c-dev infra for development (`c885aba`). No server or Android project yet, so neither gate runs.
+- Worktrees in flight under `.claude/worktrees/`: `agent-m2a` (M2a server skeleton and `kvitt-domain`), `agent-m2b` (M2b Android skeleton and `:domain`), `agent-spec3` (this docs change: SPEC v0.3, D-004, D-015 to D-025). Both M2 agents started from `5e1be38`; their briefs carried the orchestrator's resolutions that v0.3 now records.
+- The owner runs the UX sprint (U1, then U2) in a separate Claude session in the worktree `~/orca/workspaces/kvitt/UX-sprint` on branch `UX-sprint` (based on `cab3e93`, SPEC v0.1); it commits only under `docs/ux/` and rebases on `main` before landing.
+- Development infrastructure exists (M2c-dev): `infra/dev/` compose stack on the Mac (server and on-demand backup, no Caddy, no TLS), Firebase on project `kvitt-1337` with Android apps `se.hagstedt.kvitt` and `se.hagstedt.kvitt.debug`, service account `kvitt-fcm` with `roles/firebasecloudmessaging.admin`; `infra/secrets/fcm-service-account.json` and `infra/secrets/google-services.json` in the main checkout (git-ignored). The dev stack's health check from the phone is a HUMAN step and waits for M2a's image.
 - Installed on the owner's phone: nothing.
-- **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-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).
+- Land `agent-spec3` (orchestrator): SPEC v0.3, decisions D-004 and D-015 to D-025, plans and prompts with every open point closed, CLAUDE.md numbering rule (implementation agents never edit SPEC or decisions).
+- Then record M2a's and M2b's proposed decisions from their reports (D-005 to D-014, including D-010 the screenshot tool) through a docs agent (orchestrator).
+- Plans (SPEC §11.2 v0.3), in dependency order; prompt `prompts/<id>.md`:
+  - M1 Contracts and vectors: landed (`c6df2ab`).
+  - M2c-dev Infra for development: landed (`c885aba`); outstanding: phone `/health` check (owner) once M2a's image exists.
+  - U1 UX directions: owner's session (`UX-sprint`), in progress; owner then picks a direction.
+  - U2 UX design spec: owner's session (`UX-sprint`), after U1 and the pick; owner approves; then the §9.7 colour change goes into the spec (docs agent) before M6.
+  - M2a Server skeleton and `kvitt-domain`: agent in flight (`agent-m2a`).
+  - M2b Android skeleton and `:domain`: agent in flight (`agent-m2b`); plug the phone in once for `installDebug` (owner).
+  - M3 Server core API: after M2a.
+  - M4 Server sync, audit, push, scheduler: after M2a, lands after M3 (D-015).
+  - M5 Android data layer: after M2b.
+  - M6 Design system: after U2 approved, M2b and the §9.7 colour change.
+  - M7a to M7f Features: after M6, in parallel.
+  - M9 Splitwise importer: after M2a and M4.
+  - M8 App integration: after M3, M4, M5, M7a to M7f, M2c-dev.
+  - M2c-pi Infra on the Pi: after M8, before M10 (owner: answer OQ-3, grant the Pi, Home Assistant Pi, Gitea and Drive allowances at the start, D-023).
+  - M10 First release: after M2c-pi, M3, M4, M8 (owner: keystore per §10.6).
+  - M11 Import history: after M9 and M10.
 
 ## 3. Owner questions (asked, unanswered)
-- OQ-1 Local container registry address, HTTP or HTTPS, credentials (SPEC §12).
-- OQ-2 Splitwise CSV format confirmed against a real export, group list and target account names, non-SEK rows (SPEC §12).
-- OQ-3 LAN addresses and SSH users of the Kvitt Pi and the Home Assistant Pi; certificate directory on the HA Pi; which SSH add-on (SPEC §12).
-- OQ-4 Google Drive folder id for backups (SPEC §12).
+- OQ-3 LAN addresses and SSH users of the Kvitt Pi and the Home Assistant Pi; SSH port of the HA Pi; certificate directory there; which SSH add-on (SPEC §12). Needed by M2c-pi only. (OQ-1, OQ-2, OQ-4 are answered: D-001, D-003, §10.9.)
 
 ## 4. Paused (waiting on something outside the repo)
+- M2c-dev phone health check: waits for M2a's server image.
 
 ## 5. Numbering
-Next free: D-001 (no decisions logged yet; the interview decisions are in SPEC v0.1 itself). SPEC v0.1 is written; the next spec version is v0.2. Schema version 1 is defined in SPEC §14.1 (not yet implemented); the next schema version is 2. Sync protocol 1, push payload 1.
+Next free after `agent-spec3`: decision **D-026** (D-001 to D-004 and D-015 to D-025 are used; D-005 to D-014 are reserved for the M2a and M2b agents' proposals, D-010 being the screenshot tool). Spec version: v0.3 written; next **v0.4**. Schema version **1** (defined, not yet implemented); next schema version **2**. Sync protocol **1**, push payload **1**.
 
 ## 6. How the work is run
 See CLAUDE.md › Orchestration. HUMAN steps in reports are relayed in chat by the orchestrator; the owner does not