pi-hashline-edit-pro 0.3.2 → 0.3.4

package/README.md

@@ -1,8 +1,8 @@
 # pi-hashline-edit-pro
 
-A [pi-coding-agent](https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent) extension that replaces the built-in `read` and `edit` tools with a hash-anchored line-editing workflow. **Strict semantics** — no silent relocation, no autocorrection, no fuzzy fallback. **Higher-entropy anchors** — `#`-prefixed 4-character content hashes over a 64-character URL-safe base64 alphabet (24 bits / 16 777 216 buckets) so birthday-paradox collisions are effectively zero in any realistic file.
+A [pi-coding-agent](https://github.com/badlogic/pi-mono/tree/main/packages/coding-agent) extension that replaces the built-in `read` and `edit` tools with a hash-anchored line-editing workflow. Strict semantics, no silent relocation, no autocorrection, no fuzzy fallback. 4-character content hashes over a 64-character URL-safe base64 alphabet give 24 bits of entropy per anchor, so collisions are effectively zero in any realistic file.
 
-This is a fork of [pi-hashline-edit](https://github.com/RimuruW/pi-hashline-edit) by RimuruW. The strict-semantics policy is unchanged. This fork extends the upstream design in two compounding ways: a 4-character hash length and an occurrence-aware discriminator that makes identical content at different positions hash to different values.
+Fork of [pi-hashline-edit](https://github.com/RimuruW/pi-hashline-edit) by RimuruW. The strict-semantics policy is unchanged. This fork extends the upstream design in two ways: a 4-character hash length and an occurrence-aware discriminator that makes identical content at different positions hash to different values.
 
 Every line returned by `read` carries a short content hash. Edits reference those hashes instead of raw text, so the tool can detect stale context and reject outdated changes before they reach the file.
 
@@ -10,9 +10,9 @@ Every line returned by `read` carries a short content hash. Edits reference thos
 
 The original uses 2-character hashes of a 16-character alphabet, with the hash being a pure function of line content. That's 8 bits / 256 buckets, and two byte-identical lines (e.g. repeated `import` statements, repeated `}`) always share a hash because the hash is `xxHash32(content)`.
 
-This fork makes **two** changes that compound:
+This fork makes two changes that compound:
 
-1. **Bump hash length to 4 characters** of the 64-char URL-safe base64 alphabet → 24 bits / 16 777 216 buckets. Birthday-paradox collisions are effectively nullified for any realistic file.
+1. **Bump hash length to 4 characters** of the 64-char URL-safe base64 alphabet. That gives 24 bits / 16 777 216 buckets. Birthday-paradox collisions are effectively nullified for any realistic file.
 2. **Make the hash occurrence-aware.** The hash for line N is `xxHash32("C{occurrence}:{content}")` where `occurrence` is the running count of that content string earlier in the file. Symbol-only lines use `"S{lineNumber}"` as the discriminator. Two `import {...}` statements at different positions now hash to different values, so the model can target a specific occurrence without resorting to `offset` + a small `limit` window.
 
 ## Installation
@@ -27,9 +27,9 @@ pi install /path/to/pi-hashline-edit-pro
 
 ## How It Works
 
-### `read` — tagged line output
+### `read` -- tagged line output
 
-Text files are returned with a `#HASH:content` prefix on every line. The line number is no longer part of the wire format — only the `#`-prefixed 4-character hash followed by the line content. Example output for the source below; the hashes are the real xxHash-derived values for the file content shown:
+Text files are returned with a `HASH|content` prefix on every line. The line number is not part of the wire format, only the 4-character hash followed by the `|` separator and the line content. Example output for the source below:
 
 ```js
 function hello() {
@@ -40,29 +40,29 @@ function hello() {
 would be returned as:
 
 ```text
-#0qH3:function hello() {
-#szJr:  console.log("world");
-#_zlP:}
+0qH3|function hello() {
+szJr|  console.log("world");
+_zlP|}
 ```
 
-- `HASH` — `#`-prefixed 4-character content hash from the URL-safe base64 alphabet `A-Za-z0-9-_` (e.g. `#aB3x`).
+- `HASH` is a 4-character content hash from the URL-safe base64 alphabet `A-Za-z0-9-_` (e.g. `aB3x`).
 
 Optional parameters:
 
-- `offset` — start reading from this line number (1-indexed).
-- `limit` — maximum number of lines to return.
+- `offset` -- start reading from this line number (1-indexed).
+- `limit` -- maximum number of lines to return.
 
 Images (JPEG, PNG, GIF, WebP) are passed through as attachments and do not participate in the hashline protocol. Binary and directory paths are rejected with a descriptive error. Empty files return an advisory suggesting `prepend`/`append` instead of a synthetic anchor.
 
-### `edit` — hash-anchored modifications
+### `edit` -- hash-anchored modifications
 
-Edits use the `#HASH:content` anchors from `read` output to target lines precisely:
+Edits use the `HASH|content` anchors from `read` output to target lines precisely:
 
 ```json
 {
   "path": "src/main.ts",
   "edits": [
-    { "op": "replace", "start": "#ve7o", "end": "#ve7o", "lines": ["  console.log('hashline');"] }
+    { "op": "replace", "start": "ve7o", "end": "ve7o", "lines": ["  console.log('hashline');"] }
   ]
 }
 ```
@@ -73,54 +73,55 @@ Edits use the `#HASH:content` anchors from `read` output to target lines precise
 | `append` | Insert lines after `pos`. Omit `pos` to append at EOF. | `pos` optional, `lines` |
 | `prepend` | Insert lines before `pos`. Omit `pos` to prepend at BOF. | `pos` optional, `lines` |
 
-- **Request structure validation.** The request envelope (path, edits, returnMode, returnRanges) and individual edit items are validated before any file I/O. Unknown fields, missing required fields, invalid types, and malformed anchors are rejected with `[E_BAD_SHAPE]` or `[E_BAD_OP]`. This catches structural errors early with actionable messages.
+- **Request structure validation.** The request envelope (path, edits, returnMode, returnRanges) and individual edit items are validated before any file I/O. Unknown fields, missing required fields, invalid types, and malformed anchors are rejected with `[E_BAD_SHAPE]` or `[E_BAD_OP]`.
 - **Legacy dialect rejected.** The native top-level `oldText`/`newText` (and `old_text`/`new_text`) dialect and `op: "replace_text"` are rejected with `[E_LEGACY_SHAPE]`. The error message tells the model to call `read` first and send `{op:"replace", start:"<HASH>", end:"<HASH>", lines:[...]}` (or `append`/`prepend` with `pos`).
 
 All edits in a single call validate against the same pre-edit snapshot and apply bottom-up, so line numbers stay consistent across operations.
 
 ### Chained edits
 
-After a successful edit, the result text contains an `--- Anchors ---` block with fresh `#HASH:content` references for the changed region. These can be used directly in the next `edit` call on the same file without a full re-read, provided the next edit targets the same or nearby lines. For distant changes, use `read` first.
+After a successful edit, the result text contains an `--- Anchors ---` block with fresh `HASH|content` references for the changed region. These can be used directly in the next `edit` call on the same file without a full re-read, provided the next edit targets the same or nearby lines. For distant changes, use `read` first.
 
 ### Auto-read after write
 
-After a successful `write`, the extension automatically reads the file and appends a `--- Auto-read (hashline anchors) ---` block to the result. This gives the model immediate `#HASH:content` anchors for the newly written file without requiring a separate `read` call. The workflow becomes:
+After a successful `write`, the extension automatically reads the file and appends a `--- Auto-read (hashline anchors) ---` block to the result. This gives the model immediate `HASH|content` anchors for the newly written file without requiring a separate `read` call. The workflow becomes:
 
-1. `write` a file → result includes hashline anchors
+1. `write` a file, result includes hashline anchors
 2. `edit` using those anchors directly
 
 For large files (>2000 lines), the auto-read output is truncated with a pagination hint. Use `read` with `offset` to see more.
+
 ### Diff for the host
 
-The post-edit diff (with `+`/`-` markers and new `#HASH:content` anchors) is exposed to the host UI via `details.diff`. It is intentionally **not** in the LLM-visible text — the model only needs the fresh anchors in `text` to chain follow-up edits, and re-emitting the diff would cost extra tokens.
+The post-edit diff (with `+`/`-` markers and new `HASH|content` anchors) is exposed to the host UI via `details.diff`. It is intentionally not in the LLM-visible text. The model only needs the fresh anchors in `text` to chain follow-up edits, and re-emitting the diff would cost extra tokens.
 
 ## Design Decisions
 
-- **Stale anchors fail.** A hash mismatch means the file has changed since the last `read`. The error includes fresh `>>> #HASH:content` lines for the affected region; the model copies the HASH portion and retries.
+- **Stale anchors fail.** A hash mismatch means the file has changed since the last `read`. The error includes fresh `>>> HASH|content` lines for the affected region. The model copies the HASH portion and retries.
 - **No fallback relocation.** Mismatched anchors are never silently relocated to a "close enough" line. This trades convenience for correctness.
-- **Strict patch content.** If `lines` contains `+#HASH:` display prefixes (or `-N   ` diff rows), the edit is rejected with `[E_INVALID_PATCH]`. Bare `#HASH:` content (the first 6 chars of a `lines` entry looking like `#` + 4 base64 chars + `:`) is also rejected with `[E_BARE_HASH_PREFIX]` — issue #24. 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; the model should rephrase the line (quote it, escape the colon, or use a different identifier shape) and retry.
+- **Strict patch content.** If `lines` contains `+HASH|` display prefixes (or `-N   ` diff rows), the edit is rejected with `[E_INVALID_PATCH]`. Bare `HASH|` content (the first 5 chars of a `lines` entry looking like 4 base64 chars + `|`) is also 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.
 - **Legacy dialect rejected.** The native top-level `oldText`/`newText` (and `old_text`/`new_text`) dialect and `op: "replace_text"` are rejected with `[E_LEGACY_SHAPE]`. The error message tells the model to call `read` first and send `{op:"replace", start:"<HASH>", end:"<HASH>", lines:[...]}` (or `append`/`prepend` with `pos`).
 - **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.
 
 ## Hashing
 
-Hashes are computed with [xxhashjs](https://github.com/pierrec/js-xxhash) (xxHash32), then mapped to a `#`-prefixed 4-character string from the URL-safe base64 alphabet `A-Za-z0-9-_` — 64 distinct characters, 6 bits per position, **24 bits of entropy per anchor**.
+Hashes are computed with [xxhashjs](https://github.com/pierrec/js-xxhash) (xxHash32), then mapped to a 4-character string from the URL-safe base64 alphabet `A-Za-z0-9-_`. That's 64 distinct characters, 6 bits per position, 24 bits of entropy per anchor.
 
-The alphabet is sized for an LLM consumer. The model tokenizes — it doesn't squint at pixel glyphs — so the human-readability heuristics used by smaller hand-curated alphabets (no G/L/I/O because they look like digits, no vowels so the hash doesn't accidentally spell a word, no hex digits so it can't be confused with `0xFF`) don't apply. The full 64 chars give maximum entropy per character, with case and digits included.
+The alphabet is sized for an LLM consumer. The model tokenizes, it doesn't squint at pixel glyphs, so the human-readability heuristics used by smaller hand-curated alphabets (no G/L/I/O because they look like digits, no vowels so the hash doesn't accidentally spell a word, no hex digits so it can't be confused with `0xFF`) don't apply. The full 64 chars give maximum entropy per character, with case and digits included.
 
-Hashes are **occurrence-aware**: a discriminator prefix is mixed into the xxHash input before the line content. Symbol-only lines (lone `}`, etc.) use `S{lineNumber}` as the discriminator; content lines use `C{occurrence}` where `occurrence` is the running count of that canonical content earlier in the file. This way:
+Hashes are occurrence-aware: a discriminator prefix is mixed into the xxHash input before the line content. Symbol-only lines (lone `}`, etc.) use `S{lineNumber}` as the discriminator; content lines use `C{occurrence}` where `occurrence` is the running count of that canonical content earlier in the file. This way:
 
 - `}` on line 5 and `}` on line 17 hash differently (different `S{...}` prefix).
-- `import { foo } from 'bar';` on line 3 and the same string on line 47 hash differently (different `C{...}` prefix — 1 vs 2).
+- `import { foo } from 'bar';` on line 3 and the same string on line 47 hash differently (different `C{...}` prefix, 1 vs 2).
 
 The runtime always precomputes the full per-line hash array for a file via `computeLineHashes(content)`, then looks up by line number during validation and during `read` / `edit` response formatting. There is no per-line recomputation that could disagree with what the model saw in its last read.
 
 `HASH_LENGTH` and `HASH_ALPHABET` are constants at the top of `src/hashline/hash.ts`; bump the length to 5 if you ever need even more entropy.
 
-### Trade-off: the bare-prefix detector
+### Bare-prefix detector
 
-With the `#` prefix format, the bare-prefix detector regex `^\s*#[A-Za-z0-9_-]{4}:` is highly specific — it only matches lines starting with `#` followed by exactly 4 base64 chars and `:`. This eliminates false positives from common code patterns like `init:`, `data:`, `else:`, etc. that plagued the old 4-char-only detector. The detector rejects edit lines matching this pattern with `[E_BARE_HASH_PREFIX]` to prevent the model from accidentally pasting hash anchors into file content.
+With the `|` delimiter format, the bare-prefix detector regex `^\s*[A-Za-z0-9_-]{4}|` is highly specific. It only matches lines starting with exactly 4 base64 chars and `|`. This eliminates false positives from common code patterns like `init:`, `data:`, `else:`, etc. The detector rejects edit lines matching this pattern with `[E_BARE_HASH_PREFIX]` to prevent the model from accidentally pasting hash anchors into file content.
 
 ## Development
 
@@ -135,8 +136,8 @@ Set `PI_HASHLINE_DEBUG=1` to show an "active" notification at session start.
 
 ## Credits
 
-- [RimuruW](https://github.com/RimuruW) — original `pi-hashline-edit` and the strict-semantics policy
-- [can1357](https://github.com/can1357) — original [oh-my-pi](https://github.com/can1357/oh-my-pi) implementation and the hashline concept
+- [RimuruW](https://github.com/RimuruW) -- original `pi-hashline-edit` and the strict-semantics policy
+- [can1357](https://github.com/can1357) -- original [oh-my-pi](https://github.com/can1357/oh-my-pi) implementation and the hashline concept
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-hashline-edit-pro",
-  "version": "0.3.2",
+  "version": "0.3.4",
   "description": "Strict hashline read/edit tool override for pi-coding-agent with hash-anchored edits (4-char, 24-bit)",
   "repository": {
     "type": "git",

package/prompts/edit-snippet.md

@@ -1 +1 @@
-Edit a text file via #HASH anchors from read
+Edit a text file via HASH anchors from read

package/prompts/edit.md

@@ -1,8 +1,8 @@
-Patch a text file using `#HASH` anchors copied verbatim from `read`.
+Patch a text file using `HASH` anchors copied verbatim from `read`.
 
 Put all operations on one file in a single `edit` call. Stack every region into the `edits` 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, so you do not adjust anchors for line-number shifts between edits in the same call.
 
-Anchors are `#` + 4 characters (e.g. `#aB3x`), alphabet `A-Za-z0-9-_`. The wire format for `start`/`end`/`pos` is the anchor only — no line number, no trailing content, no line content.
+Anchors are 4 characters (e.g. `aB3x`), alphabet `A-Za-z0-9-_`. The wire format for `start`/`end`/`pos` is the anchor only — no line number, no trailing content, no line content.
 
 Ops:
 - `replace` — replace the inclusive range `start`..`end`. Both anchors are required. Single line: `start = end`. To delete a range, use `lines: []`. Do NOT use the `pos` field on `replace`; use `start`.
@@ -14,14 +14,14 @@ Examples:
 1. Single line replace:
 ```json
 { "path": "src/main.ts", "edits": [
-  { "op": "replace", "start": "#MQXV", "end": "#MQXV", "lines": ["const x = 1;"] }
+  { "op": "replace", "start": "MQXV", "end": "MQXV", "lines": ["const x = 1;"] }
 ] }
 ```
 
 2. Range replace (3 lines → 3 new lines):
 ```json
 { "path": "src/main.ts", "edits": [
-  { "op": "replace", "start": "#ZPMQ", "end": "#VRWS", "lines": [
+  { "op": "replace", "start": "ZPMQ", "end": "VRWS", "lines": [
     "function greet(name) {",
     "  return `Hello, ${name}`;",
     "}"
@@ -32,27 +32,27 @@ Examples:
 3. Multiple regions in one call (delete two non-adjacent ranges, insert before a third anchor):
 ```json
 { "path": "src/server.ts", "edits": [
-  { "op": "replace", "start": "#aB3x", "end": "#xY7q", "lines": [] },
-  { "op": "replace", "start": "#MQXV", "end": "#ZPMQ", "lines": [] },
-  { "op": "prepend", "pos": "#VRWS", "lines": ["// inserted before VRWS"] }
+  { "op": "replace", "start": "aB3x", "end": "xY7q", "lines": [] },
+  { "op": "replace", "start": "MQXV", "end": "ZPMQ", "lines": [] },
+  { "op": "prepend", "pos": "VRWS", "lines": ["// inserted before VRWS"] }
 ] }
 ```
 
 Rules:
 - `replace` requires both `start` and `end`. A single-line replace is `start=X, end=X`. To replace more than one line, set `end` to a different line's anchor.
-- `start`, `end`, `pos` are HASH anchors only (e.g. `#aB3x`). Other forms are rejected with `[E_BAD_REF]`.
-- `lines` is literal file content. No `#HASH:` prefix, no leading `+`/`-` (those are read/diff metadata, not file content). Lines starting with `#` + 4 base64 chars + `:` are checked; if detected, the edit is rejected with `[E_BARE_HASH_PREFIX]`. For `.py` files, this becomes a `[W_BARE_HASH_PREFIX]` warning instead (Python syntax like `else:`, `except:` triggers the detector).
+- `start`, `end`, `pos` are HASH anchors only (e.g. `aB3x`). Other forms are rejected with `[E_BAD_REF]`.
+- `lines` is literal file content. No `HASH│` prefix, no leading `+`/`-` (those are read/diff metadata, not file content). Lines starting with 4 base64 chars + `│` are checked; if detected, the edit is rejected with `[E_BARE_HASH_PREFIX]`. For `.py` files, this becomes a `[W_BARE_HASH_PREFIX]` warning instead (Python syntax like `else:`, `except:` triggers the detector).
 - Copy anchors from the most recent `read` of the file. Do not guess or construct them.
 - All edits in one call must be non-conflicting. The runtime rejects with `[E_EDIT_CONFLICT]` if: two `replace` ranges overlap; two `append`/`prepend` target the same insertion boundary (e.g. two EOF appends on a newline-terminated file); or an `append`/`prepend` falls inside a `replace` range in the same call. Fix: merge into one, use different boundaries, or split into a follow-up `edit` call.
 - If `lines` matches the current content byte-for-byte, the edit is classified as `Classification: noop` (file unchanged, not an error).
 
-On success (`changed` mode, default), the response text contains an `--- Anchors ---` block with fresh `#HASH:content` for the changed region (2 lines of context, capped at ~12 lines / 50 KB). Use those for nearby follow-up edits instead of re-reading. If the response says `Anchors omitted; use read for subsequent edits`, the region was too large — call `read` again. For distant follow-ups, or on any error, call `read` again. `full` and `ranges` modes put previews in `details`; the model only needs what's in the text.
+On success (`changed` mode, default), the response text contains an `--- Anchors ---` block with fresh `HASH│content` for the changed region (2 lines of context, capped at ~12 lines / 50 KB). Use those for nearby follow-up edits instead of re-reading. If the response says `Anchors omitted; use read for subsequent edits`, the region was too large — call `read` again. For distant follow-ups, or on any error, call `read` again. `full` and `ranges` modes put previews in `details`; the model only needs what's in the text.
 
-Errors are text starting with a bracketed code (e.g. `[E_BAD_SHAPE]`, `[E_STALE_ANCHOR]`, `[E_BAD_OP]`, `[E_INVALID_PATCH]`, `[E_LEGACY_SHAPE]`, `[E_EDIT_CONFLICT]`, `[E_BAD_REF]`, `[E_AMBIGUOUS_ANCHOR]`, `[E_BARE_HASH_PREFIX]`, `[E_WOULD_EMPTY]`). The message tells you what to retry; stale-anchor errors include `>>> #HASH:content` lines, ready to copy.
+Errors are text starting with a bracketed code (e.g. `[E_BAD_SHAPE]`, `[E_STALE_ANCHOR]`, `[E_BAD_OP]`, `[E_INVALID_PATCH]`, `[E_LEGACY_SHAPE]`, `[E_EDIT_CONFLICT]`, `[E_BAD_REF]`, `[E_AMBIGUOUS_ANCHOR]`, `[E_BARE_HASH_PREFIX]`, `[E_WOULD_EMPTY]`). The message tells you what to retry; stale-anchor errors include `>>> HASH│content` lines, ready to copy.
 
 The legacy `oldText`/`newText` shape (top-level or as `op: "replace_text"`) is rejected with `[E_LEGACY_SHAPE]`. Use hash-anchored edits instead.
 
 Auto-read after write:
-- After a successful `write`, the result includes a `--- Auto-read (hashline anchors) ---` block with `#HASH:content` for the written file.
+- After a successful `write`, the result includes a `--- Auto-read (hashline anchors) ---` block with `HASH│content` for the written file.
 - Use those anchors directly for `edit` calls without a separate `read`.
 - This enables a seamless write → edit workflow with no extra tool calls.

package/prompts/read-guidelines.md

@@ -1,3 +1,3 @@
 - Use read before edit when you do not have current HASH anchors for the file.
-- Copy exactly the HASH (the `#` + 4 characters before the `:`); never include the `:` or line content in `pos`/`end`.
-- A HASH always starts with `#`; the body may contain `-` as a normal alphabet character.
+- Copy exactly the HASH (the 4 characters before the `│`); never include the `│` or line content in `pos`/`end`.
+- A HASH may contain `-` as a normal alphabet character.

package/prompts/read-snippet.md

@@ -1 +1 @@
-Read a text file with #HASH:content anchors for edit (copy the #HASH into `start`/`end`/`pos`)
+Read a text file with HASH│content anchors for edit (copy the HASH into `start`/`end`/`pos`)

package/prompts/read.md

@@ -1,12 +1,12 @@
-Read a text file. Each line is returned as `#HASH:content`. The HASH starts with `#` followed by 4 base64 characters before the first `:`; the content after is the line verbatim. Pass the HASH (e.g. `#aB3x`) into `edit`'s `start`/`end` (for `replace`) or `pos` (for `append`/`prepend`) — never include the line content.
+Read a text file. Each line is returned as `HASH│content`. The HASH is 4 base64 characters; the content after the `│` separator is the line verbatim. Pass the HASH (e.g. `aB3x`) into `edit`'s `start`/`end` (for `replace`) or `pos` (for `append`/`prepend`) — never include the line content.
 
 HASH shape:
-- 5 characters total: `#` prefix + 4 characters from the URL-safe base64 alphabet `A-Za-z0-9-_` (e.g. `#aB3x`, `#4yN-`, `#-qkl`).
+- 4 characters from the URL-safe base64 alphabet `A-Za-z0-9-_` (e.g. `aB3x`, `4yN-`, `-qkl`).
 - The line number is not part of the wire format. Anchor by HASH, never by reading a line number off the rendered output.
 
 HASH → edit:
-- Copy the full 5-character HASH (including the `#` prefix). Use that HASH as `start` or `end` (for `replace`) or `pos` (for `append`/`prepend`) in the next `edit` call.
-- Do not include the `:`, the line content, or surrounding whitespace. The wire format for `start`/`end`/`pos` is the HASH only.
+- Copy the full 4-character HASH. Use that HASH as `start` or `end` (for `replace`) or `pos` (for `append`/`prepend`) in the next `edit` call.
+- Do not include the `│`, the line content, or surrounding whitespace. The wire format for `start`/`end`/`pos` is the HASH only.
 
 Pagination:
 - Large files return a truncated preview with a `nextOffset` line. Call `read` again with `offset=nextOffset` to continue.
@@ -14,15 +14,15 @@ Pagination:
 - Empty files return an advisory suggesting `prepend`/`append` instead of a synthetic anchor.
 
 Error recovery:
-- `[E_STALE_ANCHOR]` — the file changed since your last read. The error includes fresh `>>> #HASH:content` lines; copy the HASH portion (the `#` + 4 chars before `:`) and retry.
-- `[E_BAD_REF]` — malformed HASH. Re-read and try again with a valid HASH anchor (e.g. `#aB3x`).
+- `[E_STALE_ANCHOR]` — the file changed since your last read. The error includes fresh `>>> HASH│content` lines; copy the HASH portion (the 4 chars before `│`) and retry.
+- `[E_BAD_REF]` — malformed HASH. Re-read and try again with a valid HASH anchor (e.g. `aB3x`).
 
 File kinds:
-- Text files are returned as `#HASH:content` lines.
+- Text files are returned as `HASH│content` lines.
 - Images (JPEG, PNG, GIF, WebP) are returned as visual attachments; the HASH-line protocol does not apply.
 - Binary files and directories are rejected with a descriptive error.
 
 Auto-read after write:
-- After a successful `write`, the result includes a `--- Auto-read (hashline anchors) ---` block with `#HASH:content` for the written file.
+- After a successful `write`, the result includes a `--- Auto-read (hashline anchors) ---` block with `HASH│content` for the written file.
 - Use those anchors directly for `edit` calls without a separate `read`.
 - The auto-read output follows the same format and rules as `read` output.

package/src/edit-diff.ts

@@ -36,9 +36,9 @@ function formatDiffPreviewLine(
   hash: string | undefined,
 ): string {
   if (hash === undefined) {
-    return `${prefix}${" ".repeat(ANCHOR_LENGTH)}:${line}`;
+    return `${prefix}${" ".repeat(ANCHOR_LENGTH)}│${line}`;
   }
-  return `${prefix}${hash}:${line}`;
+  return `${prefix}${hash}│${line}`;
 }
 
 export function generateDiffString(

package/src/edit-response.ts

@@ -170,7 +170,7 @@ function truncateOutlineEntry(text: string, max = 88): string {
 function collectOutlineEntries(previewText: string): string[] {
 	const structural: string[] = [];
 	for (const line of previewText.split("\n")) {
-		const match = line.match(/^\s*#([A-Za-z0-9_\-]{4}):(.*)$/);
+		const match = line.match(/^\s*([A-Za-z0-9_\-]{4})│(.*)$/);
 		if (!match) continue;
 		const content = match[2]!.trim();
 		if (content.length === 0) continue;
@@ -226,7 +226,7 @@ function formatRequestedRangePreviews(
 			},
 			precomputedHashes,
 		);
-		const hasReturnedLines = /^\s*#[A-Za-z0-9_\-]{4}:/m.test(preview.text);
+		const hasReturnedLines = /^\s*[A-Za-z0-9_\-]{4}│/m.test(preview.text);
 		const actualEnd = hasReturnedLines
 			? preview.nextOffset !== undefined
 				? preview.nextOffset - 1

package/src/edit.ts

@@ -61,7 +61,7 @@ function stringEnumSchema<const Values extends readonly string[]>(
 
 const hashlineEditLinesSchema = Type.Array(Type.String(), {
 	description:
-		"replacement content, one array entry per line, no HASH: prefix",
+		"replacement content, one array entry per line, no HASH| prefix",
 });
 
 const returnRangeSchema = Type.Object(
@@ -92,19 +92,19 @@ const hashlineEditItemSchema = Type.Object(
 		start: Type.Optional(
 			Type.String({
 				description:
-					"required range-start anchor for op \"replace\" (hash anchor like \"#aB3x\" copied from read output); no content may follow the anchor",
+					"required range-start anchor for op \"replace\" (hash anchor like \"aB3x\" copied from read output); no content may follow the anchor",
 			}),
 		),
 		end: Type.Optional(
 			Type.String({
 				description:
-					"required range-end anchor for op \"replace\" (hash anchor like \"#aB3x\"). To replace a single line, set start = end = the line's anchor",
+					"required range-end anchor for op \"replace\" (hash anchor like \"aB3x\"). To replace a single line, set start = end = the line's anchor",
 			}),
 		),
 		pos: Type.Optional(
 			Type.String({
 				description:
-					"anchor for op \"append\" or \"prepend\" (hash anchor like \"#aB3x\"). Omit for file-boundary insertion (EOF/BOF).",
+					"anchor for op \"append\" or \"prepend\" (hash anchor like \"aB3x\"). Omit for file-boundary insertion (EOF/BOF).",				
 			}),
 		),
 		lines: Type.Optional(hashlineEditLinesSchema),

package/src/hashline/apply.ts

@@ -510,7 +510,7 @@ export function formatHashlineRegion(
 		);
 	}
 	return lines
-		.map((line, index) => `${hashes[index]}:${line}`)
+		.map((line, index) => `${hashes[index]}│${line}`)
 		.join("\n");
 }
 

package/src/hashline/hash.ts

@@ -4,9 +4,9 @@ import * as XXH from "xxhashjs";
 
 export const HASH_LENGTH = 4;
 
-export const HASH_PREFIX = "#";
+export const HASH_PREFIX = "";
 
-export const ANCHOR_LENGTH = HASH_PREFIX.length + HASH_LENGTH;
+export const ANCHOR_LENGTH = HASH_LENGTH;
 
 const HASH_ALPHABET =
 	"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
@@ -15,7 +15,6 @@ const HASH_ALPHABET_MASK = (1 << HASH_ALPHABET_BITS) - 1;
 const HASH_ALPHABET_REGEX_SAFE = HASH_ALPHABET.replace(/-/g, "\\-");
 const HASH_ALPHABET_RE = new RegExp(`^[${HASH_ALPHABET_REGEX_SAFE}]+$`);
 export const HASH_CHARS_CLASS = `${HASH_PREFIX}[${HASH_ALPHABET_REGEX_SAFE}]{${HASH_LENGTH}}`;
-
 function hashToString(h: number): string {
 	const totalBits = HASH_LENGTH * HASH_ALPHABET_BITS;
 	const shift = 32 - totalBits;
@@ -28,18 +27,18 @@ function hashToString(h: number): string {
 					HASH_ALPHABET_MASK
 			]!;
 	}
-	return HASH_PREFIX + out;
+	return out;
 }
 
 export const HASHLINE_PREFIX_RE = new RegExp(
-	`^\\s*(?:>>>|>>)?\\s*${HASH_CHARS_CLASS}:`,
+	`^\\s*(?:>>>|>>)?\\s*${HASH_CHARS_CLASS}│`,
 );
 export const HASHLINE_PREFIX_PLUS_RE = new RegExp(
-	`^\\+\\s*${HASH_CHARS_CLASS}:`,
+	`^\\+\\s*${HASH_CHARS_CLASS}│`,
 );
 export const DIFF_MINUS_RE = /^-\s*\d+\s{4}/;
 
-export const HASHLINE_BARE_PREFIX_RE = new RegExp(`^\\s*(${HASH_CHARS_CLASS}):`);
+export const HASHLINE_BARE_PREFIX_RE = new RegExp(`^\\s*(${HASH_CHARS_CLASS})│`);
 
 const RE_SIGNIFICANT = /[\p{L}\p{N}]/u;
 

package/src/hashline/parse.ts

@@ -1,7 +1,6 @@
 
 import {
 	ANCHOR_LENGTH,
-	HASH_PREFIX,
 	HASH_ALPHABET_RE,
 	HASH_CHARS_CLASS,
 	HASHLINE_PREFIX_PLUS_RE,
@@ -16,14 +15,14 @@ function diagnoseHashRef(ref: string): string {
 	const trimmed = ref.trim();
 
 	if (!trimmed.length) {
-		return `[E_BAD_REF] Invalid anchor. Expected a hash anchor like "#aB3x" (prefix "#" + 4 base64 chars).`;
+		return `[E_BAD_REF] Invalid anchor. Expected a 4-character base64 anchor (e.g. \"aB3x\").`;
 	}
 
-	if (/^\d+\s*#/.test(trimmed)) {
-		return `[E_BAD_REF] Invalid anchor. Use the hash alone (e.g. "#aB3x") — no line numbers or trailing content.`;
+	if (/^\d+/.test(trimmed)) {
+		return `[E_BAD_REF] Invalid anchor. Use the hash alone (e.g. \"aB3x\") — no line numbers or trailing content.`;
 	}
 
-	return `[E_BAD_REF] Invalid anchor "${trimmed}". Expected a hash anchor like "#aB3x".`;
+	return `[E_BAD_REF] Invalid anchor \"${trimmed}\". Expected a 4-character base64 anchor (e.g. \"aB3x\").`;
 }
 
 function parseAnchorRef(ref: string): Anchor {
@@ -31,8 +30,7 @@ function parseAnchorRef(ref: string): Anchor {
 
 	if (
 		trimmed.length === ANCHOR_LENGTH &&
-		trimmed.startsWith(HASH_PREFIX) &&
-		HASH_ALPHABET_RE.test(trimmed.slice(HASH_PREFIX.length))
+		HASH_ALPHABET_RE.test(trimmed)
 	) {
 		return { hash: trimmed };
 	}
@@ -51,7 +49,7 @@ function assertNoDisplayPrefixes(lines: string[]): void {
 			DIFF_MINUS_RE.test(line)
 		) {
 			throw new Error(
-			`[E_INVALID_PATCH] "lines" must contain literal file content, not HASH: or diff prefixes. Offending line: ${JSON.stringify(line)}`
+			`[E_INVALID_PATCH] \"lines\" must contain literal file content, not HASH| or diff prefixes. Offending line: ${JSON.stringify(line)}`
 			);
 		}
 	}

package/src/hashline/resolve.ts

@@ -107,12 +107,12 @@ export function formatMismatchError(
 			const lines = sample
 				.map((line) => {
 					const content = fileLines[line - 1] ?? "";
-					return `    ${line}: ${fileHashes[line - 1]}:${content}`;
+					return `    ${line}: ${fileHashes[line - 1]}│${content}`;
 				})
 				.join("\n");
-			out.push(
-				`  Hash "${m.ref.hash}" matches lines ${sample.join(", ")}${more}.\n${lines}`,
-			);
+				out.push(
+					`  Hash "${m.ref.hash}" matches lines ${sample.join(", ")}${more}.\n${lines}`,
+				);
 		}
 	}
 
@@ -120,7 +120,7 @@ export function formatMismatchError(
 	out.push("Current state (first lines):");
 	const sampleSize = Math.min(fileLines.length, 5);
 	for (let i = 0; i < sampleSize; i++) {
-		out.push(`>>> ${fileHashes[i]}:${fileLines[i]}`);
+		out.push(`>>> ${fileHashes[i]}│${fileLines[i]}`);
 	}
 	if (fileLines.length > sampleSize) {
 		out.push(`... ${fileLines.length - sampleSize} more.`);
@@ -284,7 +284,7 @@ export function assertNoBareHashPrefixLines(
 	const fileHashSet = new Set(fileHashes);
 	const matched = suspects.filter((s) => fileHashSet.has(s.hash));
 	const matchedCount = matched.length;
-	const exampleLine = `${suspects[0]!.hash}:${suspects[0]!.line}`;
+	const exampleLine = `${suspects[0]!.hash}│${suspects[0]!.line}`;
 
 	if (isPython) {
 		const hint = matchedCount > 0
@@ -299,7 +299,7 @@ export function assertNoBareHashPrefixLines(
 			: `${matchedCount} match file line hashes — likely a copied hash.`;
 
 	throw new Error(
-		`[E_BARE_HASH_PREFIX] ${suspects.length} edit line(s) start with a hash-like prefix (e.g. ${JSON.stringify(exampleLine)}). ${linesHint} Use literal file content in "lines" — never paste #HASH:content from read output.`
+		`[E_BARE_HASH_PREFIX] ${suspects.length} edit line(s) start with a hash-like prefix (e.g. ${JSON.stringify(exampleLine)}). ${linesHint} Use literal file content in \"lines\" — never paste HASH│content from read output.`
 	);
 }
 
@@ -344,7 +344,7 @@ export function validateAnchorEdits(
 			case "replace": {
 				const startResolved = tryResolve(edit.start);
 				const endResolved = tryResolve(edit.end);
-				if (!startResolved || !endResolved) {
+					if (!startResolved || !endResolved) {
 					continue;
 				}
 				if (startResolved.line > endResolved.line) {