pi-hashline-edit-pro 0.3.0 → 0.3.1

package/README.md

@@ -56,13 +56,13 @@ Images (JPEG, PNG, GIF, WebP) are passed through as attachments and do not parti
 
 ### `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');"] }
   ]
 }
 ```
@@ -80,11 +80,11 @@ All edits in a single call validate against the same pre-edit snapshot and apply
 
 ### 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
 2. `edit` using those anchors directly
@@ -92,13 +92,13 @@ After a successful `write`, the extension automatically reads the file and appen
 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 5 chars of a `lines` entry looking like a 4-char hash followed by `:`) is also rejected with `[E_BARE_HASH_PREFIX]` — issue #24. When the suspect's prefix happens to match a real file-line hash, the error message flags that as strong evidence the model copied a hash 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 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.
 - **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.

package/package.json

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

package/src/hashline/apply.ts

@@ -558,7 +558,7 @@ export function computeAffectedLineRange(params: {
 }
 
 /**
- * Format a list of lines as `HASH:content` rows.
+ * Format a list of lines as `#HASH:content` rows.
  *
  * Used by the read tool's preview and the changed-mode anchor block. The
  * hashes must be the precomputed per-line hashes for the file — see

package/src/hashline/hash.ts

@@ -98,7 +98,7 @@ export const DIFF_MINUS_RE = /^-\s*\d+\s{4}/;
  *
  * This is the partial-hash failure mode from issue #24: the model copies a
  * hash it saw in `read` output into the line content but drops the rest
- * of the rendered `HASH:content` form. The anchor (prefix + HASH_LENGTH chars
+ * of the rendered `#HASH:content` form. The anchor (prefix + HASH_LENGTH chars
  * + ":") is matched by this regex, then `assertNoBareHashPrefixLines` rejects
  * the edit with `[E_BARE_HASH_PREFIX]` so the model gets actionable feedback
  * instead of a silent correctness bug.

package/src/hashline/parse.ts

@@ -63,8 +63,8 @@ function parseAnchorRef(ref: string): Anchor {
 }
 
 /**
- * Parse a hash anchor. Accepts `HASH` (e.g. `"aB3x"`) only. The
- * `HASH:content` disambiguator from earlier versions is gone — the hash
+ * Parse a hash anchor. Accepts `#HASH` (e.g. `"#aB3x"`) only. The
+ * `#HASH:content` disambiguator from earlier versions is gone — the anchor
  * is the entire wire format for `pos` and `end`, and no content may
  * follow it.
  *

package/src/hashline/resolve.ts

@@ -88,7 +88,7 @@ export type HashlineToolEdit = {
  *   - `not_found`: no line in the file has this hash
  *   - `ambiguous`: the hash matches multiple lines (the model must
  *     re-read to disambiguate; the runtime does not accept a
- *     `HASH:content` disambiguator on the wire)
+	 *     `#HASH:content` disambiguator on the wire)
  */
 function resolveAnchor(
 	ref: Anchor,
@@ -332,12 +332,12 @@ function maybeWarnSuspiciousUnicodeEscapePlaceholder(
  * `assertNoDisplayPrefixes`, which rejects the unambiguous `+HASH:` form at
  * the parse stage; this catches the bare `HASH:` form (after optional leading
  * whitespace) at the apply stage. The first 5 characters of every `lines`
- * entry are checked: 4 alphabet characters (A–Z, a–z, 0–9, `-`, `_`)
+ * entry are checked: `#` prefix + 4 alphabet characters (A–Z, a–z, 0–9, `-`, `_`)
  * followed by `:`.
  *
- * Bare `HASH:` prefixes in `lines` are almost always a model mistake — the
+ * Bare `#HASH:` prefixes in `lines` are almost always a model mistake — the
  * model copied the hash prefix from a `read` output but dropped the rest of
- * the rendered `HASH:content` form. We reject with `[E_BARE_HASH_PREFIX]`
+ * the rendered `#HASH:content` form. We reject with `[E_BARE_HASH_PREFIX]`
  * rather than warn, because a stray hash in the file content is a silent
  * correctness bug (the line is written verbatim, no autocorrection) and
  * because the cost of a false positive is small: the model can rephrase the
@@ -346,7 +346,7 @@ function maybeWarnSuspiciousUnicodeEscapePlaceholder(
  *
  * The error message lists the offending lines, the suspect hash prefix for
  * each, and whether any of them collide with a real file-line hash. A
- * collision is a strong signal that the model was reading a `HASH:content`
+ * collision is a strong signal that the model was reading a `#HASH:content`
  * line and copied only the prefix.
  */
 export function assertNoBareHashPrefixLines(
@@ -394,7 +394,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.`
 	);
 }