Intentloom Desktop

Status: v0.6.0-beta.1 milestone complete.

Intentloom Desktop is the official local graphical client for the existing Intentloom platform. It is built over the standalone authenticated daemon and the versioned local protocol. It does not replace the CLI, TUI, MCP server, TypeScript-first core, application operations, or transaction engine.

Read in this order

1. v0.6.0-beta.1 Readiness Audit
2. Desktop design brief
3. Desktop v0.6 implementation plan
4. ADR-0042: Desktop Stack and Self-Contained Daemon Distribution
5. Self-contained daemon SEA feasibility spike
6. Phase 1 client contracts
7. Accessibility Audit
8. Interactive Surfaces and Agent Workspace
9. ADR-0032: Second Client Daemon Protocol Contracts
10. ADR-0033: Interactive Surfaces
11. Agent execution prompt

Product sequence

release-state closure
        ↓
Desktop stack and distribution ADR
        ↓
client contract inventory and freeze
        ↓
Tauri 2 read-only vertical slice
        ↓
Desktop Workspace review surfaces
        ↓
TUI parity and hardening
        ↓
separately reviewed Approved Apply

First vertical slice

Launch
→ connect to or start intentloomd
→ select a project
→ confirm the canonical project root
→ Overview
→ Inspect
→ Doctor
→ Diff
→ Timeline

The first slice is read-only. The current shell is intentionally disconnected from the daemon until native lifecycle, token ownership, and bounded IPC are wired. Opening, navigating, refreshing, cancelling, or closing the connected application must leave the selected project byte-for-byte unchanged.

Scope labels

Every design frame, issue, and implementation task must use one of these labels:

• v0.6 MVP: required for the first read-only Desktop vertical slice;
• v0.6 follow-up: Workspace or TUI work that follows the stable read-only slice;
• future: approved roadmap surface that is not part of the current milestone;
• concept only: exploration with no implementation commitment.

Future-looking screens must not imply that live providers, external MCP ingestion, managed extension installation, hosted accounts, unrestricted shell access, model training, or autonomous repository mutation already exist.

Architectural boundary

Desktop webview
      ↓
typed Desktop client
      ↓
minimal Tauri transport and lifecycle bridge
      ↓
authenticated local IPC
      ↓
intentloomd
      ↓
versioned protocol and shared application operations

The Tauri Rust layer may own native window, dialog, secure process, endpoint, token, and IPC transport concerns. It must not reimplement project inspection, doctor, diff, timeline, evidence, conformance, ownership, approval, or transaction rules.

Packaging uses one maintainer command: pnpm desktop:package. That builds the current daemon, generates a self-contained SEA sidecar, rejects scripts and stale src-tauri/resources/intentloomd copies, copies a stamped sidecar into the Tauri resource path, packages Desktop, and probes the bundled daemon. pnpm desktop:prepare-sidecar remains the low-level copy step for CI internals and requires INTENTLOOM_DESKTOP_SIDECAR to already point at a validated SEA executable. pnpm --filter @intentloom/desktop package only runs the Tauri bundle after that stamp exists; it refuses to reuse an unstamped Node script. Development cargo check keeps bundling disabled and never substitutes a system Node runtime for a packaged sidecar.