[shaohaozhi286]

Summary

Design proposal for a native desktop version of ACECode that embeds a system-provided WebView and reuses the existing acecode daemon + web/ front-end. Motivated by feedback that the FTXUI TUI is hard to operate.

Three docs under docs/desktop-shell/:

• proposal.md — what & why, scope, non-goals, acceptance criteria. Captures the decision against Tauri/Electron (toolchain split, npm reintroduction) in favor of webview/webview (system-native WebView, fits existing CMake/vcpkg flow).
• design.md — 14 numbered decisions: daemon as child process (crash isolation, reuses worker.cpp::run_worker), per-launch loopback token, --port 0 ephemeral binding, OS-level parent-death tracking (Job Object on Windows, prctl PR_SET_PDEATHSIG on Linux, kqueue EVFILT_PROC on macOS), additive front-end deltas only.
• tasks.md — 10-phase implementation plan: daemon CLI extensions → front-end token injection → desktop binary skeleton → supervision → WebView host → native integrations → CLI → docs → packaging → polish.

No code changes in this PR — design only. Implementation lands in follow-up PRs per the phased plan.

Note: the originally proposed location openspec/changes/add-desktop-shell/ is gitignored (matches openspec CLI convention). Docs are placed under docs/desktop-shell/ to follow the same tracked-public pattern as docs/daemon-api.md.

Test plan

• Reviewer reads proposal.md, agrees on scope (single window v1, no auto-update v1, no front-end rewrite).
• Reviewer reads design.md §3 (daemon-as-child) and §6 (per-launch token), confirms approach.
• Reviewer reviews tasks.md phase ordering — phases 1 & 2 can be parallelized, are they actually independent?
• Open question §12 (multi-window, settings UI, plugin API, auto-update, telemetry) — flag any that should be in v1 instead of deferred.

https://claude.ai/code/session_01Ds9DoAecUiN5tivHVfiSmR

---

Generated by Claude Code