This is an improve task. Your feedback context can come from two sources:

- A completed review with **Must-Fix** items (blockers) and **Suggestions** (follow-ups).
- Unresolved task **Comments** attached to the implementation.

One or both of these sections may appear above. If a review is present, it will be under a `## Review feedback to address:` heading. If comments are present, they will be under a `## Comments:` heading. Treat whichever sections are present as the authoritative feedback for this pass. If no review section is present, comments alone are sufficient to drive this improve — you are not required to fabricate Must-Fix structure when the feedback source is comments only.

Your job is to address every blocking feedback item presented:
- Treat review **Must-Fix** items as **Blockers** for this pass, and address every such item when a review section is present.
- Address every unresolved entry in the Comments section, when it is present.
- Treat review **Suggestions**/**Follow-Ups** as optional follow-up work unless the task prompt or review explicitly says they are required in this pass.

Before you edit, re-read all current feedback, inventory the entire current blocker/comment set, and treat it as one atomic closure unit for this pass. Do not pick off only the newest item. Plan the edits against the full set collectively so you do not fix one blocker while regressing another or silently leaving an older comment open.

Treat grouped blocker classes as grouped work:
- If the review groups analogous sites into one Blocker or calls out a repeated blocker class, handle that grouped class as one closure unit and fix every cited/current analogous instance in this pass.
- Do not report a grouped blocker closed because one example path is fixed while sibling instances in the same grouped class remain open.

Work through the full blocking set systematically:
- First list every in-scope review Blocker and every unresolved comment you must close in this pass.
- Identify the specific change required for each item and the shared fix plan across the set.
- Implement the fix set.
- Add or update targeted tests that cover the specific failure mode called out in the feedback. Treat these targeted tests as inner-loop checks only, not final closure proof.
- If the feedback concerns CLI, config, docs, prompts, or other operator-facing behavior, update the relevant help text or documentation in the same pass.
- If the context includes a failed or timed-out `## verify_command result`, inspect its captured stdout/stderr, `Failing output (trimmed)`, and any referenced `verify_command_output` artifacts before rerunning the full verify command.
- After each meaningful edit batch, re-check the full initial blocker/comment inventory for regressions or still-open grouped work before continuing.
- After the last edit, re-check every listed blocker/comment again, including items you believe were already addressed earlier in the pass.
- After the last edit, run the configured full final verify command required elsewhere in this prompt. Passing targeted tests alone is insufficient; the blocker/comment set is not closed until the full final verify gate is green unless the existing no-op dispute or verify-only clearance contract explicitly applies.

Before finishing, verify that your final report contains an explicit closure matrix for every blocking item in the initial inventory:
- The review item you addressed
- The comment you addressed (when comments are present)
- The grouped blocker class you closed collectively, when applicable
- The code change you made
- The targeted test you added or updated
- Any docs/help/operator-facing text you updated, if applicable
- An anti-regression statement confirming you re-checked the full initial inventory after the meaningful edit batches and again after the last edit

If a Blocker (review Must-Fix item) or comment no longer applies because the code already satisfies it or the feedback was stale, say that explicitly and cite the current code/tests that prove it instead of making unnecessary changes.
When a non-verify CODE Blocker is invalid and the correct outcome is a no-op improve, you
may emit a structured `## Disputed Blockers` section in your final report instead of
inventing a code change. Use this only when the current code or scope actually disproves
the blocker. Keep one entry per disputed blocker and use this shape:

```markdown
## Disputed Blockers

### B1
Finding: <review blocker id/title>
Reason: unreproducible | already_satisfied | stale | out_of_scope | review_error
Evidence: <current-state proof>
Current-state citation: <path:line or path:start-end>
Scope citation: <optional scope/spec citation>
Downstream task: <optional full prefixed task id if the work belongs elsewhere>
```

If you emit `## Disputed Blockers`, make the rest of the report explicit about why no
code change was required and which current code/tests prove the blocker is not open.

Disputed entries must still appear in the required machine-readable blocker closure ledger below.

Do not leave blocking feedback items partially addressed. The goal is to resolve all gating feedback in a single pass without creating extra scope.
Treat a cited path or line range as an instance of a class of issue, not the full scope of the fix. If a blocker calls out one path for a broader issue, audit every analogous path for the same problem and fix them in this pass. When multiple sites share the same fix shape, prefer a centralized helper or shared code path over per-call-site patches. "Extra scope" means unrelated changes, not other instances of the same blocker class.
When a blocker's `Open-state citation:` enumerates multiple paths or line ranges (a reviewer-enumerated class), treat the entire set as the closure condition for that one blocker - fix every cited instance in this pass, not just the first.
If the context includes a `## verify_command result` section, `Failing output (trimmed)`, or a persisted `verify_command_output` artifact reference, inspect that captured stdout/stderr before rerunning the full command. Timeout captures may already contain actionable diagnostics such as slow-phase summaries or SIGTERM-triggered stack dumps.

Before adopting a fix that weakens a bound or guardrail (test timeout, fail-fast flag, lint rule, type check, verify gate), read `docs/internal/practices.md`. The default remedy is to fix the underlying issue at the smallest unit (the specific test, file, or call site that hit the bound), or re-classify that unit to a looser bound deliberately - not to relax the suite-wide default. If the inbound review's only blocker is a verify timeout, treat that as a test-performance investigation, not a code-correctness one.

Your final report must include this exact section and cover every in-scope review Blocker and unresolved comment from this pass, even if the item was disputed or required no code change:

````markdown
## Blocker Closure Ledger (Machine Readable)

```yaml
improve_result: addressed | disputed_noop | blocked_external | needs_user
blockers:
  - source: review | comment
    source_id: <B1/comment id>
    summary: <short summary>
    status: addressed | disputed | deferred | needs_user
    closure_evidence: <code/test/current-state proof>
    verify_evidence: <targeted checks plus final full verify result>
final_verify:
  command: <configured verify command or per-project commands>
  status: passed | failed | unavailable
```
````

After the machine-readable ledger, include a short explicit closure matrix in prose or table form that lists every initial blocker/comment, its final status, and the evidence that closed it. Then add a one-sentence anti-regression statement covering the full initial inventory.
