Attribute filtered revisions to their repair attempts

docs/integrations/output-files.md

@@ -65,7 +65,9 @@ Each recovery identifies its work unit, optional `stage_id`, and successful oper
 `service_recovered`, `correction_revised`, and `proposals_filtered` together.
 `correction_revised` means a repair yielded a fully validated revision; its
 application outcome is recorded in the Markdown report. Filtering covers
-defective response proposals; low confidence, protected-term rejection,
+defective proposals and revisions under their originating operation. Only
+original proposal operations count toward `proposal_responses_with_filtering`.
+Low confidence, protected-term rejection,
 ordinary editorial rejection, and an apply-time conflict caused by an earlier
 accepted correction are not filtering recoveries. Failed operations are errors,
 not recoveries. The initial chunk identity remains stable even if earlier

docs/roadmap/remediation.md

@@ -2,9 +2,8 @@
 
 **Updated:** 2026-11-11
 
-**Status:** Nine open findings against implementation revision `aa8073c`. The
-algorithmic audit expanded R4 and added R5–R9. See the
-[implementation plan](implementation.md).
+**Status:** 1 of nine findings resolved. Findings refer to implementation revision
+`aa8073c`. See the [implementation plan](implementation.md).
 
 ## Review Result
 
@@ -34,6 +33,8 @@ replaced by a new local context-size restriction.
 
 ### R1 — Preserve Defect Attribution for Revised Proposals (P2)
 
+**Completed.** Revision defects now appear on the originating repair recovery. Subprocess tests cover exhaustion, later approval, and ordinary rejection.
+
 **Affected plan:** Stage 6, item 5; Stage 7, items 1–2.
 
 **Evidence:** In [repairCandidates](../../internal/framework/runner/repair.go),