mirror of
https://github.com/different-ai/openwork
synced 2026-05-11 09:36:23 +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.
97 lines
2.8 KiB
Markdown
97 lines
2.8 KiB
Markdown
---
|
|
title: Plugin config via API
|
|
description: Use /config for short-term plugin listing and add
|
|
---
|
|
|
|
## Set context
|
|
OpenWork manages plugins by editing `opencode.json`, but remote workspaces cannot read that file. OpenCode already exposes `/config` for reading and updating project config, so the short-term plan is to rely on `/config` for plugin listing and adds instead of introducing a new `/plugin` endpoint right away.
|
|
|
|
---
|
|
|
|
## Define goals
|
|
- List configured plugins for remote workspaces using existing `/config`
|
|
- Add plugins by updating the config API in project scope
|
|
- Keep behavior aligned with current config merge rules
|
|
|
|
---
|
|
|
|
## Call out non-goals
|
|
- No plugin status (loaded/failed) signal
|
|
- No plugin removal or update endpoints in this phase
|
|
- No automatic dependency resolution or npm install workflow
|
|
- No new `/plugin` endpoints in this phase
|
|
- No global scope add via API (requires new endpoint)
|
|
|
|
---
|
|
|
|
## Short-term API usage
|
|
GET `/config` returns the resolved config for the active workspace.
|
|
|
|
```json
|
|
{
|
|
"plugin": ["opencode-wakatime", "file:///path/to/plugin.js"]
|
|
}
|
|
```
|
|
|
|
PATCH `/config` adds plugins by submitting the full plugin list.
|
|
|
|
```json
|
|
{
|
|
"plugin": ["opencode-wakatime", "opencode-github"]
|
|
}
|
|
```
|
|
|
|
```json
|
|
{
|
|
"plugin": ["opencode-wakatime", "opencode-github"]
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
## Shape data
|
|
The plugin list is the same array of string specifiers used in config (`config.plugin`).
|
|
OpenWork treats the config list as the source of truth for "installed" plugins.
|
|
|
|
---
|
|
|
|
## Persist config
|
|
Project scope uses existing `Config.update()` behavior, which writes `<workspace>/config.json` and disposes the instance.
|
|
Global scope updates are out of scope for this short-term plan.
|
|
|
|
---
|
|
|
|
## Edge cases
|
|
- `Config.update()` merges config but replaces arrays; clients must read/merge/dedupe the full plugin list before PATCH.
|
|
- Updating config writes `config.json`, even if the project uses `opencode.json` or `opencode.jsonc`.
|
|
- The server disposes the instance on update; clients should handle reconnects without a `reloadRequired` signal.
|
|
|
|
---
|
|
|
|
## Update SDK
|
|
Expose `config.get()` and `config.update()` in the SDK for remote plugin flows.
|
|
|
|
---
|
|
|
|
## Integrate UI
|
|
Use `GET /config` to populate the plugin list in remote mode.
|
|
Use `PATCH /config` with a read/merge/write flow when adding plugins.
|
|
Host/Tauri mode can keep using local `opencode.json` parsing.
|
|
|
|
---
|
|
|
|
## Related APIs
|
|
Skills already have a dedicated endpoint (`GET /skill`), which OpenWork uses for remote listing.
|
|
|
|
---
|
|
|
|
## Log events
|
|
Log `config.get` and `config.update` when plugin changes are requested.
|
|
Errors include file path, parse details, and API caller identity.
|
|
|
|
---
|
|
|
|
## Plan rollout
|
|
Document this as the short-term path for remote plugin support.
|
|
Revisit a dedicated `/plugin` endpoint after OpenWork validates the config-based flow.
|