# Handoff: state of the work

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.
- 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).

## 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).

## 4. Paused (waiting on something outside the repo)

## 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.

## 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
read them in files.