Write Path
The Core is the source of truth for every project, task, session, pin, and session icon on that machine. It opens its own SQLite read-write and applies mutations itself. The Panel is a connection broker, not a data store.
Mutations travel as core-link frames (projectsMutate, tasksMutate, and the rest of that set). They are not REST. There is no POST /api/projects/:id/tasks. That HTTP task API is retired; it does not exist. Third parties write with @actana/sdk.
A project's path is a machine path on the Core. Only that Core can stat it. The Panel sends a candidate path; the Core rejects it if it is not absolute, not resolvable, or a file. The Panel never sees the Core's filesystem.
What the Panel stores
Two things:
- the Core registry — endpoints, sealed pairing credentials, aliases
- one
lastEventIdper Core — the event cursor for replay
Nothing task-shaped lives here. Titles, session icons, pin flags, remembered session settings: Core facts, patched over the core link, identical for every Panel connected to that Core. Offline Cores show as unreachable plus last-seen, with no cached rows.
The Fleet view fans out live tasks.list calls and merges by coreId/taskId. It is an aggregate, not a cache. Cross-Core views are eventual parallel queries, never one SQL statement on the Panel.
Events
Each mutation appends to the same monotonic event log the PTY lifecycle uses (project:created, task:updated, and so on). A reconnecting client learns about writes via lastEventId replay. No separate event channel.
A Core client sends a starting prompt as text and sends no timing with it. Prompt delivery — when to write, which dialog to answer, when the carriage return goes out — is the Core's, end to end.
See also
- Architecture — Panel vs Core.
- Core link — the frames those mutations ride.
- HTTP surfaces — three HTTP surfaces, none a public write API.
- SDK —
CoreClient/CoreSessionfor programmatic writes.
