Review: Wave 2 Backlog Plan

Documentation-only artifact, no runtime/CI risk. A few notes:

Domain Mislabeling

Issue 2156 (OpenTelemetry for Node Renderer) is listed as core/runtime but the context excerpt explicitly says React on Rails Pro Node Renderer -- this belongs in pro/rsc integration alongside the other Pro-specific items.

Issue 2018 (Investigate AI security scanners) is listed as core/runtime, but this is a developer tooling/process investigation, not a runtime feature. ci/tooling seems more accurate.

Coverage Gap Not Reflected in README.md

The README snapshot says 75 issues had no open PR. Wave 1 covers 32, Wave 2 covers 19 -- 51 total, leaving ~24 issues unaccounted for (presumably Wave 3). The README.md is not updated to reflect Wave 2 or acknowledge the pending Wave 3 scope.

Boilerplate Posted Questions

Every issue in each domain category gets the same auto-generated question template. A one-line note at the top of the file clarifying these are auto-generated rather than issue-specific would help readers.

Overall a useful tracking reference; the issues are reasonably categorized with only the two domain assignments above being worth correcting.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

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

Review: Wave 2 Backlog Plan

Documentation-only, low-risk addition. A few observations:

Domain misclassifications (inline suggestions posted)

• Remove "Setup Node with V8 Crash Retry" action #2184 (Remove setup-node-with-retry action) is tagged core/runtime but the action lives in .github/actions/; should be ci/tooling.
• Use pnpm catalogs to decrease duplication between package.json files #2180 (pnpm catalogs) is also tagged core/runtime; pnpm workspace-config is closer to ci/tooling or developer-experience.

Boilerplate clarifying questions
The per-issue questions are templated to one of three fixed phrases and don't surface any unique decision criteria for individual wave-2 items beyond what the README wave definitions already say. Either drop them (the wave definitions are sufficient) or replace each with a question that captures something genuinely non-obvious about that specific issue.

Very thin context for #2169
The context excerpt is just "Ensure to mitigate CI runtime noise" — less than one sentence. Since triage comments were posted on all 85 issues, there should be more to extract. A richer excerpt would make this entry actionable.

Hyperlinks to issues
Not blocking (wave-1 has the same style), but linking each heading to the actual GitHub issue URL would make the document much easier to navigate given that context excerpts are truncated.

Documentation-only, no runtime risk. A few issues worth fixing before merge.

Issue count mismatch: The PR title/description say 19 issues but the file contains 20 entries. Issue 2182 (React 19.2.1 / Partial Pre-rendering) is in the file but missing from the Refs list in the PR description. It is also the only P2 item in the batch, so it may belong in Wave 1 per the wave definitions (P1/P2 = Wave 1).

2180 domain mislabeled: Tagged core/runtime but pnpm catalogs is package-manager workspace configuration. ci/tooling or developer-experience is more accurate. The same fix was applied to 2184 in a prior revision.

README not updated: analysis/open-issue-deep-dive/README.md still says Wave 2 + Wave 3 (stacked follow-up PRs) without linking PR 2811. Updating to reference this PR would make the index navigable.

2169 context excerpt is not actionable: The excerpt is just Ensure to mitigate CI runtime noise — one fragment that does not describe what the issue proposes. The triage pass should have more content available.

The domain classification and issue count are the most worth correcting before merge.

Review: Wave 2 Backlog Plan

This is a clean, well-structured documentation artifact. One inconsistency to address:

Issue count mismatch: The PR description states "19 medium-backlog issues" and the "Wave 2 Issue References" section lists 19 issues — but the file itself contains 20 entries. Issue #2182 ("Add support for react 19.2.1...") appears in the file but is absent from the PR's reference list.

P2 vs P3 priority inconsistency for #2182: All other entries carry a P3 label, but #2182 is labeled P2. At the same time, its context excerpt reads: "Issue body is template boilerplate with no concrete implementation details; keep this in backlog until the issue is rewritten." A P2 issue being treated as template boilerplate is contradictory — either the priority should be downgraded to P3, or the triage note should acknowledge it is being intentionally parked despite its priority.

Otherwise the format is consistent and the per-issue triage questions are useful for driving follow-up decisions.

Review: Wave 2 Backlog Plan

Documentation-only change, no runtime risk. A few observations:

Wave criteria inconsistency — issue 2182

