local-review-harness/docs/REPORT_SCHEMA.md
Claude (review-harness setup) f3ee4722a8 Phase A + B (MVP) — local review harness
Implements the MVP cutline from the planning artifact:
- Phase A: skeleton + CLI dispatch + provider interface + stub model doctor
- Phase B: scanner + git probe + 12 static analyzers + reporters + pipeline
- Phase B fixtures: clean-repo, insecure-repo, degraded-repo

12 static analyzers per PROMPT.md "Suggested Static Checks For MVP":
hardcoded_paths, shell_execution, raw_sql_interpolation, broad_cors,
secret_patterns, large_files, todo_comments, missing_tests,
env_file_committed, unsafe_file_io, exposed_mutation_endpoint,
hardcoded_local_ip.

Acceptance gates passing:
- B1 (intake produces accurate counts) ✓
- B2 (insecure fixture fires ≥8 distinct check_ids — actually 11/12) ✓
- B3 (clean fixture produces 0 confirmed findings — no false positives) ✓
- B4 (scrum mode produces all 6 required markdown + JSON reports) ✓
- B5 (receipts.json marks degraded phases honestly) ✓
- F  (self-review on this repo runs without crashing) ✓ — exit 66 (degraded
  because Phase C LLM review is hardcoded skipped)

Phases C (LLM review), D (validation cross-check), E (memory + diff +
rules subcommands) deferred per the cutline. The MVP delivers the
evidence-first path; LLM is purely additive.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-30 00:56:02 -05:00

151 lines
2.3 KiB
Markdown
Executable File

# Report Schema
## Purpose
This document defines the expected report and receipt schemas for the local review harness.
## Finding Schema
```json
{
"id": "",
"title": "",
"severity": "low|medium|high|critical",
"status": "confirmed|suspected|rejected|blocked",
"file": "",
"line_hint": "",
"evidence": "",
"reason": "",
"suggested_fix": "",
"source": "static|llm|validator",
"confidence": 0.0
}
```
## Severity Rules
### Critical
Use for:
- credential exposure
- destructive command risk
- unauthenticated mutation endpoint
- remote code execution risk
- data corruption risk
### High
Use for:
- SQL injection risk
- broad CORS on sensitive service
- fail-open security behavior
- unsafe filesystem access
- missing validation on critical inputs
### Medium
Use for:
- hardcoded paths
- excessive file size
- weak error handling
- missing tests around important code
- fragile environment assumptions
### Low
Use for:
- minor duplication
- naming confusion
- documentation drift
- small maintainability issues
## Scrum Test Report Sections
Every Scrum test report must include:
```text
Verdict
Evidence
Confirmed Risks
Suspected Risks
Blocked Checks
Sprint Backlog
Acceptance Gates
Next Commands
```
## Risk Register Schema
```json
{
"risks": [
{
"id": "",
"title": "",
"severity": "",
"affected_area": "",
"evidence": "",
"impact": "",
"mitigation": "",
"owner": "",
"status": "open|mitigated|accepted|blocked"
}
]
}
```
## Receipt Schema
```json
{
"run_id": "",
"repo_path": "",
"started_at": "",
"finished_at": "",
"phases": [
{
"name": "",
"status": "ok|degraded|failed|skipped",
"input_hash": "",
"output_hash": "",
"output_files": [],
"errors": []
}
],
"summary": {
"confirmed_findings": 0,
"suspected_findings": 0,
"blocked_checks": 0,
"critical": 0,
"high": 0,
"medium": 0,
"low": 0
}
}
```
## Claim Coverage Table
Use this Markdown table:
```text
| Claim | Code Location | Existing Test | Missing Test | Risk |
|---|---|---|---|---|
```
## No Fake Evidence Rule
Reports must not include:
- invented file paths
- invented command output
- invented tests
- unsupported claims
- false pass/fail statements
If evidence is missing, say missing evidence.