You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"pr_comment": "The raw-shape overload requires `InputArgs extends ZodRawShape` but allows `OutputArgs extends ZodRawShape | StandardSchemaWithJSON`. The reverse mix (wrapped `inputSchema` + raw `outputSchema`) matches no overload: overload 1 rejects raw `outputSchema`, overload 2 rejects wrapped `inputSchema`. v1 code was always all-raw so this doesn't break any v1 caller, but the asymmetry is surprising.",
9
+
"reasoning": "Only matters if someone writes `registerTool('x', {inputSchema: z.object({a: z.string()}), outputSchema: {b: z.number()}}, cb)` — a hybrid that v1 didn't support either. Low impact; could add a third overload `<InputArgs extends StandardSchemaWithJSON, OutputArgs extends ZodRawShape>` for symmetry, or document that raw-shape applies all-or-nothing.",
10
+
"status": "open"
11
+
},
12
+
{
13
+
"bug_id": "r0-002",
14
+
"severity": "nit",
15
+
"file_path": "packages/server/src/server/mcp.ts",
16
+
"start_line": 43,
17
+
"end_line": 43,
18
+
"pr_comment": "`import type * as z from 'zod/v4'` adds `z.ZodType` to the public `.d.mts` surface via `ZodRawShape = Record<string, z.ZodType>`. This is intentional (raw-shape is documented Zod-only and `@deprecated`), and server already depends on zod, but it's a new direct type-surface coupling worth noting in case the intent was to keep server's primary types StandardSchema-only.",
19
+
"reasoning": "The directive flagged this as a watch-for. It's correctly scoped to the deprecated path; mentioning here so it's on record as a deliberate choice rather than a regression.",
"pr_comment": "`z.object(schema) as StandardSchemaWithJSON` — the cast is needed because `ZodObject` doesn't structurally narrow to the interface here, but it relies on zod ≥4.2.0 actually providing `~standard.jsonSchema`. On this branch alone the catalog still has `^4.0` (B1/#1895 bumps to ^4.2.0). With zod 4.0.x this cast would type-check but `standardSchemaToJsonSchema(wrapped)` could fail at runtime.",
29
+
"reasoning": "B1's fallback covers this once both land; on C4 standalone it's a hidden version assumption. Nit because the integration validates with zod 4.2+, and B1 is the right place for the catalog bump.",
"pr_comment": "Tests verify the schema is wrapped (via `isStandardSchema(tools['a'].inputSchema)`) but never call the tool to confirm the callback actually receives `{x: number}` typed args at runtime. Consider one end-to-end test that connects via InMemoryTransport and calls the tool.",
39
+
"reasoning": "Current tests prove normalization happened but not that the callback signature works end-to-end. The wrapping is the load-bearing change; the callback typing is asserted only at compile time via the overload.",
"pr_comment": "`vi.spyOn(console, 'warn')` + `expect(warn).not.toHaveBeenCalled()` are vestiges of the removed `deprecate()` runtime warns. Harmless and they document the no-warn intent, but the spy setup could be dropped for clarity since there's no warn path left in the code under test.",
49
+
"reasoning": "Policy is JSDoc-only `@deprecated`, no runtime warn. The assertions still pass but test code that guards against a removed mechanism can confuse future readers.",
"pr_comment": "`normalizeRawShapeSchema` tests cover the wrap path but not the passthrough (`normalizeRawShapeSchema(z.object({a: z.string()}))` returns the same instance) or `undefined → undefined`.",
59
+
"reasoning": "Minor coverage gap; both branches are trivial but documenting them keeps the contract explicit.",
60
+
"status": "open"
61
+
},
62
+
{
63
+
"bug_id": "r0-007",
64
+
"severity": "nit",
65
+
"file_path": "packages/server/src/server/mcp.ts",
66
+
"start_line": 1113,
67
+
"end_line": 1131,
68
+
"pr_comment": "`ZodRawShape`/`InferRawShape`/`LegacyToolCallback`/`LegacyPromptCallback` are also defined by C2 (#1900) for the variadic `.tool()/.prompt()` shims. On each PR alone that's fine; merging both into d1-base/integration produces duplicate exported type declarations in mcp.ts.",
69
+
"reasoning": "Integration concern, not a defect of this PR. Parent's d1-base merge handles the dedup (`c2efc634` already resolved a C2/C4 overlap once). Noting so it's not re-discovered.",
0 commit comments