@hanzlaa/rcode 3.6.16 → 4.1.0

package/rihal/workflows/review-adversarial.md

@@ -1,194 +0,0 @@
-# Workflow: rihal-review-adversarial
-
-<purpose>
-Assume an adversarial/hostile perspective and audit code for weaknesses: SQL injection, XSS, race conditions, data loss scenarios, unauthorized access, abuse cases, denial of service vectors. Output attack/weakness report that feeds into story AC or subtasks.
-</purpose>
-
-
-## Step 0 — Usage check
-
-If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
-
-```
-/rihal-code-review --attack
-```
-
-**Examples:**
-```
-/rihal-code-review --attack
-/rihal-code-review --attack --scope auth/
-```
-
-Note: This workflow is invoked internally by `/rihal-code-review --attack`. There is no standalone `/rihal-review-adversarial` command.
-
-STOP — do not proceed.
-
-<available_agent_types>
-- `rihal-security-adversary` — adversarial code reviewer (security-focused)
-</available_agent_types>
-
-## Step 0 — Initialize
-
-```bash
-INIT=$(node .rihal/bin/rihal-tools.cjs init review-adversarial "$ARGUMENTS")
-```
-
-Parse:
-- `flags.phase` — specific phase to review (optional)
-- `flags.component` — specific component/file (optional)
-- `review_path` — `.rihal/ADVERSARIAL-REVIEW-{phase}.md` or `.rihal/ADVERSARIAL-REVIEW.md`
-- `targets` — files/components to audit
-
-## Step 1 — Identify Review Targets
-
-**If `flags.component` provided:** Review single component
-```bash
-find {project} -name "{component}*" -type f
-```
-
-**If `flags.phase` provided:** Review all files changed in phase
-```bash
-git diff HEAD~{wave}..HEAD --name-only | grep -E '\.(js|ts|py|go|rs)$'
-```
-
-**Otherwise:** Review all source files in current phase/latest changes
-
-Collect:
-- File paths
-- File types (backend, frontend, API, database, etc.)
-- Lines of code per file
-- External dependencies used
-
-## Step 2 — Spawn Adversarial Reviewer
-
-Spawn `rihal-security-adversary` subagent:
-
-```
-Task tool call:
-  subagent_type: "rihal-security-adversary"
-  description: "Adversarial security review"
-  prompt: |
-    Conduct an adversarial security review. Assume a hostile perspective.
-    Goal: Find every possible way this code could be exploited, broken, or abused.
-    
-    **Files to audit:**
-    {target_files_with_contents}
-    
-    **Attack categories (audit all):**
-    
-    1. INJECTION ATTACKS
-       - SQL Injection (parameterized queries? raw string interpolation?)
-       - Command Injection (shell commands, subprocess, exec?)
-       - XSS (input sanitization? output encoding?)
-       - Template Injection
-    
-    2. AUTHENTICATION & AUTHORIZATION
-       - Session hijacking (JWT stored in localStorage?)
-       - Privilege escalation (role checks everywhere?)
-       - API key exposure (hardcoded, logged, in git history?)
-       - Insecure password storage
-    
-    3. DATA LOSS & CORRUPTION
-       - Race conditions (concurrent writes without locks?)
-       - Unprotected database transactions
-       - Missing rollback on error
-       - Unchecked third-party API failures
-    
-    4. DENIAL OF SERVICE
-       - Unbounded loops or recursion
-       - Excessive resource allocation (memory, CPU)
-       - No rate limiting on public endpoints
-       - Infinite file uploads
-    
-    5. ABUSE CASES
-       - Can user bypass limits (pagination, quotas)?
-       - Can user access data not theirs?
-       - Can user trigger expensive operations?
-       - Can user enumerate/discovery resources?
-    
-    For each vulnerability:
-    - Type (injection, authz, data loss, DoS, abuse)
-    - Severity (critical, high, medium, low)
-    - Attack scenario (specific steps to exploit)
-    - Impact (data breach, outage, corruption, etc.)
-    - Proof of concept (code snippet showing vulnerability)
-    - Fix (specific remediation)
-    
-    Output: ADVERSARIAL-REVIEW.md
-```
-
-## Step 3 — Store Review and File Tasks
-
-Write review to `.rihal/ADVERSARIAL-REVIEW-{phase}.md`
-
-Extract findings:
-- Critical vulnerabilities
-- High-risk issues
-- Medium-risk issues
-- Low-risk recommendations
-
-## Step 4 — File Security Tasks
-
-For each critical/high finding, optionally file as subtask:
-
-```bash
-node .rihal/bin/rihal-tools.cjs state add-task \
-  --title "Fix {vulnerability_type}: {brief_description}" \
-  --severity critical/high/medium \
-  --component {component_name}
-```
-
-Or add to story AC:
-
-Update `.rihal/story-current.md` acceptance criteria:
-
-```markdown
-## Security Requirements
-
-- [ ] No SQL injection vulnerabilities (parameterized queries)
-- [ ] All user input sanitized per OWASP guidelines
-- [ ] API keys not logged or stored in repository
-- [ ] Rate limiting on public endpoints
-- [ ] CSRF tokens on state-changing requests
-```
-
-Print:
-```
-🛡️ Adversarial Review Complete
-
-Findings by severity:
-  • Critical: {count}
-  • High: {count}
-  • Medium: {count}
-  • Low: {count}
-
-Review: {review_path}
-
-Critical findings filed as blocking AC. High findings as optional tasks.
-```
-
-## Success Criteria
-
-- ADVERSARIAL-REVIEW.md created
-- All 5 attack categories audited
-- Findings ranked by severity
-- Proof-of-concept included for each vulnerability
-- Critical/high issues filed as tasks or AC
-
-## On Error
-
-- If subagent fails: provide template adversarial review structure
-- If files too large: split review across multiple components
-- If no findings: report "No vulnerabilities found" (document assumptions)
-
-## On Completion
-
-/rihal-plan {phase} --reviews — incorporate findings into next plan
-/rihal-code-review-fix — apply suggested fixes
-/rihal-council — escalate contested findings to the full council
-
-## ▶ Next Up
-
-- **Vulnerabilities found:** Address security findings, re-run `/rihal-code-review --attack`
-- /rihal-verify-phase {phase}
-- /rihal-ship {phase}

