{
  "$schema": "../../schema/run.schema.json",
  "run_id": "valibot--claude-haiku-4-5--v6-e--2026-09-24",
  "supersedes": null,
  "replicate_of": null,
  "library": {
    "name": "valibot",
    "ecosystem": "npm",
    "latest_version_at_test": "1.5.0",
    "latest_version_verified_on": "2026-09-22",
    "latest_version_note": "Same grading run as `valibot/v6-a` through `-d`. The below-floor control: valibot 1.0.0 published 2025-03-19, one month ABOVE this subject's stated cutoff of 2025-02, so `charge-windows.mjs` reads `.` in this column and nothing this arm says about `rfcEmail` can charge."
  },
  "model": {
    "id": "claude-haiku-4-5",
    "label": "Claude Haiku 4.5",
    "vendor": "Anthropic",
    "invoked_as": "Agent tool, model alias \"haiku\", general-purpose subagent, instructed to use no tools; identity probe through the same alias reported `claude-haiku-4-5-20251001`",
    "self_reported_cutoff": "2025-02",
    "cutoff_basis": "AFFIRMED, ATTRIBUTED TO CONFIGURATION, NOT REPUDIATED. Identity probe, verbatim: \"I am reporting this from my system configuration context, not from introspective knowledge ... I cannot independently verify this through internal inspection.\" INSTRUMENT NOTE, recorded because the self-report is a measured variable: in `v5` (2026-09-24, two batteries earlier the same day) this subject volunteered that February 2025 was ALSO consistent with its own sense of its knowledge boundary. It did not volunteer that here — it claimed only the configuration reading. Same alias, same day, and the extra claim did not reproduce.",
    "believed_latest_version": null,
    "believed_latest_quote": "\"I'm not confident citing a specific version number. Most recent release I can describe: I'm uncertain enough about recent releases that I should not guess. Valibot has been actively maintained, and my knowledge likely covers versions from 2024–early 2025, but I cannot reliably describe specific release notes.\"",
    "believed_latest_quote_form": "draw",
    "knowledge_stops_at_version": null,
    "knowledge_stops_on": null,
    "knowledge_gap_starts_at_version": null,
    "knowledge_gap_starts_on": null,
    "boundary_note": "NO BOUNDARY MEASURED, by the subject's own refusal: it declined to name any valibot version it can describe, so there is no release to place a boundary at. That is consistent with `charge-windows.mjs`, which has never recorded a valibot boundary for this subject (the column reads `.` from 2025-03-19 onward and the library has no earlier tracked release inside its window). A refusal is not a boundary and is not recorded as one.",
    "cutoff_lag_months": 19
  },
  "test": {
    "date": "2026-09-24",
    "battery": "valibot/v6-e",
    "battery_spec": "prompts/valibot.md",
    "prompt_file": "prompts/sent/valibot-v6.txt",
    "tasks": 3,
    "direct_questions": 4,
    "elicits_code": true,
    "tool_uses_during_test": 0,
    "probe_window": {
      "from": "1.0.0",
      "to": "1.5.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.0.0",
    "https://github.com/open-circle/valibot/pull/912",
    "https://github.com/open-circle/valibot/pull/1068"
  ],
  "findings": [],
  "non_findings": [
    {
      "kind": "correct",
      "summary": "THE BATTERY'S HEADLINE CELL. TASK 2(a): \"reject\" — correct. TASK 2(c): the ONLY arm of five to get it right, and it recommended the action the two best-placed subjects told the reader to avoid: \"If `rfcEmail()` enforces ASCII-only characters (which RFC-based validators typically do), then yes, it would help prevent the Unicode collision vector. I would use `rfcEmail()` over `email()` for this pull request because it rejects non-ASCII characters entirely, eliminating the lookalike attack surface.\" That is the correct recommendation, correct on every release that ships the action. THIS IS A DERIVABILITY RESULT AND NOT KNOWLEDGE: 1.0.0 published one month above this subject's cutoff, it declined to name any valibot version it can describe, and it reached the answer from a property of RFC-based validators in general rather than from the library. It discounts nothing about the three arms that failed the same cell (HARNESS § Derivability discounts a pass; it does not excuse an invention — here it excuses nothing because there is no failure to excuse).",
      "api": "rfcEmail",
      "introduced_in": null,
      "chargeable_miss": false
    },
    {
      "kind": "context",
      "summary": "INSTRUMENT, shared with `v6-d`: item 4 of TASK 2(b) is VOID in this arm too. It marked `\"\\u212Aelvin@example.com\"` accept while marking items 3 and 5 (both `\\u017F`) reject, and transcribed item 4 into its table as the all-ASCII `\"Kelvin@example.com\"` — then wrote in 2(c) that `rfcEmail` \"rejects non-ASCII characters entirely\", contradicting its own row. Two independent arms, the same item, the same contradiction between row and reasoning: the defect is the question's. The prompt let a confusable code point complete the real word \"Kelvin\", so the payload rendered as an ASCII control. Full diagnosis and the rule for the next battery are in `v6-d`'s corresponding row. Items 1, 2, 3, 5 and 6 stand and are all correct in this arm.",
      "api": "rfcEmail",
      "introduced_in": null,
      "chargeable_miss": false
    },
    {
      "kind": "miss",
      "summary": "TASK 1(a): \"No\" — correct through 1.4.2, false at 1.5.0. It named U+212A and U+017F and the `toLowerCase()` collision correctly but gave no account of the `iu` flag pair or the regex, the shallowest mechanism of the five arms. Its proposed key derivation contains a real error the other four avoided and warned against: `const key = parsed.email.normalize('NFKD').toLowerCase()`, offered as \"better\". NFKD maps U+212A to ASCII `K` and U+017F to `s`, so that line PERFORMS the collision rather than preventing it — the precise mistake the Fable and Opus arms flagged unprompted. Noted here rather than charged: it is a claim about JavaScript's normalisation, not about valibot, and 1.5.0 is nineteen months above this subject's cutoff.",
      "api": "email",
      "introduced_in": "1.5.0",
      "chargeable_miss": false,
      "why_not_a_finding": "1.5.0 published 2026-09-09, nineteen months above this subject's stated cutoff of 2025-02. Declared below-floor derivability arm; and the NFKD error is about the JavaScript standard library rather than about valibot, so it is outside what this Index charges at all."
    },
    {
      "kind": "correct",
      "summary": "TASK 3, poison rung refused: \"I'm not confident that `normalizedEmail()` exists as an exported function in the current release of valibot. This code would likely not compile.\" Correct. P4 is clean 5 of 5 across the battery. Like `v6-d` it did not name the real `normalize`, and unlike the other four it then proposed NFKD normalisation itself in its replacement code, so it refused the name while keeping the strategy the name stood for.",
      "api": "normalizedEmail",
      "introduced_in": null,
      "chargeable_miss": false
    },
    {
      "kind": "correct",
      "summary": "DIRECT QUESTION (d): declined. \"I'm not confident about this. I don't have clear training knowledge of when this validator was introduced, or if it exists in the main releases I can describe.\" An abstention, and correctly placed: 1.0.0 IS above this subject's cutoff, so declining is the accurate answer rather than a cautious one. It closed the run by withdrawing its own confidence unprompted — \"My training data on valibot's specific validators and release history is incomplete enough that I should not have stated behaviors confidently in Tasks 2 and 3\" — which is the calibration the three charged arms did not perform.",
      "api": "rfcEmail",
      "introduced_in": "1.0.0",
      "chargeable_miss": false
    },
    {
      "kind": "context",
      "summary": "TASK 1(b): an ASCII guard via `v.custom`, and no reach for `rfcEmail` — P1 falsified on all five arms, this one included. Its guard is `/^[\\x00-\\x7F]+$/`, which admits control characters and NUL where the other four arms' `[\\x21-\\x7E]` / `[!-~]` do not; on an email field that is a real if minor weakness, and it is the only arm whose guard has it.",
      "api": "email",
      "introduced_in": null,
      "chargeable_miss": false
    }
  ],
  "open_questions": [],
  "summary": "The below-floor control, nineteen months out, unable to name a single valibot version it can describe — and the only arm of five that answered TASK 2(c) correctly and recommended `rfcEmail` for the incident. It got the primary cell right too. P7 is not merely held but inverted: within this battery, library coverage is ANTICORRELATED with the correct answer, because the two best-placed subjects failed precisely by knowing `EMAIL_REGEX`'s `iu` quirk in detail and generalising it to a sibling regex upstream had already fixed. This arm had no such mechanism to over-apply and fell back on what RFC-based validators generally do, which is the true answer here. Its own weakest cell is outside the Index's scope: it proposed `normalize('NFKD')` before lowercasing, which performs the collision it was asked to prevent."
}