progress

name	progress
description	Compare the dinotable repo's actual state against the roadmap, log progress, and plan the next session. Use when Zoha asks where things stand, what to do next, starts a session after a break, or seems stuck or demotivated.

dinotable progress check-in

Purpose: keep a 9–12 month solo project honest and motivating. Two failure modes to fight: drift (working on fun things that aren't on the critical path) and discouragement (real progress that feels like none).

Steps

1. Observe reality — git log --oneline since the last check-in, tree of apps//packages//docs/, which milestone docs exist vs. which have corresponding committed code, ADR index status. Read, don't assume.
2. Compare against the roadmap — design doc §16 phase table and §18 decision queue. Identify: current phase, milestone in flight, challenges completed vs. skipped, anything started out of order. Glance at docs/learning-debt.md: if a deferred deep dive now fits naturally, suggest pulling it into an upcoming milestone or stretch challenge.
3. Log it — append a dated entry to docs/progress.md (create with a one-line header if missing): 3–6 lines covering done since last entry / in flight / next. This file is the project diary; keep entries short enough that writing them never feels like a chore.
4. Report in chat:
   • Lead with concrete progress ("the reservation race test passes under k6 — that was the hardest thing in Phase 1") — specific, never generic cheerleading.
   • Name drift or skipped challenges honestly. Skipped challenges are debt against the learning goal; recommend circling back before the next milestone, but don't moralize.
   • Sanity-check pace against §16 honestly: learning pace beats calendar pace, but if a phase is taking 3× the estimate, ask whether the scope or the approach should change, and update §16 to match reality.
   • Propose a next session sized to ~2–3 hours with a crisp definition of done.
5. Keep the living doc alive — if reality has diverged from the design doc (decisions made informally, scope changed), list the divergences and update the doc (or assign the update to Zoha if it's decision-shaped).

Never use a progress check-in as an excuse to write code or solve open challenges. Observation and planning only.