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