@hanzlaa/rcode 3.6.16 → 4.1.0

package/rcode/skills/actions/3-solutioning/rcode-generate-project-context/steps/step-02-generate.md

@@ -0,0 +1,321 @@
+# Step 2: Context Rules Generation
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+- ✅ ALWAYS treat this as collaborative discovery between technical peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on unobvious rules that AI agents need to be reminded of
+- 🎯 KEEP CONTENT LEAN - optimize for LLM context efficiency
+- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 📝 Focus on specific, actionable rules rather than general advice
+- ⚠️ Present A/P/C menu after each major rule category
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter with completed sections
+- 🚫 FORBIDDEN to load next step until all sections are complete
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices for each rule category:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to explore nuanced implementation rules
+- **P (Party Mode)**: Bring multiple perspectives to identify critical edge cases
+- **C (Continue)**: Save the current rules and proceed to next category
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Invoke the `rcode-advanced-elicitation` skill
+- When 'P' selected: Invoke the `rcode-party-mode` skill
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Discovery results from step-1 are available
+- Technology stack and existing patterns are identified
+- Focus on rules that prevent implementation mistakes
+- Prioritize unobvious details that AI agents might miss
+
+## YOUR TASK:
+
+Collaboratively generate specific, critical rules that AI agents must follow when implementing code in this project.
+
+## CONTEXT GENERATION SEQUENCE:
+
+### 1. Technology Stack & Versions
+
+Document the exact technology stack from discovery:
+
+**Core Technologies:**
+Based on user skill level, present findings:
+
+**Expert Mode:**
+"Technology stack from your architecture and package files:
+{{exact_technologies_with_versions}}
+
+Any critical version constraints I should document for agents?"
+
+**Intermediate Mode:**
+"I found your technology stack:
+
+**Core Technologies:**
+{{main_technologies_with_versions}}
+
+**Key Dependencies:**
+{{important_dependencies_with_versions}}
+
+Are there any version constraints or compatibility notes agents should know about?"
+
+**Beginner Mode:**
+"Here are the technologies you're using:
+
+**Main Technologies:**
+{{friendly_description_of_tech_stack}}
+
+**Important Notes:**
+{{key_things_agents_need_to_know_about_versions}}
+
+Should I document any special version rules or compatibility requirements?"
+
+### 2. Language-Specific Rules
+
+Focus on unobvious language patterns agents might miss:
+
+**TypeScript/JavaScript Rules:**
+"Based on your codebase, I notice some specific patterns:
+
+**Configuration Requirements:**
+{{typescript_config_rules}}
+
+**Import/Export Patterns:**
+{{import_export_conventions}}
+
+**Error Handling Patterns:**
+{{error_handling_requirements}}
+
+Are these patterns correct? Any other language-specific rules agents should follow?"
+
+**Python/Ruby/Other Language Rules:**
+Adapt to the actual language in use with similar focused questions.
+
+### 3. Framework-Specific Rules
+
+Document framework-specific patterns:
+
+**React Rules (if applicable):**
+"For React development, I see these patterns:
+
+**Hooks Usage:**
+{{hooks_usage_patterns}}
+
+**Component Structure:**
+{{component_organization_rules}}
+
+**State Management:**
+{{state_management_patterns}}
+
+**Performance Rules:**
+{{performance_optimization_requirements}}
+
+Should I add any other React-specific rules?"
+
+**Other Framework Rules:**
+Adapt for Vue, Angular, Next.js, Express, etc.
+
+### 4. Testing Rules
+
+Focus on testing patterns that ensure consistency:
+
+**Test Structure Rules:**
+"Your testing setup shows these patterns:
+
+**Test Organization:**
+{{test_file_organization}}
+
+**Mock Usage:**
+{{mock_patterns_and_conventions}}
+
+**Test Coverage Requirements:**
+{{coverage_expectations}}
+
+**Integration vs Unit Test Rules:**
+{{test_boundary_patterns}}
+
+Are there testing rules agents should always follow?"
+
+### 5. Code Quality & Style Rules
+
+Document critical style and quality rules:
+
+**Linting/Formatting:**
+"Your code style configuration requires:
+
+**ESLint/Prettier Rules:**
+{{specific_linting_rules}}
+
+**Code Organization:**
+{{file_and_folder_structure_rules}}
+
+**Naming Conventions:**
+{{naming_patterns_agents_must_follow}}
+
+**Documentation Requirements:**
+{{comment_and_documentation_patterns}}
+
+Any additional code quality rules?"
+
+### 6. Development Workflow Rules
+
+Document workflow patterns that affect implementation:
+
+**Git/Repository Rules:**
+"Your project uses these patterns:
+
+**Branch Naming:**
+{{branch_naming_conventions}}
+
+**Commit Message Format:**
+{{commit_message_patterns}}
+
+**PR Requirements:**
+{{pull_request_checklist}}
+
+**Deployment Patterns:**
+{{deployment_considerations}}
+
+Should I document any other workflow rules?"
+
+### 7. Critical Don't-Miss Rules
+
+Identify rules that prevent common mistakes:
+
+**Anti-Patterns to Avoid:**
+"Based on your codebase, here are critical things agents must NOT do:
+
+{{critical_anti_patterns_with_examples}}
+
+**Edge Cases:**
+{{specific_edge_cases_agents_should_handle}}
+
+**Security Rules:**
+{{security_considerations_agents_must_follow}}
+
+**Performance Gotchas:**
+{{performance_patterns_to_avoid}}
+
+Are there other 'gotchas' agents should know about?"
+
+### 8. Generate Context Content
+
+For each category, prepare lean content for the project context file:
+
+#### Content Structure:
+
+```markdown
+## Technology Stack & Versions
+
+{{concise_technology_list_with_exact_versions}}
+
+## Critical Implementation Rules
+
+### Language-Specific Rules
+
+{{bullet_points_of_critical_language_rules}}
+
+### Framework-Specific Rules
+
+{{bullet_points_of_framework_patterns}}
+
+### Testing Rules
+
+{{bullet_points_of_testing_requirements}}
+
+### Code Quality & Style Rules
+
+{{bullet_points_of_style_and_quality_rules}}
+
+### Development Workflow Rules
+
+{{bullet_points_of_workflow_patterns}}
+
+### Critical Don't-Miss Rules
+
+{{bullet_points_of_anti_patterns_and_edge_cases}}
+```
+
+### 9. Present Content and Menu
+
+After each category, show the generated rules and present choices:
+
+"I've drafted the {{category_name}} rules for your project context.
+
+**Here's what I'll add:**
+
+[Show the complete markdown content for this category]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Explore nuanced rules for this category
+[P] Party Mode - Review from different implementation perspectives
+[C] Continue - Save these rules and move to next category"
+
+**HALT — wait for user selection before proceeding.**
+
+### 10. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Invoke the `rcode-advanced-elicitation` skill with current category rules
+- Process enhanced rules that come back
+- Ask user: "Accept these enhanced rules for {{category}}? (y/n)"
+- If yes: Update content, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Invoke the `rcode-party-mode` skill with category rules context
+- Process collaborative insights on implementation patterns
+- Ask user: "Accept these changes to {{category}} rules? (y/n)"
+- If yes: Update content, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Save the current category content to project context file
+- Update frontmatter: `sections_completed: [...]`
+- Proceed to next category or step-03 if complete
+
+## APPEND TO PROJECT CONTEXT:
+
+When user selects 'C' for a category, append the content directly to `{output_folder}/project-context.md` using the structure from step 8.
+
+## SUCCESS METRICS:
+
+✅ All critical technology versions accurately documented
+✅ Language-specific rules cover unobvious patterns
+✅ Framework rules capture project-specific conventions
+✅ Testing rules ensure consistent test quality
+✅ Code quality rules maintain project standards
+✅ Workflow rules prevent implementation conflicts
+✅ Content is lean and optimized for LLM context
+✅ A/P/C menu presented and handled correctly for each category
+
+## FAILURE MODES:
+
+❌ Including obvious rules that agents already know
+❌ Making content too verbose for LLM context efficiency
+❌ Missing critical anti-patterns or edge cases
+❌ Not getting user validation for each rule category
+❌ Not documenting exact versions and configurations
+❌ Not presenting A/P/C menu after content generation
+
+## NEXT STEP:
+
+After completing all rule categories and user selects 'C' for the final category, load `./step-03-complete.md` to finalize the project context file.
+
+Remember: Do NOT proceed to step-03 until all categories are complete and user explicitly selects 'C' for each!

