10 · How it works / USER GUIDE

One board. Native execution at the edge.

A small Go server and clients coordinate work while native tools retain execution, sign-in and permissions on their own devices.

Discovery Control route Relationships Sources of truth Pending proof

Discovery observes; it does not control

On an enrolled device, native Codex and Claude metadata is read by the local collector. HTTPS reports go to the private Go server and its saved state. The authenticated dashboard reads that state. Provider credentials remain on the device. — Implemented enrolled metadata path. The public docs and curated public dashboard do not query private runtime data.

The collector reads only supported native sources within approved same-user roots and reports bounded metadata over authenticated HTTPS. History requires a separate opt-in and grant. The server persists accepted state; browser views show that state and its age. A collector is deterministic, so unchanged polling does not call a model.

The CEO and destination control route

CEO native session calls scoped MCP relay, which accesses the server. The intended execution continuation is server to enrolled destination client to local native provider. Reply and native identity receipts return through the client; Desktop visibility and Open require a separate check. Dashed lines indicate pending general route acceptance. — Solid: finite CEO MCP read/report demonstrated. Dashed: intended general destination-client execution route; end-to-end Desktop acceptance PENDING.

A CEO is a real native provider session using scoped MCP tools. The demonstrated tools read a board and post an attributed note through the normal relay. Server authorization limits which actor can access which board/task/session; ordinary native provider permissions still govern execution. Optional custom hardening is a separate concern.

For the intended create/message route, the server records an authorized request; the enrolled destination client resolves its local provider and project and owns the supported native transport. Request acceptance, native creation, native reply and Desktop Open are four separate receipts. Source contains request/grant/claim/event machinery, but that alone does not establish a generally deployed control workflow.

If delivery becomes uncertain, reconcile the original request and native identity before another attempt. A separate-runtime resume must not masquerade as attachment to an active original turn. Provider databases are not patched to force visibility.

Logical relationships

A board has zero or more tasks. Each task belongs to one board. Tasks assign zero or more sessions and sessions can be assigned to zero or more tasks. A discovered session references one enrolled device while manually registered sessions may have no device reference. — Source-backed logical view of workspace records and discovery attribution. This is not a relational database schema or cascade-delete contract.

The current Go workspace stores boards, tasks and sessions in private JSON state; protected history/question storage is separate. Task assignments contain session references. A session retains participant, host, provider and native identity; device attribution is present for discovery and can be absent for manual registration. Project evidence and owner overrides are grouping metadata, not a physical project table in this diagram.

Sources of truth and derived views

Fact	Authority	Derived or limited evidence
Task goal, assignment, acceptance	Private DELEGATOR board	Summaries and progress labels need supporting proof.
Native execution and approvals	Original supported native provider channel	A catalog row, PID or report receipt does not establish native state.
Device reporting freshness	Server acceptance timestamp and enrollment	Online/fresh does not mean working.
Code change or CI result	GitLab repository/MR/commit/pipeline	Cached external evidence and explicit links do not accept a task.
History	Captured private generation plus its provenance and coverage	Transport completion is not complete native backup.
Public status	Reviewed dated documentation	A curated snapshot, not a live private-data feed.

What still needs proof

Destination control: one authorized native create/reply on the correct device, duplicate-safe replay and separate actual Desktop Open.
Durable continuity: versioned handoffs and reliable successor attribution without automatic replacement from weak signals.
History completeness: compatible installed capture, full requested coverage and truthful partial/recovery behavior.
Automatic coordination: scoped useful actions, allowance admission, one-child limits, recovery and native permission waits under real execution.

These are accepted outcomes or engineering work, not settled implementation claims. The delivery owner retains acceptance responsibility. See the dated status for the current boundary.