Documentation

Deskworth is a desktop application that drives the provider command-line tools you sign in to yourself, under each provider’s terms. It is not a model, it does not resell one, and it never holds your CLI sign-in: each CLI keeps its own session. This page is the map; each guide documents one part of it against a named version.

#Four states, and none of them is a promise

Every page in this space carries a state, and so does every capability inside a page. The scale never rounds up: without evidence that someone watched it run, a capability is available at best, never verified.

• VERIFIEDVERIFIEDObserved on a real machine, and the page says when. The date is part of the claim.
• AVAILABLEAVAILABLEShipped in the current build and callable. Nobody watched it during this pass, so the page does not say they did.
• PREVIEWPREVIEWWritten and covered by tests inside the core, but nothing an operator does reaches it yet.
• PLANNEDPLANNEDNothing is written. The page exists to say precisely what is missing, not to suggest it is nearly there.

#The shape of a run

1. A question arrives at the host role, which routes rather than executes.
2. The routing convenes the roles the question needs, and, when a deliverable is named, the role that owns that format.
3. Each convened role becomes a card. A card drives one vendor CLI headless, in its own isolated workspace.
4. The card emits a trace: one line per phase, per tool, per process. Never a summary. The raw process output stays available underneath, with the exact command line.
5. Tools are served to the card by a local server on the loopback address, gated by the role’s declared capabilities.
6. What the card produces, a chart module, a workbook, a blocked result, is deposited with its provenance.
7. The host stitches the desk back together and the result carries its trail.

#The registries

Four things are registries, and a registry has exactly one home. Adding an entry anywhere else is a bug, not a shortcut.

EvidenceThis site mirrors three of them, roles, providers and tools, rather than restating them 4. The tool reference is generated at build time from the core’s own registry, so a tool removed from the server disappears from this documentation without anyone remembering to delete it.

#Where to go next

• Getting started, from a fresh Mac to a first run.
• Architecture, the process tree, the workspaces, the local tool server.
• Connect a provider, the three CLIs, their sign-in doors, and the ten states of a connection.
• MCP, both directions, and the one that does not exist yet.
• API reference, every tool, its capability, its parameters and the roles that hold it.
• Security, each guarantee tied to the thing that enforces it.