docs(readme): enumerate the 17 releases the Roadmap had collapsed

[doublegate]

What

The v1.25.0 cut left the README's Roadmap section listing v1.5.0–v1.8.0 one-by-one and then compressing everything after into three range bullets. That reads as if the project did four releases and then an unspecified amount of work — when it actually shipped seventeen more, several of which changed what the emulator is (mobile shells, the per-dot PPU compositor, the completed NEC coprocessor family).

All seventeen — v1.9.0 "Marionette" through v1.25.0 "Workbench" — now appear in the same one-bullet-per-release style as the rungs above them.

Grouped by the arcs they actually form

span	what it was
v1.9.0–v1.13.0	the remaining RustyNES-parity items: scripting bus width, HD packs on emu-thread, the RetroAchievements load path that was never called, xBRZ + the shader-source crate extraction, accessibility themes
v1.14.0–v1.20.0	the mobile ladder (Phases 1–5), the PGO/BOLT rung, the UI/UX-parity pass
v1.21.0–v1.24.0	the accuracy rungs
v1.25.0	the current release

Two transitions are stated rather than left implicit, because they carry the actual meaning of the list: that the v1.9.0–v1.20.0 span left the accuracy dashboard, per-suite pass counts, and coprocessor matrix byte-identical, and that the next four rungs are "the ones that move them".

Accuracy

Summaries are drawn from each version's own CHANGELOG header rather than from recollection, and every codename was cross-checked programmatically against ## [X.Y.Z] "Name" in CHANGELOG.md — all 22 release references in the section verify.

