Sprint 32 — The dogfood writes the backlog


The plan for Sprint 32 was one word: use it. After Sprint 31’s enabler grind — security patches, dependency bumps, a build that kept running out of memory — I wanted to do the opposite of foundation work. I wanted to open Domi every day, run my actual household through it, and fix whatever made me wince.

It turns out that’s a very productive way to generate work.

What “living in it” surfaced

The tasks were too thin. A real task isn’t just a title and a due date — it has a budget, a start date for the multi-day stuff, a vendor I’m calling, a person it’s for versus a person doing it, and sometimes a document stapled to it. So tasks grew up: assignees, contacts, budgets, start dates, document attachments (link an existing one or upload a new one straight to storage), and a proper ”+ New task” modal instead of having to ask the chat for everything. You can now tick a task done right from the list without expanding it, and predicted tasks you never want again get a “don’t predict this again” button that actually teaches the engine to stop.

Then I went looking for my assets and members and realized there was no page for them. They lived in the knowledge graph and nowhere else. So now there’s a plain /assets and /members list — edit inline, archive, add new — sitting right in the sidebar where you’d expect them.

Little things, too, because little things are what you actually feel: the chat was rendering /task output as raw markdown pipes (| Due | Task |) instead of a table — a one-line missing plugin, fixed. The “New chat” button moved down next to your conversation list. The briefing digest became configurable — pick the day, the time, how many weeks back and forward it looks.

None of that was on a plan. All of it came from being annoyed at my own product.

Then I stepped back

About two-thirds through, I stopped building and did something I’d been deferring for months: I wrote the roadmap. Not a vibes list — a real table of every unshipped idea across V1, V1.5, V2, and V2.5, each scored on effort, how much it differentiates Domi from a generic to-do app, and how much it’d help me today. The point is to choose. (Top of the list: an “objective layer” — Areas, Projects, and Goals — so tasks finally have a why. That’s next sprint.)

While I was in the project board I found 165 finished cards still sitting in “Review” because moving them to Done was a manual step nobody was doing. Reconciled.

The line that stuck

The most useful thing this sprint wasn’t a feature. It was writing the spec for household membership — inviting people by email, managing their roles, emailing someone when a task assigned to them is due — and discovering that the four user roles have existed in the database for a dozen sprints and nothing enforces them. A role column is not access control. The schema was ready; the guard was never written.

That’s the whole sprint in one sentence, really. The structure is often already there. What’s missing is the part that makes it true. 10 PRs merged.

Next sprint: Areas, Projects, Goals.