Chapter II · Operating xMesh from the Station

The operator's surface: the gate, the console, the mission card as a booked trade, approvals, activity, judgement, and what to do when something is stuck.

The API chapter tells you how to command the mesh from a terminal. This one tells you how to run it from a screen.

1. What the Station is and is not

The Station is the operations cockpit for a team's mesh, and it is not part of the runtime you install from npm. The published package is API-only: the README's edition table records Station as "Not in the npm package — the customer operations cockpit is planned for the paid Team Mesh deployment", and the server ships no web build, falling back to a plain page naming the node. A deployment serves the cockpit by pointing XMESH_WEB_DIST at a locally built Station; point it at a directory holding no index.html and the server says so on startup and serves the API alone rather than degrading in silence. You are an operator here, not a developer: you state work, read what came back, and rule on it. Nothing here edits the mesh's record — it reads what the mesh has signed and routes each gesture through the runtime's own gates.

2. The first screen

You meet a gate before you meet the mesh. It asks for a passcode with no default; the note under the field states that yours was printed when the server first started and lives at <team-root>/xmesh/passcode when the server runs with XMESH_TEAM_ROOT, otherwise at ~/.xmesh/passcode. A wrong one returns "Passcode not recognized." and nothing else.

Past it, the top bar carries state, not navigation. You see MESH LIVE when any node is up and MESH IDLE when none is, then STANDING and ON MISSION as two separate counts — peers and preserved agents that outlive a mission, against workers that came up for one and go when it ends. When approvals are waiting you get an APPROVALS chip with the count; press it and the console scrolls to that queue.

The left menu owns destinations. As the code renders them they are lowercase: ＋ new ask, mission console, activity, judgement, automations, mesh nodes, ontology, board, rooms, experiments, then a MISSION-ROOMS section holding your project tree and a + new room field. That tree lists operator rooms only: minted mission rooms, review rooms and seat rooms are filtered out by naming pattern.

3. Ask the mesh

The default surface is a conversation, full width, headed ASK THE MESH. You type after the ASK ▸ prefix and press ASK ▸. A row of chips names which agents chose to speak and which stayed silent, each with its reason on hover; above eight participants it collapses to a summary reading 0 spoke · 12 silent with a who ▾ control. That is a measurement, not an error: agents self-select on what they hold, so nobody speaking means nobody's cognition matched the question.

Above the prose sits a mode badge. mind · claude-opus-5 means the deployment's own mind wrote it, grounded sentence by sentence; local · <model> means a keyless local model did; illustrative — no model means nothing composed it and you are reading a labelled restatement of the grounded contributions. Citations render as short clickable keys, web-drawn sources as links; grounded in N records from M agents opens the records themselves.

When the question deserves real work, press work on this ▸ (commission the mesh) and the turn escalates into a mission: it dispatches into the room selected in the ROOM ▸ bar, tracks through commissioning the mesh…, queued and the mesh is working, and lands as a worked completion with the critic's badge beside it. MISSION CONSOLE ▸ takes the last question to the console instead, prefilled.

4. Run a mission from the console

The console opens with section 01 · Mission console and one line: the MISSION ▸ prefix, a field reading "State a mission — the mesh grounds it, then runs it", and a RUN ▸ button.

Press RUN ▸ and nothing dispatches yet. Your sentence is parsed into CAT7 and handed back as a form headed CAT7 · shape the request with seven fields in load-bearing order: Focus (marked required), Intent, Done when, Issue, Motivation, Perspective, Mood. Done when holds your acceptance criteria and decides whether the mesh can grade itself. Write mechanical clauses there, one per line: CHECK: file|contains|not-contains|contains-at-least|run <path> <needle> — full grammar in the API chapter — with at least one substantive clause, because a mission graded on file existence alone is written as a break at end of day. Press VALIDATE ▸ for a typo and plain-English pass that never submits, then CONFIRM & RUN ▸ to dispatch. Left empty, Done when defaults to "operator will validate the completion". You then see "posted — agents self-select, grounded in the mesh" or "queued — N ahead of it". Grounding is not a choice: one the mesh cannot do surfaces as a blocked step with a root cause, never as a silent ungrounded run.

5. Read a mission card

A card is a booked trade, and every line on it is a fact about that booking. The head carries COMMISSION 4CDD08 ◢ and the worker who filled it. Then the ask, then a time line reading 14:22:07 UTC · completed 3h ago · posted 11:04:55 — that stamp is the moment it entered its current state.

Then the booking line: booked · delivered · approved by <critic>, or booked · delivered · objection by <critic>: <text>, or booked · delivered · no counterparty verdict — the critic did not rule. The third is not a pass. Where end of day has run, the line extends with · EOD matched, paid or · EOD: no counterparty.

Below that, controls appear only when they have something to open. WHY THEY SPLIT ◢ appears when a critic other than the doer objected, and opens the root cause: the fill, the objection, the harness it ran on, the implicated resource. EVIDENCE & RECORD ◢ opens the full card on the canvas and carries · checks 3/5 inline; a failing tally also gets its own line, ✗ mechanical checks failed: 0/1, stated as a failure rather than painted green. PROOF ◢ opens the completion CMB with its per-field admission and lineage, READ ◢ opens the deliverable itself, and ▸ PROCESS · steps, forks & merges expands the audit.

