forked from syntaxbullet/AuroraBot-discord
72 lines
4.6 KiB
Markdown
72 lines
4.6 KiB
Markdown
---
|
|
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. |