Files
kvitt/docs/HANDOFF.md
T
jacobh2 76ee957f41 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>
2026-10-17 21:23:38 +02:00

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

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

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