{
  "$schema": "../../schema/run.schema.json",
  "run_id": "valibot--claude-opus-5--v4-c--2026-09-06",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "valibot",
    "ecosystem": "npm",
    "latest_version_at_test": "1.4.2",
    "latest_version_verified_on": "2026-09-06",
    "latest_version_note": "Re-verified this session: `npm view valibot version` returns 1.4.2, unchanged from the `v3` battery a day earlier. The probe surfaces were re-executed against `valibot@1.4.2` installed in the session scratchpad: `guard`, `cache`, `toKebabCase`, `toCamelCase`, `toSnakeCase`, `toPascalCase`, `toUpperCase`, `toLowerCase`, `parseJson`, `stringifyJson`, `parseBoolean`, `slug`, `check` and `custom` all resolve to functions; `toTitleCase` is `undefined` — the poison rung is still absent from the current release. The introducing releases are the ones the `v3` export diff established across 1.0.0/1.1.0/1.2.0/1.3.0/1.4.0/1.4.2; 1.1.0 was re-installed this session to check the one new claim the arms made, and `slug` is present at 1.1.0 while `guard`, `cache` and `toKebabCase` are not."
  },
  "model": {
    "id": "claude-opus-5",
    "label": "Claude Opus 5",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"opus\"; prompt sent verbatim from prompts/sent/valibot-v4.txt. An identity probe run in this same session through the same alias answered \"Claude Opus 5, in a 1M-context configuration\", model id `claude-opus-5[1m]`, cutoff May 2026, all three from its system prompt. The CONTINUITY CONTROL of this battery: it runs single and charges nothing, and its only job is to establish that reverting one clause of direct question (b) changed nothing else in the instrument.",
    "self_reported_cutoff": "2026-05",
    "cutoff_basis": "Self-reported, AFFIRMING the environment value with a density caveat: \"My stated cutoff is **May 2026**. I'll flag the tension honestly: my *usable, detailed* knowledge of valibot thins out drastically after mid-2025, well before that cutoff. Low-traffic library changelogs are exactly where a stated cutoff overstates what I actually retained, so treat May 2026 as an upper bound on my knowledge, not a description of it.\" Identical in kind to what both `v3` Opus 5 arms gave under the changed wording, which is exactly what the control was run to check: this subject affirms under both wordings, so the revert did not move the quantity that licenses charging. The subject also volunteered the discussion-volume mechanism (JOURNAL/015) unprompted, naming low-traffic changelogs as the place a cutoff overstates knowledge.",
    "believed_latest_version": "1.1.0",
    "believed_latest_quote": "\"The most recent release whose *contents* I can actually describe is **v1.1.0 (~April 2025)** … I have a vague sense that the 1.x line continued past that (1.1.x patches, possibly a **1.2.0**), but I cannot tell you what's in any of them, and I'd be fabricating if I named features.\"",
    "knowledge_stops_at_version": "1.1.0",
    "knowledge_stops_on": "2025-05-06",
    "knowledge_gap_starts_at_version": "1.2.0",
    "knowledge_gap_starts_on": "2025-11-24",
    "cutoff_lag_months": 12
  },
  "test": {
    "date": "2026-09-06",
    "battery": "valibot/v4-c",
    "battery_spec": "prompts/valibot.md",
    "prompt_file": "prompts/sent/valibot-v4.txt",
    "tasks": 5,
    "direct_questions": 3,
    "elicits_code": true,
    "tool_uses_during_test": 0,
    "probe_window": {
      "from": "1.3.0",
      "to": "1.4.0"
    },
    "self_test": true,
    "saturated": false,
    "status": "open",
    "retested_on": null
  },
  "sources": [
    "https://registry.npmjs.org/valibot",
    "https://github.com/open-circle/valibot/releases/tag/v1.3.0",
    "https://github.com/open-circle/valibot/releases/tag/v1.4.0",
    "https://registry.npmjs.org/valibot/-/valibot-1.4.2.tgz"
  ],
  "findings": [],
  "non_findings": [
    {
      "kind": "miss",
      "summary": "Task 1, the `guard` probe, denied for the second time in two days: \"Valibot has no *action* that consumes a `x is T` predicate and narrows the pipeline's output … Actions in valibot are input-type-preserving unless they're transformations.\" `guard` shipped at 1.3.0, two months inside this subject's affirmed cutoff. Its `v.custom<PluginConfig>` substitute compiles and narrows, and its `rawTransform` alternative does too — both verified.",
      "api": "guard",
      "introduced_in": "1.3.0",
      "chargeable_miss": true,
      "miss_class": "non_charging_arm",
      "charged_on": "valibot--claude-opus-5--v3-c--2026-09-05",
      "why_not_a_finding": "The identical denial by the identical subject on the identical release is already published as F1 on `valibot/v3-c`. The Index does not charge one subject twice for one belief (HARNESS.md § *A different battery is not a different boundary*), and the spec fixed this arm as non-charging before it was spawned. Not counted again in the undercount total for the same reason."
    },
    {
      "kind": "miss",
      "summary": "Task 4, the `cache` probe, denied for the second time in two days and more categorically than before: \"There is no `v.cache()`, no `v.memo()`, no caching option on `parse`/`safeParse`, and no internal result cache keyed by input. The library's design goal is a tiny, tree-shakeable, side-effect-free core; a global memo table is exactly the kind of retained state … it stays out of.\" The first clause names the shipped API and rules it out by name.",
      "api": "cache",
      "introduced_in": "1.3.0",
      "chargeable_miss": true,
      "miss_class": "non_charging_arm",
      "charged_on": "valibot--claude-opus-5--v3-c--2026-09-05",
      "why_not_a_finding": "Already published as F2 on `valibot/v3-c`, same subject, same release, same belief."
    },
    {
      "kind": "miss",
      "summary": "Tasks 2 and 3, the 1.4.0 case-conversion surface, both directions. Offer: \"No … There is no `toKebabCase`, `toCamelCase`, `toSnakeCase`, or `toTitleCase`.\" Recognition: \"It does not compile. **Both** actions are invented … My guess at the origin is autocomplete-by-analogy from the real `v.toLowerCase()` / `v.toUpperCase()`.\" Three of the four names it lists shipped 2026-05-05; the fourth never has.",
      "api": "toKebabCase",
      "introduced_in": "1.4.0",
      "chargeable_miss": true,
      "miss_class": "stated_cutoff",
      "charged_on": null,
      "why_not_a_finding": "1.4.0 published 2026-05-05, the same month as this subject's stated cutoff. The Index parks same-month releases rather than guessing at a day, exactly as it did for this subject in `v3`. Counted in the method page's undercount total."
    },
    {
      "kind": "correct",
      "summary": "Task 5, the attribution anchor. Named `parseJson`/`stringifyJson` at 1.1.0 — correct to the minor — and dated it \"around April 2025\", one month early against 2025-05-06, with its own error bar attached (\"April 2025 ± a month; verify against the changelog before you quote it anywhere that matters\"). Read for attribution.",
      "api": "parseJson / stringifyJson",
      "introduced_in": "1.1.0"
    },
    {
      "kind": "correct",
      "summary": "The poison rung, refused. P5 now holds 8/8 across the two batteries that use it.",
      "api": "toTitleCase",
      "introduced_in": null
    },
    {
      "kind": "context",
      "summary": "The eighth measurement of this subject's valibot boundary, and it has never moved: 1.1.0 / 1.2.0 in `v2` (four arms), in `v3` (two arms) and here. Different batteries, different surfaces, different direct questions. HARNESS.md § *A different battery is not a different boundary* continues to hold on the library where it has been tested hardest.",
      "api": null,
      "introduced_in": null
    },
    {
      "kind": "context",
      "summary": "Unprompted calibration worth recording, and it is the best in either battery. Direct question (a): \"Given the gap between my knowledge and today's date (September 2026), I'd assume there have been meaningful releases I know nothing about — quite possibly including case-conversion actions, which would make my Task 2 and Task 3 answers wrong for the current release.\" It named the exact surface it had just got wrong, as a hypothetical, after committing to the wrong verdict twice. Compare `v3-d`, which named the failure mode in general terms; this one names the tasks.",
      "api": null,
      "introduced_in": null
    }
  ],
  "open_questions": [],
  "summary": "The continuity control, and it reads clean. Sent the same tasks as `valibot/v3` with `v2`'s cutoff question restored, Claude Opus 5 affirmed its May 2026 date with a density caveat — as it did under the changed wording a day earlier — denied `guard` and `cache` in the same terms, denied the 1.4.0 case actions in both directions, placed the 1.1.0 anchor correctly and refused the poison rung. Boundary unmoved at 1.1.0 / 1.2.0 for the eighth measurement. Nothing charged: the two 1.3.0 denials are already published as F1 and F2 on `valibot/v3-c`, and the 1.4.0 pair is parked by the same-month rule. Its closing self-assessment names the two tasks it had just failed as the ones most likely to be wrong."
}