feat: Phase 3 Tier 2 handlers implementation

[ashleyshaw]

Feature Pull Request

Linked issues

Closes#1679

Changelog

Added

• Phase 3 Tier 2 handlers: handle-needs-review.js (315L) for review type inference and CODEOWNERS-style reviewer assignment
• Phase 3 Tier 2 handlers: handle-needs-dev.js (166L) for development prerequisites validation (type/area labels, project assignment, design refs)
• Phase 3 Tier 2 handlers: handle-needs-planning.js (216L) for scope inference and milestone/PM suggestions
• Comprehensive test coverage: 57 unit tests (15+18+24) across three handlers with 80%+ code coverage per handler
• Dry-run preview mode for all handlers enabling safe validation before applying changes
• Confidence-based scoring system: keyword matching at 70% weight, regex patterns at 100% weight
• Batch processing with detailed statistics tracking for all handler operations

Changed

• Handler architecture follows consistent pattern: type inference → suggestions → single/batch processing
• GitHub API error handling now preserves error causes for better debugging

---

Checklist (Global DoD / PR)

• All AC met and demonstrated
• Tests added/updated (unit/E2E as appropriate) — 57 tests, all passing
• Accessibility checklist completed (where relevant) — N/A (backend automation handlers)
• Docs/readme/changelog updated (if user-facing) — Inline documentation in handlers
• Security checklist completed (where relevant):
  • Untrusted input validated and sanitised (GitHub API responses validated)
  • Output escaped for its rendering context (label names, reviewer names sanitised)
  • Privileged actions enforce nonce and capability checks (GitHub API token required)
  • No secrets/sensitive data introduced; OWASP risks reviewed
• Code/design reviews approved — Ready for CodeRabbit + Copilot review
• CI green; linked issues closed; release notes prepared (if shipping)

---

Summary

Implemented comprehensive Phase 3 Tier 2 handler suite with full test coverage (57 tests, 80%+ coverage per handler).

Handlers Implemented:

• handle-needs-review.js (315 lines): Review type inference (code/design/spec/docs) + CODEOWNERS-style reviewer assignment
• handle-needs-dev.js (166 lines): Development readiness validation (type/area labels, project assignment, design refs)
• handle-needs-planning.js (216 lines): Scope inference (small/medium/large) + milestone/PM suggestions + epic linkage

Features:

• Dry-run/preview mode for safe validation
• Confidence-based scoring (70% keyword match, 100% pattern match)
• Batch processing with detailed statistics
• Error handling with GitHub API integration
• Area/type-based routing and assignment

Test Coverage

• handle-needs-review.test.js: 15 tests (inferReviewType, suggestReviewers, processIssue, processBatch)
• handle-needs-dev.test.js: 18 tests (validatePrerequisites, suggestProject, processIssue, processBatch)
• handle-needs-planning.test.js: 24 tests (inferScope, suggestMilestone, suggestPM, epicLinkage, processBatch)

All 57 tests passing. Code formatted with Prettier + ESLint.

Next Phase

• Integrate Phase 3 handlers into orchestrator (Phase 3 Phase 2)
• Test with real issues using --dry-run mode (post-merge)
• Implement Phase 4 handlers (needs-design, needs-documentation, needs-audit)

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@ashleyshaw, you've reached your PR review limit, so we couldn't start this review.

Next review available in:45 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 912139a8-bf9b-47c1-bc4b-76eaae1bec8b

📥 Commits

Reviewing files that changed from the base of the PR and between 479f03a and 1f8cd06.

📒 Files selected for processing (6)

• scripts/automation/__tests__/handle-needs-dev.test.js
• scripts/automation/__tests__/handle-needs-planning.test.js
• scripts/automation/__tests__/handle-needs-review.test.js
• scripts/automation/handlers/handle-needs-dev.js
• scripts/automation/handlers/handle-needs-planning.js
• scripts/automation/handlers/handle-needs-review.js

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[github-actions]

✅ Template check passed after update. Thanks for fixing the PR description.

[github-actions]

⏱️ Aging and SLA annotation

• Age: 0 day(s)
• SLA state: Within SLA
• Thresholds: warn at 7 days, breach at 14 days
• Last updated: 2026-08-09T17:48:25.155Z

Maintained by project-meta-sync workflow.