feat(server): search/execute-routed connections & plugin skills — stop pasting them into the harness#2472
Draft
benjaminshafii wants to merge 2 commits into
Draft
feat(server): search/execute-routed connections & plugin skills — stop pasting them into the harness#2472benjaminshafii wants to merge 2 commits into
benjaminshafii wants to merge 2 commits into
Conversation
…bilities/execute_capability
Land OpenWork Cloud's two-tool pattern locally so connections and plugin
content no longer have to be pasted into the engine config:
- MCP connections can be routing:"search": stored server-side but excluded
from the engine runtime config and hot-add sync (engine disconnects on
flip); POST /workspace/:id/mcp/:name/routing toggles it, with a desktop
Switch ("On-demand via search") in the connection details.
- New capability router (apps/server/src/capability-router.ts): indexes
local connections' tools (on-demand MCP clients: stdio + streamable HTTP,
pooled, 60s tools/list cache) and workspace/global skills, scored like
den-api's search; executes tools just-in-time and returns skill content.
- New built-in OpenCode plugin exposes bare search_capabilities /
execute_capability, resolves the workspace from context (directory,
then sessionID probe, then explicit workspaceId arg), and federates
unmatched queries/names to the openwork-cloud connection so Den
capabilities (memory bank etc.) merge into the same surface.
- Server routes: GET /workspace/:id/capabilities/search,
POST /workspace/:id/capabilities/execute (viewer tokens rejected).
- Voiceover-first spec (evals/voiceovers/search-routed-capabilities.md),
passing fraimz flow, and a zero-dependency stdio MCP fixture.
Verified: openwork-server typecheck + bun test (280 pass), @openwork/app
typecheck, plugin bundles in build, fraimz 8/8 frames passed on the real
Electron app (local connection, plugin skill, and signed-in cloud
federation all through the two verbs).
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Member
Author
fraimz — ✅ PASSED1 passed · 0 failed · 0 skipped — run Full frame proof with validated screenshots: ✅ search-routed-capabilities — Connections and plugins are found and run via search_capabilities/execute_capability — never pasted into the harnessUser-facing flow demo
|
PR comments can't reference local screenshot paths, so [ELIFECYCLE] Command failed with exit code 1. was posting frame-by-frame proof with no actual images — just filenames. postPrComment now uploads every frame screenshot to Vercel Blob first (zero-dependency plain fetch, same approach as the upload-photo skill, deterministic pathname openwork-fraimz/<runId>/<file>) and embeds the public URL as an <img> in the comment. Missing BLOB_READ_WRITE_TOKEN or a failed upload degrades gracefully (comment still posts, just without that image) rather than blocking the run. Verified for real: re-posted the search-routed-capabilities fraimz proof on PR #2472 — all 8 screenshots uploaded, embedded, and confirmed publicly served (200, image/png) at their blob.vercel-storage.com URLs. Replaced the earlier image-less comment.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.








What
Lands OpenWork Cloud's proven two-tool pattern (
search_capabilities+execute_capability, from Den/mcp/agent) locally, so connections and plugin content stop being pasted into the harness (engine runtime config + fragile hot-add sync) and become capabilities the agent discovers and runs on demand.Voiceover-first: the approved spec is
evals/voiceovers/search-routed-capabilities.md; the passing fraimz flow isevals/flows/search-routed-capabilities.flow.mjs(8/8 frames, real Electron, real model, no mocks).The pieces
routing: "search"connections — server-managed MCP entries can opt out of engine injection entirely: excluded from theOPENCODE_CONFIGruntime file and hot-add sync; flipping to search disconnects the engine client immediately. New routePOST /workspace/:id/mcp/:name/routing; desktop Switch ("On-demand via search") in the connection details + "On-demand" badge.apps/server/src/capability-router.ts) — indexes local connections' tools via on-demand MCP clients (stdio + streamable HTTP, pooled with idle eviction, 60stools/listcache, per-connection search timeouts +unavailablediagnostics) and workspace/global skills (skill:<name>executes to the SKILL.md content). Scoring mirrors den-api's lexical search.openwork-capability-router.ts) — exposes the bare canonical namessearch_capabilities/execute_capability(MCP tools are server-prefixed, so no collision withopenwork-cloud_*). Resolves the workspace from context directory →sessionIDprobe → explicitworkspaceIdarg. Federates to cloud: unmatched queries/names forward through theopenwork-cloudconnection, so Den capabilities (memory bank, org capabilities) merge into the very same search surface — the Memory Bank system-prompt instructions keep working, now even routed locally.GET /workspace/:id/capabilities/search,POST /workspace/:id/capabilities/execute(viewer tokens rejected).Why
openwork-clouditself can become search-routed (follow-up), leaving the engine with exactly two capability tools.Testing
pnpm --filter openwork-server typecheck— passcd apps/server && bun test— 280 pass / 0 fail (new: capability-router unit + real stdio MCP integration tests, routing setter, engine-map exclusion, validators)pnpm --filter @openwork/app typecheck— passpnpm --filter openwork-server build— bundles the new pluginpnpm fraimz --flow search-routed-capabilities --cdp-url http://127.0.0.1:9826— PASSED 8/8 frames against the real desktop app (dev build, seeded local Den for the cloud frame): connection flipped to on-demand in the UI → engine list provably never carries it → plain question → agentsearch_capabilities→execute_capabilitydials the stdio server just-in-time → real definition in the answer → plugin skill read through the same two verbs → signed-in cloud capabilities merged into the same search → still not in the harness.Fraimz proof (frame-by-frame with voiceover + validated screenshots) posted as a comment below.
Notes / follow-ups
unavailablewith a reason (parity with Den'sneeds_connectionhint is follow-up).openwork-cloudsync could mark itselfrouting: "search"once we're confident — that's the endgame (two tools total).openwork-extensions-preview; not touched here to keep the diff minimal.