Follow-up to #637. The extracted @bounded-systems/verbspec package contains the spec core: defineVerb, parseArgs, dispatch, toMcpTool/toAnthropicTool/toOpenApiOperation, render, and the VerbSpec/Registry types.
The richer projections still live in packages/prx/src/cli/:
router.ts — namespaced/multi-token verb resolution (dispatchTree)claude-plugin.ts — toClaudePlugin (plugin manifest + .mcp.json + slash commands)mcp-server.ts — prx mcp serve runtime (handleMcpRequest)permissions.ts — actor → ToolPolicy projection
Decision needed
Do these belong in the standalone verbspec library, or stay prx-side?
- Move out if they're generic, reusable projection machinery that any verbspec consumer would want.
- Keep in prx if they carry prx-specific assumptions (actor model, the
prx plugin identity, prx's permission policy) that don't generalize.
A likely split: keep router (generic) as a candidate to move; keep permissions and the prx-branded plugin/server wiring prx-side. Resolve before or alongside the extraction (#637 follow-up).
Context: claude.ai/code session 01PGAut6CEjiQjFMURp8UA5A
Follow-up to #637. The extracted
@bounded-systems/verbspecpackage contains the spec core:defineVerb,parseArgs,dispatch,toMcpTool/toAnthropicTool/toOpenApiOperation,render, and theVerbSpec/Registrytypes.The richer projections still live in
packages/prx/src/cli/:router.ts— namespaced/multi-token verb resolution (dispatchTree)claude-plugin.ts—toClaudePlugin(plugin manifest +.mcp.json+ slash commands)mcp-server.ts—prx mcp serveruntime (handleMcpRequest)permissions.ts— actor →ToolPolicyprojectionDecision needed
Do these belong in the standalone verbspec library, or stay prx-side?
prxplugin identity, prx's permission policy) that don't generalize.A likely split: keep
router(generic) as a candidate to move; keeppermissionsand theprx-branded plugin/server wiring prx-side. Resolve before or alongside the extraction (#637 follow-up).Context: claude.ai/code session 01PGAut6CEjiQjFMURp8UA5A