The Morning Question Cockpit

The dashboard I built stopped working before it ever shipped. Not because the code broke. Because I built it to answer the wrong question.

The first version showed everything: every active session, every open ticket, every classified thought from the archive pipeline. I called it a dashboard because that’s what you call a page with numbers on it. What it actually was, functionally, was a mirror of the backlog. Opening it in the morning felt like opening the ticket tracker with extra steps. More data, same paralysis.

The audit that named the problem

I ran a multi-agent architecture review, the kind where I hand a hard question to an agent and make it defend its answer against the actual state of the system, not vibes. One of the questions I asked was blunt: when I open the cockpit, what should be the first thing I see?

The answer that came back reframed the whole project. Not a table. Not a summary. One thing: the single most important blocked item or next action, derived from the active epics. Everything else is secondary.

That’s a different design brief than “show me my data.” A backlog view answers “what exists.” A cockpit has to answer “what do I do right now.” Those sound similar and they are not. A list of forty open tickets sorted by priority still leaves you doing the sorting in your head every single morning. The whole point of automating classification and triage upstream is so you don’t have to re-derive the same judgment call at 7am with coffee not yet kicked in.

What got cut

The proposed layout was three sections, and the second one mattered more than the first: Current Focus, one task, no more. Requires Input, capped at three items, pulling from things like a decayed reconciliation queue entry or a pending PR. Recent Context, links to the last couple of sessions, for when I need to remember what I was mid-thought on.

The explicit “must not” list was just as important as what made the cut. No full backlog dump. No entire conversation archive. No system health metrics unless something was actually on fire. Every one of those is legitimate data I have access to. None of it belongs on the first screen, because none of it answers the morning question. It’s all one click away if I want it. It should never be zero clicks away by default.

Getting to a one-task cockpit meant the pipeline underneath it had to actually work first. Right now the enrichment layer classifies raw sessions but the calendar generation step doesn’t read that enriched data yet, so the dashboard has nothing worth surfacing even if the UI is right. There’s a reconciliation queue for the classifications the system isn’t confident about, and the standing question was whether to gate on clearing that queue to zero. I decided against it. In a single-user system, if a low-confidence item hasn’t gotten my attention in a week, it almost certainly didn’t matter. Let it decay out on its own instead of blocking the pipeline on a queue that will never hit zero.

The stop signal

I wrote down a concrete definition of “the infra is good enough, stop building it”: the system captures, classifies, and surfaces my daily work without me running a script by hand or fixing a parser that broke overnight. That’s it. That’s the finish line for this phase.

I needed that line in writing because the same audit flagged something else, less comfortable: my time was running skewed toward building the system instead of using it. Weeks of infra work against a healthy ratio that should favor actual product work. Not wrong to build tooling. Wrong to keep building tooling past the point it’s useful, using “one more feature” as a way to avoid the harder, less controllable work waiting on the other side of it.

A cockpit with one task on it is a forcing function. If the top of the screen only has room for one thing, I have to actually finish deciding what the one thing is, upstream, before I ever open the page. That’s uncomfortable in a way a forty-item table never is. A table lets you stay in triage mode forever. One task doesn’t.

I haven’t earned the right to say the pipeline hits that stop signal yet. The enrichment step needs to feed the calendar generation step, the parser needs to survive a week without me touching it, and only then does the one-task view mean anything. But I know what I’m building toward now, and I know what I’m cutting to get there. That’s more than the first version had.

dxdev LESSON · paste into your AI coding agent
LESSON: A dashboard that shows everything is a backlog with extra steps, not an answer to 'what do I do right now'
SOURCE: dxdev.com/blog/2026-07-31_the-morning-question-cockpit
WHAT HAPPENED: An operational dashboard's first version displayed every active session, every open ticket, and every classified item from the archive pipeline, and opening it each morning felt like opening the ticket tracker with extra steps, more data producing the same paralysis rather than less. An architecture review, forced to defend its answer against the system's actual state rather than intuition, reframed the design brief from "show me my data," which only answers what exists, to "what do I do right now," and the redesign cut the page to three sections: one current-focus task and no more, up to three items requiring input, and links to recent sessions for context, with an explicit must-not list banning the full backlog dump, the entire conversation archive, and system health metrics unless something was actually on fire. A related decision was to let a reconciliation queue of low-confidence classifications decay on its own rather than gating the pipeline on clearing it to zero, reasoning that in a single-user system, an item that hasn't drawn attention in a week almost certainly didn't matter. The same review surfaced an uncomfortable finding: time was skewing toward building the system rather than using it, prompting a written definition of the actual stop signal for infrastructure work.
THE RULE: A dashboard's job is to answer what to do right now, not to display everything that exists; a list sorted by priority still leaves the viewer re-deriving the same judgment call every time they open it. Write an explicit must-not list alongside the must-show list, and write down a concrete stop signal for infrastructure work before "one more feature" becomes the default way to avoid harder, less controllable work.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any dashboard or status page whose default view is a full list or table of items sorted by priority or recency, rather than a single surfaced next action derived from that list.
  2. Any dashboard design without an explicit must-not list stating which legitimate, available data is deliberately excluded from the default view.
  3. Any ongoing infrastructure or tooling project without a written, concrete definition of the condition under which building stops and using begins.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.