profit/local-review-harness
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
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

2.3 KiB
Executable File
Raw Blame History

Report Schema

Purpose

This document defines the expected report and receipt schemas for the local review harness.

Finding Schema

{
  "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:

Verdict
Evidence
Confirmed Risks
Suspected Risks
Blocked Checks
Sprint Backlog
Acceptance Gates
Next Commands

Risk Register Schema

{
  "risks": [
    {
      "id": "",
      "title": "",
      "severity": "",
      "affected_area": "",
      "evidence": "",
      "impact": "",
      "mitigation": "",
      "owner": "",
      "status": "open|mitigated|accepted|blocked"
    }
  ]
}

Receipt Schema

{
  "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:

| 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.