pi-hashline-edit-pro 0.16.5 → 0.16.7

package/README.md

@@ -143,7 +143,7 @@ The file is created automatically when any setting is toggled. Both fields are i
 - **Strict patch content.** If `content_lines` contains `+HASH│` display prefixes (or `-N   ` numbered deletion rows), the edit is rejected with `[E_INVALID_PATCH]`. This narrowly guards against pasting the tool's own diff-preview rows back as content; standard unified-diff lines (`+x`, `-x`, ` x`, `@@ … @@`) are **not** rejected — they are written literally, since literal content must never be silently altered. Bare `HASH│` content (the first 4 chars of a `content_lines` entry looking like 3 base64 chars + `│`) is rejected with `[E_BARE_HASH_PREFIX]`. When the suspect's prefix happens to match a real file-line anchor, the error message flags that as strong evidence the model copied an anchor from the read output.
 - **Atomic writes.** Files are written via temp-file-then-rename to avoid corruption from interrupted writes. Symlink chains are resolved so the target file is updated without replacing the symlink. Hard-linked files are updated in place to preserve the shared inode. File permissions are preserved across atomic renames.
 - **Per-file mutation queue.** Edits queue by the canonical write target, so concurrent edits through different symlink paths still serialize onto the same underlying file.
-- **Boundary duplication warnings.** When the last line of a replacement matches the next surviving line (or the first line matches the preceding one), a warning is emitted. This catches a common LLM pattern where closing delimiters like `}`, `});`, or `} else {` are accidentally duplicated. The warning is a short header followed by a hashline-anchored window: the duplicated pair plus 2 lines of context before and after, shown as plain `HASH│content` rows with post-edit hashes. Seeing the duplication in context (rather than just being told a hash) is what prompts the model to act on it — and since the hashes are current and staleness is per-line, the model can remove the duplicate in one follow-up `replace` without re-reading. No autocorrection is applied — the duplicate stays in the file and the model decides whether to remove it. Raw line comparison (not trimmed) avoids false positives when indentation differs.
+- **Boundary duplication auto-fix.** When the last line of a replacement matches the next surviving line (or the first line matches the preceding one), the runtime automatically strips the duplicate from `content_lines` before applying the edit. This catches a common LLM pattern where closing delimiters like `}`, `});`, or `} else {` are accidentally duplicated. The auto-fix is completely silent — the model sees a normal successful edit. The duplicate never reaches the file. Raw line comparison (not trimmed) avoids false positives when indentation differs.
 - **Flat mode normalization.** When flat mode is active, the tool's `execute` function wraps the top-level `hash_range_inclusive` and `content_lines` into a single-element `changes` array internally, then runs the same pipeline as bulk mode. The `normReq` function in `replace-normalize.ts` also handles flat format directly, so any code path that normalizes input (e.g. `compPreview`) works with both formats.
 - **Persistent hash store.** `lineHashes` is async and uses a persistent store to preserve hashes for unchanged lines across edits. The store is at `~/.config/pi-hashline-edit-pro/hash-store.json` and is auto-created on first use. It contains per-file snapshots (last known content+hashes). When called from the replace pipeline, it maps old vs new content and copies hashes for unchanged lines. When called from read, it returns saved hashes if the content matches, otherwise computes fresh hashes via `_lineHashesPure`. Stale snapshots are pruned on session start. This ensures that editing one part of a file does not cascade to change hashes of unrelated lines.
 ## Hashing

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-hashline-edit-pro",
-  "version": "0.16.5",
+  "version": "0.16.7",
   "description": "Strict hashline read/replace tool for pi-coding-agent with hash-anchored edits (3-char, 18-bit, perfect hashing)",
   "main": "index.ts",
   "repository": {

package/prompts/replace-bulk-guidelines.md

@@ -3,5 +3,4 @@
 - On `[E_STALE_ANCHOR]`, call `read` to get fresh anchors, copy the 3-character HASH of the start and end of the range you are replacing into `hash_range_inclusive`, and retry.
 - `hash_range_inclusive` replaces the ENTIRE range inclusively. Every line from the first anchor through the second anchor is deleted. Only put the replacement lines in `content_lines` — do not include lines that already exist outside the range.
 - **Preserve leading whitespace (indentation) exactly.** The content after `│` in read output includes all leading spaces and tabs — copy them into `content_lines` unchanged.
-- **`content_lines` must be a native JSON array of strings**, not a JSON string. Do NOT serialize it: `"content_lines": "[\"line1\", \"line2\"]"` is WRONG. Use `"content_lines": ["line1", "line2"]` instead.
-- If the response includes a "Boundary duplication" warning, the edge line of your `content_lines` matches a line outside the replaced range. Remove that line from `content_lines` — the original is still in the file outside the range.
+- **`content_lines` must be a native JSON array of strings**, not a JSON string. Do NOT serialize it: `"content_lines": "[\"line1\", \"line2\"]"` is WRONG. Use `"content_lines": ["line1", "line2"]` instead.

package/prompts/replace-bulk.md

@@ -2,20 +2,6 @@ Replace lines in a text file using HASH anchors from `read`.
 
 Put all operations on one file in a single `replace` call. Stack every region into the `changes` array, even when they are far apart. Anchors within one call must all come from the same pre-edit read; the runtime applies them atomically against that one snapshot.
 
-How to use:
-
-1. Call `read` to get HASH anchors:
-```
-read({ path: "src/main.ts" })
-```
-
-2. Copy the 3-character HASH (before `│`) into `hash_range_inclusive`:
-```json
-{ "changes": [
-  { "content_lines": ["const x = 99;"], "hash_range_inclusive": ["MQX", "MQX"] }
-], "path": "src/main.ts" }
-```
-
 Examples:
 
 1. Single line replace:
@@ -51,13 +37,6 @@ Examples:
 ], "path": "src/main.ts" }
 ```
 
-5. Seed content into an empty file (replace the single empty-line hash returned by read):
-```json
-{ "changes": [
-  { "content_lines": ["first line", "second line"], "hash_range_inclusive": ["aB3", "aB3"] }
-], "path": "src/main.ts" }
-```
-
 ⚠️ Common mistake: do not copy the `HASH│` prefix into `content_lines`.
 
 Wrong:
@@ -123,17 +102,4 @@ Right: Only include the new lines that belong in the range:
 { "content_lines": ["  const y = 2;", "  return y;"], "hash_range_inclusive": ["X", "Y"] }
 The `}` on line 4 is outside the range and stays in place.
 
-Error recovery:
-- `[E_STALE_ANCHOR]` — the anchored line's content changed since the last read. Call `read` to get fresh anchors, then copy the 3-char HASH of the start and end of the range you are replacing into `hash_range_inclusive` and retry. (Staleness is per-line: editing or appending lines does not invalidate anchors for lines whose content is unchanged, so anchors for untouched regions stay valid across edits.)
-- `[E_BAD_REF]` — malformed HASH. Re-read and try again.
-- `[E_BAD_OP]` — invalid operation (e.g. start line > end line).
-- `[E_BAD_SHAPE]` — malformed request or change item (missing fields, wrong types, unknown fields).
-- `[E_LEGACY_SHAPE]` — old `oldText`/`newText` or `old_text`/`new_text` format detected. Use `{content_lines, hash_range_inclusive}` instead.
-- `[E_EDIT_CONFLICT]` — two changes overlap on the same line range. Make changes non-overlapping.
-- `[E_AMBIGUOUS_ANCHOR]` — hash collision. Call `read` to get fresh anchors.
-- `[E_BARE_HASH_PREFIX]` — a `content_lines` entry starts with `HASH│`. Remove the hash prefix; keep only the literal line content that appears after `│` in `read` output. `content_lines` uses file content only, `hash_range_inclusive` uses hash anchors.
-- `[E_INVALID_PATCH]` — a `content_lines` entry matches the diff preview's `+HASH│…` addition-row form. Use literal file content. (Plain `+`/`-` lines are not rejected — they are written literally.)
-- `[E_WOULD_EMPTY]` — edit would empty a non-empty file.
-- `[E_FILE_TOO_LARGE]` — file exceeds the 1,000,000-line edit limit. Use `write` or a non-line-based approach for very large files.
-
 **Undo:** If a replace produced incorrect results, call `undo_last_replace` with the file path to revert the last replace. The tool reports how many lines were removed and restored. After undoing, call `read` to get fresh anchors for a corrected replace.

package/prompts/replace-flat-guidelines.md

@@ -3,5 +3,4 @@
 - On `[E_STALE_ANCHOR]`, call `read` to get fresh anchors, copy the 3-character HASH of the start and end of the range you are replacing into `hash_range_inclusive`, and retry.
 - `hash_range_inclusive` replaces the ENTIRE range inclusively. Every line from the first anchor through the second anchor is deleted. Only put the replacement lines in `content_lines` — do not include lines that already exist outside the range.
 - **Preserve leading whitespace (indentation) exactly.** The content after `│` in read output includes all leading spaces and tabs — copy them into `content_lines` unchanged.
-- **`content_lines` must be a native JSON array of strings**, not a JSON string. Do NOT serialize it: `"content_lines": "[\"line1\", \"line2\"]"` is WRONG. Use `"content_lines": ["line1", "line2"]` instead.
-- If the response includes a "Boundary duplication" warning, the edge line of your `content_lines` matches a line outside the replaced range. Remove that line from `content_lines` — the original is still in the file outside the range.
+- **`content_lines` must be a native JSON array of strings**, not a JSON string. Do NOT serialize it: `"content_lines": "[\"line1\", \"line2\"]"` is WRONG. Use `"content_lines": ["line1", "line2"]` instead.

package/prompts/replace-flat.md

@@ -1,17 +1,5 @@
 Replace lines in a text file using HASH anchors from `read`. Only one edit per call (no bulk `changes` array — `hash_range_inclusive` and `content_lines` sit at the top level).
 
-How to use:
-
-1. Call `read` to get HASH anchors:
-```
-read({ path: "src/main.ts" })
-```
-
-2. Copy the 3-character HASH (before `│`) into `hash_range_inclusive`:
-```json
-{ "content_lines": ["const x = 99;"], "hash_range_inclusive": ["MQX", "MQX"], "path": "src/main.ts" }
-```
-
 Examples:
 
 1. Single line replace:
@@ -38,11 +26,6 @@ Examples:
 { "content_lines": ["old last line", "new line"], "hash_range_inclusive": ["ZPM", "ZPM"], "path": "src/main.ts" }
 ```
 
