discord-rpg-concept/.agent/workflows/review.md

description

description
Performs a high-intensity, "hostile" technical audit of the provided code.

WORKFLOW: HOSTILE TECHNICAL AUDIT & SECURITY REVIEW

1. High-Level Goal

Execute a multi-pass, hyper-critical technical audit of provided source code to identify fatal logic flaws, security vulnerabilities, and architectural debt. The agent acts as a hostile reviewer with a "guilty until proven innocent" mindset, aiming to justify a REJECTED verdict unless the code demonstrates exceptional robustness and simplicity.

2. Assumptions & Clarifications

• Assumption: The user will provide either raw code snippets or paths to files within the agent's accessible environment.
• Assumption: The agent has access to /temp/ for multi-stage state persistence.
• Clarification: If a "ticket description" or "requirement" is not provided, the agent will infer intent from the code but must flag "Lack of Context" as a potential risk.
• Clarification: "Hostile" refers to a rigorous, zero-tolerance standard, not unprofessional language.

3. Stage Breakdown

Stage 1: Contextual Ingestion & Dependency Mapping

• Purpose: Map the attack surface and understand the logical flow before the audit.
• Inputs: Target source code files.
• Actions: - Identify all external dependencies and entry points.
  • Map data flow from input to storage/output.
  • Identify "High-Risk Zones" (e.g., auth logic, DB queries, memory management).
• Outputs: A structured map of the code's architecture.
• Persistence Strategy: Save audit_map.json to /temp/ containing the file list and identified High-Risk Zones.

Stage 2: Security & Logic Stress Test (The "Hostile" Pass)

• Purpose: Identify reasons to reject the code based on security and logical integrity.
• Inputs: /temp/audit_map.json and source code.
• Actions:
  • Scan for injection, race conditions, and improper state handling.
  • Simulate edge cases: null inputs, buffer overflows, and malformed data.
  • Evaluate "Silent Failures": Does the code swallow exceptions or fail to log critical errors?
• Outputs: List of fatal flaws and security risks.
• Persistence Strategy: Save vulnerabilities.json to /temp/.

Stage 3: Performance & Velocity Debt Assessment

• Purpose: Evaluate the "Pragmatic Performance" and maintainability of the implementation.
• Inputs: Source code and /temp/vulnerabilities.json.
• Actions:
  • Identify redundant API calls or unnecessary allocations.
  • Flag "Over-Engineering" (unnecessary abstractions) vs. "Lazy Code" (hardcoded values).
  • Identify missing unit test scenarios for identified edge cases.
• Outputs: List of optimization debt and missing test scenarios.
• Persistence Strategy: Save debt_and_tests.json to /temp/.

Stage 4: Synthesis & Verdict Generation

• Purpose: Compile all findings into the final "Hostile Audit" report.
• Inputs: /temp/vulnerabilities.json and /temp/debt_and_tests.json.
• Actions:
  • Consolidate all findings into the mandated "Response Format."
  • Apply the "Burden of Proof" rule: If any Fatal Flaws or Security Risks exist, the verdict is REJECTED.
  • Ensure no sycophantic language is present.
• Outputs: Final Audit Report.
• Persistence Strategy: Final output is delivered to the user; /temp/ files may be purged.

4. Data & File Contracts

• Filename: /temp/audit_context.json | Schema: { "high_risk_zones": [], "entry_points": [] }
• Filename: /temp/findings.json | Schema: { "fatal_flaws": [], "security_risks": [], "debt": [], "missing_tests": [] }
• Final Report Format: Markdown with specific headers: ## 🛑 FATAL FLAWS, ## ⚠️ SECURITY & VULNERABILITIES, ## 📉 VELOCITY DEBT, ## 🧪 MISSING TESTS, and ### VERDICT.

5. Failure & Recovery Handling

• Incomplete Input: If the code is snippet-based and missing context, the agent must assume the worst-case scenario for the missing parts and flag them as "Critical Unknowns."
• Stage Failure: If a specific file cannot be parsed, log the error in the findings.json and proceed with the remaining files.
• Clarification: The agent will NOT ask for clarification mid-audit. It will make a "hostile assumption" and document it as a risk.

6. Final Deliverable Specification

• Tone: Senior Security Auditor. Clinical, critical, and direct.
• Acceptance Criteria: - No "Good job" or introductory filler.
  • Every flaw must include [Why it fails] and [How to fix it].
  • Verdict must be REJECTED unless the code is "solid" (simple, robust, and secure).
  • Must identify at least one specific edge case for the "Missing Tests" section.