Reference · The local companion
The local companion
The desktop app keeps its own store and its own cases, with the same seven sections and the same words as the hosted app. What crosses between them is bounded and named: a case pushed up, a team's decision pulled back, a prevention package staged for the next session, and receipts about what a session did with it.
See it in motion
The same case, two stores
A case the desktop app opens from a local source (a failed build, a guard, a local pull of Sentry, Vercel, GitHub or PostHog, a manual report) lives in the local store first. When the machine is bound to a team, the case and its receipts are pushed to the hosted account, where the team reads it in the same seven sections. The local case keeps its own status; the team's status is mirrored beside it.
What comes back
A decision an owner or admin makes on the hosted app, a status move or an assignee, is pulled back on a cursor: the local app asks for decisions on this machine's cases since the last one it took, applies each, and records when it pulled. The case detail shows the mirror as mirrored with who decided and when, and as stale when the local status and the team's status disagree, so a person sees the difference rather than one side silently winning. A cursor never rewinds.
The same request brings back the team's current approval on each case: a build approval bound to the digest the desktop verified, or a containment approval. The Fix section's Team approval row shows who approved and when, and for a build whether the approved digest is still the head this machine verified; when the branch moved after the team approved, the row says the approval does not cover what is there now. It sits beside the local approval and never replaces it: the build and the merge on the desktop still take their own approve.
Prevention packages on this machine
A published package reaches the desktop app through a delta the app pulls after its durable cursor. Each version is staged under the repository's brain directory by a write to a temporary file and a rename, the next-session manifest is rebuilt from what is on disk, and the curated block in the instruction files is kept without overwriting an edit a person made inside it. The app acknowledges delivered and installed by exact version and hash. At session start the briefing reads the manifest into context and leaves a retrieval receipt; with no manifest it says package protection is unverified. Receipts about retrieval, acknowledgment, use and a guard's run are pushed to the team's ledger in a batch. The workflow end to end is the package page.
Unbound, offline, stale
- Not bound
- Every team read answers a stated zero state: there is no registry to pull from and nothing to push to. Local cases, local checks and local results work as they do bound.
- Offline
- A pull that cannot reach the service keeps its cursor and its last result. Staged packages stay; the manifest is shown as stale past the policy's age and kept under it; revocations are reconciled on the next successful pull before the manifest is called current again.
- Parked
- A local source that failed five times in a row stops retrying with its last health word until a person fixes the cause. The words and their fixes.
What never crosses
Code stays local. A raw transcript crosses only under a grant a person gave, and a package never carries one. The full private brain is never committed to a repository. What leaves, what stays and who can delete is on Privacy and retention; the case's shape is on The incident case.
Last updated