@yagni-app/code-staging 1.1.4-staging.1386.1 → 1.1.4-staging.1387.1

package/dist/extension/condensedTools.js

@@ -28,6 +28,7 @@ import * as os from "node:os";
 import * as path from "node:path";
 import { createBashToolDefinition, createEditToolDefinition, createFindToolDefinition, createGrepToolDefinition, createLsToolDefinition, createReadToolDefinition, createWriteToolDefinition, getAgentDir, getLanguageFromPath, highlightCode, renderDiff, SettingsManager, } from "@earendil-works/pi-coding-agent";
 import { Container, Text } from "@earendil-works/pi-tui";
+import { logEvent } from "./errorSink.js";
 import { ReadStateTracker, READ_FIRST_ERROR, readIsPartial, readTextOf, STALE_ERROR } from "./fileGuards.js";
 import { isQuiet, kindForTool, ToolRunTracker } from "./toolRuns.js";
 /** Lines of write content shown collapsed (mirrors Claude Code's preview). */
@@ -388,8 +389,23 @@ export function registerCondensedTools(pi, deps = {}) {
                 // nothing — its content is error text, not the file — and must not
                 // clobber a prior good record of the same path.
                 if (name === "read" && target && !isErrorResult(result)) {
-                    const partial = readIsPartial({ path: args.path, offset: args.offset, limit: args.limit }, result.details ?? undefined);
-                    await readState.recordRead(target, cwd, readTextOf(result), partial);
+                    // An image read carries an image part whose "content" is a
+                    // processing note, not the file — never record it (Claude Code
+                    // never stores image reads in readFileState either). The skip
+                    // rides the trail so a later read-first refusal on an image-read
+                    // path is diagnosable instead of confusing.
+                    if (hasImages(result)) {
+                        logEvent({
+                            source: "condensedTools",
+                            level: "info",
+                            event: "read_record_skipped_image",
+                            fields: {},
+                        });
+                    }
+                    else {
+                        const partial = readIsPartial({ path: args.path, offset: args.offset, limit: args.limit }, result.details ?? undefined);
+                        await readState.recordRead(target, cwd, readTextOf(result), partial);
+                    }
                 }
                 else if (name === "write" && target && typeof args.content === "string" && !isErrorResult(result)) {
                     await readState.recordWrite(target, cwd, args.content);

package/dist/extension/fileGuards.d.ts

@@ -9,10 +9,17 @@
  * model has not read in this session, and refuse again when the file
  * changed on disk since that read (mtime, with a content-compare fallback
  * so a spurious timestamp bump — cloud sync, antivirus, `utimes` noise —
- * does not produce a false refusal on a full read). New-file creates and
- * partial reads follow Claude Code exactly: a create needs no prior read;
- * an offset/limit or truncated read does NOT satisfy the read-first
- * requirement (`isPartialView`).
+ * does not produce a false refusal on a full read). New-file creates
+ * follow Claude Code exactly: a create needs no prior read. ANY
+ * successful read — windowed (offset/limit) or truncated — satisfies
+ * read-first, matching Claude Code, whose Read tool never marks a
+ * partial view (its `isPartialView` exists only for auto-injected memory
+ * content that differs from disk, a path this tracker does not record).
+ * The `partial` classification instead selects the staleness strategy:
+ * a full read's record holds the whole file, so a bumped mtime can be
+ * content-compared before refusing; a partial record holds only a slice
+ * (with pi's continuation notice appended), so a bumped mtime refuses
+ * outright — Claude Code's exact stance for offset/limit reads.
  *
  * Fail-open contract: any guard-internal filesystem error that is not one
  * of the two refusals (EACCES, EMFILE, a racing delete, ...) delegates

package/dist/extension/fileGuards.js

@@ -9,10 +9,17 @@
  * model has not read in this session, and refuse again when the file
  * changed on disk since that read (mtime, with a content-compare fallback
  * so a spurious timestamp bump — cloud sync, antivirus, `utimes` noise —
- * does not produce a false refusal on a full read). New-file creates and
- * partial reads follow Claude Code exactly: a create needs no prior read;
- * an offset/limit or truncated read does NOT satisfy the read-first
- * requirement (`isPartialView`).
+ * does not produce a false refusal on a full read). New-file creates
+ * follow Claude Code exactly: a create needs no prior read. ANY
+ * successful read — windowed (offset/limit) or truncated — satisfies
+ * read-first, matching Claude Code, whose Read tool never marks a
+ * partial view (its `isPartialView` exists only for auto-injected memory
+ * content that differs from disk, a path this tracker does not record).
+ * The `partial` classification instead selects the staleness strategy:
+ * a full read's record holds the whole file, so a bumped mtime can be
+ * content-compared before refusing; a partial record holds only a slice
+ * (with pi's continuation notice appended), so a bumped mtime refuses
+ * outright — Claude Code's exact stance for offset/limit reads.
  *
  * Fail-open contract: any guard-internal filesystem error that is not one
  * of the two refusals (EACCES, EMFILE, a racing delete, ...) delegates
@@ -167,38 +174,43 @@ export class ReadStateTracker {
             throw error; // unknown fs failure — the wrapper fails open
         }
         const record = this.reads.get(key);
-        if (!record || record.partial) {
+        if (!record) {
             throw new Error(READ_FIRST_ERROR);
         }
-        if (Math.floor(mtimeMs) > record.mtimeMs) {
-            // Timestamp moved, but on some platforms (cloud sync, antivirus) it
-            // moves without content changes. For a full read, compare content
-            // before refusing — Claude Code's exact fallback. The record holds
-            // the read tool's exact output and pi returns file bytes verbatim,
-            // so identical content compares byte-equal.
-            let onDisk;
-            try {
-                onDisk = await (this.io.readFile ?? readTextFile)(key);
-            }
-            catch (error) {
-                // Unreadable now, but the read succeeded then — stale — but the real
-                // cause (EACCES/EIO on the re-read, not an edit) rides the trail so
-                // the refusal is not misdiagnosed as a content change.
-                logEvent({
-                    source: "fileGuards",
-                    level: "info",
-                    event: "staleness_reread_failed",
-                    fields: { code: error?.code ?? "unknown" },
-                });
-                throw new Error(STALE_ERROR);
-            }
-            if (onDisk !== record.content) {
-                throw new Error(STALE_ERROR);
-            }
-            // Content-identical: refresh the record so the next write's mtime
-            // comparison uses the bumped timestamp instead of refusing again.
-            this.reads.set(key, { ...record, mtimeMs: Math.floor(mtimeMs) });
+        if (Math.floor(mtimeMs) <= record.mtimeMs)
+            return; // not stale
+        // The timestamp moved. A partial record holds only a slice (plus pi's
+        // continuation notice), so it cannot be content-compared — refuse
+        // outright, Claude Code's stance for offset/limit reads.
+        if (record.partial) {
+            throw new Error(STALE_ERROR);
+        }
+        // For a full read, compare content before refusing — Claude Code's exact
+        // fallback: on some platforms (cloud sync, antivirus) the timestamp moves
+        // without content changes. The record holds the read tool's exact output
+        // and pi returns file bytes verbatim, so identical content compares equal.
+        let onDisk;
+        try {
+            onDisk = await (this.io.readFile ?? readTextFile)(key);
+        }
+        catch (error) {
+            // Unreadable now, but the read succeeded then — stale — but the real
+            // cause (EACCES/EIO on the re-read, not an edit) rides the trail so
+            // the refusal is not misdiagnosed as a content change.
+            logEvent({
+                source: "fileGuards",
+                level: "info",
+                event: "staleness_reread_failed",
+                fields: { code: error?.code ?? "unknown" },
+            });
+            throw new Error(STALE_ERROR);
+        }
+        if (onDisk !== record.content) {
+            throw new Error(STALE_ERROR);
         }
+        // Content-identical: refresh the record so the next write's mtime
+        // comparison uses the bumped timestamp instead of refusing again.
+        this.reads.set(key, { ...record, mtimeMs: Math.floor(mtimeMs) });
     }
     isInside(absolute, base) {
         const slashed = (p) => p.replace(/\\/g, "/");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yagni-app/code-staging",
-  "version": "1.1.4-staging.1386.1",
+  "version": "1.1.4-staging.1387.1",
   "description": "YAGNI Code: a terminal coding agent that already knows your company. One YAGNI login routes the model and grounds the agent in your team's context.",
   "license": "SEE LICENSE IN LICENSE.md",
   "author": "YAGNI, Inc. <jack@yagni.app> (https://yagni.app)",
@@ -58,5 +58,5 @@
     "turndown": "^7.2.4",
     "typebox": "^1.3.15"
   },
-  "yagniSourceSha": "0fa67403fcaeaf2bdba61d03dc84eb9816b46a0f"
+  "yagniSourceSha": "e8e7f5d88707ad223e9cbeb16216b80239af3224"
 }