Domios capability map

Generated from essences/capabilities.md. Edit the source; changes made here are overwritten.

What Domios fundamentally does, grouped by the few vectors that give the system its shape. Each row names a capability, what it makes possible, where it is reached (UI surface, CLI command group, API area), the rules that must not break, its status, the core parts or clients it runs on, and the capabilities it feeds. Why these vectors exist is stated once, in the vision; the core parts, clients and the routing spine are described in the core essence; how to maintain this map is stated in the documentation contract.

Code is volatile and gets rebuilt in pieces; these essences are the product's stable vectors. They rarely change, and when they do they evolve gradually instead of being restructured, which is what lets them serve as the expected inputs and outputs a change must keep.

Status: stable is in the latest release; in rollout is merged for the next release and not yet shipped; planned is an agreed direction with no shipped surface; roadmap is where the product is heading, with its exact shape still open. Detail names the UI surfaces, CLI command groups, and API areas through which a capability is reached.

Runs on names core parts and clients exactly as the core essence does. Feeds names capabilities of this map; a capability with no outgoing link is a sink and is fed by at least one other row.

Every element carries an explicit stable id in its metadata: a vector heading ends with {#vector:<slug>}, and a table row's first cell is its id. An id outlives its display text, so a rename keeps the id; a replaced element is retired and never reused. Runs on and Feeds name ids, not labels, so a rename never breaks a link.

Invariants that bind every vector

• domios is the primary CLI command; codeterm remains a fully working alias. Help, usage, prompts and generated contracts teach the canonical name.
• Production listens on port 7685 and is never killed by development work; development uses 7686 or a named instance.
• Closing the desktop releases frontend resources while the daemon and its sessions continue; tray or application activation restores one authenticated frontend without replaying input. Launch immediately shows branded starting feedback, replaced by the rendered UI through lifecycle events; startup errors remain visible with Retry and Quit.
• Core asks capabilities, never provider identities. The Supporter contract keeps model judgments subordinate to deterministic evidence across every vector.
• A routed <domios> frame is accepted as host-injected only when the host placed the complete tag pair at the leading frame; the same bytes anywhere else are content. Position does not authenticate the sender or protect against direct writes into a tab's input stream.
• Coordination waits on observed events, never on sleeps or polling intervals.
• Changes to PTY or Chat input delivery get heightened attention: they name the causal finding, the files and symbols touched and the rollback boundary, and land only with focused proof that the delivery invariants still hold.
• Agent-to-agent traffic, memory and documentation are English.

1. Agents live and work in tabs

Detail: Workspace sidebar and chat view; workspace, tab, agent, and sessions command groups; workspace, tab, agent, and session APIs; core essence.

ID	Capability	What it enables	Entry points	Invariants	Status	Runs on	Feeds
capability:workspaces-and-tabs	Workspaces and tabs	Shells and agents grouped by project, each tab recognisable for its whole life; the General workspace hosts Main and independent General sessions	Sidebar General New session on desktop and web; New Terminal profile menu; Settings > General default shell; CLI workspace, workspace set-cwd, tab, tab describe, tab new --timeout, tab timeout, tab new --shell, tab new --list-shells; tab, shell-profile and workspace API	A lost workspace folder is marked and replaces session creation with Choose folder; relocation preserves workspace, tab, Team, Plan and session identity; Agent-owned utility shell bounds restart at each command-start mark and cancel on finish; idle shells have no deadline; expiry stops the owned process tree while keeping the tab open and sends one owner status; bounds survive daemon restart and lost running commands are reported; dev servers keep no timeout; owner and Team cleanup still remove utility shells; selected shell profiles survive restart; WSL shell working directories map between Linux and host paths; no chosen profile preserves the existing default shell; agent processes remain native; listing covers every workspace unless one is named; the General workspace and Main are protected; General New session creates a distinct General-role session in the daemon General home using its configured provider and model policy, preserving Main selection, identity and recovery ownership; a confirmed human may close a workspace containing coordinators, while an agent cannot close its own coordinator workspace; close refusals are visible; a tab's name is set once at spawn, and a task-bound tab refuses rename and records progress in its description	stable; shell profiles and all-workspace default listing in rollout	core:service-layer, core:host-state, core:general-agent	capability:agent-providers
capability:agent-providers	Agent providers	PTY providers run in terminals; Chat providers, including the Codex stdio runtime, run without a terminal	Agent picker; CLI agent spawn, agent providers, agent models	Workers default to full machine access with explicit launch confinement available; execution intent governs plan authority separately. Agent access follows the permission contract; detection reads only the tab's own session; provider-authenticated subagents are inspectable read-only inside the parent tab under its root binding, without child sends, rebinds or new tabs; disabling or uninstalling a provider ends its live runtimes; an unsupported reasoning effort refuses the launch instead of downgrading; provider-declared Fast mode appears in the shared model picker and Settings defaults, confirms against the bound runtime and applies to the next turn; a spawn runs in its requested cwd or is refused, and reports a provider that exits before readiness as a failed spawn, never a live agent; runtime background-command lifetime follows the structured thread control contract; declared safe onboarding choices may unblock delegated Workers and Planners while owner-facing prompts remain visible to the owner	stable; Cursor and Codex Chat-only runtime and provider-declared remote task locations in rollout; Aider and Goose planned	core:agents-and-providers, core:plugin-host, core:general-agent	capability:session-continuity, capability:usage-and-analytics
capability:message-delivery	Message delivery	Text, keys and chat turns reach a tab; authored payloads travel as private pad files	CLI send, tab respond, tab stop, pad; --from-pad on messaging commands; tab send and chat-send API	A lazy-session PTY may admit exactly one first user turn when its own TUI composer is live on the same launch attempt while nonce binding is pending; later sends wait for authenticated readiness; the payload is written at most once; once queued, a failure is only "submit unconfirmed"; structured runtime delivery requires live evidence for each exclusive send id on its bound thread, nonce and runtime epoch; busy user messages steer immediately without local joining, and Stop follows the provider's pending-input behavior; no paste follows RPC handoff; dead runtime channels receive one bounded same-session recovery attempt without replay, and failed recovery raises an incident; unsupported durable admission proof settles as not applicable without inventing non-delivery; screen-based refusals and delivery evidence follow the PTY contract; chat clears the composer immediately and shows one bubble with evidence-backed delivery state; Retry reuses it only for proven non-delivery and echoes never duplicate it; Delete cancels held input atomically against its write claim or durably dismisses uncertain and failed bubbles without replay; delivered bubbles have no Delete; authored bodies travel as pad files, never as inline shell text	stable; structured runtime delivery in rollout	core:pty, core:message-gateway-and-bridges	— (sink: fed by every inbound route)
capability:chat-view	Chat view	An agent read and driven as a conversation: tool cards, Mermaid, sandboxed HTML, file previews, voice and image attachments; a tab's recorded edits inspected cumulatively or per turn, as a diff or the full current file with fullscreen	Chat view and tab side panel; CLI tab chat	Bounded bodies initially clip without internal vertical scrolling; Show all raises their height limit by 30%, and expanded-body edge scrolling chains into the transcript on desktop and mobile; rendered HTML has no network or arbitrary file access; cards follow the CLI command tree; recorded edits follow the tab's own loaded transcript, sum recorded changes, preserve renames and disclose missing shell changes; current-file previews keep tab scope and size limits, and unavailable files retain access to recorded diffs; composer mentions follow the scoped search and plain-text contract in interface conventions	stable; remote attachment handoff and recorded changes view in rollout	client:ui	capability:message-delivery
capability:session-continuity	Session continuity	Tabs return after restart; past sessions of any provider are found by content and resumed	CLI sessions, tab rebind, tab repair, tab adopt-agent, agent restart recovers failed launches to the saved session; failure card Start new session; agent restart --fresh; tab menu Switch provider; agent switch-provider and provider-switch API	provider switches preserve tab and task identity, retire the old session, retain readable history and deliver bounded context for a target-generated summary; failed launches preserve provider, role, profile, saved session and exact restore data across restarts; agent restart resumes a session with this tab's own verified binding or journaled launch target only after its provider confirms existence for the tab's cwd, then binds a new nonce; saved recovery sessions never silently become fresh conversations; Tab restore after a restart is unconditional; with resume_sessions enabled (the default), a provider resumes only a session it uniquely owns; when disabled, a known provider launches fresh and the old binding remains history only; an agent mid-turn at any stop receives exactly one system continue once its own resumed session is agent-ready, while idle and unresumed tabs receive none; agent restart fresh-launches a known provider from a confirmed LaunchBindingUnconfirmed shell when no verified recovery session is available and reports resumed or fresh_launch; an unavailable exact restore never silently swaps conversations; the owner may explicitly start fresh in the same tab only after the provider confirms the saved session is missing, preserving identity and launch overrides; a live foreign PTY can be owner-adopted as an agent send target without restart; the lifecycle journal is telemetry, not authority; conversations are searched as sessions, durable facts in memory; a provider store session search could not fully read is named in the result, never a silent miss; General Agent recovery follows the Supporter limits	stable; provider handoff and bounded event-driven General Agent recovery in rollout	core:agents-and-providers, core:host-state, core:general-agent, core:crash-recovery-supervisor, core:supporter-agent	capability:chat-view
capability:scheduling	Scheduling	Agent work later or on a schedule; the machine kept awake while it runs	CLI cron, delayed, send --delay, keepawake; Mesh tab crons	System jobs carry explicit protection: they can be enabled or disabled, but cannot be deleted or have their schedule/task edited; a cron inherits its creator's Team unless detached; its owner-chosen directory carries trust provenance under the folder-trust contract; keep-awake goes through Domios, never OS tools directly	stable scheduling; owner-chosen cron folder trust and unattended notification handling merged for 1.12.4, in rollout	core:host-state, core:message-gateway-and-bridges, core:supporter-agent	capability:message-delivery
capability:sentinels	Blueprints	Agents describe recurring actions as Blueprint graphs that replace LLM polling: bounded probes or agent/CronRun observations, decisions among offered code-defined options, safe requests to answer provider-declared prompts, and unknown outcomes escalated to the creator or a same-Team agent; a Team member may amend the graph to handle that case next time	CLI blueprint webhook, blueprint check, blueprint apply, blueprint new --intent, blueprint keep, blueprint recipe, blueprint schema, blueprint export/import, blueprint update, blueprint history, blueprint escalation resolve, and blueprint delete; docs BLUEPRINTS; shared agent guidance; named graphs in Team Mission Control and workspace automation	The Blueprint contract admits native v2 YAML only; each code or command step runs with the user's own permissions, like an agent in a tab, without Domios credentials in its environment; foreign Blueprints are gated by folder trust (1.15.4). It preserves typed graph identity and refuses unsupported execution before effects, bounds probes and budgets, makes no model call on unchanged output, binds CronRun stages only to the verified run's recorded automation tab, resets the per-run transition allowance on replacement while retaining history under a separate lifetime cap, unbinds on completion or tab removal and notifies the creator on stops, lets the answer path choose only a provider-declared option, keeps every action code-defined, acts within the owning agent's authority, preserves creator visibility when a solo graph's creator joins a Team, retains creation scope, deletes stopped Blueprints and their history after 30 minutes unless an update restarts them, carries bounded purpose notes in definitions and recipes, and confines bounded definition detail to an opened Blueprint in its exact creation scope while keeping configured fallback separate from actual decision provenance	in rollout: explicitly kept generalised solution skills with 1-3 controlled catalogue tags for user browsing, committed save and eviction receipts, storage-bounded retention, callable consolidation requiring matching contents and agreeing purposes, descriptive-name conflict refusals, compact typed intent cards and immutable call reuse, probes, choice classification, closed handlers, named graphs, tab and CronRun observation, other escalation, provider-declared prompt response requests through the existing safe-answer path, versioned graph amendments, per-graph secret-authenticated JSON webhook triggers through the existing run executor, typed read-only canvases, nested call and selected-run evidence with bounded redacted per-port value previews, semantic review and read-only repository discovery	core:supporter-agent, core:host-state, core:message-gateway-and-bridges, core:prompts	capability:message-delivery, capability:scheduling, capability:notifications

2. Agents coordinate as meta-teams through plans

Detail: Plan canvas; team, plan, spec, and task command groups; plan and task APIs; core essence.

ID	Capability	What it enables	Entry points	Invariants	Status	Runs on	Feeds
capability:teams-and-roles	Teams and roles	An Orchestrator coordinates and verifies at speed; an optional Planner designs tasks; one optional Cartographer Manager authors the project essence map; Workers execute tasks	Plan canvas; CLI agent set-orchestrator, team, team attach-cartographer, team adopt-agent --peer, agent reparent, agent spawn --role, orchestrator; Team staffing API and socket	Role boundaries, plan adoption, close authority and safe Team teardown follow the orchestration contract; Workers never spawn and the Orchestrator owns plan approval and task acceptance; Full-access remote membership transfers require the current parent or owner, preserve the exact session and share the Team lifetime	stable	core:plans-and-orchestration, core:prompts	capability:task-fitted-personality, capability:dispatch-and-reports
capability:task-fitted-personality	Task-fitted personality	Each Worker starts from a framing that narrows its attention to its task and stays a recognisable colleague	Task executor role, role guidance, personality and model (CLI plan task add, plan task update); CLI persona	The Planner assigns the framing while cutting the task (the Orchestrator when planning is waived); executor role, one-word executor persona, and role guidance are required at creation and cannot be blanked; the persona name is kept for the worker's tab; Worker kinds add role prompts with or without task bindings and do not restrict execution ability; runtime overlays add leaf kinds only and never grant spawn or Team authority	stable	core:plans-and-orchestration, core:prompts	capability:dispatch-and-reports, capability:workspaces-and-tabs
capability:goals-specs-plans-and-tasks	Goals, specs, plans and tasks	Durable intent: goal, what and why, how, bounded tasks, evidence, and the plan skills every executor reads	Plan canvas; CLI plan, spec, task, effort, radar, plan skill; plan API	Planner state is the source of truth; every task carries acceptance criteria and an executable test plan; executors read applicable plan skills before acting	stable	core:plans-and-orchestration, client:ui	capability:dispatch-and-reports
capability:dispatch-and-reports	Dispatch and reports	One call spawns a Worker, assigns the task and delivers its brief; the Worker hands back by a report pushed into the Orchestrator's tab	CLI plan task dispatch, agent ack, agent report, plan task files, agent turns, todo submit/approve/amend	Local reassignment requires verified live binding and a fresh ACK; dispatch and respawn explicitly reopen blocked tasks while recording the old reason; respawn preserves prior review evidence; refused reports are diagnostics and never task reports; every Worker turn ends in a report; a report is input and is never replied to; only the live Plan owner marks a task done, including direct completion from pending, blocked or in progress with a result note; delivered task-bound reports carry one advisory verdict footer; a reopened task reuses its retained lane; locked checklist criteria retain their identity and text, warn when open at submission, complete on acceptance and reopen on bounce; checklist sharing and parent/Plan-owner review are advisory, with agent-to-agent proposal delivery and review, no human review cards in the parent chat, and unreviewed markers in sidebar and Underway; tool-less Workers receive capability-attached structured task files and exact attempt skills, and expose bounded completed own-session turns to their Orchestrator	stable; tool-less context and turn inspection in rollout	core:plans-and-orchestration, core:message-gateway-and-bridges	capability:isolated-lanes, capability:message-delivery, capability:review-and-decisions
capability:review-and-decisions	Review and decisions	Results accepted or bounced on evidence; owner questions routed as decision gates	CLI plan review, plan decision, plan qa	A bounce names the failing command and its evidence; it returns work to the Worker when its continuation is available, or reopens the task as pending when the Worker is gone, preserving the note, attempt history, and lane for redispatch; ambiguous attempts refuse	stable	core:plans-and-orchestration	capability:integration, capability:dispatch-and-reports
capability:reminders-milestones-and-pause	Reminders, milestones and pause	A plan keeps moving without polling; the owner can hold it	Heartbeat; CLI plan milestone, plan pause, plan resume	Plan pause is the only agent-issued pause; paused tasks are system holds and there is no separate pause command for a single task; the default Curator mirrors the Orchestrator model on a clamped cadence and replaces its heartbeat; owners may select heartbeat mode and interval; human waits suspend Curator rounds; each running round is a visible, temporary, read-only Manager tab without focus transfer; only its Orchestrator and the host deliver input; failures expose heartbeat fallback; plan events never produce extra reminders; a blocked verdict sends no reminder to its recipient and creates one owner notice per blocker; accepted reminders repeat only after recipient-local state changes	stable; task-pause removal in rollout	core:plans-and-orchestration, core:message-gateway-and-bridges	capability:message-delivery
capability:team-observer	Team observer	A small, cheap local model quietly watches a working team in the background, reads bounded changes in each agent's recent context, and surfaces simple truths: what each agent is doing, how the team is doing, who has been stuck too long; its hints help the Orchestrator and the owner see the team without reading it	Watcher role on a watcher-capable open agent shell (charter and tick policy)	Observes and suggests, never acts on a task or holds authority; uses changed observations rather than LLM polling; costs little enough to remain available	roadmap	core:agents-and-providers, core:plans-and-orchestration	capability:teams-and-roles

3. Work flows through isolated lanes into canonical

Detail: Plan canvas; plan, task, and review command groups; plan API; core essence.

ID	Capability	What it enables	Entry points	Invariants	Status	Runs on	Feeds
capability:isolated-lanes	Isolated lanes	Parallel writers, each in its own worktree and lane branch	CLI plan task dispatch, plan lanes	A mutating dispatch never writes the canonical checkout or another task's lane. The Orchestrator may explicitly opt one Worker into canonical instead; that opt-in is exclusive and holds lane acceptance until its verdict. Lane Workers run only isolated checks that do not rebuild the whole project: no full rebuilds, full suites, dev servers, packaging or self-install	stable	core:plans-and-orchestration	capability:integration
capability:integration	Integration	Accepted lanes land in canonical, collected per version on an integration branch	Git merge in the canonical checkout; CLI plan lane-remove	Real merge commits only, never cherry-pick, squash or replay; a lane is deleted only after its ancestry is proven	stable	core:plans-and-orchestration	capability:canonical-verification
capability:canonical-verification	Canonical verification	Executable QA for each merged wave, with utility work reporting its outcome to the coordinating agent	Build script operations; Team utility tabs; read-only verification Worker; CLI plan qa	One QA gate per physical machine at a time; utility reports distinguish proven readiness, completion and failure; tests run through the repository wrapper; Playwright runs with heightened attention when it is the right oracle, never as an automatic gate	stable	core:plans-and-orchestration	capability:release, capability:review-and-decisions
capability:generated-cli-artifacts	Generated CLI artifacts	The CLI manifest, CLI reference and chat command paths track the command tree	CLI cli-manifest	Regenerated by the CLI built from the checkout being changed, never hand-edited; a contract change audits docs, prompts, skills and cards	stable	client:cli	capability:chat-view, capability:release
capability:release	Release	Signed artifacts for macOS, Windows and Linux plus a public updater manifest	Release tag and workflows; release skill	Artifacts come from the tagged master commit; published tags never move; the release branch is cut from master and deleted at the tag; public issues close only after the released bytes are verified as served	stable	— (the repository toolchain, outside the product; see the core essence's leftovers)	capability:updates-and-local-install

4. Machines join a mesh

The mesh assumes a closed private network, typically a tailnet, and deploying it that way is the recommendation: peers reach each other over a private subnet rather than the open internet. Wider reach is never wildcard — it is authenticated, explicitly opted into and scoped to one chosen private address, with loopback staying primary.

Detail: Mesh tab; mesh, paste, and service command groups; mesh and service APIs; core essence.

ID	Capability	What it enables	Entry points	Invariants	Status	Runs on	Feeds
capability:pairing-and-trust	Pairing and trust	A flat mesh of the owner's machines	Mesh tab; CLI mesh	New links come only from the owner's account: both machines signed in, enrolled, online and directly reachable, each holding a fresh online authorization after the receiving machine approves the request; declining or ten minutes without approval cancels it; no broadcast, scan, manual address or introduction creates a link; the local web UI/API binds health-proven listeners on assigned Tailscale addresses whenever Tailscale and the API are enabled, independently of account sign-in and Mesh admission; signed-in machines publish their endpoint to the account; native address changes update listeners, and sign-out, revocation or Mesh off blocks peer traffic while preserving instance-token web API access; the Mesh UI card offers QR and token-bearing Open/Copy links only for proven listeners; listeners never bind wildcard or LAN addresses; pairs persisted before the account gate keep working as one-time legacy edges until both sides adopt them in place, and adoption never falls back; explicit sign-out blocks every edge and open stream without deleting it, the same account restores and another account cannot; retained slots carry explicit presence, a confirmed sign-out disables remote actions as Signed out independently of endpoints or expiry, and offline sign-out preserves the last confirmed remote observation; explicit disconnect removes the pair on both machines, immediately through a signed notice or on next contact if the peer was offline; account revoke also removes a pair; pairing keys on peer identity; dev instances have distinct mesh names and local CLI routing; access level is per peer and decided locally; one machine belongs to one mesh	stable	core:mesh	capability:remote-work
capability:remote-work	Remote work	Tabs, agents and plan commands on another machine; remote Workers report back across the mesh; payloads handed between machines by short id	--mesh PEER on CLI commands; CLI paste; mesh relay API	Hard rules bind on every peer; secrets never cross the mesh; pasted payloads are ephemeral, with a time to live	stable	core:mesh, core:message-gateway-and-bridges, core:general-agent	capability:dispatch-and-reports, capability:message-delivery
capability:service-registry	Service registry	Daemons with health probes, push tokens and an activity log; a daemon pushes text into a tab with its own token	Mesh tab; CLI service	A push token is shown once; rotation invalidates the old token; a peer's services are read from that peer, never gossiped	stable	core:mesh, core:host-state	capability:message-delivery

5. People reach agents through bridges, voice and the web

Detail: Integrations, bridge topics, notification panel, and web UI; bridge, plugin, notify, and web command groups; bridge, receiver, notification, and web APIs; core essence.

ID	Capability	What it enables	Entry points	Invariants	Status	Runs on	Feeds
capability:telegram-bridge	Telegram bridge	Conversation with the General Agent, and with individual tabs through their own topics; the poller can move to another peer without restarting either daemon	Settings Integrations; CLI bridge send, bridge thread, bridge react, bridge restart, bridge migrate	A bridge-routed message is answered through the bridge, never only in the tab; one poller per bot token; tab posts appear only in their topic when available, otherwise in General; migration runs on the source machine only	stable; unified topic attachment in rollout; other services planned	core:message-gateway-and-bridges, core:mesh, core:general-agent	capability:text-hooks, capability:voice, capability:message-delivery
capability:webhook-receivers	Webhook receivers	Plugins accept inbound events and deliver them to a chosen tab	CLI plugin receiver-target; plugin webhook API	A receiver that authenticates reads its secret from the secret store	stable; host transcription of receiver audio in rollout	core:message-gateway-and-bridges, core:plugin-host	capability:voice, capability:message-delivery
capability:text-hooks	Text hooks	A user daemon forwards, replaces or annotates inbound bridge text before the General Agent sees it	Integrations config	Agents act on hook metadata instead of re-classifying	stable	core:message-gateway-and-bridges	capability:message-delivery
capability:notifications	Notifications	Every agent notification is kept; its level decides whether it interrupts on desktop, sound or push	Bell panel; CLI notify	The bell keeps agent notify send records and daemon-owned Mesh connection approval requests and owner-enabled bounded Neighbor arrival previews; diagnostic system and automation events stay in logs; all transient floating notices the user must know about or act on share the local notification toast stack, while diagnostics use the development debug log, following the interface contract; local toasts never enter the bell; Workers and Planners route conditions to their report owner; user-owned cron prompts reach their live creator tab or the user; questions use choices, never provider prompt tools	stable	core:message-gateway-and-bridges, core:supporter-agent, client:ui	capability:telegram-bridge
capability:voice	Voice	Inbound voice becomes text through a swappable transcription service	Transcription settings; Transcriber plugin	The speech engine stays an external service behind one transcribe contract; hardware capture opens only the separately selected microphone on START, verifies the live track identity and releases its stream on exact-generation invalidation; the frozen clip enters ordinary owner voice delivery once	stable; confined hardware capture and invalidation in rollout; native local dictation planned	core:plugin-host, core:message-gateway-and-bridges	capability:message-delivery
capability:web-ui	Web UI	The full UI from a phone or browser over the owner's Tailnet	Daemon root URL; CLI web link	Tailnet-only by default; the API token is the credential; future web-client behavior shares the host judgment and evidence contract	stable; further Supporter-based web-client behavior is roadmap	client:ui, core:service-layer, core:supporter-agent	capability:chat-view

6. The host owns memory, secrets, plugins and configuration

Detail: Memory and Settings surfaces; mem, plugin, and config command groups; memory, secret, plugin, and configuration APIs; core essence.

ID	Capability	What it enables	Entry points	Invariants	Status	Runs on	Feeds
capability:guided-onboarding	Guided onboarding	First-run setup establishes the user and introduces useful host capabilities through the Guide; future journeys build on the spinal cord	General Agent first-run setup; Settings > Guide; chat Guide navigation	The General Agent may mention installed capabilities when directly relevant during the first seven days from its first session on the machine; Settings can disable this, and the host never injects suggestion cards. The onboarding contract keeps the Supporter introduction after setup, connection voluntary and future journeys within host authority	stable first-run setup; Supporter introduction and Guide navigation in rollout; further onboarding is roadmap	core:general-agent, core:prompts, core:supporter-agent, client:ui	capability:supporter-agent, capability:agent-providers
capability:memory-and-skills	Memory and skills	Durable facts, notes, preferences and folder skills with hybrid search, a graph and nightly consolidation, discoverable by every agent	Memory UI; CLI mem, mem skill; memory API	English only; persistent memory lives here and never in provider side stores; bodies carry no dates; skills are registered through memory, never written into provider skill directories; hidden memory workers trust their daemon-owned folder by the provenance contract; the memory contract bounds extraction retries and worker deadlines and keeps failure status and durations honest; model transitions retain published semantic recall; query inference has priority and a bounded keyword fallback; live embedding queue counts and failures remain visible	stable; hidden-worker folder provenance merged for 1.12.4, in rollout	core:memory	capability:memory-decision-rerank, capability:memory-hygiene, capability:agent-providers
capability:memory-decision-rerank	Memory decision recall	Recall ranked by how directly candidates answer the query, with optional candidate sources and an explicit relevance signal	Settings > Agents; memory search CLI and API; recall configuration	Connection enables ranking automatically; a per-search diagnostic override remains available; result preservation, baseline fallback, source admission and access accounting follow the memory contract; fan-out follows the Supporter quality boundary	stable; always-on connection and qualified shared-state scoring in rollout	core:memory, core:supporter-agent, core:host-state, client:ui, client:cli	capability:agent-providers
capability:supporter-agent	Supporter Agent	The OS spinal cord's shared judgments: rank memory, classify event-level states first with heuristic fallback, and support bounded recovery, Blueprints and provider update coordination	Settings > Agents > Supporter Agent; Guide; saved connection, model, activation, disconnect, token and status CLI/API	No feature switches; saved connections keep their own models and write-only tokens; removing active leaves none selected; stale state disables mutations; absent-model fallback preserves behavior; evidence authorizes and the model names; no request cap by default, explicit positive caps and spend guards follow the Supporter contract	stable decision interface; always-on core and bounded recovery in rollout; model-first event coverage and no default request cap planned for 1.12.4	core:supporter-agent, core:host-state, client:ui, client:cli	capability:memory-decision-rerank, capability:health-and-diagnostics, capability:session-continuity, capability:scheduling, capability:notifications, capability:provider-updates, capability:guided-onboarding, capability:web-ui, capability:sentinels, capability:usage-and-analytics
capability:memory-hygiene	Memory hygiene	The Dreamer consolidates knowledge reversibly and leaves an honest record of completed and unfinished work	CLI mem dream, mem merge, mem area merge, mem taxonomy, mem restore, mem calibration stale, mem graph hubs; memory API and dream diary	Archives preserve history; protected knowledge survives consolidation; stale archival is off by default; the memory contract owns restore, budgets, graph suggestions and partial finalization	stable	core:memory	capability:memory-and-skills
capability:secret-store	Secret store	Local credentials for Domios, plugins and bridges	Settings Secrets; CLI mem secret, plugin get, plugin config --secret; secrets API	Values arrive on stdin, never argv; plugin get exposes secret presence only; secrets stay on their machine	stable	core:host-state	capability:telegram-bridge, capability:webhook-receivers
capability:plugins-and-channels	Plugins and channels	Providers and capability plugins installed from channels; plugin views run in sandboxed frames; plugins declare graph nodes whose conversions the host chains by declaration; a helper guides the owner through setup	Marketplace and Plugins panel with sensitive-permission consent and toggles; CLI plugin, plugin channel list/diff/refresh; plugin and Mesh setup buttons; helper spawn API	The system channel is included in list, diff and refresh even before local registration; core providers release independently with explicit minimum host versions and synchronize silently without a user update action; official core installs are trusted and never downgraded by an older embedded fallback; plugin code runs confined; missing sensitive grants receive explicit consent and a single refused-action retry; setup changes require owner confirmation through the permission-gated configuration path; a helper always opens in the General workspace with the General Agent's provider, regardless of which workspace was active	stable; helper General placement in rollout	core:plugin-host, core:agents-and-providers	capability:agent-providers, capability:webhook-receivers, capability:voice
capability:provider-integrations	Provider integrations	Provider hooks bind sessions to tabs	Settings; CLI integration	Hook content is instance-agnostic; Domios rewrites only hooks it owns; install records consent; only the machine owner reclaims dead launch profiles, preserves provider trust and keeps live or unknown instances; exact-pattern legacy cleanup reports counts once	stable	core:agents-and-providers	capability:session-continuity
capability:configuration-and-themes	Configuration and themes	Settings, themes and keybindings read and written	Settings; CLI config, theme	Configuration keys use dot notation; sensitive configuration and state restrict broad access on every OS while preserving explicit runtime access grants; the API credential is held separately in the local secret store and snapshotted at startup; a full dump is redacted; writes to held configuration fail without changing live settings until the file is repaired or restored	stable	core:host-state, client:ui	capability:notifications, capability:text-hooks

7. The product observes and updates itself

Detail: Health and update surfaces; identify, tab, orchestrator, plan, and update command groups; health and update APIs; core essence.

ID	Capability	What it enables	Entry points	Invariants	Status	Runs on	Feeds
capability:essence-anchored-code-map	Essence-anchored code map	A generated source map and optional Cartographer preserve the product foundation; planned code-to-essence mapping helps agents identify the capabilities and expectations a code change touches	Workspace Map view Create map and Refresh map; CLI essence-map generation and validation; Team Cartographer staffing; planned code-to-essence mapping	The map is an indirect beacon: work is done with an eye on it, but real architecture is more complex and is never bent to mirror the map; essences stay the stable anchor; the map is generated, never hand-drawn	in rollout: source-map generation, validation, Cartographer and workspace map canvas; code-to-essence mapping planned	core:plans-and-orchestration, client:ui	capability:canonical-verification
capability:accounts	Domios accounts	A signed-in identity shared by account-dependent features	Settings > Account and General > Neighbors; CLI account, account neighbors; local account API	Hosted sign-in uses the system browser, a matching random state and backend-verified PKCE; active ID tokens stay in memory and ordinary calls reuse them until expiry, concurrent refreshes share one result and post-call session checks stay local; account and Mesh installation credentials stay in a local owner-only private file, startup never waits on a remote vault or prompts for OS credentials; sign-out blocks locally and deletes the refresh credential before one bounded server session and receiver stop, reports an unconfirmed stop offline, and keeps an executable cleanup intent with only the captured ID token until expiry; native connectivity changes or the next sign-in complete cleanup before a new session is published, without restoring the old session; Neighbor channels use one active receiving installation chosen only through revision-bound confirmation, live receiver state on every signed-in machine, no inbox delivery elsewhere, OS-stored private keys, encrypted relay envelopes, local owner or General Agent grants, friendship-owned concierge bindings and bounded local conversation history, verify-decrypt-admit-ack ordering and content-free delivery status; a persisted per-instance switch hot-stops channel admission and request notifications while preserving list reads, connections and keys; Free retains connections with a locked channel; Domios referral admission, signed writing access and ordinary no-trial subscription choices follow the account contract; installation-bound session revocation signs out a named machine, preserves its installation key, blocks Mesh and opens sign-in with a clear explanation; a local development provider works without an external account	implementation in rollout	core:service-layer, client:ui, client:cli	capability:product-analytics
capability:product-analytics	Product analytics	Optional feature usage with a closed typed event catalog	Settings > General; CLI analytics; local analytics API	On by default only for absent local settings; the local toggle gates desktop events to Amplitude, and OFF stops delivery and persists across restart; no desktop server-consent or identity-linking calls; backend funnel events are independent; one toggle and a passive first-run Settings link shown only for local ON, with no consent dialog, banner or toast; no prompts, paths, names or terminal output; providers share bounded queue and retry rules	implementation in rollout	core:service-layer, client:ui, client:cli	—
capability:usage-and-analytics	Usage and Analytics	Provider quota projections and token usage per tab and plan, with planned Supporter spend alongside provider allowances	Analytics titlebar view; provider allowance views; CLI usage; usage and Supporter status APIs	Refresh reads the provider's quota-free source and never spends quota; provider-declared rate-limit reset credits show their available count and known expiry, spending requires explicit irreversible-action confirmation, and retries reuse that confirmation request; each provider response counts once; a ledger rebuild is idempotent; Supporter costs follow the estimated-spend contract	stable; ledger rebuild and confirmed reset credits in rollout; decision-adapter spend row beside allowances planned for 1.12.4	core:host-state, core:plugin-host, core:supporter-agent, client:ui	— (sink: fed by Agent providers and Supporter Agent)
capability:health-and-diagnostics	Health and diagnostics	Liveness, running build identity, orchestration and plan consistency, with visible Supporter activity and limits	Health API; CLI identify, tab inspect, orchestrator status, plan doctor; Supporter status CLI/API and Settings > Agents; planned activity feeds in General and Team Mission Control	Debugging starts by confirming the running build matches the source; model observations remain distinct from authoritative state; activity views show scrubbed, capped daemon-owned questions and answers, group named questions per model request and follow the redacted visibility contract	stable; Supporter accounting and recovery evidence in rollout; General and per-Team activity feeds planned for 1.12.4	core:service-layer, core:crash-recovery-supervisor, core:supporter-agent	capability:session-continuity
capability:provider-updates	Provider updates	Provider CLI updates with session-preserving runtime handoff	Declared provider update checks and safe prompt observations; Settings CLI status; automatic update setting	The provider update contract owns deduplication and safe prompt choices; active turns defer background updates; explicit verified updates restart idle runtimes and wait for active turns, preserving sessions and never replaying input; runtime failures receive one recovery attempt; incompatible targets are withheld; results stay in logs and Settings	Claude, Codex and OpenCode silent updates in rollout; remaining provider coverage planned	core:agents-and-providers, core:supporter-agent, core:host-state	capability:session-continuity
capability:updates-and-local-install	Updates and local install	Signed updates checked, installed and relaunched; a local production build installed on this machine resumes the calling tab	One grouped Update surface for app, plugins and Interface; CLI update check, update install; build script local install	One authoritative availability inventory covers plugins, app and interface bundle and publishes changes after actions; badges count only compatible newer user updates; Update all persists its intent, applies the app first and rechecks plugin compatibility against the resumed host before the Interface swap; Interface swaps require explicit consent and health-confirmed activation with rollback; a client is offered only an artifact for its own platform and compatible host; manifests are signature-verified; channel switching is disabled; local install is an explicit operation and development commands never touch production's port or CLI	stable	core:service-layer, client:cli, core:crash-recovery-supervisor	capability:session-continuity

Stable capability contracts

Agent models

Each provider owns its model and reasoning-effort catalog. A live provider catalog defines the models that can be launched: user settings may reorder or describe those entries but cannot add or hide them. Without a live catalog, the provider's static catalog and user settings define the choices; settings merge by model identifier by default, while an explicit full-list setting replaces that static catalog.

Model availability has three honest states: available, unavailable, and unknown. A confirmed unavailable model is disabled. A failed or inconclusive availability check remains unknown and selectable; it is never reported as unavailable. Provider group labels, per-group usage, and quota values come from that provider, and Domios does not infer missing labels or balances. Usage retains the provider-declared billing mode and whether limits were reported; a subscription without metrics shows that limits were not reported. Unsupported reasoning efforts are refused at launch rather than silently downgraded. See the core essence for provider boundaries and session ownership.

The status line presents the harness as plain text and the model and effort as the picker control. Provider-declared primary models form the initial short list; Show all models exposes the complete catalogue and remembers the choice per provider. Search always spans the complete catalogue. Providers without primary models show their full catalogue.

The status-line model picker stages model, reasoning, and declared runtime-mode choices until Apply. Cancel or Escape discards the draft; restart confirmation follows Apply when required. The status line immediately displays the applied selection, including next-turn choices, and restores its previous display if the request fails. Busy model and effort changes are staged as pending unless the provider explicitly supports commands during an active turn. Such commands are sent immediately in the same session, answer only declared screen states, and require fresh session confirmation. A harness that buffers output shows “Switch sent; confirms when this turn ends” until exact own-session evidence arrives; only proven refusal or an unrecognized confirmation is a failure incident. Confirmed model and effort changes preserve the session, and restart remains a separate explicit action.

Providers that declare NextTurn switching apply model, reasoning effort and runtime-mode changes to the next turn without restarting. A successful request remains pending until the tab's own thread reports the setting or model. The agentRuntime capability selects Chat-only stdio transport with one tab-owned process and exact thread. Live chat and history reconcile stable items, and approval replies target the exact pending server request in the current runtime epoch. Nonfatal runtime bookkeeping failures warn once per epoch and keep the turn running. Process or pipe failure remains visible with a reason and Retry; a real readiness, send or command event may resume the same thread within a failure deadline. Recovery never silently opens a fresh conversation, falls back to a terminal, or replays uncertain input. Signed-out providers share capability-declared sign-in, cancellation and link/code cards. Get started continues verified CLI installation automatically and presents CLI account choices before starting the General; runtime sign-in supports browser, device-code and masked API-key methods. A verified completion resumes the same thread; API keys never enter argv, logs or the mesh.

Web UI and health

The web UI serves the complete interface to a phone or browser over the owner's private Tailnet, with no cloud relay and no public exposure by default. Access requires both Tailnet membership and the instance's API token. A paired machine uses its own web address and token. See the core essence for the web client and service boundaries.

The health API is the daemon's liveness signal and reports its status, startup readiness, build identity, version, instance name and platform. A live listener is distinct from a ready service; only loopback health requests bypass authentication. Desktop and web startup show the current daemon phase until the service is ready. Memory-intensive background work is bounded and isolated so it cannot take down or starve API handling. An external supervisor owns recovery when the daemon exits or stops answering its liveness check. See the core essence for health and crash-recovery ownership.