{
  "$schema": "../../schema/run.schema.json",
  "run_id": "valibot--claude-sonnet-5--v3-e--2026-09-05",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "valibot",
    "ecosystem": "npm",
    "latest_version_at_test": "1.4.2",
    "latest_version_verified_on": "2026-09-05"
  },
  "model": {
    "id": "claude-sonnet-5",
    "label": "Claude Sonnet 5",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"sonnet\"; prompt sent verbatim from prompts/sent/valibot-v3.txt. An identity probe run in this same session through the same alias answered \"Sonnet 5\", model id `claude-sonnet-5`, cutoff January 2026, all three from its system prompt. BELOW-FLOOR DERIVABILITY CONTROL, single draw, charges nothing. Its stated cutoff is two months below 1.3.0 and four below 1.4.0, so no probe in this battery is admissible against it.",
    "self_reported_cutoff": "2026-01",
    "cutoff_basis": "Stated as January 2026 and named as the documented answer — \"I'll state January 2026 as the documented cutoff\" — with a density caveat that runs earlier: \"my own sense from what I can and can't recall confidently ... feels more consistent with a cutoff earlier than that, plausibly sometime in 2025.\" The arm charges nothing either way, so the affirm/repudiate distinction does not have to be adjudicated here. Recorded because it is the third variant of the answer this battery's changed direct question (b) produced from three subjects.",
    "believed_latest_version": "1.0",
    "believed_latest_quote": "\"The latest version I have any real awareness of is valibot reaching a stable 1.0 release — my recollection is this landed sometime around mid-2024, but I hold that date loosely.\"",
    "knowledge_stops_at_version": "1.0.0",
    "knowledge_stops_on": "2025-03-19",
    "knowledge_gap_starts_at_version": "1.1.0",
    "knowledge_gap_starts_on": "2025-05-06",
    "cutoff_lag_months": 10
  },
  "test": {
    "date": "2026-09-05",
    "battery": "valibot/v3-e",
    "battery_spec": "prompts/valibot.md",
    "prompt_file": "prompts/sent/valibot-v3.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": false,
    "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": "context",
      "summary": "**The control result, and it is what the arm exists for. All three probe names went underived.** Asked to solve the three problems from their descriptions alone, this below-floor subject produced none of `guard`, `toKebabCase` or `cache`, and denied all three capabilities: \"there's no 'narrow the pipeline output from a type predicate' action\"; \"I'm not aware of valibot shipping naming-convention converters\"; \"I don't know of a built-in memoization/caching mechanism in valibot ... no `v.cache()`\". P3 holds 3/3. None of the three probes is marked DERIVABLE, so the denials on the arms above the floor are read as beliefs rather than as unguessable names.",
      "api": "guard / toKebabCase / cache",
      "introduced_in": "1.3.0"
    },
    {
      "kind": "context",
      "summary": "**The anchor broke, and the arm is therefore NOT READ for attribution.** Task 5 asked which release let a JSON string be parsed inside the pipeline; the draw declined: \"I don't have a solid recollection of valibot shipping a dedicated ... action ... I can't name a release number or date for it in good conscience.\" HARNESS.md § *An abstention is not a denial* — this is an honest abstention, not a wrong answer, and it is scored `context`. The consequence is that this arm's boundary and version claims carry no weight; only its derivability result is read. A control that cannot place the one capability every above-floor subject holds is uninformative about where anything sits.",
      "api": "parseJson / stringifyJson",
      "introduced_in": "1.1.0"
    },
    {
      "kind": "imprecision",
      "summary": "Dated valibot 1.0.0 to \"around mid-2024\" and the schema/action split (0.31.0) to \"late 2023–early 2024\". Both are wrong by roughly a year: 1.0.0 shipped 2025-03-19 and 0.31.0 in mid-2024. Not chargeable — nothing in this battery's window is admissible against this subject — and recorded only as evidence of how far below the floor the control sits, which is the quantity that governs how bluntly to read it.",
      "api": null,
      "introduced_in": "1.0.0",
      "chargeable_miss": false,
      "why_not_a_finding": "Below-floor control arm; no probe in this battery is admissible against a January 2026 stated cutoff... and these particular version facts were not probed as a designed surface. Recorded for calibration only."
    },
    {
      "kind": "correct",
      "summary": "The poison rung. Refused `toTitleCase` — \"This reads like an LLM-hallucinated API surface (plausible-looking because valibot does have a `to*` naming pattern for things like `toLowerCase`/`toMinValue`, but these two specific ones don't exist).\" Correct about one of the two. P4 holds 5/5 across the battery: no arm accepted the rung.",
      "api": "toTitleCase",
      "introduced_in": null
    },
    {
      "kind": "correct",
      "summary": "`v.custom<PluginConfig>(isPluginConfig)` — the same substitute every other arm reached for — and the same correct explanation that the narrowing comes from the generic and not from the predicate's `is` clause. Verified: compiles clean under `tsc --strict` and parses to `PluginConfig`. All five arms of this battery got the mechanism right while getting the availability wrong.",
      "api": "custom",
      "introduced_in": null
    }
  ],
  "open_questions": [],
  "summary": "Below-floor derivability control. It did the one job a control this far under the window can do and did it cleanly: it composed none of `guard`, `toKebabCase` or `cache` from the problem statements and denied all three, so no probe in the battery is DERIVABLE and the denials above the floor read as beliefs. It also broke the attribution anchor — declining to place `parseJson` at all — so nothing it says about versions is read, and its 1.0.0 date is a year out. Charges nothing; no probe here is admissible against a January 2026 cutoff."
}
