fix(read_file): detect metadata-only responses by the request flag

[stag7824]

Fixes #970

The bug

readFileFormatter decided whether a response was metadata-only like this:

const isMetadataOnly =
  (result?.startsWith('File:') ?? false) &&
  !args.start_line &&
  !args.end_line &&
  totalLines > FILE_READ_PREVIEW_THRESHOLD_LINES;

The metadata branch emits (read-file.tsx:48):

let output = `File Information for "${args.path}"\n`;

"File Information for ..." does not start with "File:" — the fifth character is a space, not a colon. So the prefix test never matched and isMetadataOnly was always false.

The other half of it

The three remaining conditions describe the truncated-preview response, not this one. read_file returns one of three shapes:

Shape	Emitted at	Detected by
metadata block	line 48, returned line 102	isMetadataOnly ← broken
truncated preview	line 133	result.includes('[Truncated at line ') ✅
plain content	line 150	neither

The metadata branch is guarded by if (args.metadata_only) at line 34 and returns before any line range or file size is considered. So requiring !args.start_line && !args.end_line && totalLines > 1500 could never be right for it — a metadata_only read on a 120-line file fails the threshold even if the prefix had matched.

Impact

With isMetadataOnly stuck false, a metadata_only: true read renders as an ordinary content read:

• the (metadata only) marker never appears (line 254)
• the metadata layout never renders; the content-read layout renders instead (line 260)
• the Tokens: row renders even though it is meant to be hidden for metadata reads (line 281)
• tokens are computed from result — the metadata block itself — rather than from the full file (lines 349–355), so the number describes the wrong thing

The change

-const isMetadataOnly =
-  (result?.startsWith('File:') ?? false) &&
-  !args.start_line &&
-  !args.end_line &&
-  totalLines > FILE_READ_PREVIEW_THRESHOLD_LINES;
+const isMetadataOnly = args.metadata_only === true;

args.metadata_only is the flag that selects this response shape at line 34, so it is exactly the right signal. FILE_READ_PREVIEW_THRESHOLD_LINES is still used at line 123, so the import stays live.

Verification

Against the exact string the metadata branch emits:

metadata output begins: "File Information for \"src/app.ts\""
char 5 is " " - a space, not ":"

old prefix test  result.startsWith("File:")  -> false

case                                  old      new
metadata_only on a 120-line file      false    true
metadata_only on a 4000-line file     false    true

The truncated-preview and plain-content paths are untouched — isTruncated on the following line is unchanged, and neither path sets metadata_only.

A changeset is included (@nanocollective/nanocoder, patch).

[will-lamerton]

Diagnosis is correct and I reproduced it: on main a metadata_only: true read rendered Lines: 1 - 4 and Tokens: ~89 (tokens measured from the metadata block), and on this branch it correctly renders (metadata only) / Total lines: 4 with no Tokens: row. Types, lint, format and the 42 existing read-file.spec.tsx tests all pass.

Three things before merge:

1. Needs a regression test. This bug shipped precisely because no formatter test ever passes metadata_only: true - the three existing ReadFileFormatter tests cover path, truncated preview and error results only, and the metadata_only tests exercise the handler rather than the formatter. Nothing in the suite would catch this coming back. A test asserting (metadata only) renders and Tokens: does not would close it.

2. Directories and unreadable files still render the wrong layout. isMetadataOnly is computed inside the try, after getCachedFileContent(), which throws EISDIR for a directory. So a metadata_only read of a directory still falls into the catch and renders the content layout:

⚒ read_file
Path:  .../some-dir
Lines: 1 - 0
Tokens: ~0

The tool explicitly supports directories (if (type === 'directory') at line 94, with a handler test for it), so this is the same class of bug left half-fixed. Hoisting the flag above the try and into the initial fileInfo handles both cases.

3. === true disagrees with the executor. executeReadFile gates on truthy if (args.metadata_only) while the formatter now requires === true. The XML fallback path can produce non-boolean truthy values: xml-parser.ts:161 does JSON.parse() and falls back to the raw string, so <metadata_only>True</metadata_only> arrives as a string. I confirmed that passing 'true' reproduces the exact bug being fixed here. Boolean(args.metadata_only) keeps the two predicates identical by construction and fixes this alongside point 2.

Two smaller notes, take or leave:

• With isMetadataOnly now actually true, tokens = calculateTokens(content) runs a full-file tokenization whose result is never rendered, since the Tokens: row is hidden for metadata reads. Worth skipping.
• The 6-line comment is mostly archaeology about why the old code was wrong. Comments elsewhere in this file explain intent rather than history, and the changeset already tells that story. One line on what the flag means would fit better.

[stag7824]

Thanks for the thorough review and for reproducing it independently — all three addressed in 17ea57f:

1. Regression test — added three: a metadata_only read on a regular file, one on a directory, and one with metadata_only passed as the string 'true'.
2. Directories/symlinks — isMetadataOnly is now set from args.metadata_only before the file read, not derived after it succeeds. Your fix (hoist it into the initial fileInfo) is exactly what I did.
3. Boolean() vs === true — changed, and I confirmed your repro: with the old === true, passing metadata_only: 'true' (string) reproduced the identical bug this PR fixes.

Also took the two smaller suggestions: skipped calculateTokens() for metadata-only reads since that row is hidden, and trimmed the inline comment — the changeset now carries the "why".

test:types, test:lint, test:format, and test:knip all pass; read-file.spec.tsx is green including the three new tests (one pre-existing unrelated failure — ReadFileFormatter renders with path fails the same way on main, it's a terminal-width truncation assumption that breaks under a long cwd, unrelated to this change).