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>

prompts/README.md

@@ -1,8 +1,8 @@
 # Start prompts
 
-One ready-to-paste start prompt per plan (`PLAN-<id>.md` at the repository root), plus `ORCHESTRATOR-prompt.md`. Before pasting, the orchestrator fills `{{NEXT_DECISION}}`, `{{SPEC_VERSION}}`, `{{SCHEMA_VERSION}}` (disjoint ranges for agents that run in parallel, CLAUDE.md › Numbering) and `{{ORCHESTRATOR_NOTES}}` (answers to the plan's open points, phone assignment, overrides). `U2.md` also takes `{{OWNER_PICK_AND_COMMENTS}}`. U1 and U2 run in the owner's own Claude session on branch `agent-ux`.
+One ready-to-paste start prompt per plan (`PLAN-<id>.md` at the repository root), plus `ORCHESTRATOR-prompt.md`. Before pasting, the orchestrator fills `{{NEXT_DECISION}}`, `{{SPEC_VERSION}}`, `{{SCHEMA_VERSION}}` (disjoint ranges for agents that run in parallel, CLAUDE.md › Numbering) and `{{ORCHESTRATOR_NOTES}}` (answers to the plan's open points, phone assignment, overrides). `U2.md` also takes `{{OWNER_PICK_AND_COMMENTS}}`. U1 and U2 run in the owner's own Claude session in `~/orca/workspaces/kvitt/UX-sprint` on branch `UX-sprint`. The numbers are for proposed entries in agents' reports: implementation agents never edit `SPEC.md` or `docs/decisions.md`; a docs agent records what the orchestrator accepts (CLAUDE.md › Orchestration).
 
-Dependencies follow SPEC §11.1 and §11.2 (v0.2, D-001). Status as of 2026-10-17: M0 done, M1 landed (`c6df2ab`).
+Dependencies follow SPEC §11.1 and §11.2 (v0.3). Status as of 2026-10-17: M0 done, M1 landed (`c6df2ab`), M2c-dev landed (`c885aba`); M2a and M2b in flight; U1 in the owner's session. The plans' open points are resolved in SPEC v0.3 and recorded in each plan's §4.
 
 ## Dependency order and waves
 
@@ -14,10 +14,10 @@ Plans in the same wave can run in parallel (they own disjoint paths, SPEC §14.7
 | 0 | U1 UX directions | `U1.md` | M0 | everything in waves 0 to 2 (owner's session) |
 | 1 | M2a Server skeleton and `kvitt-domain` | `M2a.md` | M1 | M2b, M2c-dev, U1/U2 |
 | 1 | M2b Android skeleton and `:domain` | `M2b.md` | M1 | M2a, M2c-dev, U1/U2 |
-| 1 | M2c-dev Infra for development | `M2c-dev.md` | M0 (its health check needs M2a's image) | M2a, M2b, U1/U2 |
+| 1 | M2c-dev Infra for development | `M2c-dev.md` | M0 (its health check needs M2a's image) | done (`c885aba`) |
 | 1 | U2 UX design spec | `U2.md` | U1 and the owner's pick | M2a, M2b, M2c-dev, wave 2 |
-| 2 | M3 Server core API | `M3.md` | M2a | M4 (see coupling below), M5, M6 |
-| 2 | M4 Server sync, audit, push, scheduler | `M4.md` | M2a | M3, M5, M6 |
+| 2 | M3 Server core API | `M3.md` | M2a | M4 (M4 lands after M3), M5, M6 |
+| 2 | M4 Server sync, audit, push, scheduler | `M4.md` | M2a; lands after M3 (D-015) | M3, M5, M6 |
 | 2 | M5 Android data layer | `M5.md` | M1, M2b | M3, M4, M6 |
 | 2 | M6 Design system | `M6.md` | U2 approved, M2b, the §9.7 colour spec change | M3, M4, M5 |
 | 3 | M7a Feature onboarding | `M7a.md` | M6 | M7b to M7f, M9 |
@@ -34,8 +34,9 @@ Plans in the same wave can run in parallel (they own disjoint paths, SPEC §14.7
 
 ## Constraints the orchestrator must keep in mind
 
-- **M3 and M4 are coupled** through recurring generation (E-28 generates a due period; §9.5 logic, audit writer and push queue are M4's). Decide the interface before starting both (PLAN-M3 open point a, PLAN-M4 open point b), or land M4's generation function first.
-- **M2a and M2b need the stub-file decisions** in their notes before starting (PLAN-M2a open points a to f, PLAN-M2b open points a to g): they create files in directories §14.7 gives to later milestones.
-- **M7a to M7f** need M2b's feature convention (Hilt or not, navigation callbacks) and M6's shared components (ledger rows, expense form fields) settled first.
+- **M3 and M4** (D-015): M2a provides `next_occurrence_date`, the `AuditWriter`/`PushQueue` traits with no-op implementations and `tasks::start`; M3 writes the recurring generation function and calls the traits; M4 replaces the implementations, its scheduler calls M3's function, and M4 lands after M3.
+- **M2a and M2b** create shell files and modules in later milestones' paths (D-004); ownership passes on when they land.
+- **M7a to M7f** follow the feature convention of SPEC §6.2 (D-017) and take the ledger rows and expense editor fields from M6's `:core:design` (D-019).
+- **M6** starts only after the §9.7 colour change from U2's proposal has landed in SPEC (§11.1).
 - **Phone:** M2b (one `installDebug`), M5 (only if instrumented tests), M8 and M10 use the phone; only one at a time, named in the notes.
-- **Outside the repository:** M2c-dev (gcloud, Firebase, secrets in the main checkout), M2c-pi (SSH to the Pi, Gitea, Drive), M8 (dev server on the Mac), M10 and M11 (production) need the owner's allowance in the notes.
+- **Outside the repository:** M2c-dev (D-022, done), M2c-pi (the Kvitt Pi, the Home Assistant Pi, Gitea, Drive: allowances requested at the start of that sprint, D-023), M8 (dev server on the Mac), M10 and M11 (production) need the owner's allowance in the notes.