Running the Beer App Like a Real Agile Project

The harden-foundation branch merged into master this session: migrations, seed data, and role-based auth all landed together in one pull request. That closed out the gaps from the last audit. The obvious next move was to start building the mug club feature itself. Instead I stopped and set up a lightweight Agile process first.

That might sound like overhead on a project with exactly one contributor. It isn't. The reason to bother is the same reason the last audit found three foundational gaps hiding under a working demo: a solo project with no tracking drifts the same way a team project does, just with nobody around to notice until later.

Epics as labels, sprints as milestones, no new tools

I didn't want a separate PM tool layered on top of GitHub, so EPICS_AND_SPRINTS.md maps directly onto GitHub's own primitives instead of inventing new ones:

• Epic → label. epic:mug-club, epic:auth, and so on. Epics span more than one sprint, so a cross-cutting label fits better than a milestone.
• Sprint → milestone. A milestone bundles the stories for one sprint and tracks percent-closed automatically. Since this is a solo, session-based effort rather than a team on a calendar, sprints are scope-based, not time-boxed: a sprint closes when its bundle of stories is done, however many sessions that takes.
• Story/Task → issue, labeled with its epic and assigned to its sprint's milestone.

Only the next epic gets fully broken into issues at any given time. Sprint 1, Mug Club Core, is now five ticketed issues (#2 through #6): the data model, the bartender confirm endpoint, the customer progress endpoint, then the two matching UI screens. Later epics, like Discovery and Admin, are named in the doc so the roadmap is visible, but they don't get groomed into issues until they're actually next. Pre-ticketing work that's sprints away just produces tickets that describe a shape the work won't end up having.

Retiring the trackers that went stale

The same audit that produced CLAUDE.md had already flagged PROGRESS_TRACKER.md and PHASE1_IMPLEMENTATION_CHECKLIST.md as stale: one still described a plain CRUD app, the other stayed fully unchecked long after the work it was tracking got done. Rather than patch them back into accuracy, I retired both into short stubs that point at the new docs. A status document that describes the wrong thing is worse than no status document, because it looks authoritative right up until someone trusts it.

SESSION_LOG.md is the other half: a dated entry per working session, noting which sprint or story it touched and linking the commits involved. It's what makes it possible to check, later, whether the work actually stayed in line with the plan or quietly drifted away from it.

Catching my own stale doc, immediately

Setting this up surfaced a small irony right away. EPICS_AND_SPRINTS.md still said the Auth & Roles epic was "code complete on harden-foundation, not yet merged to master," written just before the merge happened. CLAUDE.md had the same line, plus a "likely next steps" section still instructing a merge that had already occurred. Both got fixed in the same session, but it's a clean example of the exact failure mode the new process exists to catch: a status document is a snapshot, and it goes stale the moment the thing it describes changes underneath it.

The PM angle

None of this builds toward the mug club feature directly. It's the same judgment call as the foundation-hardening session: before adding scope, make sure the thing tracking the scope is trustworthy. On a team, a stale sprint board costs someone else a bad status update in standup. On a solo project, it costs future-me a wrong starting point next session, which is arguably worse, since there's nobody else around to catch it. Sprint 1 is next: Tavern and BeerConfirmation entities, then the confirm endpoint, then progress, then the two screens that make it visible.