ACT Phase 3: Structured finding extraction from model responses

[DSado88]

Context

Model responses are unstructured text blobs (ReviewModelResult.response: Option<String>). Every downstream ACT phase — pairing, training, critic scoring — needs discrete, structured findings.

This is the critical infrastructure gap identified by all 5 models in the ACT review (2026-03-10). Codex: "there is no native 'finding' object anywhere in the review path."

Depends on: Phase 5.5 skill capture (done)
Blocks: Phase 4 (DPO training), Phase 5 (critic integration)

Proposal

Add a post-processing step that extracts structured findings from model responses after the review fan-out returns.

New types

struct Finding {
    finding_id: String,        // hash of content
    review_id: String,         // links to review run
    model_key: String,
    severity: Severity,        // critical/high/medium/low/info
    summary: String,           // one-line description
    body: String,              // full finding text
    file_path: Option<String>, // if model cited a file
    line_range: Option<(u32, u32)>,
    confidence: Option<f64>,   // if model reported confidence
}

Extraction approach

Two options (not mutually exclusive):

A. Prompt engineering (cheap, immediate)
Add structured output instructions to the review system prompt: "Output each finding as ### [severity] Title\n- File: path:line\n- Detail: ..." — then regex-parse the response.

B. LLM extraction pass (expensive, accurate)
After review returns, run a cheap local model (qwen3-coder:30b via Ollama) to parse each response into structured findings. More accurate but adds latency.

Start with A, add B later if extraction quality is too low.

Schema

CREATE TABLE findings (
    finding_id TEXT PRIMARY KEY,
    review_id TEXT NOT NULL,
    model_key TEXT NOT NULL,
    severity TEXT,
    summary TEXT NOT NULL,
    body TEXT,
    file_path TEXT,
    start_line INTEGER,
    end_line INTEGER,
    confidence REAL,
    outcome TEXT  -- NULL, 'acted_on', 'ignored', 'memorized'
);

Persistence

Findings written alongside review results: .squall/reviews/{review_id}_findings.json

Success criteria

• Each model response is parsed into 0-N discrete findings
• Findings have at minimum: summary, severity, model_key
• File/line extraction works when models cite them (best-effort)
• Findings are queryable for ACT pair export

Estimated scope

~400-600 LoC depending on extraction approach. Schema migration + types + parser + persistence + tests.