ProgressBoard

What it is

One screen showing every project on my machine at once, with the cards that are waiting on me pulled to the front. A card is a markdown file inside the project's own repository, and the folder it sits in is its state, so moving a card is a git mv.

There is no link to try it: the repository is private, because the tool reads across every project on this machine and several carry client material.

Why I built it

A handover document on one of my projects reached 1,510 lines before anybody measured it. In prose, adding a line costs nothing and declaring something finished costs real editing, so the first keeps happening and the second does not. Across a dozen active projects I could not see what was moving, least of all what was waiting on me.

The measurement that shaped it

Before building anything I classified the 35 open cards on a live project. About 26 were decisions I had not made; about 4 were work somebody could build.

That is the point of the tool. When an agent writes the implementation, developer hours stop being the bottleneck and my attention becomes it. I then surveyed 145 file-based kanban and agent-task projects, fetching each repository myself rather than trusting a summary. Almost all model units of work. None models a decision owed, so "waiting on me" is a lane here rather than a note in a comment.

The rules it holds to

• The folder is the state. There is no status: field, because a card carrying both would eventually disagree with itself, which is what the tool exists to remove. No created, updated or author fields either: git holds those already.
• A card is NNNN-slug.md. Every folder-based tool in the survey identifies a card by its filename, so retitling it destroys its identity. The number leads and survives every move; the slug stays free to rewrite.
• The app never writes a card's substance. It may move one. Every tool in the survey that gained a write path went on to invent fields for its own convenience.
• No central store, no database, no account, no telemetry. Every fact is recomputed per request, so the view cannot disagree with what is on disk.
• Card kind is worked out, not declared. A card with ## Options is a decision, one with ## Tasks is a feature, and a decision card is judged on whether it carries a recommendation.

The part I am careful about

A scheduled job runs each morning and writes the missing options, recommendation and ask onto cards that cannot be answered as they stand. An agent writing into my repositories unattended is only tolerable because of what it does not have: no shell, no git, no way to move a card, no way to commit. What it writes waits in the working tree for me.

The containment is the tool list, not the prompt. A prompt asks an agent not to do something; a missing tool means it cannot. I watched the first unattended run end to end and every rule held.

Where it is

Built in a week: Laravel on PHP 8.4, Blade only, no database and no build step. It scans 30 projects, gives each a row with lane counts in aligned columns, and opens a card in a modal that renders it, edits it, takes an answer, and moves it with a git mv and a commit in the owning project.

It changed what I work on. The four other projects on this site run their queues through it, and this write-up exists because the board made five months of unwritten-up work obvious.

What I would do differently

1. Read from the default branch, not the working tree. A board scanned from whatever branch each repository happens to be on is a function of last Friday's git checkout. Designed, not yet built.
2. Measure before arguing. I left work-in-progress limits out of version one and still think that was right, but the measurement should have gone in at the same time.
3. Put the convention in one place sooner. The same board convention in five repositories had drifted within a day.