test-execution-feedback-looplisted

## What It Does Reads the structured verification evidence file produced by the verifier, and for every entry in `gates[].failures[]` proposes the smallest change that would make that test pass. Each proposal is anchored to a specific file, line, AC id, and root-cause hypothesis — no prose-only suggestions and no fixes that work around the test. The point is to collapse the typical fix-test-rerun-repeat loop from two turns into one: the model's next implementation turn can act on a structured proposal instead of re-reading raw test output. ## Use This When Use this immediately after the verifier reports `overall_status: "fail"` and before the next implementation turn begins. Run it whenever there are at least one failure in the evidence file. Skip in the fast lane unless explicitly requested. ## Inputs - Read the verification evidence at `verification_evidence_path` first; reject the run if `schema_version` is not `1.0.x`. - Read the acceptance criteria artifact when supplied so each failure's `ac_id` can be cross-checked. - Read the changed-file list to calibrate confidence (failures pointing at files outside the change set lower confidence to `low`). - Read `references/fix-proposal-template.md` before drafting proposals so every proposal has the required fields. ## Procedure 1. Run `scripts/load-failures.sh [evidence-path]` — emits one JSON object per failure, exits 1 if schema_version is unsupported. Iterate over those rows. 2. For each failure, read an excerpt aro