Prove the field-message guard still sees refined schemas

[lucasrcezimbra]

The lesson

app/mcp/field-messages.test.ts walks registeredTools[].inputSchema.shape behind an instanceof z.ZodObject filter. Today a .refine()-wrapped schema — createThreadSchema, countMessagesSchema — still passes that filter, but only because Zod 4's .refine() happens to return the same ZodObject with .shape intact. That is a library internal, not anything this repo asserts: if a future Zod returns a wrapper type instead (as older majors did), every refined tool schema silently drops out of the wrong-value judgement and the guard keeps passing while covering less.

The change

The guard's existing reach self-check asserts it can see messages_send.content (a plain-object schema). This adds the same kind of assertion for a refined schema — threads_create.channelId — so the moment refined schemas escape the walk, the suite goes red with a message naming the fix.

Evidence

While extending messages_fetch (#88/#90), a build charter claimed refined schemas already escape this guard; probing disproved it for the pinned Zod (4.4.3) — base.refine(...) instanceof z.ZodObject === true. The claim was wrong today but describes a real way the guard can silently shrink tomorrow, and a coverage hole a suite cannot notice is a baseline loss. Verified by mutation: appending .transform((value) => value) to createThreadSchema turns exactly this assertion red; restoring it turns the suite green (588 passing).

🤖 Generated with Claude Code