20 lines
1.1 KiB
Markdown
20 lines
1.1 KiB
Markdown
|
# Audit process and report conventions
|
||
|
|
|
||
|
|
## Report location
|
||
|
|
Root-level dotfiles (`.bug_report.md`, `.adversarial_bug_report.md`, `.verdict.md`) following precedent from previous reviews — NOT task artifacts.
|
||
|
|
|
||
|
|
## Bug finder workflow
|
||
|
|
Read all source files in parallel, identify bugs, score by severity (1-10), write `.bug_report.md` with Bug N, Location, Description, Suggested Fix.
|
||
|
|
|
||
|
|
## Adversarial bug find
|
||
|
|
Attack-vector focused — test edge cases, security implications, race conditions, input manipulation. Write `.adversarial_bug_report.md`.
|
||
|
|
|
||
|
|
## Batch processing
|
||
|
|
Group bugs by severity. High-severity (batch 1) first, then Medium/Low (batch 2). Each bug gets its own task with full lifecycle (SPEC → IMPLEMENTATION → CODE_REVIEW → BUG_REPORT → ADVERSARIAL_BUG_REPORT → DOC_REVIEW → VERDICT).
|
||
|
|
|
||
|
|
## Verdict format
|
||
|
|
Uses `## Status: PASS` or `## Status: FAIL` structured line (parsed by `_parse_verdict_status_line()` in status.py and `parse_verdict_status()` in dashboard task.py).
|
||
|
|
|
||
|
|
## Pre-approved workflow
|
||
|
|
User can pre-approve all tasks upfront, allowing the agent to drive all phases to completion without stopping for approval gates.
|