# Desktop Host Round 13 Plan

## Summary

Round 13 should turn the existing desktop backend facade and Tauri-shaped command adapter into a real runnable desktop host scaffold.

The key distinction is:

- `src/desktop.rs` already defines the backend-facing desktop contract
- `src/desktop/tauri.rs` already defines Tauri-shaped command DTOs and wrappers
- `src-tauri/` currently exists only as a scaffold crate and does not yet boot a real Tauri application

This round should close that gap without redesigning the lifecycle or retrieval core.

## Current Baseline

Already implemented:

- desktop-facing Rust facade in `src/desktop.rs`
- Tauri command adapter module in `src/desktop/tauri.rs`
- desktop/Tauri smoke coverage against the command adapter layer
- `src-tauri/` scaffold crate that re-exports command symbols

Still missing:

- actual Tauri app bootstrap
- command registration into a runnable host
- Tauri config/app manifest
- frontend shell for invoking the desktop flows

## Goals

1. make the desktop host real enough to run locally
2. keep the desktop host thin by delegating all business logic to existing desktop/service layers
3. expose only a narrow, stable initial workflow instead of attempting a full product shell in one round

## Scope

### In Scope

- convert `src-tauri/` from scaffold into a minimal runnable Tauri host
- register the existing desktop command wrappers as invokable host commands
- add the smallest frontend shell that can exercise:
  - context retrieval
  - wakeup generation
  - review queue loading
  - record detail/history loading
  - manual/proposed memory creation
  - accept / promote / archive actions
- preserve `DesktopErrorEnvelope` as the error contract crossing the host boundary

### Out Of Scope

- batch lifecycle actions
- edit-in-place record mutation
- redesigning desktop payload shapes
- replacing shared lifecycle formatter/summary helpers with desktop-only variants
- introducing new retrieval logic or ingestion pipelines in this round

## Architecture Constraints

1. desktop host code should call `src/desktop.rs` through the existing Tauri adapter layer instead of reaching directly into lower-level services
2. response payload shapes should stay aligned with `src/lifecycle_summary.rs`
3. the host should not invent a second validation or error taxonomy beyond `DesktopErrorEnvelope`
4. lifecycle actions remain append-only and single-record
5. daemon usage remains optional and additive

## Proposed Work Breakdown

### Step 1: Host Bootstrap

- add the actual Tauri dependency and app bootstrap to `src-tauri`
- replace the current placeholder `main.rs` scaffold with a real Tauri startup path
- add required Tauri config files

### Step 2: Command Registration

- register the existing command wrappers from `src-tauri/src/commands.rs`
- verify serde request/response shapes remain unchanged
- keep command names stable and narrow

### Step 3: Minimal Frontend Shell

- create one narrow operator shell instead of a broad navigation system
- first-screen priority:
  - load workbench
  - inspect selected record
  - inspect history
  - create manual/proposed memory
  - apply single-record actions
- second-screen priority:
  - context retrieval
  - wakeup generation

### Step 4: Verification

- keep existing Rust smoke coverage green
- add a host-level smoke path where feasible
- validate that desktop errors surface as structured envelopes
- validate that the frontend shell can complete one end-to-end memory review cycle

## Suggested Delivery Slice

The smallest acceptable slice for this round is:

1. runnable Tauri host
2. registered commands
3. workbench + record/history + action flow
4. create/propose flow

Context retrieval and wakeup UI can be added in the same round if the shell stays small, but they are secondary to proving the lifecycle workbench flow.

## Risks

- spending too much time on frontend shell aesthetics before the command loop is proven
- bypassing shared desktop contracts and recreating logic in the host
- overbuilding navigation before the first operator flow works
- drifting response/error contracts away from CLI/MCP/desktop shared helpers

## Completion Criteria

Round 13 should be considered complete when:

- `src-tauri` boots a real app host locally
- the existing desktop command wrappers are registered and invokable
- one operator can load the queue, inspect a record, inspect history, create/propose memory, and apply a lifecycle action from the desktop shell
- structured error envelopes survive the host boundary
- existing Rust tests remain green

## Follow-Up After Round 13

If Round 13 succeeds, the next likely desktop follow-up should be:

1. refine shell ergonomics and state management
2. add context/wakeup screens if they were deferred
3. decide whether daemon preferences should become a visible desktop setting
4. only after that, consider richer desktop-only conveniences

## Current Progress

Last checked: `2026-04-14`

Implemented in the current slice:

- added a real `tauri` host bootstrap in `src-tauri`
- registered the existing desktop command wrappers as invokable host commands
- added `tauri.conf.json`, `build.rs`, and a minimal icon asset
- added a zero-dependency static frontend shell under `frontend/`
- verified `cargo check --manifest-path src-tauri/Cargo.toml`
- verified `cargo test --test tauri_smoke`

Still open inside Round 13:

- improve frontend ergonomics and operator flow polish
- decide whether daemon settings should be visible in the desktop shell
- decide whether the current static frontend should remain static or later move under a richer frontend toolchain