-5. Seed content into an empty file (replace the single empty-line hash returned by read):
-```json
-{ "content_lines": ["first line", "second line"], "hash_range_inclusive": ["aB3", "aB3"], "path": "src/main.ts" }
-```
-
 ⚠️ Common mistake: do not copy the `HASH│` prefix into `content_lines`.
 
 Wrong:
@@ -109,16 +92,4 @@ Right: Only include the new lines that belong in the range:
 { "content_lines": ["  const y = 2;", "  return y;"], "hash_range_inclusive": ["X", "Y"] }
 The `}` on line 4 is outside the range and stays in place.
 
-Error recovery:
-- `[E_STALE_ANCHOR]` — the anchored line's content changed since the last read. Call `read` to get fresh anchors, then copy the 3-char HASH of the start and end of the range you are replacing into `hash_range_inclusive` and retry. (Staleness is per-line: editing or appending lines does not invalidate anchors for lines whose content is unchanged, so anchors for untouched regions stay valid across edits.)
-- `[E_BAD_REF]` — malformed HASH. Re-read and try again.
-- `[E_BAD_OP]` — invalid operation (e.g. start line > end line).
-- `[E_BAD_SHAPE]` — malformed request or change item (missing fields, wrong types, unknown fields).
-- `[E_LEGACY_SHAPE]` — old `oldText`/`newText` or `old_text`/`new_text` format detected. Use `{content_lines, hash_range_inclusive}` instead.
-- `[E_AMBIGUOUS_ANCHOR]` — hash collision. Call `read` to get fresh anchors.
-- `[E_BARE_HASH_PREFIX]` — a `content_lines` entry starts with `HASH│`. Remove the hash prefix; keep only the literal line content that appears after `│` in `read` output. `content_lines` uses file content only, `hash_range_inclusive` uses hash anchors.
-- `[E_INVALID_PATCH]` — a `content_lines` entry matches the diff preview's `+HASH│…` addition-row form. Use literal file content. (Plain `+`/`-` lines are not rejected — they are written literally.)
-- `[E_WOULD_EMPTY]` — edit would empty a non-empty file.
-- `[E_FILE_TOO_LARGE]` — file exceeds the 1,000,000-line edit limit. Use `write` or a non-line-based approach for very large files.
-
 **Undo:** If a replace produced incorrect results, call `undo_last_replace` with the file path to revert the last replace. The tool reports how many lines were removed and restored. After undoing, call `read` to get fresh anchors for a corrected replace.

