Project study / Developer Tools
Active Development
Daemon
A local-first desktop co-partner that turns bounded context and persistent state into a visible Mate presence.
Daemon is a macOS-first desktop companion: Binder and local signals remain authoritative context sources while Daemon owns continuity, attention policy, presentation state, and clean human handoff.
System portrait / documented flow
Diagram routes and groups
Authoritative context
- Binder / project context
- Desktop signals
Bounded synthesis
- Context contracts
- Attention / policy
Continuity
- Persistent working state
Presentation
- Mate
- Island
- RESTING / PEEK / EXPANDED
- Binder / project contextAuthoritative input
- Context + policyBounded synthesis
- Persistent stateContinuity
- Mate / IslandDesktop presence
02 / Problem and response
Make a persistent desktop presence useful without turning it into a chatbot or mascot.
Constraint
Desktop assistants often collapse into a chatbot or mascot, leaving context ownership, interruption, and action boundaries unclear.
A persistent companion needs to earn its place on the desktop while remaining useful without AI, without AP, and without duplicating the systems that own project truth.
Approach
Daemon separates native desktop presence from semantic state and rendering: a Mate and an edge-attached Island make continuity visible without turning the character into the product itself.
It consumes bounded Binder and local context, applies deterministic attention and policy, and hands work back cleanly; optional AI and AP sit beside that loop rather than owning it.
03 / Architecture and boundaries
Context, state, policy, and presentation keep their boundaries.
Native platform adapters, Binder capabilities, and local signals enter through explicit context contracts; Binder remains authoritative for project truth and Daemon does not crawl or duplicate its database.
Daemon owns continuity, behavior and attention policy, persistent working state, scheduling, and the executor boundary before projecting semantic state to its shell and face renderer.
Rust/AppKit owns physical desktop placement and persistence while React owns semantic state, orientation, pose, and expression across the Mate and Island surfaces.
Authoritative context
Binder's read-only project capabilities and native/local signals provide bounded context; Daemon consumes it without taking ownership.
State and policy
Continuity, attention, policy, scheduling, and clean handoff keep the product useful without requiring a model or constant interruption.
Desktop presence
Mate and Island remain separate surfaces while native placement and React-rendered visual state stay in their appropriate boundaries.
- 01
The native shell, independent windows, menu-bar presence, Island anchors, and RESTING / PEEK / EXPANDED presentation states are implemented.
- 02
Live desktop context collection, broader initiative behavior, and the final presentation-viability gate remain active product work.
- 03
Binder owns project semantics; AP is optional routing and Daemon remains useful locally and offline.
04 / Current state and next work
What exists, and what follows.
Active Development
Native presentation is proven; the daily-use gate, initiative loop, and broader context work remain ahead.
Started 2026 · Last updated October 2026
Next direction
- Complete the presentation-viability gate with a compact composed home, home / away semantics, and persisted preferences.
- Strengthen the Binder capability bridge and define the product contract for context and initiative.
- Develop the initiative and return-handoff loop behind explicit policy and executor boundaries.
A desktop presence has to earn its place through useful continuity, not character polish alone.
Working lesson / Daemon