pi-hashline-edit-pro 0.16.6 → 0.16.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-hashline-edit-pro",
-  "version": "0.16.6",
+  "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.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.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/prompts/replace-guidelines.md

@@ -1,7 +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`.

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.