package/src/hashline/apply.ts

@@ -10,6 +10,7 @@ import {
 	type NEdit,
 	type HEdit,
 	type BDupWarn,
+	type AutoFix,
 } from "./resolve";
 import { cntLines } from "../utils";
 
@@ -262,7 +263,7 @@ export function applyEdits(
 	lastChangedLine: number | undefined;
 	warnings?: string[];
 	noopEdits?: NEdit[];
-	boundaryWarnings?: BDupWarn[];
+	autoFixes?: AutoFix[];
 } {
 	abortIf(signal);
 	if (!edits.length)
@@ -272,13 +273,12 @@ export function applyEdits(
 			lastChangedLine: undefined,
 		};
 
-
 	const lineIndex = buildIdx(content);
 	const fileHashes = precomputedHashes ?? _lineHashesPure(content);
 	const noopEdits: NEdit[] = [];
 	const warnings: string[] = [];
 
-	const { resolved, mismatches, boundaryWarnings } = valEdits(
+	const { resolved: initialResolved, mismatches, boundaryWarnings } = valEdits(
 		edits,
 		lineIndex.fileLines,
 		fileHashes,
@@ -294,6 +294,47 @@ export function applyEdits(
 	assertNoBarePrefix(edits, lineIndex.fileLines, fileHashes);
 	warnUnicodeEsc(edits, warnings);
 
+	// Auto-fix boundary duplications: strip the offending line from content_lines
+	let resolved = initialResolved;
+	let autoFixes: AutoFix[] | undefined;
+	if (boundaryWarnings.length > 0) {
+		autoFixes = [];
+		// Deep-copy edits so we don't mutate the originals
+		const correctedEdits: import("./resolve").HEdit[] = edits.map(e => ({
+			...e,
+			content_lines: [...e.content_lines],
+		}));
+		for (const bw of boundaryWarnings) {
+			const edit = correctedEdits[bw.editIndex];
+			if (!edit) continue;
+			if (bw.kind === "trailing") {
+				const removed = edit.content_lines.pop();
+				if (removed !== undefined) {
+					autoFixes.push({ kind: "trailing", editIndex: bw.editIndex, removedLine: removed });
+				}
+			} else {
+				const removed = edit.content_lines.shift();
+				if (removed !== undefined) {
+					autoFixes.push({ kind: "leading", editIndex: bw.editIndex, removedLine: removed });
+				}
+			}
+		}
+		// Re-validate with corrected edits
+		const correctedResult = valEdits(
+			correctedEdits,
+			lineIndex.fileLines,
+			fileHashes,
+			warnings,
+			signal,
+		);
+		if (correctedResult.mismatches.length) {
+			throw new Error(
+				fmtMismatch(correctedResult.mismatches, lineIndex.fileLines, fileHashes, filePath),
+			);
+		}
+		resolved = correctedResult.resolved;
+	}
+
 	const orderedSpans = resSpans(
 		resolved,
 		content,
@@ -312,7 +353,7 @@ export function applyEdits(
 		lastChangedLine: range?.lastChangedLine,
 		...(warnings.length ? { warnings } : {}),
 		...(noopEdits.length ? { noopEdits } : {}),
-		...(boundaryWarnings.length ? { boundaryWarnings } : {}),
+		...(autoFixes ? { autoFixes } : {}),
 	};
 }
 

package/src/hashline/index.ts

@@ -25,13 +25,13 @@ export {
 	type HTEdit,
 	type NEdit,
 	type BDupWarn,
+	type AutoFix,
 	descEdit,
 	resEdits,
 	valEdits,
 	assertNoBarePrefix,
 	fmtMismatch,
 } from "./resolve";
-
 export {
 	buildIdx,
 	applyEdits,

package/src/hashline/resolve.ts

@@ -30,6 +30,13 @@ export interface BDupWarn {
 	editIndex: number;
 }
 
+export interface AutoFix {
+  kind: "trailing" | "leading";
+  editIndex: number;
+  removedLine: string;
+}
+
+
 export interface NEdit {
 	editIndex: number;
 	loc: string;

package/src/replace.ts

@@ -18,7 +18,6 @@ import { resolveTarget, writeAtomic } from "./fs-write";
 import {
   applyEdits,
   lineHashes,
-  fmtBoundaryWarning,
   resEdits,
   type HTEdit,
 } from "./hashline";
@@ -195,30 +194,7 @@ export async function execPipeline(
     removedHashes,
   });
 
-  const resultLines = result.split("\n");
   const warnings = [...(anchorResult.warnings ?? [])];
-  for (const bw of anchorResult.boundaryWarnings ?? []) {
-    let seen = 0;
-    let matchIndex = -1;
-    for (let i = 0; i < resultLines.length; i++) {
-      if (resultLines[i] === bw.survivingLineContent) {
-        if (seen === bw.occurrence) { matchIndex = i; break; }
-        seen++;
-      }
-    }
-    if (matchIndex >= 0) {
-      warnings.push(
-        fmtBoundaryWarning({
-          kind: bw.kind,
-          survivingContent: bw.survivingLineContent,
-          matchIndex,
-          resultLines,
-          resultHashes,
-        }),
-      );
-    }
-  }
-
   return {
     path,
     toolEdits,
@@ -297,7 +273,7 @@ export function buildToolDef(opts: { flat: boolean }): ToolDef {
     AUTO_READ_GUIDANCE: readGuidance,
   });
 
-  const parameters = opts.flat ? flatEditToolSchema : editToolSchema;
+  const parameters = editToolSchema;
 
   return {
     name: "replace",
@@ -311,7 +287,7 @@ export function buildToolDef(opts: { flat: boolean }): ToolDef {
           if (!isRec(args)) return args as any;
           const record = { ...args };
           normalizeFilePath(record);
-          return record as any;
+          return normReq(record) as any;
         }
       : (args: unknown) =>
           normReq(args) as ReqParams,
@@ -404,17 +380,7 @@ export function buildToolDef(opts: { flat: boolean }): ToolDef {
     },
 
     async execute(_toolCallId, params, signal, _onUpdate, ctx) {
-      const canonical = opts.flat
-        ? normReq({
-            content_lines: (params as any).content_lines,
-            hash_range_inclusive: (params as any).hash_range_inclusive,
-            path: (params as any).path,
-            changes: [{
-              content_lines: (params as any).content_lines,
-              hash_range_inclusive: (params as any).hash_range_inclusive,
-            }],
-          })
-        : normReq(params);
+      const canonical = normReq(params);
 
 
       const normalizedParams = canonical as { path: string; changes: HTEdit[] };

package/prompts/replace-guidelines.md

@@ -1,8 +0,0 @@
-- Use `replace` with HASH anchors for all file changes; batch every change to one file into a single `replace` call.
-- After a successful `replace`, the response shows the change summary. {{AUTO_READ_GUIDANCE}}
-- On `[E_STALE_ANCHOR]`, call `read` to get fresh anchors, copy the 3-character HASH of the start and end of the range you are replacing into `hash_range_inclusive`, and retry.
-- `hash_range_inclusive` replaces the ENTIRE range inclusively. Every line from the first anchor through the second anchor is deleted. Only put the replacement lines in `content_lines` — do not include lines that already exist outside the range.
-- **Preserve leading whitespace (indentation) exactly.** The content after `│` in read output includes all leading spaces and tabs — copy them into `content_lines` unchanged.
-- **`content_lines` must be a native JSON array of strings**, not a JSON string. Do NOT serialize it: `"content_lines": "[\"line1\", \"line2\"]"` is WRONG. Use `"content_lines": ["line1", "line2"]` instead.
-- Two modes are available: bulk (default, uses `changes` array) and flat (top-level `hash_range_inclusive`/`content_lines`). Toggle with `/toggle-replace-mode`.
-- If the response includes a "Boundary duplication" warning, the edge line of your `content_lines` matches a line outside the replaced range. Remove that line from `content_lines` — the original is still in the file outside the range.

package/prompts/replace-snippet.md

@@ -1 +0,0 @@
-Replace lines in a text file via HASH anchors from read, batching all changes to a file in one call. Supports bulk mode (changes array) and flat mode (top-level fields), toggled via /toggle-replace-mode.

package/prompts/replace.md

@@ -1,188 +0,0 @@
-Replace lines in a text file using HASH anchors from `read`.
-
-Two modes are available, toggled via `/toggle-replace-mode` (persists across sessions):
-
-**Bulk mode (default):** `hash_range_inclusive` and `content_lines` go inside a `changes` array, supporting multiple edits in one call.
-
-**Flat mode:** `hash_range_inclusive` and `content_lines` sit at the top level. Only one edit per call.
-
----
-
-Put all operations on one file in a single `replace` call. Stack every region into the `changes` array, even when they are far apart. Anchors within one call must all come from the same pre-edit read; the runtime applies them atomically against that one snapshot.
-
-How to use:
-
-1. Call `read` to get HASH anchors:
-```
-read({ path: "src/main.ts" })
-```
-
-2. Copy the 3-character HASH (before `│`) into `hash_range_inclusive`:
-
-**Bulk mode:**
-```json
-{ "changes": [
-  { "content_lines": ["const x = 99;"], "hash_range_inclusive": ["MQX", "MQX"] }
-], "path": "src/main.ts" }
-```
-
-**Flat mode:**
-```json
-{ "content_lines": ["const x = 99;"], "hash_range_inclusive": ["MQX", "MQX"], "path": "src/main.ts" }
-```
-
-Examples:
-
-1. Single line replace:
-
-Bulk:
-```json
-{ "changes": [
-  { "content_lines": ["const x = 1;"], "hash_range_inclusive": ["MQX", "MQX"] }
-], "path": "src/main.ts" }
-```
-
-Flat:
-```json
-{ "content_lines": ["const x = 1;"], "hash_range_inclusive": ["MQX", "MQX"], "path": "src/main.ts" }
-```
-
-2. Range replace (3 lines → 3 new lines):
-
-Bulk:
-```json
-{ "changes": [
-  { "content_lines": [
-    "function greet(name) {",
-    "  return `Hello, ${name}`;",
-    "}"
-  ], "hash_range_inclusive": ["ZPM", "VRW"] }
-], "path": "src/main.ts" }
-```
-
-Flat:
-```json
-{ "content_lines": [
-    "function greet(name) {",
-    "  return `Hello, ${name}`;",
-    "}"
-  ], "hash_range_inclusive": ["ZPM", "VRW"], "path": "src/main.ts" }
-```
-
-3. Multiple regions in one call (bulk mode only — flat mode supports one edit per call):
-```json
-{ "changes": [
-  { "content_lines": [], "hash_range_inclusive": ["aB3", "xY7"] },
-  { "content_lines": [], "hash_range_inclusive": ["MQX", "ZPM"] }
-], "path": "src/server.ts" }
-```
-
-4. Append after the last line (include the old last line so the new line is added after it):
-
-Bulk:
-```json
-{ "changes": [
-  { "content_lines": ["old last line", "new line"], "hash_range_inclusive": ["ZPM", "ZPM"] }
-], "path": "src/main.ts" }
-```
-
-Flat:
-```json
-{ "content_lines": ["old last line", "new line"], "hash_range_inclusive": ["ZPM", "ZPM"], "path": "src/main.ts" }
-```
-
-5. Seed content into an empty file (replace the single empty-line hash returned by read):
-
-Bulk:
-```json
-{ "changes": [
-  { "content_lines": ["first line", "second line"], "hash_range_inclusive": ["aB3", "aB3"] }
-], "path": "src/main.ts" }
-```
-
-Flat:
-```json
-{ "content_lines": ["first line", "second line"], "hash_range_inclusive": ["aB3", "aB3"], "path": "src/main.ts" }
-```
-
-⚠️ Common mistake: do not copy the `HASH│` prefix into `content_lines`.
-
-Wrong:
-```json
-{ "content_lines": ["F4T│import { x } from \"./x\";"], "hash_range_inclusive": ["F4T", "F4T"] }
-
-Right:
-```json
-{ "content_lines": ["import { x } from \"./x\";"], "hash_range_inclusive": ["F4T", "F4T"] }
-
-`hash_range_inclusive` uses the hash anchor. `content_lines` uses literal file content only — the same text that appears after the `│` in `read` output.
-
-⚠️ Common mistake: `hash_range_inclusive` is only the 3-character HASH, not the full `HASH│content` line.
-
-Wrong:
-```json
-{ "content_lines": [...], "hash_range_inclusive": ["F4T│import { x } from \"./x\";", "F4T│import { x } from \"./x\";"] }
-
-Right:
-```json
-{ "content_lines": [...], "hash_range_inclusive": ["F4T", "F4T"] }
-
-⚠️ Common mistake: do not serialize `content_lines` as a JSON string.
-
-Wrong:
-```json
-{ "content_lines": "[\"line1\", \"line2\"]", "hash_range_inclusive": ["F4T", "F4T"] }
-
-Right:
-```json
-{ "content_lines": ["line1", "line2"], "hash_range_inclusive": ["F4T", "F4T"] }
-
-`content_lines` must be a native JSON array of strings, not a string that looks like an array. Pass it as a proper JSON array value.
-
-Rules:
-- `hash_range_inclusive` is a pair `[start, end]`. A single-line replace is `hash_range_inclusive: ["X", "X"]`.
-- To delete a range, use `content_lines: []`.
-- `hash_range_inclusive` elements are HASH anchors only (e.g. `aB3`). Do not include `│` or line content.
-- `content_lines` is literal file content — each string becomes exactly one line in the file. No `HASH│` prefix. A line that happens to start with `+` or `-` is written as-is; the only rejected form is the diff preview's `+HASH│…` row (see `[E_INVALID_PATCH]`).
-- **Preserve leading whitespace (indentation) exactly.** The content after `│` in read output includes all leading spaces and tabs — copy them into `content_lines` unchanged. Dropping indentation will produce broken code.
-- Don't add `""` for spacing unless you actually want a new blank line.
-- Copy anchors from the most recent `read` of the file. Do not guess or construct them.
-- All changes in one call must be non-conflicting. The runtime rejects with `[E_EDIT_CONFLICT]` if two ranges overlap.
-- If `content_lines` matches current content, the replace is classified as `noop` (file unchanged).
-- The `hash_range_inclusive` is inclusive — the entire span from the first anchor through the second anchor is deleted and replaced with `content_lines`. The old lines in that span are gone. If your replacement content includes lines that already exist in the file (e.g. closing brackets), make sure those lines are within your range, otherwise they will appear twice.
-- `changes` (in bulk mode), `hash_range_inclusive`, and `content_lines` must be native JSON values, not JSON strings. Do not serialize them — pass them as proper arrays and strings.
-On success, the response text shows the line change summary (e.g. "Added 3 line(s), removed 1 line(s).") plus any warnings if present. {{AUTO_READ_GUIDANCE}}
-
-⚠️ Common mistake: `hash_range_inclusive` replaces the ENTIRE range. Every line from the first anchor through the second anchor is deleted and replaced with `content_lines`. Do not include "context" or "surrounding" lines in `content_lines` — they are outside the range and will be preserved automatically.
-
-Wrong: To replace lines 2-3 in this function:
-```
-function greet() {
-  const x = 1;
-  return x;
-}
-```
-A model might write:
-```json
-{ "content_lines": ["  const y = 2;", "  return y;", "}"], "hash_range_inclusive": ["X", "Y"] }
-This produces `function greet() {\n  const y = 2;\n  return y;\n}\n}` — the `}` appears twice because it was already on line 4 (outside the range) AND in `content_lines`.
-
-Right: Only include the new lines that belong in the range:
-```json
-{ "content_lines": ["  const y = 2;", "  return y;"], "hash_range_inclusive": ["X", "Y"] }
-The `}` on line 4 is outside the range and stays in place.
-
-Error recovery:
-- `[E_STALE_ANCHOR]` — the anchored line's content changed since the last read. Call `read` to get fresh anchors, then copy the 3-char HASH of the start and end of the range you are replacing into `hash_range_inclusive` and retry. (Staleness is per-line: editing or appending lines does not invalidate anchors for lines whose content is unchanged, so anchors for untouched regions stay valid across edits.)
-- `[E_BAD_REF]` — malformed HASH. Re-read and try again.
-- `[E_BAD_OP]` — invalid operation (e.g. start line > end line).
-- `[E_BAD_SHAPE]` — malformed request or change item (missing fields, wrong types, unknown fields).
-- `[E_LEGACY_SHAPE]` — old `oldText`/`newText` or `old_text`/`new_text` format detected. Use `{content_lines, hash_range_inclusive}` instead.
-- `[E_EDIT_CONFLICT]` — two changes overlap on the same line range. Make changes non-overlapping.
-- `[E_AMBIGUOUS_ANCHOR]` — hash collision. Call `read` to get fresh anchors.
-- `[E_BARE_HASH_PREFIX]` — a `content_lines` entry starts with `HASH│`. Remove the hash prefix; keep only the literal line content that appears after `│` in `read` output. `content_lines` uses file content only, `hash_range_inclusive` uses hash anchors.
-- `[E_INVALID_PATCH]` — a `content_lines` entry matches the diff preview's `+HASH│…` addition-row form. Use literal file content. (Plain `+`/`-` lines are not rejected — they are written literally.)
-- `[E_WOULD_EMPTY]` — edit would empty a non-empty file.
-- `[E_FILE_TOO_LARGE]` — file exceeds the 1,000,000-line edit limit. Use `write` or a non-line-based approach for very large files.
-
-**Undo:** If a replace produced incorrect results, call `undo_last_replace` with the file path to revert the last replace. The tool reports how many lines were removed and restored. After undoing, call `read` to get fresh anchors for a corrected replace.