package/rihal/workflows/review-edge-case-hunter.md

@@ -1,214 +0,0 @@
-# Workflow: rihal-review-edge-case-hunter
-
-<purpose>
-Systematically enumerate edge cases by category (input, state, concurrency, network) with severity (critical/high/medium/low). Callable during code-review.md workflow. Output feeds into story AC or subtasks. Focuses on "what breaks?" rather than security.
-</purpose>
-
-
-## Step 0 — Usage check
-
-If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
-
-```
-/rihal-review-edge-case-hunter <argument-here>
-```
-
-**Examples:**
-```
-/rihal-review-edge-case-hunter example 1
-/rihal-review-edge-case-hunter example 2
-```
-
-STOP — do not proceed.
-
-<available_agent_types>
-- `rihal-edge-case-hunter` — edge case enumeration agent
-</available_agent_types>
-
-## Step 0 — Initialize
-
-```bash
-INIT=$(node .rihal/bin/rihal-tools.cjs init review-edge-case-hunter "$ARGUMENTS")
-```
-
-Parse:
-- `flags.phase` — specific phase to analyze (optional)
-- `flags.component` — specific component (optional)
-- `output_path` — `.rihal/EDGE-CASES-{phase}.md` or `.rihal/EDGE-CASES.md`
-- `targets` — files/components to audit
-
-## Step 1 — Identify Review Targets
-
-Same as review-adversarial Step 1:
-
-Collect files by phase or component, extract:
-- Function/method signatures
-- Input parameters and types
-- State mutations
-- External API calls
-- Error handling
-
-## Step 2 — Spawn Edge Case Hunter
-
-Spawn `rihal-edge-case-hunter` subagent:
-
-```
-Task tool call:
-  subagent_type: "rihal-edge-case-hunter"
-  description: "Enumerate edge cases"
-  prompt: |
-    Enumerate all edge cases that could cause failures or unexpected behavior.
-    Focus on: What inputs break? What state combinations are invalid? What network scenarios fail?
-    
-    **Files/functions to analyze:**
-    {target_files_with_signatures}
-    
-    **Enumerate by category:**
-    
-    1. INPUT EDGE CASES
-       - Empty inputs (null, undefined, empty string, empty array)
-       - Boundary values (0, -1, MAX_INT, MAX_FLOAT)
-       - Invalid types (string instead of number, object instead of array)
-       - Malformed data (invalid JSON, truncated, oversized)
-       - Special characters (unicode, newlines, control chars, emoji)
-       - Whitespace variations (leading/trailing spaces, tabs, mixed)
-    
-    2. STATE EDGE CASES
-       - Uninitialized/missing state
-       - State mutations during async operations
-       - Re-entrance (function called again while executing)
-       - State transitions not covered (skipped steps, out-of-order)
-       - Stale cached state
-       - Conflicting state values
-    
-    3. CONCURRENCY EDGE CASES
-       - Two requests for same resource simultaneously
-       - Writes during reads
-       - Partial updates (write interrupted)
-       - Lock contention or deadlock
-       - Race conditions between check and use
-       - Order-dependent operations executed out of order
-    
-    4. NETWORK EDGE CASES
-       - Timeouts (slow/hanging requests)
-       - Connection drops (mid-response)
-       - Retries (request sent twice, duplicate processing)
-       - Invalid responses (malformed JSON, wrong status code)
-       - Cascading failures (API A calls B, B fails)
-       - Rate limiting (429 Too Many Requests)
-    
-    For each edge case:
-    - Category (input, state, concurrency, network)
-    - Severity (critical, high, medium, low)
-    - Scenario (specific input/state combination)
-    - Expected behavior (what should happen)
-    - Actual behavior (what might go wrong)
-    - Test case (how to reproduce)
-    - Acceptance criteria for handling
-    
-    Output: EDGE-CASES.md with severity-ordered list
-```
-
-## Step 3 — Categorize by Severity
-
-Critical: Causes data loss, security breach, complete feature failure
-High: Causes incorrect output, feature partially broken, user-facing error
-Medium: Degrades performance, confuses user, edge case not handled gracefully
-Low: Minor inconsistency, cosmetic issue, optimization opportunity
-
-Organize output:
-
-```markdown
-# Edge Cases: {phase_name}
-
-## Critical ({count})
-- {edge_case_1}
-- {edge_case_2}
-
-## High ({count})
-- {edge_case_1}
-- {edge_case_2}
-
-## Medium ({count})
-- {edge_case_1}
-
-## Low ({count})
-- {edge_case_1}
-```
-
-## Step 4 — File as AC or Tasks
-
-For each critical/high edge case, add to story AC:
-
-Update `.rihal/story-current.md` acceptance criteria:
-
-```markdown
-## Edge Case Handling
-
-**Critical:**
-- [ ] {edge_case_1}: {acceptance_criteria}
-
-**High:**
-- [ ] {edge_case_2}: {acceptance_criteria}
-```
-
-Or file as subtasks:
-
-```bash
-node .rihal/bin/rihal-tools.cjs state add-task \
-  --title "Handle edge case: {scenario}" \
-  --category edge-case \
-  --severity {critical|high}
-```
-
-Print:
-```
-🔍 Edge Case Analysis Complete
-
-By severity:
-  • Critical: {count}
-  • High: {count}
-  • Medium: {count}
-  • Low: {count}
-
-Analysis: {output_path}
-
-Critical/high cases filed as AC or tasks.
-```
-
-## Integration: code-review.md
-
-In code-review.md workflow, after completing main review, optionally offer:
-
-```bash
-AskUserQuestion([
-  {
-    header: "Edge Cases",
-    question: "Run edge case analysis on this code?",
-    multiSelect: false,
-    options: [
-      { label: "Yes, find edge cases", description: "Comprehensive edge case hunt" },
-      { label: "Skip for now", description: "Continue review" }
-    ]
-  }
-])
-```
-
-If "Yes, find edge cases":
-```
-/rihal-review-edge-case-hunter --phase {current_phase}
-```
-
-## Success Criteria
-
-- EDGE-CASES.md created with all 4 categories
-- Minimum 3 edge cases per category (if applicable)
-- Severity-ordered list
-- Test case included for each critical/high
-- Critical/high filed as AC or tasks
-
-## On Error
-
-- If subagent fails: provide template edge-case structure
-- If no edge cases found: report "No new edge cases identified" (acceptable)
-- If too many cases: prioritize by severity, file medium/low in backlog

