There is a quiet gap between a tool you open and a tool you live in. Most terminal UIs are the first kind. You launch them to do one thing — check a status, edit a file, run a query — and you close them. They can be a little rough at the edges, because the edges are where you leave.

The NAOMS cockpit is meant to be the second kind. It is the surface we want to keep open all day: the place where the agent fleet reports in, where approvals land, where we pick which model answers and watch what it costs. The word that carries all the weight is daily-driver. A daily-driver surface has a different bar than a tool you visit, and most of this piece is about what that bar actually is.

The cockpit, rendered

Here is the real thing, captured from an end-to-end snapshot on 2026-05-05 — the cockpit after a real password unlock, talking to a live local daemon:

NAOMS Cockpit  actor: Owner (you) [owner]  v0.21.0  Connected  MCP ⚠ SLOW   Session: "New Chat"   [anthropic* ollama×]
┌▶ Attention Queue (1)──────────────────┐┌In-Flight (0)──────────────────────────┐
│▇ · #0 Approval requested              ││(no items)                             │
│  unknown · APPROVAL                   ││                                       │
└───────────────────────────────────────┘└───────────────────────────────────────┘
┌Ready-to-Start (0)─────────────────────┐┌Scheduled by Kronos (71)───────────────┐
│(no items)                             ││▇ ⏳ #0  unknown · ?                    │
│                                       ││▇ ⏳ #0  unknown · ?   …(71 total)      │
└───────────────────────────────────────┘└───────────────────────────────────────┘
 S1: New Chat
┌ > ────────────────────────────────────────────────────────────────────────────┐
│ Type a message...                                                              │
└────────────────────────────────────────────────────────────────────────────────┘
 i:attach A:audit d:dag x:unsched !:override F4:providers F5:cost ?:help Esc:back ^Q:quit

(Trimmed for width from the full snapshot the test suite captured.)

Read it the way you would read a dashboard you trust. Four panes. Top-left is the Attention Queue — things waiting on you, here a single approval request. Top-right is In-Flight — work the fleet is actively running. Bottom-left is Ready-to-Start, bottom-right is Scheduled by Kronos (the scheduler), showing 71 queued. The footer is the keymap. None of this is decoration; each pane answers a question a daily driver has to answer the instant you glance at it.

Demand one: an attention queue, not a feed

A tool you visit can afford a feed — a flat stream you scroll. A tool you live in cannot, because a feed makes you do the triage every time. The cockpit's top-left pane is not a log; it is a queue of things that are blocked on a human decision. An approval requested. A choice only you can make. The design move here is that attention is a scarce resource the UI is responsible for protecting, not a firehose it dumps on you.

That sounds obvious until you build it, and then you discover the hard part: deciding what counts as attention-worthy. Get it wrong in the noisy direction and the queue becomes a feed again. Get it wrong in the quiet direction and a real approval sits unhandled while the fleet stalls. The separation you see above — Attention Queue distinct from In-Flight distinct from Ready-to-Start — is the answer to "what does the human need to see now versus what is merely true." That distinction is the whole job.

Demand two: status that is honest under load

Look again at the header: MCP ⚠ SLOW. The cockpit is not claiming everything is fine. The connection to the governance layer (MCP) is degraded and the UI says so, plainly, in the one spot your eye lands first. A daily-driver surface earns trust by being honest when things are bad, not by looking clean.

This matters more than it seems. If the status line is green when the system is struggling, you stop believing the status line — and a status line you do not believe is worse than no status line, because it actively misleads. So the bar for a daily driver is: every indicator must degrade truthfully. Connected becomes a warning becomes a failure, visibly, in real time. The [anthropic* ollama×] cluster at the right does the same for model providers: a star for the active one, an × for one that is configured but unreachable. You should never have to guess which model is about to answer you.

Demand three: a picker that refuses to lie about capability

The piece of work that landed on 2026-05-05 carried a goal worth pausing on: tool-status honesty in the model picker. The honesty there is specific. When you open the actor/model picker and choose a model, the cockpit has to tell you the truth about what that model can do — in particular, whether it can use tools. A model that cannot call tools should not be silently offered as if it can, and if you pick one and ask for something that needs a tool, the UI must deny the parity and say why, rather than pretending the request succeeded.

This is the same principle as the honest status line, pushed one level deeper. It is not enough for the surface to be honest about its own health; it has to be honest about the capabilities of the things it lets you select. A daily driver is a set of promises about what will happen when you press a key. The moment one of those promises is false, the surface stops being a place you can live and becomes a place you have to second-guess.

Why a terminal, and why this is harder than it looks

You could ask why this lives in a terminal at all. The honest answer is that the terminal is where we already are, and a daily driver should meet you where you work. But a TUI buys you nothing for free: there is no browser layout engine, no flexbox, no accessibility tree handed to you. Four panes that stay aligned at every width, a keymap that never shadows itself, a render that survives a slow connection without freezing — all of it is hand-built against a grid of character cells. The reward is a surface with no chrome, no loading spinners borrowed from the web, no dependency on anything but a terminal and a local daemon. That is the Wholeness axiom showing up in the client layer: complete in itself, no external service required to do its core job.

The bar, stated plainly

So here is what "daily driver" really demands, distilled:

• An attention queue, not a feed — the UI does the triage, so your scarce attention is spent on decisions only you can make.
• Status that is honest under load — every indicator degrades truthfully; a status line you cannot trust is worse than none.
• A picker that refuses to lie about capability — you always know which model will answer and what it can actually do before you commit.

A tool you visit can skip all three and still be useful. A tool you live in cannot skip any of them, because the cost of each small dishonesty is paid every single day, by you, in the one currency a daily driver is supposed to protect: your attention and your trust. The cockpit closeout was the work of taking those three demands seriously. The honesty thread running through it — status, capability, the refusal to fake a success — turned out to be the same thread that would define the entire week. But that is a confession for another day.

Written by AI agents from real project logs; owned and edited by Mujo.