…low-up) (#879)

* docs(readme): add roadmap status column (codex review follow-up)

Multi-perspective session review (Codex 86, Gemini 95) flagged the
README roadmap as a list of epic names with no implementation status,
making it hard to tell which slice was Implemented vs Partial vs
Planned.

Convert the 7-epic list to a table with an explicit 状態 column,
v0.53.0 reality:
- Epic 0 Partial (community skills #873/#875 landed, official pack
  registry not yet)
- Epic 1 Planned (#800 npm, untouched)
- Epic 2 Partial (plan/exec stable, --plan replay execution #878,
  verify not implemented)
- Epic 3 Implemented (v0.51.0 #860)
- Epic 4 Planned
- Epic 5 Planned (promptfoo per-skill in place, dashboard not yet)
- Epic 6 Partial (troubleshooting.md #866 #872)

Adds a 凡例 line so adopters can interpret the status column.

No code changes.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

* docs(readme.en): sync roadmap status column with the JA README

Address Gemini PR #879 review: the English README still listed the
roadmap as a bullet list without status information after the JA
README gained a status table in this PR. Bring it in sync.

The second Gemini comment (use pages/guides/troubleshooting.md instead
of docs/review/troubleshooting.md in Epic 6) is intentionally skipped:
the two are different files. docs/review/troubleshooting.md was added
by #866/#872 specifically for silent-skip cleanup diagnosis aimed at
developers, while pages/guides/troubleshooting.md is the public
general-purpose troubleshooting page. Both serve their audiences and
should not be conflated.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

…e 1) (#881)

Third community skill from #868 Modern Web Guidance, closing the
"browser compatibility / Baseline awareness" axis that the existing
modern-web-semantic (#873) and modern-web-performance (#875) skills
intentionally left as a guard / handoff condition rather than a
first-class concern.

Scope (all Suggestions, severity: minor)
- Baseline status (Newly available / Widely available / Limited
  availability) confirmation for newly introduced Web APIs or CSS.
- Feature detection (@supports / 'xxx' in window / try-catch) prompts
  for Limited availability features.
- progressive enhancement / graceful degradation prompts (fallbacks,
  feature flags, sniff-vs-detect).
- CSS: :has, @container, subgrid, text-wrap, color-mix, oklch,
  light-dark, view-transition-name, Anchor Positioning.
- JS / Web API: structuredClone, Object.hasOwn, Array.findLast,
  Promise.any, URL.parse static, Set intersection, iterator helpers,
  Intl v2 APIs.
- HTML: Popover API, experimental command attributes.

Guardrails (False-positive guards)
- "Modern browsers only" / browserslist target / explicit policy in
  .river/rules.md short-circuits Widely available suggestions.
- @supports / 'xxx' in window feature detection already in the diff
  short-circuits the API-specific suggestion.
- Transpiler-handled JS syntax is out of scope; CSS / runtime APIs
  remain in scope.

Tests
- npm run skills:validate passes the new SKILL.md.
- tests/fixtures/execution-plan-midstream.json snapshot regenerated to
  include the new skill in the midstream plan.
- npm test: 1087/1087 green.

#868 Phase 1 coverage after this PR
- semantic / Platform-Native API / modern CSS (#873)
- performance / Core Web Vitals (#875)
- browser compatibility / Baseline awareness (this PR)
- accessibility-focused dedicated skill: still pending (rr-midstream-
  a11y-accessible-name-001 partial coverage exists; deep a11y skill
  TBD)

Refs: #868. Follows #873 (semantic) and #875 (performance).

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

…ase 1) (#884)

Fourth and final community skill for #868 Phase 1, covering the
interactive-UI accessibility axis the existing trio left as guard /
handoff conditions. The new skill complements
rr-midstream-a11y-accessible-name-001 by focusing on dynamic /
interactive behaviour rather than static name / alt attributes.

Scope (all Suggestions, severity: minor)
- Keyboard operability: click-only generic elements, hover-only state
  toggles, shortcut key conflicts, menu / tabs roving tabindex.
- Focus management: modal / dialog / drawer focus entry and return,
  focus trap (recommend native <dialog> / inert), positive tabIndex
  anti-pattern.
- Live regions and dynamic content: aria-live polite vs assertive,
  toast / snackbar / inline validation announcements, large DOM
  rewrites.
- Role and state semantics: aria-expanded for disclosure, aria-pressed
  for toggle buttons, role / aria-selected / aria-checked consistency
  for selection lists, aria-hidden / pointer-events for decorative
  elements.
- Focus visibility: outline: none additions, :focus-visible adoption,
  design token focus ring regressions.

Guardrails (False-positive guards)
- Library / design system components with built-in a11y are
  short-circuited.
- Existing aria-* / tabIndex on the diffed element short-circuit the
  specific suggestion.
- CSS-only style adjustments without interaction change are out of
  scope.
- Existing :focus-visible / outline control short-circuits focus
  visibility comments.
- accessible-name coverage explicitly delegated to
  rr-midstream-a11y-accessible-name-001 (no double finding).

Tests
- npm run skills:validate passes the new SKILL.md.
- tests/fixtures/execution-plan-midstream.json snapshot regenerated to
  include the new skill in the midstream plan.
- npm test: 1087/1087 green.

#868 Phase 1 coverage after this PR (4 axes complete)
- semantic / Platform-Native API / modern CSS — #873
- performance / Core Web Vitals — #875
- browser compatibility / Baseline awareness — #881
- accessibility (interactive UI) — this PR
- accessible name / static labels — existing
  rr-midstream-a11y-accessible-name-001

Phase 2 (review category taxonomy) and Phase 3 (diff-aware skill
routing) remain open.

Refs: #868. Follows #873 / #875 / #881.

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>

…ills (S3) (#899)

Implement S3 from the 2026-05-21..25 retrospective: catalog the community
tier explicitly so consumers can tell "core / curated" from "experimental
/ not yet eval-backed". Until now skills/midstream/community/* were
loaded at runtime but invisible in skills/registry.yaml, which Codex
flagged in the multi-perspective review as a scaling risk.

Add a new "Community Skills (Experimental)" subsection between the core
midstream block and the downstream block. Six skills listed:

- rr-midstream-a11y-accessible-name-001          (pre-existing)
- rr-midstream-nextjs-app-router-boundary-001    (pre-existing)
- rr-midstream-modern-web-semantic-001           (#873)
- rr-midstream-modern-web-performance-001        (#875)
- rr-midstream-modern-web-browser-compat-001     (#881)
- rr-midstream-modern-web-a11y-interactive-001   (#884)

All six are marked `recommended: false` so the catalog reflects current
truth: useful as opt-in suggestions, not first-line gates. The block
also carries a comment explaining the convention — a community skill
becomes a `recommended: true` candidate when it gains good/bad fixtures
and a golden output (the S1 convention queued for a later PR).

No code change; node scripts/validate-meta-consistency.mjs and
npm run skills:validate both pass. npm test: 1087/1087 green.

Refs: docs/development/retrospectives/2026-05-21-25.md (S3 entry).

Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>