package/rihal/workflows/review.md

@@ -1,287 +0,0 @@
-<purpose>
-Cross-AI peer review — invoke external AI CLIs to independently review phase plans.
-Each CLI gets the same prompt (PROJECT.md context, phase plans, requirements) and
-produces structured feedback. Results are combined into REVIEWS.md for the planner
-to incorporate via --reviews flag.
-
-This implements adversarial review: different AI models catch different blind spots.
-A plan that survives review from 2-3 independent AI systems is more robust.
-</purpose>
-
-<process>
-
-<step name="detect_clis">
-Check which AI CLIs are available on the system:
-
-```bash
-# Check each CLI
-command -v gemini >/dev/null 2>&1 && echo "gemini:available" || echo "gemini:missing"
-command -v claude >/dev/null 2>&1 && echo "claude:available" || echo "claude:missing"
-command -v codex >/dev/null 2>&1 && echo "codex:available" || echo "codex:missing"
-command -v coderabbit >/dev/null 2>&1 && echo "coderabbit:available" || echo "coderabbit:missing"
-command -v opencode >/dev/null 2>&1 && echo "opencode:available" || echo "opencode:missing"
-```
-
-Parse flags from `$ARGUMENTS`:
-- `--gemini` → include Gemini
-- `--claude` → include Claude
-- `--codex` → include Codex
-- `--coderabbit` → include CodeRabbit
-- `--opencode` → include OpenCode
-- `--all` → include all available
-- No flags → include all available
-
-If no CLIs are available:
-```
-No external AI CLIs found. Install at least one:
-- gemini: https://github.com/google-gemini/gemini-cli
-- codex: https://github.com/openai/codex
-- claude: https://github.com/anthropics/claude-code
-- opencode: https://opencode.ai (leverages GitHub Copilot subscription models)
-
-Then run /rihal-review again.
-```
-Exit.
-
-Determine which CLI to skip based on the current runtime environment:
-
-```bash
-# Environment-based runtime detection (priority order)
-if [ "$ANTIGRAVITY_AGENT" = "1" ]; then
-  # Antigravity is a separate client — all CLIs are external, skip none
-  SELF_CLI="none"
-elif [ -n "$CLAUDE_CODE_ENTRYPOINT" ]; then
-  # Running inside Claude Code CLI — skip claude for independence
-  SELF_CLI="claude"
-else
-  # Other environments (Gemini CLI, Codex CLI, etc.)
-  # Fall back to AI self-identification to decide which CLI to skip
-  SELF_CLI="auto"
-fi
-```
-
-Rules:
-- If `SELF_CLI="none"` → invoke ALL available CLIs (no skip)
-- If `SELF_CLI="claude"` → skip claude, use gemini/codex
-- If `SELF_CLI="auto"` → the executing AI identifies itself and skips its own CLI
-- At least one DIFFERENT CLI must be available for the review to proceed.
-</step>
-
-<step name="gather_context">
-Collect phase artifacts for the review prompt:
-
-```bash
-INIT=$(node ".rihal/bin/rihal-tools.cjs" init phase-op "${PHASE_ARG}")
-if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
-```
-
-Read from init: `phase_dir`, `phase_number`, `padded_phase`.
-
-Then read:
-1. `.planning/PROJECT.md` (first 80 lines — project context)
-2. Phase section from `.planning/ROADMAP.md`
-3. All `*-SPRINT.md` files in the phase directory
-4. `*-CONTEXT.md` if present (user decisions)
-5. `*-RESEARCH.md` if present (domain research)
-6. `.planning/REQUIREMENTS.md` (requirements this phase addresses)
-</step>
-
-<step name="build_prompt">
-Build a structured review prompt:
-
-```markdown
-# Cross-AI Plan Review Request
-
-You are reviewing implementation plans for a software project phase.
-Provide structured feedback on plan quality, completeness, and risks.
-
-## Project Context
-{first 80 lines of PROJECT.md}
-
-## Phase {N}: {phase name}
-### Roadmap Section
-{roadmap phase section}
-
-### Requirements Addressed
-{requirements for this phase}
-
-### User Decisions (CONTEXT.md)
-{context if present}
-
-### Research Findings
-{research if present}
-
-### Plans to Review
-{all SPRINT.md contents}
-
-## Review Instructions
-
-Analyze each plan and provide:
-
-1. **Summary** — One-paragraph assessment
-2. **Strengths** — What's well-designed (bullet points)
-3. **Concerns** — Potential issues, gaps, risks (bullet points with severity: HIGH/MEDIUM/LOW)
-4. **Suggestions** — Specific improvements (bullet points)
-5. **Risk Assessment** — Overall risk level (LOW/MEDIUM/HIGH) with justification
-
-Focus on:
-- Missing edge cases or error handling
-- Dependency ordering issues
-- Scope creep or over-engineering
-- Security considerations
-- Performance implications
-- Whether the plans actually achieve the phase goals
-
-Output your review in markdown format.
-```
-
-Write to a temp file: `/tmp/rihal-review-prompt-{phase}.md`
-</step>
-
-<step name="invoke_reviewers">
-For each selected CLI, invoke in sequence (not parallel — avoid rate limits):
-
-**Gemini:**
-```bash
-gemini -p "$(cat /tmp/rihal-review-prompt-{phase}.md)" 2>/dev/null > /tmp/rihal-review-gemini-{phase}.md
-```
-
-**Claude (separate session):**
-```bash
-claude -p "$(cat /tmp/rihal-review-prompt-{phase}.md)" 2>/dev/null > /tmp/rihal-review-claude-{phase}.md
-```
-
-**Codex:**
-```bash
-codex exec --skip-git-repo-check "$(cat /tmp/rihal-review-prompt-{phase}.md)" 2>/dev/null > /tmp/rihal-review-codex-{phase}.md
-```
-
-**CodeRabbit:**
-
-Note: CodeRabbit reviews the current git diff/working tree — it does not accept a prompt. It may take up to 5 minutes. Use `timeout: 360000` on the Bash tool call.
-
-```bash
-coderabbit review --prompt-only 2>/dev/null > /tmp/rihal-review-coderabbit-{phase}.md
-```
-
-**OpenCode (via GitHub Copilot):**
-```bash
-cat /tmp/rihal-review-prompt-{phase}.md | opencode run - 2>/dev/null > /tmp/rihal-review-opencode-{phase}.md
-if [ ! -s /tmp/rihal-review-opencode-{phase}.md ]; then
-  echo "OpenCode review failed or returned empty output." > /tmp/rihal-review-opencode-{phase}.md
-fi
-```
-
-If a CLI fails, log the error and continue with remaining CLIs.
-
-Display progress:
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Rihal ► CROSS-AI REVIEW — Phase {N}
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-◆ Reviewing with {CLI}... done ✓
-◆ Reviewing with {CLI}... done ✓
-```
-</step>
-
-<step name="write_reviews">
-Combine all review responses into `{phase_dir}/{padded_phase}-REVIEWS.md`:
-
-```markdown
----
-phase: {N}
-reviewers: [gemini, claude, codex, coderabbit, opencode]
-reviewed_at: {ISO timestamp}
-plans_reviewed: [{list of SPRINT.md files}]
----
-
-# Cross-AI Plan Review — Phase {N}
-
-## Gemini Review
-
-{gemini review content}
-
----
-
-## Claude Review
-
-{claude review content}
-
----
-
-## Codex Review
-
-{codex review content}
-
----
-
-## CodeRabbit Review
-
-{coderabbit review content}
-
----
-
-## OpenCode Review
-
-{opencode review content}
-
----
-
-## Consensus Summary
-
-{synthesize common concerns across all reviewers}
-
-### Agreed Strengths
-{strengths mentioned by 2+ reviewers}
-
-### Agreed Concerns
-{concerns raised by 2+ reviewers — highest priority}
-
-### Divergent Views
-{where reviewers disagreed — worth investigating}
-```
-
-Commit:
-```bash
-node ".rihal/bin/rihal-tools.cjs" commit "docs: cross-AI review for phase {N}" --files {phase_dir}/{padded_phase}-REVIEWS.md
-```
-</step>
-
-<step name="present_results">
-Display summary:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Rihal ► REVIEW COMPLETE
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Phase {N} reviewed by {count} AI systems.
-
-Consensus concerns:
-{top 3 shared concerns}
-
-Full review: {padded_phase}-REVIEWS.md
-
-To incorporate feedback into planning:
-  /rihal-plan {N} --reviews
-```
-
-Clean up temp files.
-</step>
-
-</process>
-
-<success_criteria>
-- [ ] At least one external CLI invoked successfully
-- [ ] REVIEWS.md written with structured feedback
-- [ ] Consensus summary synthesized from multiple reviewers
-- [ ] Temp files cleaned up
-- [ ] User knows how to use feedback (/rihal-plan --reviews)
-</success_criteria>
-
-## ▶ Next Up
-
-- **Issues found:** Fix identified problems, then re-run `/rihal-review`
-- /rihal-ship {phase}
-- /rihal-secure-phase {phase}