Skip to content

feat(desktop): introduce React Desktop 2.0 - #775

Closed
abraxas914 wants to merge 4 commits into
lsdefine:mainfrom
abraxas914:codex/react-desktop-v2-integration
Closed

feat(desktop): introduce React Desktop 2.0#775
abraxas914 wants to merge 4 commits into
lsdefine:mainfrom
abraxas914:codex/react-desktop-v2-integration

Conversation

@abraxas914

Copy link
Copy Markdown
Contributor

Summary

This draft introduces the React-based GenericAgent Desktop 2.0 on top of the current upstream main while preserving the existing static desktop as an independent v1 implementation.

The integration uses upstream commit b0d270394d7f2852ac33d71217217bb37e31e1b6 as its base and squashes the fork's desktop work into four reviewable commits. It retains upstream conductor, runtime, Hub/P2P, LLM, Streamlit, memory-import, and security changes rather than importing the fork's historical merge graph.

Architecture and scope

  • React v2 owns frontends/desktop/src/**, public/**, the Vite build, and the packaged dist entry point.
  • frontends/desktop/static/** remains byte-for-byte identical to upstream and is not used as a source tree for React v2.
  • The desktop always launches its package-owned desktop_bridge.py; an external core is selected only through GA_ROOT after a compatibility probe.
  • move_ga_runtime remains registered and authorized, with asynchronous copy/switch/rollback semantics; React v2 does not expose a migration UI in this PR.
  • Package, lockfile, Cargo, Tauri, and artifact metadata are aligned at 0.2.0.
  • The fork-only nightly workflow and release-packaging rewrite are excluded. The upstream release workflow changes only to preinstall the macOS runtime and assert the prepared package contract.

Conflict resolution highlights

  • Preserves upstream memory-import semantics: full memory backup, memory overwrite, add-only responses, and deduplicated sessions.
  • Preserves optional P2P degradation when heavy dependencies are absent without blocking Hub or normal desktop startup.
  • Protects foreign bridge-port owners, supports retry after release, and avoids killing unrelated processes.
  • Makes external-core selection transactional: incompatible roots fail before persistence, and failed switches roll back settings and runtime identity.
  • Keeps the macOS application bundle immutable after installation by preparing dependencies during packaging and using a writable versioned runtime outside the app.

Validation completed on candidate

Candidate commit: 07763ab07922c7a9ba5c8074dafec66b8ad316ae

  • Merge invariants: no conflict markers or unmerged paths; static/** and memory/** have zero diff from upstream; no local Codex/Trellis/agent files, old QR images, or nightly workflow are present.
  • React: 43 Vitest files / 345 tests; TypeScript and E2E type checks; production build, bundle, packaging, CI-contract, and production-isolation checks.
  • Python: 149 tests.
  • Rust: 11 production tests and 11 E2E-feature tests; formatting check.
  • Browser E2E: 4/4 deterministic critical journeys.
  • Native Tauri E2E: 3/3 journeys, including compatible GA_ROOT switch/clear and foreign-port recovery.

The three-platform same-SHA package workflow and release-package acceptance evidence are being collected while this PR remains a draft. A real-model canary is intentionally non-blocking.

Known non-blocking observations

  • npm ci currently reports 20 inherited dependency audit findings (2 moderate, 18 high). No lockfile-mutating forced audit fix is included in this integration PR.
  • Vite reports one mixed static/dynamic import and a large-bundle warning.
  • Tauri warns that the existing bundle identifier ends in .app.

中文摘要

本 Draft PR 将 React Desktop 2.0 集成到当前 upstream main,同时严格保留原有 static v1,二者源码边界完全解耦。集成保留 upstream 最近的 conductor、运行时、Hub/P2P、LLM、Streamlit、记忆导入及安全更新;桌面始终运行包内 bridge,外部仓库只通过兼容性探测后的 GA_ROOT 接入。

候选 SHA 已通过本机 L0–L4:React 345、Python 149、Rust 11+11、浏览器 4 条、原生 Tauri 3 条。三平台同 SHA 打包和真包验收证据将在 Draft 阶段继续补齐;完成前不会转为 Ready。

@abraxas914

Copy link
Copy Markdown
Contributor Author

Closing this draft because the integration must be reviewed and merged in the fork first. An upstream PR will be prepared only after the fork integration and package validation are complete.

@abraxas914 abraxas914 closed this Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant