Files
kvitt/docs/HANDOFF.md
T
jacobh2 853c038c58 SPEC v0.5: M3 and M5 decisions (D-026 to D-034, D-040 to D-043), HANDOFF rewritten
Records the decisions proposed by M3 (503cee5) and M5 (c28c52b). M5's proposals
D-030 to D-033 are renumbered D-040 to D-043; D-035 to D-039 are reserved for M4.
Adds the D-027 clock-skew re-stamp rule, M5's contract requests for M8 (PLAN-M8,
SPEC 11.3), the connect-info note for M4 (PLAN-M4), the picture size note (PLAN-M6),
and updates prompts/README status.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TQd3pEP9UeN2uifbHknQ7B
2026-10-17 22:21:43 +02:00

5.6 KiB
Raw Blame History

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 c28c52b (M5) plus the SPEC v0.5 docs commit from agent-spec5 once it lands. History: 5e1be38 plans and prompts, c885aba M2c-dev, 76ee957 SPEC v0.3, fad6fc9 M2b, fdf2093 M2a, 040bf41 SPEC v0.4, 503cee5 M3, c28c52b M5.
  • Landed: M0 spec, M1 contracts and vectors (c6df2ab), M2a server skeleton and kvitt-domain (fdf2093), M2b Android skeleton and :domain (fad6fc9), M2c-dev infra for development (c885aba), SPEC v0.4 (040bf41), M3 server core API (503cee5), M5 Android data layer (c28c52b). With agent-spec5: SPEC v0.5 with M3's D-030 to D-034 and M5's D-026 to D-029 and D-040 to D-043 (M5's proposals D-030 to D-033 renumbered to D-040 to D-043; D-035 to D-039 reserved for M4).
  • Both gates exist: Android tools/gradle-serial.sh check (from android/), server cargo fmt --check && cargo clippy -- -D warnings && cargo test (from server/).
  • Worktrees in flight under .claude/worktrees/: agent-m4 (M4 server sync, audit, push, scheduler), agent-spec5 (this docs change: SPEC v0.5).
  • The owner runs the UX sprint (U1, then U2) in a separate Claude session in ~/orca/workspaces/kvitt/UX-sprint on branch UX-sprint; it commits only under docs/ux/ and rebases on main before landing.
  • Development stack (M2c-dev): running on the Mac, reachable at http://192.168.1.210:8080; the owner confirmed /health from the phone on the home Wi-Fi on 2026-10-17. Firebase project kvitt-1337 with apps se.hagstedt.kvitt and se.hagstedt.kvitt.debug; service account kvitt-fcm; infra/secrets/fcm-service-account.json and infra/secrets/google-services.json in the main checkout (git-ignored).
  • Installed on the owner's phone: nothing yet (M2b's installDebug is pending).

2. Open work (one line each, with who owns it: agent or owner)

  • Land agent-spec5 (orchestrator): SPEC v0.5, decisions D-026 to D-034 and D-040 to D-043, PLAN-M8 (M5's contract requests, D-027 follow-up), PLAN-M6 (picture size note), PLAN-M4 (into_make_service_with_connect_info), prompts/README status.
  • Tell agent-m4 before it lands (orchestrator): D-035 to D-039 are its range; v0.5 asks M4 to add into_make_service_with_connect_info::<SocketAddr>() to serve (D-032, §11.3); M3's tests are in tests/core_api/; generation sets the template's updated_at (§9.5); D-033 resume rule.
  • D-027 re-stamp (orchestrator assigns: M8 as a contract request on :data, or a small :data agent): on the first sync attempt after a clock_skew rejection the phone re-stamps updated_at of each such pending row to its current clock before pushing. Not in :data at c28c52b.
  • Picture size (M6, if needed): :data always fetches E-11 at 512; a size parameter for the 128 variant is a contract request on :core:model and :data.
  • server/README.md (server-owned, next server agent): still says M3's tests go in tests/core_*.rs; v0.5 §14.7 records the single binary tests/core_api/.
  • Plans (SPEC §11.2 v0.5), in dependency order; prompt prompts/<id>.md:
    • M1 Contracts and vectors: landed (c6df2ab).
    • M2a Server skeleton and kvitt-domain: landed (fdf2093).
    • M2b Android skeleton and :domain: landed (fad6fc9); outstanding: installDebug on the phone (owner plugs it in).
    • M2c-dev Infra for development: landed (c885aba); phone /health check done (owner, 2026-10-17).
    • U1 UX directions: owner's session (UX-sprint), in progress; owner then picks a direction.
    • U2 UX design spec: owner's session, after U1 and the pick; owner approves; then the §9.7 colour change goes into the spec (docs agent) before M6.
    • M3 Server core API: landed (503cee5).
    • M4 Server sync, audit, push, scheduler: agent in flight (agent-m4); lands after M3 (done).
    • M5 Android data layer: landed (c28c52b).
    • Next waves: M9 Splitwise importer after M4; M6 Design system after U2 approved and the §9.7 colour change; M7a to M7f Features after M6, in parallel; M8 App integration after M7 (and M3, M4, M5).
    • 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, D-024).
    • M11 Import history: after M9 and M10.

3. HUMAN steps pending (relay in chat)

  • Plug the phone in over USB so an agent can run installDebug of the debug app (expected: the Kvitt debug app opens to an empty themed screen).
  • UX direction pick from U1's directions, with comments (owner's UX-sprint session).

4. Owner questions (asked, unanswered)

  • 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. The only open question (OQ-1, OQ-2, OQ-4 answered: D-001, D-003, §10.9).

5. Paused (waiting on something outside the repo)

  • Nothing.

6. Numbering

  • Decisions: D-001 to D-034 and D-040 to D-043 used (D-008 and D-009 unused). Reserved: D-035 to D-039 for M4 (in flight). Next free for anything else: D-044.
  • Spec version: v0.5 written; next v0.6.
  • Server schema version 1; next 2. Room schema version 1 (android/data/schemas/se.hagstedt.kvitt.data.db.KvittDatabase/1.json, unchanged by M5); next 2.
  • Sync protocol 1, push payload 1.

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