Skip to content
This repository was archived by the owner on Jun 8, 2026. It is now read-only.

[POC] FEA-1469: run Symphony Desktop in Electron with local SQLite - #263

Closed
aeyeCEO wants to merge 4 commits into
PRD-407-in-process-onlyfrom
FEA-1469-symphony-web-poc
Closed

aeyeCEO wants to merge 4 commits into
PRD-407-in-process-onlyfrom
FEA-1469-symphony-web-poc

Conversation

@aeyeCEO

@aeyeCEO aeyeCEO commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

POC ONLY - not intended to merge to main

This is a draft prototype PR for FEA-1469, stacked on PRD-407-in-process-only. It is meant to capture and review what we proved locally, not to be treated as production-ready or merged directly into main.

If anything from this branch should ship, it should be extracted deliberately into follow-on production features after the PRD-415 strategy decisions are made.

What this prototype demonstrates

  • Electron can launch a local Symphony app runtime and expose it inside the desktop app.
  • Symphony can run in desktop-local mode against a localhost API backed by SQLite.
  • The POC can route common Symphony API calls to local data, including projects, workstreams, documents, users, local identity, settings, agents, loops, and session history.
  • Basic local single-player CRUD works for projects, workstreams, and documents without team/multiplayer data.
  • Classic desktop remains available as an escape hatch while Symphony Desktop becomes the default experimental surface.
  • Session history and agent catalog data can be read from the existing Classic/agent-monitor SQLite data and shaped for Symphony routes.
  • First-run UI can show app-server readiness separately from background session import/backfill work.
  • The port-conflict path from the PRD-407 in-process monitor is safer: legacy orphan sidecars can be reclaimed, but live ClosedLoop/Electron app holders require explicit consent instead of silent killing.

Architecture in this POC

  • The Electron main process owns a SymphonyWebPocRuntime that starts a desktop-local API server and either points at an external Symphony URL, spawns a sibling Symphony app, or falls back to a local harness.
  • The renderer defaults to the Symphony Desktop surface when the feature flag is enabled, with Desktop Classic available as a fallback button.
  • The local API persists POC entities in SQLite under application support and maps selected Symphony API contracts to local handlers.
  • The POC passes desktop_api_url, desktop_api_token, and desktop_local=1 to the Symphony app to keep local data access scoped to the Electron-managed runtime.
  • Team and multiplayer concepts are intentionally minimized or no-op in desktop-local mode.

What was not accomplished

  • This does not package a production-built Symphony app. Dev mode still relies on the source app / next dev style workflow.
  • This does not replace the iframe-style POC hosting with direct BrowserWindow.loadURL(...) as the long-term primary surface.
  • This does not complete the full Symphony Postgres-to-SQLite schema story.
  • This does not implement cloud sync, team upgrade, multi-device sync, or multiplayer features in desktop-local mode.
  • This does not retire Desktop Classic or merge its IA into Symphony.
  • This does not include a production auth/security hardening pass for the local API/token boundary.
  • This does not ship a polished final IA for which screens stay, move, hide behind Labs, or get removed.

Major decisions still pending

  • Production runtime shape: direct-loaded packaged Next standalone/runtime vs another local-server packaging approach.
  • Whether and how to generate the local SQLite schema from the cloud schema.
  • Exact single-player capability matrix: which team/org/collaboration surfaces disappear, become Labs, or become local-only equivalents.
  • How Classic is exposed long term: secondary route, secondary window, menu item, or temporary fallback only.
  • How local sessions/agents become first-class Symphony data without coupling production code to the POC bridge.
  • Whether FEA-1471 should be the immediate next productionization feature after this handoff.

Validation

  • rtk pnpm --dir apps/desktop exec tsc -p tsconfig.json --noEmit
  • rtk pnpm --dir apps/desktop exec tsx --test test/feature-flags.test.ts test/symphony-web-poc-runtime.test.ts test/agent-monitor-port-reconcile.test.ts test/agent-monitor-wiring-static.test.ts

The focused test bundle passed 66 tests locally.

Related ClosedLoop docs

  • PRD-415: Unified Product Runtime strategy root
  • FEA-1469: this POC
  • FEA-1471: recommended follow-on for direct packaged runtime productionization

@github-actions

github-actions Bot commented Jun 1, 2026

Copy link
Copy Markdown

Compatibility Smoke Test Results ⚠️

Status: skipped
Electron SHA: 2d90cf96846e9e31204c9ed9c1ac2f95302e448d
Symphony Alpha SHA (last-known-good): 24741ed9be45cc761195d7a7b6613bd30cdfce84
Note: Skipped because the stage GitHub App credentials are not configured for this workflow run.

View Actions run

@mikeangstadt

Copy link
Copy Markdown
Contributor

This was solid prototype; landing new PR inspired by this from @thadeusb this AM

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants