mirror of
https://github.com/different-ai/openwork
synced 2026-04-25 17:15:34 +02:00
2b91b4d777
* refactor(repo): move OpenWork apps into apps and ee layout Rebase the monorepo layout migration onto the latest dev changes so the moved app, desktop, share, and cloud surfaces keep working from their new paths. Carry the latest deeplink, token persistence, build, Vercel, and docs updates forward to avoid stale references and broken deploy tooling. * chore(repo): drop generated desktop artifacts Ignore the moved Tauri target and sidecar paths so local cargo checks do not pollute the branch. Remove the accidentally committed outputs from the repo while keeping the layout migration intact. * fix(release): drop built server cli artifact Stop tracking the locally built apps/server/cli binary so generated server outputs do not leak into commits. Also update the release workflow to check the published scoped package name for @openwork/server before deciding whether npm publish is needed. * fix(workspace): add stable CLI bin wrappers Point the server and router package bins at committed wrapper scripts so workspace installs can create shims before dist outputs exist. Keep the wrappers compatible with built binaries and source checkouts to avoid Vercel install warnings without changing runtime behavior.
2.6 KiB
2.6 KiB
OpenCode Server
Run tasks from a shared runtime
Summarize
- Define a local OpenCode server that OpenWork can discover, connect to, and use for task execution across devices
Define problem
- OpenWork needs a reliable way to run tasks without bundling a full CLI per device while keeping setup simple and transparent
Set goals
- Enable a host machine to run tasks for multiple OpenWork clients with clear status, fast connect, and predictable behavior
- Keep setup minimal and align with least-privilege, mobile-first usage
Exclude scope
- Building a hosted SaaS, multi-tenant cloud, or marketplace for remote agents
- Supporting non-OpenWork clients beyond a basic compatibility layer
Describe personas
- Mobile user who wants to run tasks from a phone against a home or work machine
- Power user who wants a stable local runtime for repeated workflows
- Admin who needs simple setup and clear permission prompts
Define requirements
- Functional: discover host on LAN, connect via pairing, run tasks, stream logs, and handle reconnects gracefully
- UX: show connection status, explain permissions, and expose a clear health panel with actionable errors
Detail integration
- Lifecycle: start server on host, advertise via local discovery, accept pairing, and serve OpenCode APIs over a secured channel
- Host/client: host runs OpenCode runtime and permission gates while clients send tasks, receive progress, and read logs
Set permissions
- Require explicit pairing approval, scoped runtime permissions, and per-task confirmation for sensitive tools
Cover telemetry
- Optional local metrics for uptime, connection failures, and task success, stored on host and never uploaded by default
Map flow
- Onboarding: guide install, start server, and generate pairing code
- Connect: discover host, enter code, and validate permissions summary
- Health: show server uptime, last task status, and recovery actions
Note risks
- Network discovery inconsistencies across platforms and routers
- Trust confusion if pairing and permission prompts are unclear
Ask questions
- Should remote access beyond LAN be supported in this phase, and if so, which transport is acceptable
Measure success
- 90%+ successful first-time pairing on supported platforms with fewer than two manual retries
- Stable task execution with <1% disconnect-related failures over 7 days
Plan rollout
- Phase 1: local discovery and pairing on desktop host with basic status UI
- Phase 2: mobile client support, health panel, and reconnect logic
- Phase 3: permission refinements, metrics, and troubleshooting guide