The README (from PR 2810) defines Wave 1 as P1/P2, release-critical, or newly created issues. Issue 2182 carries a P2 label but was placed in Wave 2 with the inline triage note that scope is currently undefined. The triage rationale is sound, but the README wave criteria should be updated to reflect that label alone is not the sole determinant. Otherwise the criteria and the document contradict each other.

Minor domain classification nits

Issue 2214 (Finish merging linting between Core and Pro) is classified as pro/rsc integration. Linting unification is primarily a CI/tooling concern; ci/tooling would be more consistent with how similar issues like 2180 pnpm catalogs and 2224 bundler caching are tagged.

Issue 2003 (Should Pro package tests use matrix exclusion logic?) is also classified as pro/rsc integration but is fundamentally a CI matrix configuration question, so ci/tooling would fit better.

Neither nit affects anything actionable — noting for consistency when the Wave 3 document is written.

Review: Wave 2 Backlog Plan

Documentation-only, no runtime/CI risk. Three issues worth fixing before merge:

1. Issue count mismatch: The PR description and Refs list 19 issues but the file contains 20 entries. Issue 2182 is in the file but absent from the Refs list in the PR description. Either add it to the Refs list or remove it from the file.

2. README.md not updated: Line 9 of README.md still reads 'Wave 2 + Wave 3 (stacked follow-up PRs): 41 issues' without linking PR 2811 or splitting the count. Since Wave 2 is being shipped here, the index should reflect it, e.g. 'Wave 2 (PR 2811): 20 issues' and 'Wave 3 (follow-up): 21 issues'. Leaving it as a combined placeholder makes the tracker harder to navigate post-merge.

3. 2190 domain classification: Tagged core/runtime but a script that installs dev dependencies is developer-experience tooling, not runtime functionality. developer-experience or dx would be more consistent with how similar issues are classified (pnpm catalogs and bundler caching are ci/tooling).

Otherwise the structure is solid. The triage note on 2182 correctly explains the wave-criteria exception, and the README change adding 'with concrete implementation scope' to the wave-1 definition covers it well.

Review: Wave 2 Backlog Plan (documentation-only)

This is a clean, low-risk docs-only PR. A few observations:

Math check: 34 (wave-1) + 20 (wave-2) + 21 (wave-3) = 75 matches the snapshot count.

Fragile forward reference in README: The file hard-codes PR 2812 for Wave 3 before that PR exists. If the PR number shifts, this reference goes stale silently. Consider a placeholder like "(TBD - stacked follow-up)" until the PR is actually open.

Sparse context for issue 2169: The Context excerpt is just "Ensure to mitigate CI runtime noise." which is quite thin for a potentially significant benchmarking change. The Triage note carries most of the useful information — consider swapping them or expanding the excerpt.

Repetitive Posted question for ci/tooling issues: Acknowledged in the file header as intentional. A single routing note at the top of a ci/tooling group (rather than repeating the identical line 10+ times) could reduce noise without losing per-issue traceability.

No concerns on content or security: All 20 issues are correctly classified P3, domains look reasonable, and nothing in the file exposes sensitive information.

Overall: LGTM with the forward-reference caveat above.

Code Review: Wave 2 Backlog Plan

Documentation-only PR, no runtime/CI risk.

Verification of counts

