[← Blog]

Progress That Reports Itself

No one filled in a status report this week. We still know, to the feature, what shipped, what’s mid-build, and what one decision is sitting in someone’s queue. That picture comes from three things we’d already be keeping anyway — not from a standup.

The instinct in most teams is to bolt a fourth system onto the other three: a tracker for the tracker. We didn’t build one. We pointed at what already existed — a durable notes store, a card per feature, and the commit history that doesn’t lie — and rolled them up.

Three sources, none of them new

The notes store holds the slow-moving facts: how the repos fit together, what the standing rules are, what was decided and why. The board holds the fast-moving ones: one card per feature, broken into the pieces that make it up, each piece marked off as it lands. Git history holds the part neither of the other two can fake — what code actually shipped, in which repository, on which day.

None of these exist for reporting. The notes store exists so context survives between sessions. The board exists so work has somewhere to live. The commit log exists because that’s what version control is. The dashboard is just the three of them, read together.

NOTES decisions, standing rules BOARD cards, one per feature GIT HISTORY what actually landed THE DASHBOARD no one filled this in by hand
Fig. 1 — notes, board, and git history roll up into one picture
A generated dashboard showing 17 feature areas tracked, 10 shipped and live, 4 actively building, and 1 waiting on a decision, plus a daily commit-activity chart broken out by app.
Fig. 1a — an actual snapshot, generated from the rollup, not written by hand

A card already knows its own state

Because a feature’s card is broken into the pieces that make it up, it doesn’t need a person to estimate how done it is — it counts. “5 of 6 pieces done” isn’t a guess written into a spreadsheet on a Friday; it’s a tally of what’s actually checked off, read at whatever moment someone asks.

The same is true of the bars in the daily activity chart — they’re not a velocity metric someone calculated. They’re a count of commits, per repository, per day, because that’s a fact the git history already has.

PRIVATE CLOUD CHAT one-click AI setup 5 OF 6 PIECES DONE WAITING ON YOU EVERY CARD carries this on its own
Fig. 2 — every card carries its own completion state

The one thing the rollup can’t decide

Most of what moves a card forward is reversible and local — a piece lands, the count ticks up, the card advances. None of that needs a person in the loop. But a card occasionally reaches a decision with real consequences outside the repo — something that spends real money, or becomes visible to people who aren’t us — and that one doesn’t move on its own. It sits, clearly labeled, until someone makes the call.

A CARD moves through the board REVERSIBLE, LOCAL ships on its own SPENDS MONEY, OR PUBLIC waits for a person holds here DONE
Fig. 3 — most state advances itself; spend and public decisions hold for a person

That’s the whole point of rolling these three sources up automatically: not to remove the human from the loop, but to make sure the only thing waiting on a human is a human decision — not a status update someone forgot to write.

Built with Brain and Kanban — open-source apps on LastDB — inside our autonomous build loop.

[← Blog]