Replace the manual developer-run launcher with a single tab-bar toggle that records enabled and active state for the next desktop launch. Electron starts an isolated CDP profile on Windows, Linux, and macOS, while Tauri enables the supported WebView2 path on Windows and keeps unsupported hosts hidden. Route project-local OpenCode automation through an authenticated loopback bridge with window, instance, and session ownership checks. Keep the externally owned OpenCode daemon alive during desktop relaunches and make DOM clicks use resolved HTMLElement activation instead of fragile synthetic mouse coordinates. Harden Electron shutdown against destroyed WebContents races by retaining the original renderer handle and removing registry mappings by window identity. Relaunch now occurs only after renderer state, client state, and the embedded CodeNomad server have shut down. Validated with Electron 178/178 tests, server 369 passing and 2 skipped, Tauri 131/131 tests, the Windows Electron package build, and live inspect/click/screenshot/restart reconnection while the OpenCode daemon PID remained stable.
3 KiB
Documentation Index
Quick reference to all documentation files.
Main Documents
README.md
Project overview, installation, and getting started guide.
SUMMARY.md
Executive summary of the entire project - start here!
MVP-PRINCIPLES.md
MVP development philosophy - Focus on functionality, NOT performance ⚡
DESKTOP_V2_COMPARISON.md
Incremental comparison with official OpenCode Desktop V2, including parity, closed defects, remaining correctness work, runtime upgrade scope, and optional feature gaps.
DEV_V2_CODE_REDUCTION.md
Measured DEV-v2 growth analysis, maintainer position on test volume, ranked reduction candidates, and guardrails for later simplification without product regressions.
DEVELOPER_MODE.md
Persistent Electron/Tauri Developer Mode, OpenCode feedback tools, reconnect behavior, and trust boundaries.
Specification Documents
architecture.md
Complete system architecture
- Component layers and responsibilities
- State management structure
- Data flow diagrams
- Technology stack
- Security and performance considerations
Read this to understand: How the app is structured
user-interface.md
Complete UI/UX specifications
- Every screen and component layout
- Visual design specifications
- Interaction patterns
- Accessibility requirements
- Color schemes and typography
Read this to understand: What the app looks like and how users interact
technical-implementation.md
Implementation details
- File structure
- TypeScript interfaces
- Shared OpenCode service and location ownership
- Native
@opencode-ai/clientintegration - IPC communication
- Error handling strategies
Read this to understand: Current implementation boundaries
Reading Order
For First-Time Readers:
- SUMMARY.md - Get the big picture
- architecture.md - Understand the structure
- user-interface.md - See what you're building
For Implementers:
- technical-implementation.md - Implementation patterns
- Refer to architecture.md and user-interface.md as needed
For Designers:
- user-interface.md - Complete UI specs
- architecture.md - Component structure
- SUMMARY.md - Feature overview
Quick Reference
Common Questions
Q: Where do I start?
A: Read SUMMARY.md, then architecture.md and technical-implementation.md.
Q: What does the UI look like?
A: See user-interface.md for complete specifications
Q: How does it work internally?
A: See architecture.md for system design
Q: How do I build feature X?
A: See technical-implementation.md for patterns