[AdaWorldAPI]

What this is

Documentation-only. .claude/plans/r2il-behavioral-ir-v1.md carried a session
verdict — "V3 is sufficient. No V4" — restated as a §22.5 stop condition. The
operator ruled otherwise on 2026-08-21: V4 is minted as an additive sibling
tier for R2IL's 100%-coverage requirement and other special needs, with V3
continuing unchanged for everything it already carries.

What changed

Two supersession blocks, appended in place rather than edited, per the
append-only convention for plan and board text:

• after the verdict bullet — the full ⊘ block, naming what survives (the
  evidence: no V3 mechanism was falsified, and the mint is not a repair of a V3
  defect), what is retracted (the conclusion — a session verdict does not
  outrank an operator ruling), and what the ruling explicitly leaves open
  (V4's layout, its home crate, the full special-needs set, the V3-vs-V4
  routing rule, and whether the 0xC4 mint under O5/PR 3 lands as V3 or V4);
• after the §22.5 line — a one-line pointer, scoping the retraction to the
  "no V4" half only. The "variable arity already routed upstream" half is
  unaffected and stands.

No code, no test, no behaviour change.

Why the blocks name the open items

Reading the ruling as settling more than it did is the likelier failure than
missing it entirely. Five questions are genuinely unanswered, and the one most
likely to be assumed away is the last: the classid mint is gated on O5 and has
not been assigned to a tier.

Cross-references

• lance-graph .claude/board/EPIPHANIES.md E-V4-IS-THE-100-PERCENT-TIER-V3-UNCHANGED-1
  is the durable board record of the ruling.
• lance-graph docs/architecture/ARC-B-OWNERSHIP-AND-ADDRESSING-REASSESSMENT.md
  §7 already writes the external path as binary → Ghidra/SLEIGH/P-code → r2sleigh → V4 R2IL (2026-08-19) — the label was in circulation before the
  ruling, which is corroboration rather than a competing definition.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AGVLyRZNEKKBSfBDJfbY3V

---

Generated by Claude Code

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_28c901c4-d3a9-4a2b-a1f3-f483fd3a9b4a)

[AdaWorldAPI]

cargo publish dry-run is red here, and it is not this PR — it is upstream registry drift that will fail every PR opened against main today. Not fixing it in a docs-only branch; the diagnosis, so the next PR does not re-derive it:

What fails. ruff_graph's tarball verification builds against two versions of ruff_cache and of ruff_python_parser at once. The compiler says so directly:

error[E0599]: no method named `cache_key` found for struct `ExtensionMapping`
note: there are multiple different versions of crate `ruff_cache` in the dependency graph
  --> .../index.crates.io-.../ruff_cache-0.0.10/src/cache_key.rs:74:1   <- expected trait
  ::: .../-9cf9d774767a10c8/ruff_cache-0.0.9/src/cache_key.rs:74:1      <- imported trait
error: failed to verify package tarball

Same shape for ParseOptions: From<PySourceType> against ruff_python_parser-0.0.9.

Why now. ruff_cache 0.0.10 was published to crates.io on 2026-08-20 18:00 UTC. The last green CI run on main was 2026-08-18 13:20 UTC — two days earlier, when 0.0.9 was still the newest. The job resolves the registry fresh, so the same main tree that passed on the 18th fails today with no commit in between.

Why it cannot be this branch. The diff against origin/main is one file, +20 −0, in .claude/plans/ — a markdown supersession note. No Rust source, no Cargo.toml, no lockfile. Nothing here reaches a package tarball.

Not re-running the job. This is deterministic version resolution, not flakiness; a re-run resolves the same 0.0.10 and fails identically.

What would actually fix it — and why it is not mine to land here: syncing the fork's crate versions with upstream 0.0.10 (or pinning the publish verification to the workspace versions). That is a dependency change to the fork's release story and belongs in its own PR, judged on its own evidence, not smuggled in under a docs correction.

Every other check on the run is green or correctly skipped for a docs-only diff. The Cursor Bugbot neutral result is that account's usage limit, not a finding.

---

Generated by Claude Code