fix-from-logs

Output Contract

Produces per bug cluster: (1) one targeted code edit at the confirmed root cause location, (2) one named typed pytest function with mocks, (3) one-line root cause statement in the test comment.

Does NOT produce: architecture refactors, style fixes, unrelated test coverage, multiple competing fixes.

Hands off to: CI / pytest — the final action is confirming the full suite is green.

---

Process

Phase 1 — Ingest & Triage

1. Accept log input from paste, file path, or stdin reference.
2. Filter to FATAL/ERROR severity first; set INFO/DEBUG aside unless they precede the first error.
3. Cluster related errors: cascading failures share one root cause — group by error type, file, and timestamp proximity before analysing individual lines.
4. For each cluster, extract: error type, file path, line number, function name, request/correlation IDs, timestamp window.
5. Output a structured error inventory (1–3 clusters max; surface the highest-severity first).

Read references/rca-framework.md — Section 1 (triage sequence) and Section 2 (failure mode glossary).

---

Phase 2 — Localize (file → function → line)

1. Read the flagged file(s) in the codebase using the paths extracted in Phase 1.
2. Trace the call chain backward from the error site — the logged error is almost always a symptom, not the cause.
3. Apply 5 Whys: for each "why did this fail?" step, read the upstream caller or dependency until reaching an actionable root cause (something changeable in this codebase, not a framework or stdlib).
4. Read 20–30 lines of surrounding context in the affected file to understand: naming conventions, type usage, existing mock patterns, and error handling style. The fix must be native to this style.
5. Form 2–3 ranked hypotheses per cluster. Each hypothesis must have: root cause statement, location (file:line), confidence level (high/medium/low), and supporting evidence from the log + code.

Read references/rca-framework.md — Section 3 (5 Whys walkthrough).