@hanzlaa/rcode 3.6.16 → 4.0.0

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

@@ -1,321 +0,0 @@
-# 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 `rihal-advanced-elicitation` skill
-- When 'P' selected: Invoke the `rihal-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 `rihal-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 `rihal-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/rihal/skills/actions/3-solutioning/rihal-generate-project-context/workflow.md

@@ -1,43 +0,0 @@
-# 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}/.rihal/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/rihal/skills/actions/4-implementation/rihal-browser-verify/SKILL.md

@@ -1,73 +0,0 @@
----
-name: rihal-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
----
-@.rihal/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:** `.rihal/memory/project/stack.md` (frontend layer detection)
-- **Writes:** append to `.rihal/memory/incidents/known-issues.md` if a browser-runtime bug is acknowledged but not fixed in this session

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

@@ -1,75 +0,0 @@
----
-name: rihal-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 Rihal Code.
-
-## Do NOT use this skill for
-
-- **Automated code review without a human** — use `/rihal-code-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 `/rihal-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 `rihal-retrospective` or `rihal-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}/.rihal/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:** `/rihal-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 rihal-code-review), or for phase verification (use rihal-verify-phase).

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

@@ -1,115 +0,0 @@
----
-name: rihal-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
----
-@.rihal/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 rihal-deploy-unify), security hardening (use rihal-harden), or MVP-to-production migration (use rihal-migrate).
-
-## Memory Bank Hooks
-
-- **Reads:** `.rihal/memory/project/stack.md` (deploy target)
-- **Writes:** when CI gains a new gate, append to `.rihal/memory/project/decisions.md` with the rationale

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

@@ -1,59 +0,0 @@
----
-name: rihal-code-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
-  rihal-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
----
-@.rihal/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 .rihal/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."