Command Center
Vision-to-work planning dashboard
- Client
- Brightinfinite
- Industry
- Internal operations
- Outcome
- A local-first planning system where long-range intent, daily work, and agent output all land in one record
The brief
An internal tool, built for one operator, to answer a question most planning software refuses to take seriously: what did I actually do, against what I said I was going to do?
Not a task list. A single nested arc of intent, from a ten year horizon down to the current quarter, with the day's work hanging off the bottom of it. The point is longitudinal. Over time it records course changes, abandonment, reprioritisation, and capacity breaches, so the drift becomes visible instead of being reconstructed from memory.
It runs on real data rather than test data, which is the only way an internal tool gets honest quickly.
What shipped
A local-first application on Next.js and TypeScript, with SQLite behind Drizzle and a shadcn interface.
The work model runs vision, priority, goal, project, task, and block, deliberately flat below vision so that a plan cannot hide from its own scope. On top of it: a day timeline with a close ritual, an OKR worktable, daily and weekly review cycles with a divergence ledger, a laboratory surface where the app's own experiments are built, a registry of agentic systems, an embedded terminal, and a nightly backup rig across three disks.
It also carries its own issue tracker. Markdown files in the repository are authoritative, a SQLite table and full text index are derived from them, and one module is permitted to write that table, enforced by a test that fails the build if anything else does. It replaced a tool whose sixty issues had been gitignored for three months and had never reached a remote. The corpus is now past a hundred issues and every one of them survives a machine going missing.
How it was made
Built by the same agentic pipeline the studio sells, against a production codebase rather than a demo. Agents write into it directly through an MCP server, so progress recorded by a machine lands in the same arc as work recorded by a person.
The discipline that made it survivable is worth naming, because it is the transferable part. Files stay authoritative and databases stay derived, so a corrupted index is rebuilt rather than recovered. Every check must be able to prove its own success rather than assert it, after three separate tools were found reporting clean over the exact condition they existed to catch. And no permanent record is allowed to name a machine or a person, because names get reassigned and records do not.
Over a thousand tests run against it. The parts of it that generalise are the parts clients get.