package/rcode/skills/actions/3-solutioning/rcode-generate-project-context/workflow.md

@@ -0,0 +1,43 @@
+# Generate Project Context Workflow
+
+**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing code. This file focuses on unobvious details that LLMs need to be reminded of.
+
+**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality code generation across all AI agents working on the project.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **micro-file architecture** for disciplined execution:
+
+- Each step is a self-contained file with embedded rules
+- Sequential progression with user control at each step
+- Document state tracked in frontmatter
+- Focus on lean, LLM-optimized content generation
+- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
+
+---
+
+## INITIALIZATION
+
+### Configuration Loading
+
+Load config from `{project-root}/.rcode/config.json` and resolve:
+
+- `project_name`, `output_folder`, `user_name`
+- `communication_language`, `document_output_language`, `user_skill_level`
+- `date` as system-generated current datetime
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
+
+### Paths
+
+- `output_file` = `{output_folder}/project-context.md`
+
+---
+
+## EXECUTION
+
+Load and execute `./steps/step-01-discover.md` to begin the workflow.
+
+**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.

package/rcode/skills/actions/4-implementation/rcode-browser-verify/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: rcode-browser-verify
+internal: true
+description: Use Chrome DevTools MCP to verify browser behaviour — DOM state, console errors, network requests,.
+triggers:
+  - "verify in browser"
+  - "check the dom"
+  - "browser test"
+  - "dev tools mcp"
+  - "screenshot diff"
+  - "console errors"
+  - "network trace"
+  - "browser smoke test"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+A passing build doesn't mean a working UI. This skill drives Chrome via the DevTools MCP server to inspect actual runtime: DOM nodes, console output, network requests, computed CSS, performance traces, and screenshots. Especially valuable for Three.js (where `getComputedStyle` lies and frame timing is the only truth), scroll-driven UI, and bisecting "works on dev, breaks on prod".
+
+## Pre-flight
+
+Chrome DevTools MCP must be available. If not, halt with: *"DevTools MCP not configured. Enable it before running this skill — without browser inspection we'd be guessing from HTML."*
+
+## Workflow
+
+1. **Identify the surface to verify.** A specific URL, route, or component path.
+2. **Choose verification mode:**
+   - **Static** — DOM + computed CSS + screenshot (default; fast)
+   - **Dynamic** — record interactions; capture before/after states
+   - **Performance** — trace, FPS, paint flame chart (for Three.js, animations, smooth-scroll libs)
+   - **Network** — failed requests, slow waterfalls, missing resources
+3. **Boot the dev server** (or open the prod URL). Confirm it loads without console errors first.
+4. **Run the appropriate DevTools queries.** For DOM: `document.querySelector(...).getBoundingClientRect()` etc. For perf: start trace, exercise the surface, stop trace.
+5. **Diff against expectation.** Either a stored baseline screenshot or a verbal description from the user.
+6. **Report findings** with concrete evidence — pixel coordinates, console messages verbatim, network failures by URL, frame times in ms.
+
+## Output Format
+
+```
+Surface verified: <URL or route>
+Mode: <static | dynamic | performance | network>
+
+Findings:
+  ✓ <thing that passed>
+  ⚠ <warning, with evidence>
+  ✗ <failure, with evidence>
+
+Console output (filtered for errors/warnings):
+  <verbatim>
+
+Recommendation:
+  <next action — fix, defer, or accept>
+```
+
+Do NOT include: "looks fine to me" without inspection; subjective "the page seems slow" without a trace; fixes applied without re-verifying.
+
+## Examples
+
+**Happy path — Three.js perf** — "Hero scene drops to 20fps on entry" → record perf trace → identify long task in `setupGeometry()` → recommend deferring `geometry.computeVertexNormals()` to a Web Worker → verify trace post-fix shows steady 60fps.
+
+**Happy path — scroll-driven UI** — "Tabs switch on scroll but layout jumps" → static check shows `position: sticky` conflicts with `transform` on parent → fix; re-verify with screenshot diff.
+
+**Edge case — works on dev, breaks on prod** — Console shows "ChunkLoadError" only on prod. Network trace shows missing `/_next/static/chunks/...js` (404). Recommend: re-deploy or check CDN purge.
+
+**Negative — no DevTools MCP** — Halt. Without DevTools the skill is a guess; the user gets a clear error and a path to enable it.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rcode/memory/project/stack.md` (frontend layer detection)
+- **Writes:** append to `.rcode/memory/incidents/known-issues.md` if a browser-runtime bug is acknowledged but not fixed in this session

package/rcode/skills/actions/4-implementation/rcode-checkpoint-preview/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: rcode-checkpoint-preview
+internal: true
+description: "LLM-assisted human-in-the-loop review."
+triggers:
+  - "checkpoint preview"
+  - "preview the checkpoint"
+  - "human-in-the-loop review"
+  - "review before checkpoint"
+  - "checkpoint review session"
+  - "preview changes before approval"
+user-invocable: true
+---
+
+## Overview
+
+Checkpoint preview skill for rcode.
+
+## Do NOT use this skill for
+
+- **Automated code review without a human** — use `/rcode-review --karpathy` or a code-reviewer agent directly.
+- **Approving a deploy or merge** — this skill explains a change; it does not authorize git push, deploys, or PR merges.
+- **Bug investigation** from scratch — use `/rcode-debug` or the diagnose-issues workflow.
+- **Architecture review of an undelivered design** — this skill reviews delivered code/diffs, not specs.
+- **Sprint retros or milestone closure** — use `rcode-retrospective` or `rcode-complete-milestone`.
+
+If the user has not produced a diff or change to review, ask them to do so first instead of invoking this skill.
+
+## Workflow
+
+
+# Checkpoint Review Workflow
+
+**Goal:** Guide a human through reviewing a change — from purpose and context into details.
+
+You are assisting the user in reviewing a change.
+
+## Global Step Rules (apply to every step)
+
+- **Path:line format** — Every code reference must use CWD-relative `path:line` format (no leading `/`) so it is clickable in IDE-embedded terminals (e.g., `src/auth/middleware.ts:42`).
+- **Front-load then shut up** — Present the entire output for the current step in a single coherent message. Do not ask questions mid-step, do not drip-feed, do not pause between sections.
+- **Language** — Speak in `{communication_language}`. Write any file output in `{document_output_language}`.
+
+## INITIALIZATION
+
+Load and read full config from `{project-root}/.rcode/config.yaml` and resolve:
+
+- `implementation_artifacts`
+- `planning_artifacts`
+- `communication_language`
+- `document_output_language`
+
+## FIRST STEP
+
+Read fully and follow `./step-01-orientation.md` to begin.
+
+## Output Format
+
+- 5-step walkthrough output inline in conversation (orientation → walkthrough → detail → testing → wrapup)
+- Each step front-loaded (entire step in one message, no drip-feed, no mid-step questions)
+- All code references use CWD-relative `path:line` format
+- Trail artifact generated per `./generate-trail.md` at end
+
+## Examples
+
+### Happy Path
+**Input:** `/rcode-checkpoint-preview` after a feature branch is complete
+**Expected:** 5-step human review session with clear focus on what matters, testing recommendations, wrapup decision.
+
+### Edge Case: No changes to review
+**Expected:** Exit early, suggest the user make changes first.
+
+## When NOT to use this skill
+
+Do NOT use this skill for autonomous execution without a human (it is human-in-the-loop by design), for full code review (use rcode-review), or for phase verification (use rcode-verify-phase).

package/rcode/skills/actions/4-implementation/rcode-ci/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: rcode-ci
+internal: true
+description: CI/CD setup and quality gates for the rcode-default stack — GitHub Actions for Node test matrix,.
+triggers:
+  - "set up ci"
+  - "github actions"
+  - "ci pipeline"
+  - "quality gate"
+  - "helm chart"
+  - "docker compose"
+  - "k8s deploy"
+  - "release workflow"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+CI is the contract that keeps `main` green. This skill enforces a small, predictable set of gates rather than a sprawling pipeline. For deployment, the rcode-default path is: Docker Compose for dev → Helm chart for K8s production. The skill knows the common pitfalls (env drift, missing healthchecks, cold-start memory limits).
+
+## CI pre-merge gates (in order)
+
+1. **Lint / format.** Whatever the project uses (ESLint, Prettier, ruff). Auto-fixable issues block merge.
+2. **Type check.** `tsc --noEmit` for TS projects, `mypy --strict` for Python.
+3. **Test.** `node --test` / `pnpm test` / `pytest`. Across the supported runtime matrix (e.g. Node 18/20/22/24).
+4. **Build.** Whatever produces shippable artefacts. Fails-on-warnings.
+5. **Custom invariants.** rcode example: `zero-dep` job that asserts `package.json` has no runtime dependencies.
+
+If any gate fails, no merge. No `--no-verify`. Fix the underlying issue.
+
+## GitHub Actions template (Node project)
+
+```yaml
+name: test
+on:
+  push:    { branches: [main] }
+  pull_request: { branches: [main] }
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        node-version: ['18.x', '20.x', '22.x', '24.x']
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with: { node-version: '${{ matrix.node-version }}' }
+      - run: node --test
+```
+
+Reference the production rcode workflow at `.github/workflows/test.yml` for the full pattern (zero-dep invariant + syntax-check job).
+
+## Docker Compose dev environment
+
+- **Healthchecks on every service.** Postgres, Redis, the app — all of them. Without healthchecks `depends_on` is a lie.
+- **Volumes for source code only.** Don't volume-mount `node_modules`; use a named volume to avoid cross-host syncs.
+- **Single `.env.example`** in the repo. CI doesn't load it, but new contributors copy from it.
+- **One docker-compose.yml.** No "dev" / "prod" splits — production is Helm. Compose is for laptops only.
+
+## Helm chart conventions (K8s production)
+
+- **`values.yaml` documents every config knob.** No silent defaults.
+- **Liveness AND readiness probes.** Liveness is "process alive"; readiness is "ready to serve". Different thresholds.
+- **Resource limits.** Memory request = limit (no over-commit). CPU request realistic; limit forgiving.
+- **`PodDisruptionBudget`** for any deployment with `replicas > 1`.
+- **Secrets via External Secrets Operator** or sealed-secrets. Never plain `Secret` objects in git.
+
+## Workflow
+
+1. **Detect what's there.** Read `.github/workflows/`, `docker-compose.yml`, `helm/` (or wherever charts live).
+2. **Map to the gates above.** What's missing? What's redundant?
+3. **Add the smallest set of gates** that covers lint + types + tests + build + invariants.
+4. **Verify locally first.** Every gate should runnable on the contributor's laptop with `act` (for Actions) or directly.
+5. **Push, watch the run, fix.** Iterate until green on a real PR, not just locally.
+
+## Output Format
+
+```
+Detected CI: <list of existing workflows>
+Detected dev environment: <docker-compose | makefile | scripts>
+Detected production: <helm | terraform | none>
+
+Gates currently in place:
+  ✓ <gate>
+  ✗ missing: <gate>
+
+Recommendations:
+  1. <add or modify>
+  2. ...
+
+Next steps:
+  - <commit + PR>
+  - <verify run>
+```
+
+## Examples
+
+**Happy path — fresh repo** — No CI yet. Add `.github/workflows/test.yml` with the matrix template. Add `docker-compose.yml` with Postgres + app + healthchecks. Open a PR; verify CI runs green.
+
+**Edge case — flaky test in CI only** — Test passes locally, fails in CI 30% of the time. Bisect: is it a timeout? a race condition with the mock server? a CI-specific resource limit? Fix the root cause; don't add `retry: 3` as a workaround.
+
+**Negative — "just disable the failing check"** — Refuse. The check exists for a reason. Either fix what's broken or remove the check with a documented rationale.
+
+## When NOT to use this skill
+
+Do NOT use this skill for application code changes, deployment infrastructure beyond CI (use rcode-deploy-unify), security hardening (use rcode-harden), or MVP-to-production migration (use rcode-migrate).
+
+## Memory Bank Hooks
+
+- **Reads:** `.rcode/memory/project/stack.md` (deploy target)
+- **Writes:** when CI gains a new gate, append to `.rcode/memory/project/decisions.md` with the rationale

package/rcode/skills/actions/4-implementation/rcode-code-review/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: rcode-review
+internal: true
+description: >
+  Review code changes using parallel adversarial review layers and produce
+  actionable findings. Activates when the user says "review this code", "run
+  code review", "do a PR review", "review the diff", "critique this
+  implementation", or "CR". Do NOT use for documentation review (use
+  rcode-validate-prd or editorial skills).
+triggers:
+  # English
+  - "review this code"
+  - "run code review"
+  - "do a PR review"
+  - "review the diff"
+  - "critique this implementation"
+  - "find bad code practices"
+  - "code smells"
+  - "code quality check"
+  # Roman Urdu / Hindi
+  - "code check karo"
+  - "code review karo"
+  - "kharab code dekho"
+  # Arabic native
+  - "راجع الكود"
+  - "مراجعة الكود"
+  - "افحص الكود"
+  - "تدقيق الكود"
+  - "جودة الكود"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+Review code changes using parallel adversarial review layers and produce actionable findings.
+
+## Workflow
+
+Follow the instructions in ./workflow.md.
+
+## Output Format
+
+- Produces review report with severity per finding: Critical / High / Medium / Low
+- Report table: File:Line | Severity | Issue | Suggested Fix
+- Final verdict: APPROVE / REQUEST CHANGES / BLOCK
+- Saved to .rcode/artifacts/reviews/{pr-id}.md
+- Do NOT silently fix issues — the author must decide
+
+## Examples
+
+### Happy Path
+**Input:** "Run code review on this PR diff"
+**Expected behavior:** Load diff, run parallel reviews (blind hunter, edge case hunter, acceptance auditor), triage findings, produce verdict.
+
+### Edge Case: Diff Too Large
+**Input:** (diff is 2000+ lines)
+**Expected behavior:** Report: "Diff is too large for a single review (2000+ lines). Split into smaller PRs, or pick 3-4 focus areas to review first."