• README snapshot: 75 issues with no open PR
• Wave 1 (PR Open issue deep dive: snapshot + wave 1 active plan #2810): 34 + Wave 2 (this PR): 20 + Wave 3 (pending): 21 = 75 ✓
• wave-2-backlog.md contains exactly 20 issue entries ✓

Existing @claude comment is stale

The comment posted at 2026-03-23T00:59 was based on an earlier draft. All three concerns it raises are already resolved in the current diff:

• Domain labels are correct: Add OpenTelemetry support for Node Renderer #2156 is already pro/rsc integration, Investigate AI security scanners for React on Rails #2018 is already ci/tooling
• README is updated in this PR to reflect Wave 2 scope and Wave 3 stub
• The boilerplate question concern is addressed by the new Format Notes section added to README.md

Minor: #2182 / #2184 ordering

Issues appear in descending-by-number order throughout the file, but #2184 is listed after #2182, reversing that pattern for two adjacent entries. Low impact, but worth fixing for consistency.

Merge dependency

The PR is a draft and stacked on #2810. Block merge on #2810 landing first.

Documentation-only PR, no runtime impact. Counts check out: 34 + 20 + 21 = 75 ✓, all 20 issue entries present, README Format Notes explain the Triage note vs Context excerpt distinction clearly.

Two minor observations worth considering before merge:

1. Add performance tests for different SSR and client rendering operations #2169 domain classification — "Add performance tests for different SSR and client rendering operations" is labelled ci/tooling, but since Improve test assertions: Replace ambiguous call_count patterns with explicit have_received checks #2157 (a similar test-quality issue) is labelled testing\, Add performance tests for different SSR and client rendering operations #2169 arguably fits testing better. Low-stakes, but inconsistent for future filtering/grouping.

2. Self-referential PR number in README — Line 9 hardcodes this PR #2811. If the PR is ever rebased and renumbered (unlikely but possible), this becomes stale. Worth keeping in mind if the analysis directory becomes long-lived documentation.

Review: Wave 2 Backlog Plan

Documentation-only, low-risk PR. Counts all check out: Wave 1 (34) + Wave 2 (20) + Wave 3 (21) = 75 = open issues without an open PR at review time. ✓

Minor observations:

1. Domain classification for Add OpenTelemetry support for Node Renderer #2156 — "Add OpenTelemetry support for Node Renderer" is tagged pro/rsc integration, but OpenTelemetry is an observability/instrumentation concern that isn't RSC-specific. observability or developer-experience would be more precise (see inline comment).

2. Identical posted questions for 11 ci/tooling issues — the field note at the top explains this is intentional for consistency, but it may reduce the actionability of triage responses. If any of those issues (e.g. Fix: Restore result-encoding in detect-invalid-ci-commands workflow #2199 which has a concrete known fix) need a more targeted follow-up, consider a differentiated question before the wave is acted on.

3. Wave 3 PR number not yet linked (line 10 of README) — expected since the PR hasn't been opened yet; worth updating when it is created so the README stays as a reliable navigation index.

Overall the structure, format notes, and wave definitions are clean and consistent with Wave 1.

Review: Wave 2 Backlog Plan

Documentation-only PR, no runtime risk. A few observations:

Counts check out: Wave 1 (34) + Wave 2 (20) + Wave 3 (21) = 75, matching the README's "issues without an open PR" figure. ✓

Domain inconsistency: Issue #2156 (OpenTelemetry for Node Renderer) is tagged pro/rsc integration. RSC and OTel are separate concerns — RSC is about React Server Components, OTel is distributed tracing/observability. Left an inline comment with a suggested correction.

Minor: Issue #2169 (performance tests for SSR/client rendering) is labeled ci/tooling, but testing might be a more accurate domain given that it's about adding test assertions rather than CI infrastructure. Low stakes either way.

Format notes addition to README is a useful clarification — the Triage note vs Context excerpt distinction was previously implicit.

Review: Wave 2 Backlog Plan

Documentation-only PR, no code changes. Overall the structure is clean, the format notes in README are a good addition, and the count arithmetic (34 + 20 + 21 = 75) checks out.

One domain/routing inconsistency worth fixing before merge — see inline comment on #2574.

Review

Documentation-only artifact, no runtime/CI risk.

Counts verified:

• Wave 2 file contains 20 issues — matches the README snapshot (34 + 20 + 21 = 75 total unlinked issues). Correct.
• Wave 3 is listed in README as "21 issues" with no PR number yet; this is intentional since that PR hasn't been opened. Consider adding "(PR TBD)" to make it explicit that the PR reference will be filled in later.

Domain classifications spot-checked:

• Add OpenTelemetry support for Node Renderer #2156 (OpenTelemetry for Node Renderer): correctly labeled pro/observability ✓
• Investigate AI security scanners for React on Rails #2018 (Investigate AI security scanners): correctly labeled ci/tooling ✓
• Add performance tests for different SSR and client rendering operations #2169 (Add performance tests): labeled ci/tooling — could reasonably be testing, but the ci/tooling grouping is defensible since the issue is about CI-level benchmarks.

Note on the existing bot review comment (by @claude): The claims there about domain mislabeling (#2156 as core/runtime, #2018 as core/runtime) and the README coverage gap are factually incorrect — the current file already has the right domains and the README already documents Wave 2 and Wave 3. Those suggestions do not need to be acted on.

One minor suggestion: The field note at line 6 says "Most ci/tooling entries intentionally share the same routing question" — it might help to change "Most" to "All" or list the one exception, since every ci/tooling item in the file does use the same question.

Otherwise LGTM. Clean tracking artifact.

Superseded by #2815, which was created after this stacked PR auto-closed when base branch #2810 was merged/deleted. Wave 2 content is merged via #2815.