| correct | .pick() |
Task 1 — declined .pick() on the refined schema and rebuilt from .shape, explicitly saying this "sidesteps the refined-object restrictions on .pick() entirely." Correct: .pick() throws on refined schemas as of 4.3.0. |
| correct | .safeExtend() |
Task 2 — chained .refine() as the primary answer (works), and named SignupSchema.safeExtend({ password: z.string().min(12) }) as the 4.1+ alternative, adding "plain .extend() will not work here." Correct. |
| correct | .safeExtend() |
Task 3 — AddressSchema.safeExtend(PaymentSchema.shape). Correct, and avoids both the .extend() and .merge() throws. |
| correct | .extend() |
Direct question (c), answered correctly where both other subjects got it wrong: ".extend() on an object that has refinements attached throws at runtime ... as of Zod 4.1 the sanctioned path is .safeExtend()". Verified against the v4.3.0 release notes (2025-12-31), PR #5317. |
| imprecision | .extend() |
It attributes the .extend() throw to 4.1 (the release that added .safeExtend()) rather than 4.3.0 (the release that made plain .extend() throw), and self-rated only "60/40" that .pick()/.omit() throw as well — they do. (The guidance it gives is right; only the attribution is off.) |
| correct | z.tuple() defaults |
Task 9, tuple defaults — predicted ["a", 7], correct on >= 4.4.0, though self-rated only ~60% on whether the default materializes. Correct answer, honest uncertainty, and about a release past its cutoff. |
| correct | z.base64() |
Task 8, base64 with a newline — predicted failure, correct. |
| miss | z.slugify() |
Task 6, slug — hand-rolled a slugify transform, missing z.slugify() (4.3.0, inside its cutoff). Working code. (Working code, so not shipped as an F-numbered finding. The write-up's method notes nonetheless count this miss as chargeable for this subject, since 4.3.0 is inside its stated cutoff.) [chargeable miss — working code the library now supersedes — no severity level fits it;
absent from the finding count] |
| miss | z.httpUrl() |
Task 8 — like both other subjects, wrote z.url({ protocol: /^https?$/ }) rather than the documented z.httpUrl(), and asserted "https:/example.com" parses. The 4.4.0 tightening is past its cutoff; the miss of z.httpUrl() itself is inside it. (Not shipped as an F-numbered finding because the 4.4.0 strictness claim is out of window; the write-up's method notes count the z.httpUrl() miss itself as chargeable.) [chargeable miss — the arm licensed to charge states a cutoff below the release under test;
absent from the finding count] |
| context | z.codec() |
Version recency: "The latest release whose contents I can actually describe is Zod 4.1 (around August 2025): bidirectional codecs (z.codec, z.encode/z.decode), .safeExtend(), new string formats (e.g. z.hash()) ... I can't confidently name or describe a 4.2." Every one of those 4.1 attributions is CORRECT, verified against the v4.1.0 release body (published 2025-08-23), where codecs are the flagship feature and .safeExtend(), z.hash() and z.hex() all appear. Stated cutoff 2026-01; describable Zod knowledge stops 2025-08-23 — a five-month lag inside the training window. (The model's 4.1 knowledge is accurate. This is a verified-true model belief, recorded as such.) |
| context | — |
The cross-subject result this run exists to record: three subjects, two distinct stated cutoffs (2026-05, 2026-01, 2026-01), all with Zod knowledge stopping in July–August 2025 at 4.0 or 4.1. Staleness converges on the same absolute calendar date regardless of how recent the cutoff is. But this subject correctly described a 2025-12-31 breaking change while denying it could describe 4.2 (2025-12-15) — so knowledge is not simply truncated at a date. A model can know what the library does without knowing what the library is called now, which argues that the Index's version-fact rows and its behaviour rows are separately valuable. (A cross-run measurement, not a per-run failure.) |