Three weeks after the stack was picked, the foundation lands — and it lands as one batch, not twelve small ones.
On 2026-04-01 every story in the E1 epic moves review → done in the same
stroke: KMP scaffolding, the shared module structure, core data models, SQLite
integration and its Android DAO, the YAML config manager, the minimal Compose
UI, the KMP ViewModel pattern, the JNI scaffold stub, the connectivity
indicator, the error-handling patterns, and the integration smoke test. The epic
itself closes the same day.
That is a choice, not an accident. Each of those stories was already bounded — they were scoped on 2026-03-10 precisely so they could be finished as units. A batched landing is fine when the units were defined up front; it is a red flag when they were not, because then “everything closed at once” really means “nobody can tell you what changed”.
There is a wrinkle worth stating plainly: the git history in this window is submodule bumps and sync commits. The durable record of what closed is the vault status machine, so this entry carries its provenance there rather than claiming commit evidence it does not have. Fourteen transitions on one day is a much stronger signal than four vague commit subjects.
Lessons learned
- Batching reviewable units into one landing is fine when the units were scoped up front. The scoping is what makes the batch legible. Without it, a mass close is just an audit problem waiting to happen.
- An epic closing is only meaningful if its stories closed with it. An epic marked done over open stories is a status lie. Here all twelve moved together, which is what the epic is supposed to summarise.
- When git is quiet and the vault is loud, say which one you are reading. Claiming a commit SHA that turns out to be a submodule bump is how a devlog loses the reader’s trust on its fourth paragraph.