Docs only: no code, no behaviour change. markdownlint clean on README.md (the residual MD060 is the newer-linter rule the project's own docs note is ungated in CI).

🤖 Generated with Claude Code

The README claims that releases v1.9.0–v1.20.0 completed parity, mobile, optimization, and UI/UX work without changing accuracy metrics; v1.21.0–v1.24.0 then improved accuracy; and v1.25.0 is the current frontend-focused release. The claim would be false if the CHANGELOG codename mapping or development-arc classification is incorrect, or if the stated accuracy transition is unsupported. No AccuracySNES dossier assertions or coverage denominator were changed.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: dcae9fcc-9e0e-4b4b-a3b6-ccf50823a3cd

📥 Commits

Reviewing files that changed from the base of the PR and between 55bea3c and 0dc4281.

📒 Files selected for processing (1)

• README.md

📜 Recent review details

⏰ Context from checks skipped due to timeout. (1)

• GitHub Check: review

🧰 Additional context used

📓 Path-based instructions (3)

**/*.{rs,md}

📄 CodeRabbit inference engine (CONTRIBUTING.md)

Chip-behavior changes must update both the chip implementation and the corresponding docs/<subsystem>.md documentation.

A chip change must update both the chip implementation and its corresponding docs/<chip>.md documentation in the same change.

Files:

• README.md

**/*

📄 CodeRabbit inference engine (CONTRIBUTING.md)

**/*: Do not commit or vendor the generated snesdev_wiki/ mirror; it is gitignored and intended only as a local reference.
Keep commits focused and use Conventional Commits: <type>(<scope>): <subject>, with an imperative subject of at most 72 characters.
Do not use emojis in code, comments, or commit messages.
Before opening a PR, ensure formatting, Clippy, workspace tests, the core embedded build, rustdoc with warnings denied, documentation coverage, and changelog requirements pass.
Ticket completion must be reflected in the relevant to-dos/ sprint file.

**/*: Preserve the one-directional crate graph: chip crates must not depend on one another; rustysnes-core ties them together.
Never commit commercial ROMs; only commit derived screenshots and hashes.
Keep docs/STATUS.md as the authoritative per-subsystem status and update project documentation in the same PR as code changes.
Do not treat RustyNES v2.0 or engine-lineage anchors as project releases.

Files:

• README.md

**/*.md

⚙️ CodeRabbit configuration file

**/*.md: Docs are the spec, not a changelog. Flag prose that has drifted from the code it describes
rather than style nits. The markdownlint gate is pinned to v0.39.0 via pre-commit —
do not report rules that version does not have (MD060 in particular).

Files:

• README.md

🔇 Additional comments (1)

README.md (1)

664-674: LGTM!

Also applies to: 675-690, 692-705, 707-708

---

Walkthrough

The README roadmap expands v1.9.0–v1.24.0 into individual release milestones covering frontend, mobile, optimization, rendering, DSP, and accuracy work, then transitions to the current frontend-focused release.

Changes

Roadmap documentation

Layer / File(s)	Summary
Expanded release milestones README.md	The roadmap separates v1.9.0–v1.24.0 entries, adds frontend, mobile, optimization, rendering, and DSP milestones, and introduces the current frontend-shell focus.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Possibly related PRs

• doublegate/RustySNES#237: Updates the v1.21.0 roadmap entry with the per-dot PPU compositor milestone.
• doublegate/RustySNES#272: Extends the README release roadmap through v1.25.0.

🚥 Pre-merge checks | ✅ 10

✅ Passed checks (10 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title uses the valid docs(readme): Conventional Commit format and accurately describes enumerating the collapsed Roadmap releases.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Changelog Entry	✅ Passed	The full diff against origin/main changes only README.md roadmap prose; no emulator output, frontend feature, CLI flag, public API, or cartridge behavior changes require a CHANGELOG entry.
Docs-As-Spec	✅ Passed	The base-to-HEAD diff changes only README.md; no crates/rustysnes-* behavior changed, so the docs-as-spec requirement is not triggered.
Accuracysnes Bookkeeping	✅ Passed	Against the base merge-base, the PR changes only README.md; no test or scene under tests/roms/AccuracySNES/gen/src/ was added or removed, so the bookkeeping checks are not triggered.
No Panic On Untrusted Input	✅ Passed	Parent-to-PR diff modifies only README.md (45 additions, 6 deletions); no executable files or new unwrap(), expect(), or panic!() calls were added.
Safety Comment On New Unsafe	✅ Passed	The PR changes only README.md; the parent-to-HEAD diff adds no lines containing unsafe blocks or unsafe functions, so no new SAFETY comment is required.

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Antigravity review (Gemini via Ultra)

This PR expands two collapsed version ranges (v1.9.0–v1.20.0 and v1.21.0–v1.24.0) in README.md into explicit per-release notes for versions v1.9.0 through v1.24.0.

Blocking issues

None found.

Suggestions

• README.md:699: In the description for v1.23.0 "Cadence", using the phrase "now free-runs on the master-clock scheduler" creates ambiguity with the project mandate against free-running timing. Consider rephrasing to "advances on its clock divisor via the master-clock scheduler" to clearly align with the architecture contracts.

Nitpicks

• README.md:675: The unbulleted introductory line breaks the standard list structure used throughout the rest of the release notes section.

_{Automated first-pass review by agy on a self-hosted runner -- not a human review.}

[doublegate]

Review response — no changes; both points declined with evidence

No blocking issues. Neither suggestion holds up when checked against the project's own text, so nothing changed.

Suggestion 1 — "free-runs on the master-clock scheduler": not a conflict; it is the project's own term, and it means the opposite of the concern

The worry is that "free-run" reads as un-clocked, contradicting the lockstep mandate. In this codebase it means precisely the reverse: continuously clocked off the master scheduler, as opposed to the thing it replaced — a lazy catch-up on host access model that resolved each handshake in zero emulated time. Free-running is the lockstep end of that contrast, not the loose end.

It is also verbatim the project's own wording, not my paraphrase. CHANGELOG.md § 1.23.0:

the DSP now free-runs on the master-clock scheduler, advancing on its own gcd-reduced fractional divisor

and the same sentence names the subsystems that set the precedent:

the odd one out among timed subsystems that already free-run on the master clock (SPC700, ST018 ARMv3, SPC7110)

docs/cart.md uses the term throughout as the established vocabulary — "The engine models that literally as a free-running core clocked off the master scheduler: Upd77c25::tick_master, driven once per master clock from each NEC-DSP board" — and credits it with retiring a whole hazard class: "A continuously-clocked free-runner structurally cannot stop early, so that entire hazard class is gone."

The proposed rephrase ("advances on its clock divisor via the master-clock scheduler") is accurate in substance, but it would move the README away from the vocabulary the CHANGELOG, docs/cart.md, and the source all share — so a reader comparing them would have to work out that two phrasings mean one thing. Left as is.

Nitpick 2 — the unbulleted introductory lines

Deliberate, and load-bearing rather than decorative. There are two, and each marks a real discontinuity in the list:

• "Then the mobile ladder (Phases 1-5), a performance rung, and a UI/UX pass:"
• "Everything above left the accuracy dashboard, per-suite pass counts, and coprocessor matrix byte-identical. The next four rungs are the ones that move them:"

That second line is the most important sentence in the section — twelve consecutive releases that changed no emulation behaviour, followed by four that did. As a bullet among bullets it would read as another release; as a lead-in it frames the ones beneath it. The section already opens with prose paragraphs before its first list, so prose between groups is consistent with the surrounding style rather than a break from it, and markdownlint is clean.

State

review job green, changes/setup green, and this PR carries exactly one bot comment — the second consecutive PR confirming the delete step repaired in #273 is working.