Three actions sit at the bottom; none reopens anything. DISMISS annotates the booking as dismissed — the record stays, nothing is undone. VALIDATE annotates it as validated. Both post your verdict against the commission's completion: the runtime records it, closes the commission, and emits it as a signed grounding, so your judgement calibrates the learning loop. REPLAY ▸ mints a new commission citing this one as parent and staffs it; the original is left exactly as it booked, replayedInto points at the newest attempt, and the button then reads REPLAYED and refuses a second press. A ruling annotates a closed booking; a REPLAY is a new trade.

6. The mission console counts

Section 02 · Missions carries a count line, and each term is bounded. N booked, unruled is completions awaiting your annotation. N queued is missions you already approved, waiting for capacity. N open elsewhere is the rest of the working set — open, not running. N running is the only running number, and it comes from the governor.

Beneath it, when anything is unruled, you see mind slots as 3/6 with the line "mind slots in use · 2 waiting — crews are released at booking; nothing waits on your ruling". Read that literally: a mission books the instant it fills and releases its crew then, so deferring a verdict costs no capacity.

7. Approvals

Section 03 · Capability approvals holds a different queue from section 02, and says so: when clear it reads "no capability request is waiting — completions to rule are in 02". Each card is a worker asking for a capability it lacks. You see who asked, the authority needed as min <role> · quorum <n>, the reason in the worker's words, and, where the grant is standing, Approving grants: <effect> — what you authorise beyond this one mission. PROOF ◢ opens the record behind the request. DENY and APPROVE cast your vote; prior votes render underneath by name, and a refused vote shows 403 · <reason>. The same card appears inline on the blocked mission it holds, so you rule from where you stand.

8. Activity

activity answers what the mesh is doing right now, in three parts. PRESSURE leads: mind slots as live over cap, waiting, queue depth and loop p95 in milliseconds, each turning warn on crossing a threshold, never a verdict. Under it, when completions are unruled, a control reading N booked missions unruled — crews already released; a ruling annotates the record expands into the list, capped at twenty-five and saying so, and a warn line names anything stalled. RUNNING lists in-flight missions with their status and worker (or unstaffed), the hosted workers and the deployed agents. FEED is the live event stream, marked LIVE or OFFLINE; rows carrying a record open it in the inspector.

9. Judgement

judgement is adjudication rather than activity, and it is scoped: the head states this tenant · N rooms, so every count below is bounded by rooms you own. judged by 2+ nodes leads — records more than one sovereign node evaluated independently, the claim a single-judge harness cannot make about itself. judges disagreed is the subset where those verdicts split, and signed verdicts and nodes judging give the denominator. Beneath is the verdict mix — aligned, guarded, redundant, rejected as percentages — and it reads both ways: all aligned means nothing is discriminating, all rejected means the mesh has fragmented. show disagreements only filters to splits and flips to showing disagreements only; returning nothing there is the mesh cohering, not a missing feature. Open a row for each receiver's verdict with its per-CAT7-field decisions underneath — a record can be aligned overall while most of its fields were held redundant, so both are shown.

10. When something is stuck

Two states look alike and are not. paused is the supervisor noticing a worker died; it is not a booking and can continue in place. blocked is a mission that hit a capability it lacks: it books as a root-cause outcome, its crew is released, and its approval card is the corporate action.

The controls follow that distinction. On a paused mission you get ABANDON — "End this mission — a terminal needs-human resolution" — and RESUME, which returns it to the offer queue for the live crew. RESUME staffs first and flips second: if it cannot staff a worker the mission is left where it was with the reason, so the button never claims a resume nobody performed. A blocked mission gets REPLAY ▸ instead, because resuming a released crew revived a corpse and read as dismissed on the way; ABANDON refuses a booked row with "a booking is not withdrawn; replay it or rule on it".

Above the actions the card states blocked — <pause reason>, blocked — needs your approval: <reason>, or approved — waiting for a free mind slot to resume once granted. Every stuck mission carries ROOT CAUSE ◢, opening the tier-1 report on the canvas, with its acceptance clauses badged live above it as PASS, FAIL, or · for anything never mechanically evaluated.

11. What the Station will not do

It will not let you approve in bulk without reading. Approvals open one at a time behind ▾ N more waiting and verdict cards five at a time behind ▾ N more to rule, each carrying its reason, grant effect and proof.

It will not report completion silently. A configured critic that returned nothing renders as no counterparty verdict — the critic did not rule and as ⚠ not cross-checked, never as a clean pass. A failing check tally is stated as a failure, and an artifact a completion named but that is unreadable on this host is listed as exactly that.

And it will not rewrite a booking. VALIDATE and DISMISS annotate, REPLAY mints a new trade citing the old one, ABANDON books a withdrawal. No control here edits a record the mesh has signed — including none that interrupts running work, which is done by stopping the worker.