CLI-First — the interface-optional charter

The principle

The data stores are the API surface. Command-line clients are the primary clients. Every interface — a terminal dashboard, a web portal, a voice agent, a chat bot — is a derived, optional view that can be regenerated or bypassed.

Tool infrastructure is built CLI-first so it is reachable from the main terminal and any remote terminal, program-to-program, with no interface in the critical path. A graphical interface is a convenience layered on top, never the only way to do a thing. If a capability can only be exercised by clicking, it isn’t done yet.

This is not a new direction — it names the de facto architecture. The capture pipeline, the task dispatcher, the decision queue, the voice interface, and the engine-dispatch layer already work this way. This charter makes it explicit and governs it.

The cascade

stores of record   shared tables + versioned markdown       ← canonical
   │               (tasks, session locks, inboxes, decision
   │                queues, docs). Everything else is derived from here.
   ▼
clients            the cockpit CLI  +  command skills        ← where work happens
   │               Read and write the stores directly.
   │               Loopable, scriptable, remote-drivable.
   ▼
views              dashboard · voice · web portals · chat    ← derived, optional, disposable
                   Never hand-edited. "Wrong? Re-run it."

The invariant: the stores below are the record; the interface is the lens. A view going stale, breaking, or being unavailable never blocks the work — the store is still right there, one command away.

The approval-gate ladder

CLI-first does not mean unguarded. The gates are structural, and going CLI-first preserves them:

• Reads are open. Any store is readable from the terminal. No interface gate on knowing the state.
• Internal writes are direct. Capturing a task, claiming work, answering a decision, messaging a peer — these mutate the fleet’s own stores and need no human approval.
• Outbound-to-a-human writes stay approval-gated. Anything that leaves the fleet for a real person — an email, a text message, a call — routes through the send gate: a staging outbox that never fires on its own, and an approval queue that releases one message at a time. The terminal delegates to those gated paths like everything else. A terminal is not a license to send.

What already embodies it

The pattern was in production before it was named. Across the fleet, each capability exposes a command-line surface as its primary client and treats any screen as an optional, regenerable view:

• a capture pipeline whose whole point is the terminal capture;
• a task dispatcher with a CLI claim/close flow and a dashboard tab as the view;
• a decision queue answered by command, mirrored to a dashboard;
• a voice interface that runs in the terminal;
• an engine-dispatch layer that routes to external model engines without ever leaving the cockpit;
• a database browser that reads rows from the CLI and renders an optional HTML view.

In every case the CLI came first and the view is disposable.

Governance

1. New tooling lands a CLI entrypoint first. A cockpit subcommand or a command skill is the definition of done; a UI is added only afterward, as a derived view.
2. No GUI-only capability. Nothing becomes the sole way to do a thing via a graphical interface. If the dashboard or web can do it, the terminal can too.
3. One implementation, two front doors. Where the CLI and a skill do the same operation, both call the same shared function. Logic is never duplicated between shell and skill.
4. Outbound stays gated (see the ladder above) regardless of the front door.
5. Views are regenerable, never canonical. If a view and a store disagree, the store wins; re-run the view.