From 04974e8b5b078c8b238d9ff4e729a9843600c0da Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oliver=20J=C3=A4gle?= Date: Thu, 7 May 2026 17:52:11 +0200 Subject: [PATCH] fix: move zod to peerDependencies so plugin shares OpenCode's zod instance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## High level changes - `packages/opencode-plugin/package.json`: Moved `zod` from `dependencies` to `peerDependencies` (version `>=4.1.8`), marked as non-optional - `pnpm-lock.yaml`: Updated to reflect the dependency change - `.vibe/development-plan-fix-opencode-plugin-parameter-descriptions.md`: Added EPCC plan documenting root cause analysis and fix strategy ## Motivation Parameter descriptions defined via `.describe()` on Zod schemas in our plugin tools were silently stripped from the JSON Schema sent to the LLM. This caused the AI to not understand parameter meanings — most critically, which workflow names are valid for `start_development`, leading to incorrect workflow selection. Root cause: our plugin loaded its own Zod 4.3.6 instance while OpenCode used Zod 4.1.8. In Zod v4, `.describe()` stores descriptions in a module-level `globalRegistry` singleton. Since two separate instances were loaded, the plugin registered descriptions in its own registry, but OpenCode's `z.toJSONSchema()` read from its own (empty) registry — resulting in all descriptions being absent. ## Details - `tsup.config.ts` already had `external: ['zod']`, meaning zod was architecturally intended to be provided by the host — but `package.json` still listed it as a `dependency`, causing pnpm to install a separate copy in the plugin's `node_modules` - Moving zod to `peerDependencies` ensures consumers (OpenCode) provide their own zod instance, so both sides share a single `globalRegistry` - All 5 tool handlers that use `.describe()` benefit: `start_development`, `proceed_to_phase`, `conduct_review`, `reset_development`, `setup_project_docs` - No source code changes required — the `.describe()` calls in tool handlers remain identical --- .beads/issues.jsonl | 14 +++ .beads/last-touched | 2 +- ...-opencode-plugin-parameter-descriptions.md | 116 ++++++++++++++++++ packages/opencode-plugin/package.json | 9 +- pnpm-lock.yaml | 2 +- 5 files changed, 138 insertions(+), 5 deletions(-) create mode 100644 .vibe/development-plan-fix-opencode-plugin-parameter-descriptions.md diff --git a/.beads/issues.jsonl b/.beads/issues.jsonl index 3817549e..e8000729 100644 --- a/.beads/issues.jsonl +++ b/.beads/issues.jsonl @@ -348,6 +348,20 @@ {"id":"responsible-vibe-33.1.3","title":"Update documentation links and references","status":"open","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-04-22T06:19:17.167665+02:00","created_by":"Oliver Jägle","updated_at":"2026-04-22T06:19:17.167665+02:00","dependencies":[{"issue_id":"responsible-vibe-33.1.3","depends_on_id":"responsible-vibe-33.1","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} {"id":"responsible-vibe-33.2","title":"Implement","description":"Write clean, focused code for the minor enhancement, test your changes, and prepare for commit. **STEP 1: Review Design and Requirements** - If exists: Follow your design from - Otherwise: Elaborate design options and present them to the user - If exists: Ensure the relevant requirements from are met - Otherwise: Ensure existing requirements are met based on your task context **STEP 2: Implement Changes** - Write clean, focused code for the minor enhancement - Test your changes to ensure they work correctly and don't break existing functionality **STEP 3: Prepare for Finalization** - Update task progress as needed - Prepare documentation and commit when ready","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-04-22T06:18:43.200189+02:00","created_by":"Oliver Jägle","updated_at":"2026-04-22T06:18:43.200189+02:00","dependencies":[{"issue_id":"responsible-vibe-33.2","depends_on_id":"responsible-vibe-33","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"responsible-vibe-33.2","depends_on_id":"responsible-vibe-33.1","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]} {"id":"responsible-vibe-33.3","title":"Finalize","description":"Ensure code quality and documentation accuracy through systematic cleanup and review. **STEP 1: Code Cleanup** Systematically clean up development artifacts: - **Remove Debug Output**: Search for and remove all temporary debug output statements used during development. Look for language-specific debug output methods (console logging, print statements, debug output functions). Remove any debugging statements that were added for development purposes. - **Review TODO/FIXME Comments**: - Address each TODO/FIXME comment by either implementing the solution or documenting why it's deferred - Remove completed TODOs - Convert remaining TODOs to proper issue tracking if needed - **Remove Debugging Code Blocks**: - Remove temporary debugging code, test code blocks, and commented-out code - Clean up any experimental code that's no longer needed - Ensure proper error handling replaces temporary debug logging **STEP 2: Documentation Review** Review and update documentation to reflect final implementation: - **Update Long-Term Memory Documents**: Based on what was actually implemented: - If exists: Update if requirements changed during development - If exists: Update if design details were refined or changed - **Compare Against Implementation**: Review documentation against actual implemented functionality - **Update Changed Sections**: Only modify documentation sections that have functional changes - **Remove Development Progress**: Remove references to development iterations, progress notes, and temporary decisions - **Focus on Final State**: Ensure documentation describes the final implemented state, not the development process - **Ask User to Review Document Updates** **STEP 3: Final Validation** - Run existing tests to ensure cleanup didn't break functionality - Verify documentation accuracy with a final review - Ensure minor enhancement is ready for delivery - Update task progress and mark completed work as you finalize the minor enhancement","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-04-22T06:18:43.386927+02:00","created_by":"Oliver Jägle","updated_at":"2026-04-22T06:18:43.386927+02:00","dependencies":[{"issue_id":"responsible-vibe-33.3","depends_on_id":"responsible-vibe-33","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"responsible-vibe-33.3","depends_on_id":"responsible-vibe-33.2","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34","title":"workflows: epcc (development-plan-fix-opencode-plugin-parameter-descriptions.md)","description":"Responsible vibe engineering session using epcc workflow for workflows","status":"open","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:29:23.994469+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:29:23.994469+02:00"} +{"id":"responsible-vibe-34.1","title":"Explore","description":"Figure out the INTENT of the users instructions. Research the codebase to understand existing patterns and gather context about the problem space. - If uncertain about conventions or rules, ask the user about them - Read relevant files and documentation - If exists: Understand and document requirements there - Otherwise: Document requirements in your task management system Focus on understanding without writing code yet. Document your findings and create tasks as needed.","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:29:24.384883+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:29:24.384883+02:00","dependencies":[{"issue_id":"responsible-vibe-34.1","depends_on_id":"responsible-vibe-34","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.1.1","title":"Reproduce the bug: verify parameter descriptions are missing when passed to OpenCode","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:34:28.125241+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:34:43.596967+02:00","closed_at":"2026-05-07T17:34:43.596967+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.1.1","depends_on_id":"responsible-vibe-34.1","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.1.2","title":"Find root cause: why descriptions are not passed through","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:34:28.351866+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:36:49.556268+02:00","closed_at":"2026-05-07T17:36:49.556268+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.1.2","depends_on_id":"responsible-vibe-34.1","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.1.3","title":"Document findings and key decisions in plan file","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:34:28.581855+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:38:33.481193+02:00","closed_at":"2026-05-07T17:38:33.481193+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.1.3","depends_on_id":"responsible-vibe-34.1","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.2","title":"Plan","description":"Create a detailed implementation strategy based on your exploration: - If exists: Base your strategy on requirements from it - Otherwise: Use existing task context Break down the work into specific, actionable tasks. Consider edge cases, dependencies, and potential challenges. - If architectural changes needed and exists: Document in - Otherwise: Create tasks to track architectural decisions - If exists: Adhere to the design in it - Otherwise: Elaborate design options and present them to the user Document the planning work thoroughly and create implementation tasks as part of the code phase as needed.","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:29:24.614607+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:29:24.614607+02:00","dependencies":[{"issue_id":"responsible-vibe-34.2","depends_on_id":"responsible-vibe-34","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"responsible-vibe-34.2","depends_on_id":"responsible-vibe-34.1","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.2.1","title":"Design: registry bridge in tool-helper.ts","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:46:42.041381+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:48:47.248577+02:00","closed_at":"2026-05-07T17:48:47.248577+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.2.1","depends_on_id":"responsible-vibe-34.2","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.2.2","title":"Verify: check all tool files use .describe() correctly","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:46:42.28365+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:46:54.663435+02:00","closed_at":"2026-05-07T17:46:54.663435+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.2.2","depends_on_id":"responsible-vibe-34.2","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.2.3","title":"Document implementation plan in plan file","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:46:42.50771+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:49:02.584+02:00","closed_at":"2026-05-07T17:49:02.584+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.2.3","depends_on_id":"responsible-vibe-34.2","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.3","title":"Code","description":"Follow your plan to build the solution: - If exists: Follow the design from it - Otherwise: Elaborate design options and present them to the user - If exists: Build according to the architecture from it - Otherwise: Elaborate architectural options and present them to the user - If exists: Ensure requirements from it are met - Otherwise: Ensure existing requirements are met based on your task context Write clean, well-structured code with proper error handling. Prevent regression by building, linting, and executing existing tests. Stay flexible and adapt the plan as you learn more during implementation. Update task progress and create new tasks as needed.","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:29:24.846625+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:29:24.846625+02:00","dependencies":[{"issue_id":"responsible-vibe-34.3","depends_on_id":"responsible-vibe-34","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"responsible-vibe-34.3","depends_on_id":"responsible-vibe-34.2","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.3.1","title":"Move zod to peerDependencies in package.json","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:50:35.761459+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:50:59.358892+02:00","closed_at":"2026-05-07T17:50:59.358892+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.3.1","depends_on_id":"responsible-vibe-34.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.3.2","title":"Run pnpm install to update lock file","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:50:35.968498+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:51:12.461356+02:00","closed_at":"2026-05-07T17:51:12.461356+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.3.2","depends_on_id":"responsible-vibe-34.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.3.3","title":"Build and verify no TypeScript errors","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:50:36.175905+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:51:19.586457+02:00","closed_at":"2026-05-07T17:51:19.586457+02:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-34.3.3","depends_on_id":"responsible-vibe-34.3","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} +{"id":"responsible-vibe-34.4","title":"Commit","description":"Ensure code quality and documentation accuracy through systematic cleanup and review. **STEP 1: Code Cleanup** Systematically clean up development artifacts: 1. **Remove Debug Output**: Search for and remove all temporary debug output statements used during development. Look for language-specific debug output methods (console logging, print statements, debug output functions). Remove any debugging statements that were added for development purposes. 2. **Review TODO/FIXME Comments**: - Address each TODO/FIXME comment by either implementing the solution or documenting why it's deferred - Remove completed TODOs - Convert remaining TODOs to proper issue tracking if needed 3. **Remove Debugging Code Blocks**: - Remove temporary debugging code, test code blocks, and commented-out code - Clean up any experimental code that's no longer needed - Ensure proper error handling replaces temporary debug logging **STEP 2: Documentation Review** Review and update documentation to reflect final implementation: 1. **Update Long-Term Memory Documents**: Based on what was actually implemented: - If exists: Update it if requirements changed during development - If exists: Update it if architectural impacts were identified - If exists: Update it if design details were refined or changed - Otherwise: Document any changes in the plan file 2. **Compare Against Implementation**: Review documentation against actual implemented functionality 3. **Update Changed Sections**: Only modify documentation sections that have functional changes 4. **Remove Development Progress**: Remove references to development iterations, progress notes, and temporary decisions 5. **Focus on Final State**: Ensure documentation describes the final implemented state, not the development process 6. **Ask User to Review Document Updates** **STEP 3: Final Validation** - Run existing tests to ensure cleanup didn't break functionality - Verify documentation accuracy with a final review - Ensure code is ready for production/delivery Update task progress and mark completed work as you finalize the feature.","status":"open","priority":3,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-05-07T17:29:25.065441+02:00","created_by":"Oliver Jägle","updated_at":"2026-05-07T17:29:25.065441+02:00","dependencies":[{"issue_id":"responsible-vibe-34.4","depends_on_id":"responsible-vibe-34","type":"parent-child","created_at":"0001-01-01T00:00:00Z"},{"issue_id":"responsible-vibe-34.4","depends_on_id":"responsible-vibe-34.3","type":"blocks","created_at":"0001-01-01T00:00:00Z"}]} {"id":"responsible-vibe-4","title":"Responsible-Vibe Development: responsible-vibe","description":"Development session using minor workflow for responsible-vibe","status":"open","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-01-20T08:45:26.033247+01:00","created_by":"Oliver Jägle","updated_at":"2026-01-20T08:45:26.033247+01:00"} {"id":"responsible-vibe-4.1","title":"Explore","description":"minor workflow explore phase tasks","status":"open","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-01-20T08:45:26.241377+01:00","created_by":"Oliver Jägle","updated_at":"2026-01-20T08:45:26.241377+01:00","dependencies":[{"issue_id":"responsible-vibe-4.1","depends_on_id":"responsible-vibe-4","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} {"id":"responsible-vibe-4.1.1","title":"Analyze current verbose task management sections in plan file templates","status":"closed","priority":2,"issue_type":"task","owner":"github@beimir.net","created_at":"2026-01-20T08:46:16.960883+01:00","created_by":"Oliver Jägle","updated_at":"2026-01-20T08:46:58.154323+01:00","closed_at":"2026-01-20T08:46:58.154323+01:00","close_reason":"Closed","dependencies":[{"issue_id":"responsible-vibe-4.1.1","depends_on_id":"responsible-vibe-4.1","type":"parent-child","created_at":"0001-01-01T00:00:00Z"}]} diff --git a/.beads/last-touched b/.beads/last-touched index 03f771fe..fda1d612 100644 --- a/.beads/last-touched +++ b/.beads/last-touched @@ -1 +1 @@ -responsible-vibe-33.1.3 +responsible-vibe-34.3.3 diff --git a/.vibe/development-plan-fix-opencode-plugin-parameter-descriptions.md b/.vibe/development-plan-fix-opencode-plugin-parameter-descriptions.md new file mode 100644 index 00000000..74eb86de --- /dev/null +++ b/.vibe/development-plan-fix-opencode-plugin-parameter-descriptions.md @@ -0,0 +1,116 @@ +# Development Plan: workflows (fix/opencode-plugin-parameter-descriptions branch) + +*Generated on 2026-05-07 by Vibe Feature MCP* +*Workflow: [epcc](https://codemcp.github.io/workflows/workflows/epcc)* + +## Goal +Fix the `opencode-plugin` so that parameter `description` fields defined via `.describe()` on Zod schemas are correctly passed to OpenCode, allowing the AI to understand parameter meanings (e.g. which workflow names are available and what they mean). + +## Key Decisions + +### Root Cause (confirmed via reproduction) +**Two separate Zod instances** are loaded at runtime: +- `opencode-plugin` uses **Zod 4.3.6** (from its own `node_modules/zod`) +- OpenCode uses **Zod 4.1.8** (from its own `node_modules/zod`) + +In Zod v4, `.describe(description)` stores the description in `core.globalRegistry` — a **module-level singleton** keyed by schema instance. When the plugin registers a description in its Zod 4.3.6 `globalRegistry`, OpenCode's `z.toJSONSchema()` looks it up in OpenCode's own Zod 4.1.8 `globalRegistry` — and finds nothing. Result: all `description` fields are absent from the JSON Schema sent to the LLM. + +**Evidence:** +- `plugin_schema.description` getter returns the description correctly (reads from plugin's registry) +- `opencode_zod.toJSONSchema(wrapped_schema)` strips descriptions (reads from opencode's registry which has no entry) +- Manually bridging: `ocRegistry.add(schema, { description: schema.description })` fixes the output + +### Plugin Architecture +- `opencode-plugin` uses `external: ['zod']` in tsup config — Zod is NOT bundled +- At runtime, Node/Bun module resolution finds `zod` from the **plugin's own `node_modules`** (4.3.6) +- OpenCode's `fromPlugin()` in `registry.ts` does `z.object(def.args)` with **its own `z`** (4.1.8) +- Then `z.toJSONSchema(item.parameters)` is called in `prompt.ts` with OpenCode's `z` (4.1.8) + +### Fix Strategy +**Option A (chosen): Pin zod to same exact version + make it a peerDependency** +- Change `zod` from `dependencies` to `peerDependencies` in opencode-plugin's `package.json` +- Pin to `"4.1.8"` (matching `@opencode-ai/plugin`'s dependency) +- When users install our plugin alongside OpenCode, they'll share the same zod instance +- In our monorepo: ensure the workspace-level zod resolved for opencode-plugin is 4.1.8 + +**Option B (upstream): Patch OpenCode's `fromPlugin` in `registry.ts`** +- After `z.object(def.args)`, walk each field and bridge descriptions via `globalRegistry.add()` +- More robust but requires upstream PR to opencode + +**Why Option A is preferred for our plugin:** +- `@opencode-ai/plugin` already declares `zod: 4.1.8` as a dependency — our plugin should match +- Moving zod to peerDependencies is the correct semantic (we use the host's zod) +- This is a common pattern for plugins that extend frameworks + +**Fix verified via test:** Using zod 4.1.8 as shared instance produces correct JSON Schema with all descriptions intact — workflow enum description and require_reviews description both present. See `/tmp/test-same-version.mjs` test. + +**Bridge approach also verified:** Accessing inner field schemas from a wrapped `ZodObject` via `parameters._zod.def.shape` and bridging registries also works. But Option A is simpler. + +**Final decision: Option A — make `zod` a peerDependency.** + +Rationale: +- `tsup.config.ts` already has `external: ['zod']` — architecturally intended to use host's zod +- Plugin currently has `"zod": "^4.1.8"` in `dependencies` — should move to `peerDependencies` +- OpenCode has zod 4.1.8 via `@opencode-ai/plugin` dependency — guaranteed present +- No code changes needed in tool handlers — `.describe()` calls stay identical +- Verified: Option A produces correct JSON Schema with all descriptions + +## Implementation Plan (Code Phase Tasks) + +1. **`opencode-plugin/package.json`**: Move `zod` from `dependencies` to `peerDependencies` with version `">=4.1.8"` +2. **`pnpm-lock.yaml`**: Run `pnpm install` to regenerate lock file +3. **Build verification**: Run `pnpm build` in opencode-plugin and verify no TypeScript errors +4. **Test**: Write/run a unit test that verifies `.describe()` descriptions appear in JSON Schema output when using the shared zod instance + +## Notes + +### How OpenCode Processes Plugin Tool Schemas +1. `plugin.ts` (our plugin): tool args defined as `ZodRawShape` with `.describe()` calls +2. `registry.ts` (opencode): `fromPlugin()` wraps args: `parameters: z.object(def.args)` (opencode's zod 4.1.8) +3. `prompt.ts` (opencode): `z.toJSONSchema(item.parameters)` converts to JSON Schema (opencode's zod 4.1.8) +4. The JSON Schema is sent to the LLM — **descriptions are missing** due to registry mismatch + +### Affected Tools +All plugin tools that use `.describe()` are affected: +- `start_development`: workflow enum description (most impactful — causes wrong workflow selection) +- `proceed_to_phase`: target_phase, reason, review_state descriptions +- `conduct_review`: target_phase description +- `reset_development`: confirm, reason, delete_plan descriptions +- `setup_project_docs`: architecture, requirements, design descriptions + +## Explore + +### Tasks + +*Auto-synced — do not edit here, use `bd` CLI instead.* + +- [x] `responsible-vibe-34.1.1` Reproduce the bug: verify parameter descriptions are missing when passed to OpenCode +- [x] `responsible-vibe-34.1.2` Find root cause: why descriptions are not passed through +- [x] `responsible-vibe-34.1.3` Document findings and key decisions in plan file + +## Plan + +### Tasks + +*Auto-synced — do not edit here, use `bd` CLI instead.* + +- [x] `responsible-vibe-34.2.1` Design: registry bridge in tool-helper.ts +- [x] `responsible-vibe-34.2.2` Verify: check all tool files use .describe() correctly +- [x] `responsible-vibe-34.2.3` Document implementation plan in plan file + +## Code + +### Tasks + +*Auto-synced — do not edit here, use `bd` CLI instead.* + +- [x] `responsible-vibe-34.3.1` Move zod to peerDependencies in package.json +- [x] `responsible-vibe-34.3.2` Run pnpm install to update lock file +- [x] `responsible-vibe-34.3.3` Build and verify no TypeScript errors + +## Commit + +### Tasks + +*Auto-synced — do not edit here, use `bd` CLI instead.* + diff --git a/packages/opencode-plugin/package.json b/packages/opencode-plugin/package.json index 2eac30c4..794318dd 100644 --- a/packages/opencode-plugin/package.json +++ b/packages/opencode-plugin/package.json @@ -24,8 +24,7 @@ "format": "prettier --write ." }, "dependencies": { - "effect": "4.0.0-beta.48", - "zod": "^4.1.8" + "effect": "4.0.0-beta.48" }, "devDependencies": { "@codemcp/workflows-core": "workspace:*", @@ -35,11 +34,15 @@ "vitest": "4.0.18" }, "peerDependencies": { - "@anthropic-ai/sdk": "*" + "@anthropic-ai/sdk": "*", + "zod": ">=4.1.8" }, "peerDependenciesMeta": { "@anthropic-ai/sdk": { "optional": true + }, + "zod": { + "optional": false } }, "keywords": [ diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml index 3ba18a7b..f06ab44e 100644 --- a/pnpm-lock.yaml +++ b/pnpm-lock.yaml @@ -184,7 +184,7 @@ importers: specifier: 4.0.0-beta.48 version: 4.0.0-beta.48 zod: - specifier: ^4.1.8 + specifier: '>=4.1.8' version: 4.3.6 devDependencies: '@codemcp/workflows-core':