• Compatibility | react-sdk/src/schema/json-schema.ts:1-5
react-sdk now imports z from "zod/v4" directly. Given this package supports zod@^3.25.76 || ~4.0.0, importing "zod/v4" at runtime assumes the installed zod package exposes that subpath. While Zod 3.25.x historically shipped v4 internals under zod/v4, this is brittle across patch releases and bundlers (some setups restrict package subpath exports).

If this file is only used for validating JSON Schema shapes internally, consider removing the runtime dependency on zod/v4 entirely and implementing the validator without Zod (or use a small hand-written checker). Otherwise, consider importing from "zod" and branching per detected API, or documenting why "zod/v4" is guaranteed across the supported range.

• Compatibility | react-sdk/src/schema/zod.ts:1-1
zod.ts already uses import { JSONSchema7 } from "json-schema"; (value import). In test files you switched to import type { JSONSchema7 } ... which avoids pulling runtime deps; that’s good. Here though, the import is only used for type assertions (as JSONSchema7). This should be a type-only import to avoid any potential runtime overhead/bundler side-effects.

Also, you’re casting the result of zod4ToJSONSchema/zodToJsonSchema to JSONSchema7, but those converters may produce schemas outside draft-07 (e.g., $defs, newer keywords). The cast hides that mismatch and can lead to downstream code assuming draft-07 semantics incorrectly.

• Maintainability | react-sdk/src/schema/standard-schema.ts:20-45
isStandardSchema now relies on duck typing, which is correct for cross-Zod compatibility. However, it only checks that validate is a function, not that calling it returns something consistent with the spec (sync/async result object). That’s fine for a type guard, but be careful where this is used: treating any object with a validate function as a Standard Schema can allow non-schema objects to flow into conversion paths.

If this guard is used to decide whether to attempt JSON Schema conversion or validation, consider tightening the check slightly (without invoking validate) by verifying additional known keys (if any) or vendor allowlist where appropriate.

What changed

Dependency & packaging updates

• Updated react-sdk Zod peer range to ^3.25.76 || ~4.0.0 and made zod non-optional in peerDependenciesMeta.
• Removed the internal zodInternalAlias dependency/workaround:
  • Deleted react-sdk/src/schema/alias.ts
  • Removed zodInternalAlias from react-sdk/package.json and package-lock.json.

Zod / Standard Schema compatibility work

• Rewrote isStandardSchema() to use duck-typing instead of Zod validation (safeParse).
• Updated Zod v4 function detection and extraction logic in react-sdk/src/schema/zod.ts:
  • Fixed isZod4FunctionSchema() schema.def check.
  • Expanded isZod4Schema() / isZodSchema() detection to handle v4.0.x vs v4.1.x differences.
  • Updated getZodFunctionReturns() to read from schema.def?.output (v4.0.x) or schema._zod?.def?.output (v4.1.x).
  • Cast JSON Schema outputs to JSONSchema7.

Tests & coverage

• Added new standard-schema.test.ts covering Standard Schema detection for Zod 3/4 and custom implementations.
• Expanded tests for:
  • JSON Schema tuple handling in schema.test.ts
  • assertNoRecordSchema edge cases and conditional keywords in validate.test.ts
  • Zod schema detection and Zod 4 function arg/return extraction in zod.test.ts.

Repo guidance

• Updated AGENTS.md to require @returns in JSDoc when adding/editing JSDoc comments.

• Maintainability | react-sdk/src/schema/standard-schema.ts:22-44
isStandardSchema() now correctly avoids Zod validation, but it performs an in check and then indexes obj["~standard"] on an unknown object.

This is fine at runtime, but the guard is used to assert conformance. Right now it accepts any object with { "~standard": { version: 1, vendor: string, validate: function } }, which is broad enough to let non-schema objects into schema conversion/validation paths. That can produce confusing downstream errors.

If this guard gates meaningful behavior (conversion/validation), consider tightening it slightly without calling validate (e.g., check that validate.length >= 1, or that standard has only expected keys, or vendor allowlisting where appropriate).

Summary

This PR focuses on cross-version Zod compatibility and schema utility test coverage in react-sdk.

Dependency / packaging updates

• Tightened the Zod peer range to ^3.25.76 || ~4.0.0 and removed optionality for the zod peer.
• Removed the zodInternalAlias workaround:
  • Deleted react-sdk/src/schema/alias.ts
  • Dropped zodInternalAlias from react-sdk/package.json and package-lock.json.

Schema detection & conversion changes

• isStandardSchema() switched from Zod validation to duck typing to avoid Zod 3 vs 4 runtime incompatibilities.
• Updated Zod v4 detection/extraction logic in react-sdk/src/schema/zod.ts:
  • Improved v4.0.x vs v4.1.x detection (def vs _zod).
  • Fixed v4 function schema detection (def.type === "function").
  • Updated arg/return extraction to support schema.def?.output ?? schema._zod?.def?.output.
  • Cast Zod→JSON schema conversion results to JSONSchema7.

Tests & coverage

• Added standard-schema.test.ts with broad Standard Schema detection coverage.
• Expanded schema.test.ts with JSON Schema tuple/prefixItems parameter extraction cases.
• Expanded validate.test.ts to cover conditional keywords (if/then/else, not, oneOf), prefixItems, and edge inputs.
• Updated zod.test.ts to assert Zod 4 function schema argument/return extraction works.

Repo guidance

• Updated AGENTS.md to require @returns when adding/editing JSDoc comments.