Module edit_quality 

Quality loop v1 (#494): compression-caused edit failures feed back into mode selection.

BounceTracker/path_mode_memory close the loop for re-read bounces, but an edit that fails because the file was last read in a compressed mode (old_string not found — the body simply wasn’t in context) taught the system nothing. This module records edit outcomes correlated with the last read mode and feeds two signals back into auto_mode_resolver::resolve:

1. Per-path escalation — after a compression-correlated edit failure the next auto read of that file resolves to full (one-shot, 1 h TTL).
2. Per-(extension × mode) penalty — modes whose edit-failure rate for a file type crosses the risky threshold resolve to full until the rate recovers (hysteresis, see below).

Risk formula (documented in docs/contracts/quality-loop-v1.md): a (ext, mode) pair becomes risky when fails >= 2 && fails / (fails + successes) >= 0.25, and stops being risky only when the rate drops below 0.15 — two thresholds so one lucky edit doesn’t flap the decision.

Storage: ~/.lean-ctx/edit_quality.json, atomic write (tmp+rename), loaded once per process, flushed periodically like path_mode_memory.

Structs

EditQualityStore

PairStats

Functions

flush

is_risky_mode

Process-global: is mode currently risky for files with this extension?

metrics_snapshot

Snapshot for ctx_metrics: (risky pairs, per-pair stats, escalations served).

record_edit_outcome

Process-global: record the outcome of an edit, correlated with the mode of the last read of that file. last_mode must be the recorded read mode (empty = file was never read through lean-ctx → no signal, skipped). Compression-correlated failures additionally arm the one-shot per-path escalation so the next auto read of path resolves to full.

take_pending_escalation

Process-global: one-shot check-and-consume of the per-path escalation.