Problem

Discussion #3970: the plan completes but the todo list never updates, and in the worst case the model loops on complete_step retries — each one rejected with step "Phase 5：脚本编辑与执行代码" has no matching todo_write item in this turn — quietly burning tokens.

Root cause is exactly what the reporter guessed: matchTodoStep required byte-exact (case-folded) equality between the cited step and a todo's text. Any drift — fullwidth ： cited back as halfwidth : , an extra space, a wording subset — could never match, and nothing in the error told the model how to fix its citation, so it retried the same string forever. #3982 fixed this disease for command citations; the todo-text limb still had it.

Fix

• Normalize before comparing: fullwidth ASCII forms → halfwidth, whitespace dropped, case-folded. The reported case (Phase 5： vs Phase 5: ) now matches.
• Unique-containment fallback: a citation that is a substring of exactly one todo (or vice versa, shorter side ≥ 6 runes) resolves to it; if it would match two todos, it stays unmatched rather than guessing.
• Actionable rejection: the error now lists this turn's todos (cite a todo verbatim or by number: 1) "…", 2) "…"), the same receipts-in-error pattern that let models self-correct within 1–2 turns in fix(evidence): stop rejecting real complete_step verifications over command-string drift #3982's A/B run.

Tests

• Verbatim 计划已经完成，但是待办列表没有更新 #3970 shape: fullwidth-colon todo cited with halfwidth colon, plus case/whitespace/U+3000/subset/fullwidth-digit-index variants.
• Negative cases: unrelated text, too-short containment, ambiguous shared-prefix citations stay unmatched while exact ones still resolve.
• todoInventory lists todos and degrades cleanly on an empty ledger.

go test ./internal/evidence/... ./internal/tool/builtin/... passes.

Addresses the remaining half of discussion #3970; #3982 covered the command-citation half.