The hashline prefix stripping logic uses an "all-or-nothing" heuristic:
it only strips N#XX: anchors when every non-empty line carries one.
When the Read tool truncation notice (e.g. [Showing lines 1-300 of
332. Use sel=L301 to continue]) is present in content passed to the
Edit or Write tool, that marker line breaks the heuristic, causing ALL
anchors to be written to disk verbatim. On subsequent reads, those
persisted anchors get double-prefixed (1#NX:1#BQ:---), compounding
the corruption.
This can happen when the AI model pastes Read tool output (including
the truncation marker) back into an Edit/Write call. While this is
arguably a model-level issue, the toolchain should be resilient against
it rather than silently corrupting files.
Changes:
- Add READ_TRUNCATION_NOTICE_RE to detect Read tool truncation markers
- Update collectLinePrefixStats to exclude truncation marker lines from
the non-empty line count so they no longer break the stripping heuristic
- Add stripLeadingHashlinePrefixes helper for recursive stripping of
nested/double-prefixed anchors (handles already-corrupted content)
- Add filterTruncationNotices helper to remove truncation marker lines
- Update both stripNewLinePrefixes and stripHashlinePrefixes to filter
truncation markers and use recursive anchor stripping
- Add 5 new test cases covering truncation markers and nested anchors
Qiang
e36bfcfba8