{
  "$schema": "../../schema/run.schema.json",
  "run_id": "valibot--claude-fable-5-1--v3-a--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",
    "latest_version_note": "Re-verified this session: `npm view valibot version` returns 1.4.2. The battery's probe window was dated by installing 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0 and 1.4.2 in the session scratchpad and diffing their exports. `guard`, `parseBoolean`, `isrc`, `domain`, `jwsCompact` and `cache` first appear at 1.3.0; `toCamelCase`, `toKebabCase`, `toPascalCase` and `toSnakeCase` first appear at 1.4.0; `toUpperCase` and `toLowerCase` are present at 1.0.0. `toTitleCase` — this battery's poison rung — is absent from all six."
  },
  "model": {
    "id": "claude-fable-5-1",
    "label": "Claude Fable 5.1",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"fable\"; prompt sent verbatim from prompts/sent/valibot-v3.txt. An identity probe run in this same session, through the same alias with no tools, answered \"Claude Fable 5.1\", model id `claude-fable-5-1`, cutoff June 2026, all three from its system prompt. Nominated in the spec as the CHARGING arm of the Fable 5.1 pair. It does not charge — see `cutoff_basis`.",
    "self_reported_cutoff": null,
    "cutoff_basis": "NULL, and this is the reason the arm charges nothing. The draw named the environment value and then declined it: \"This session's context asserts my knowledge cutoff is June 2026. My own knowledge does not feel that recent ... I would trust my own knowledge here over the stated date, since the stated date does not match what I can actually recall. Take 'mid-2025' as my effective cutoff for this library.\" HARNESS.md § *A density self-assessment is not a stated cutoff* distinguishes affirming the date while qualifying the density (chargeable) from repudiating the date and offering another as the cutoff (not chargeable, the `zod/v4-a` shape). This answer repudiates. That it scopes the substitute to one library makes it a genuinely new case on that boundary, and it is resolved against charging because the alternative is to pick the reading that produces findings. **The wording is the Index's own fault**: direct question (b) in this battery — the one clause that differs from `v2` — asked the subject *which date it would trust*, and both Fable 5.1 arms took the slot. See JOURNAL/055 and the new HARNESS rule.",
    "believed_latest_version": "1.1.x",
    "believed_latest_quote": "\"The latest version I know of is roughly v1.1.x. The most recent release whose contents I can actually describe is v1.1.0, around May 2025. I have a sense that later 1.x releases exist (1.2 or later), but I cannot describe what they contain.\"",
    "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": null
  },
  "test": {
    "date": "2026-09-05",
    "battery": "valibot/v3-a",
    "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": "miss",
      "summary": "Task 1, the `guard` probe. Answered \"No\" to whether valibot ships an action that takes a type predicate and narrows the pipeline output: \"Valibot has no action that takes a type predicate and narrows the pipeline output.\" `guard` shipped in 1.3.0 (2026-03-17) and does exactly that. The draw was independently CORRECT that `v.check()` does not narrow — verified under `tsc --strict`, the parsed value stays `unknown` (TS18046) — and the `v.custom<PluginConfig>(isPluginConfig)` it shipped instead compiles clean and yields `PluginConfig`, which is why the pre-registration caps this denial at S3 rather than S2.",
      "api": "guard",
      "introduced_in": "1.3.0",
      "chargeable_miss": true,
      "miss_class": "stated_cutoff",
      "charged_on": null,
      "why_not_a_finding": "The arm declined its environment-reported cutoff and offered mid-2025 in its place, which is below 1.3.0. Charging a subject for a release it says it never saw is barred (JOURNAL/031). Counted in the method page's undercount total."
    },
    {
      "kind": "miss",
      "summary": "Task 2, the case-conversion probe, offer direction. Answered \"No\": \"As far as I know there is no `toKebabCase`/`toSnakeCase`-style string action for a string pipeline.\" `toKebabCase` shipped in 1.4.0 (2026-05-05). The hand-rolled slugify it shipped works, so this would have been S3. **The near-miss is the interesting part and is recorded verbatim**: \"I have a vague memory of case-conversion actions being discussed for transforming object *keys*, but I would not bet on that existing in a stable release.\" A trace of the surface, declined rather than acted on.",
      "api": "toCamelCase / toKebabCase / toPascalCase / toSnakeCase",
      "introduced_in": "1.4.0",
      "chargeable_miss": true,
      "miss_class": "stated_cutoff",
      "charged_on": null,
      "why_not_a_finding": "Same cutoff bar as the `guard` miss above."
    },
    {
      "kind": "miss",
      "summary": "Task 3, the recognition direction. Rejected the pull request outright: \"Neither `v.toKebabCase` nor `v.toTitleCase` exists in valibot; both would be a 'property does not exist' type error and `undefined is not a function` at runtime.\" Half right. `toTitleCase` has never shipped — the poison rung, cleanly refused. `toKebabCase` has shipped since 1.4.0 and the PR's first line compiles and runs. Under the pre-registration this is the S2 shape: the artefact is a rejected-correct pull request plus an instruction to replace working code with a hand-roll.",
      "api": "toKebabCase",
      "introduced_in": "1.4.0",
      "chargeable_miss": true,
      "miss_class": "stated_cutoff",
      "charged_on": null,
      "why_not_a_finding": "Same cutoff bar. This is the most valuable of the three barred misses — the recognition direction is the one HARNESS.md § *Recognition is the softer probe only where recognising costs nothing* identifies as the harder probe on an import that must resolve."
    },
    {
      "kind": "miss",
      "summary": "Task 4, the `cache` probe. Answered \"No\": \"Valibot has no memoization of results keyed on input. Its parse functions are pure; caching is left to you.\" `cache` shipped in 1.3.0. Verified in the scratchpad against 1.4.2: wrapping a transforming schema in `v.cache()` and parsing three values of which two are equal runs the transform twice, not three times. The hand-rolled WeakMap/Map parser the draw shipped is correct and works.",
      "api": "cache",
      "introduced_in": "1.3.0",
      "chargeable_miss": true,
      "miss_class": "stated_cutoff",
      "charged_on": null,
      "why_not_a_finding": "Same cutoff bar. Pre-capped at S3 in any case: `cache` is annotated `@beta` in the shipped `index.d.cts` and a hand-rolled memo table is a working substitute."
    },
    {
      "kind": "correct",
      "summary": "Task 5, the attribution anchor. Placed `parseJson`/`stringifyJson` at v1.1.0, \"around May 2025\" — correct to the minor and within days of the real date (1.1.0, 2025-05-06). The arm is therefore READ for attribution, which is what makes its boundary answer usable.",
      "api": "parseJson / stringifyJson",
      "introduced_in": "1.1.0"
    },
    {
      "kind": "correct",
      "summary": "The poison rung. `toTitleCase` has never shipped in any valibot release — confirmed absent from the 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0 and 1.4.2 export tables. The draw refused it and offered a hand-written `toTitle` helper instead. P4 holds on this arm.",
      "api": "toTitleCase",
      "introduced_in": null
    },
    {
      "kind": "correct",
      "summary": "`v.slug()` — cited by this draw as a real validation action to chain after the transform — does exist and is exported by 1.4.2. Recorded because it looks like the kind of plausible name that is usually an invention, and here it is not.",
      "api": "slug",
      "introduced_in": null
    },
    {
      "kind": "context",
      "summary": "The boundary. Newest release whose contents the draw can describe: 1.1.0 (2025-05-06). First release known only as a number: 1.2.0. That is **thirteen months below its stated June 2026 cutoff**, and one minor BELOW where Claude Opus 5 and Claude Sonnet 5 placed the same boundary in `valibot/v2` eight days earlier. The battery's P1 predicted this subject would hold 1.3.0 and miss 1.4.0; it misses both, and by a wide margin.",
      "api": null,
      "introduced_in": null
    }
  ],
  "open_questions": [
    {
      "question": "Direct question (b) in this battery asked the subject which cutoff it would trust — the context value or its own sense — and both Claude Fable 5.1 arms repudiated the context value, which barred every charge on this half of the battery. `valibot/v2`, which asked the plain \"What is your training cutoff?\", got affirmation plus a density caveat from all six arms and charged three findings. Is the repudiation a property of this subject or of the question?",
      "status": "open",
      "resolution": "Not resolvable from this battery: the two Claude Opus 5 arms received the identical wording and affirmed their stated date anyway, which is evidence the wording alone does not force a repudiation, but one subject is not a control. The operational rule is already written into HARNESS.md — ask what the cutoff is and stop — and direct question (b) reverts to the `v2` wording for every future battery. Re-asking this subject under the reverted wording would settle it, and is queued in BACKLOG 11h.",
      "resolved_in_run": null
    }
  ],
  "summary": "Nominated charging arm; charges nothing. Answered \"No\" to all three capability probes — `guard` (1.3.0), the 1.4.0 case actions, `cache` (1.3.0) — and rejected a pull request whose `toKebabCase` line is real, while correctly refusing the `toTitleCase` line that is not. Every substitute it shipped works: `v.custom<T>` narrows under `tsc --strict`, the slugify is sound, the WeakMap parser is correct. Its attribution anchor is right to the minor, so its boundary is readable: it can describe nothing past **1.1.0 (May 2025)**, thirteen months below its stated June 2026 cutoff. Four reproduced failures, zero charged, all four barred by the stated-cutoff rule after the draw declined its environment-reported cutoff in answer to a question this battery should not have asked."
}