hashed-editlisted

# Hashed Edit ## Purpose Catch stale-line edit failures BEFORE they corrupt a file. A stale-line edit happens when an agent reads a file, plans an edit, then submits the edit after another tool call has rewritten the line — the edit applies to the wrong content. Adapted from oh-my-openagent's `hashline_edit` pattern (which reports reducing stale-line edit failures from ~93% to 32% on Grok Code). The mechanism: every line read through `read-with-hashes.sh` is tagged with a content-hash anchor (`<lineno>#<hash>|<content>`). The edit companion `edit-by-hash.sh` applies the edit IFF the current line's hash matches the anchor. Mismatch → refuse + diff. ## Scope Two operations, no third: - **Read with hashes** — produce tagged output an agent can refer back to - **Edit by hash** — apply a single-line replacement (or deletion) gated by hash match Multi-line edits and structural transforms (move blocks, refactor across files) are out of scope. Use the standard `Edit` tool for those, or break them into per-line hashed edits where the staleness risk is real. ## When to use - **Long sessions on large files.** A 2000-line file read at minute 5 may have changed by minute 35. Hash-anchored edits catch the staleness. - **Multi-agent dispatch on shared files.** When multiple specialists may touch the same file, hash anchors make race-condition edits fail loud instead of silently corrupting. - **Models that struggle with line numbers.** Some models drift between the line t