host: the diagnostics report names whether the journal is recording but never the file it records into #2388

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: e08157279c1646fe9f85d457be5043d3
Branch: dev/1-diagnostics-journal-file
Base: 460738c
At: 2026-11-04T11:43:10Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.
Written-by: FlyBot Lead

What happens

A diagnostics report says whether the state journal is recording, but nothing about the file it records into: not where it lives, not how big it is, not whether it was written at all. A report that says state journal: recording reads the same on a host whose journal file is a few hundred bytes and on one whose file is 40 MB of history, and the same on a host whose file another program replaced with a link — in which case the journal is not recording into a file of this host's own at all, and the sentence above still says recording.

Live main 460738ccfc7edde75c34ddb9966d64f07d0e6915:

• core/src/host/diagnostics.js:86 — the only journal paragraph: `state journal: ${facts.stateJournal}`;
• core/src/host/diagnostics.js:267-273 — stateJournal is recording / paused (this window is read-only) / not started (opens with the first save) / stopped (<reason>);
• core/src/host/journal.js:388-389 — openJournal returns { record, path, status }, so the file's own path is already on rt.journal.path; status() returns { recording: true } or { recording: false, because };
• core/src/host/diagnostics.js:41-50 — cleanText already rewrites the home directory to ~, which is what keeps the report safe to paste into a public issue.

How to see it

Run a host that records (default), let it save once so the journal opens, then open Diagnostics and copy the report: the journal appears as one line, state journal: recording, and nothing names the file, its size, or when it was last written. Same report on a host where logs/ was replaced by a link: state journal: still says recording while the journal is not writing into a file of its own.

Expected

One more line, in the journal's own shape (a paragraph of its own, right after state journal: …), produced without opening the file — lstat only, never readFile/open:

• journal running and the file is a plain file with one name → journal file: <path, home as ~> (<size>, last written <ISO UTC>);
• no file yet → journal file: none yet;
• path is a link, or a file with more than one name, or the check cannot run → journal file: not a plain file (nothing is read or written);
• journal off → no line at all (the host: a stopped state journal is invisible in the diagnostics report #2134 rule: an off journal is not a fact about this host).

The line reports what the file is, not a promise about writes: state journal: keeps saying whether recording is happening (that is #2135/#2153/#2374's job and must not change), and a refusal or a missing file must not add a stderr line or change the journal's behaviour in any way.

Minimal slice

core/src/host/diagnostics.js — a journalFile fact beside stateJournal (lstat(rt.journal.path), home redacted through the existing clean), one paragraph in reportMarkdown in the same shape as the journal and log paragraphs; docs/subsystems/core-host.md gains the three states and the read-nothing rule; changelog.d/ fragment. No change to journal.js's behaviour, to clear(), or to the stderr lines #2089/#2364/#2383 own.

Verification (red first)

core/test/diagnostics.test.js (same harness the #2383 cases already use, with a temp journal path):

1. plain file → the line exists, names the path (home shown as ~), the byte size, and the mtime as ISO UTC — fails today (no such line);
2. no file → none yet, and the rest of the report is unchanged;
3. symbolic-link leaf and a hard-linked leaf (nlink = 2) → not a plain file (nothing is read or written), and neither the link target nor the second name changes a byte;
4. journal off → no journal file: line at all;
5. open/readFile/createReadStream on the journal path is never called — asserted by a probe on the path (a 0-byte permission-denied file must still report its size and mtime, which a read could not).

core/test/journal.test.js must stay green untouched.

Duplicate check

Live search (open + closed) on journal file size diagnostics, "state journal" location size, diagnostics report journal path: no open issue for this. The nearest closed ones are #2134/#2135/#2153/#2157/#2374 (whether the journal is recording), #2089/#2094/#2162 (writes through a linked leaf), #2146 (rotation over a link) — all about behaviour, none about the report naming the file. Backlog has no matching entry.

Notes

Host lane (core/src/host/**), one PR at a time in that lane; reported by FlyBot Product in its earlier audit round, anchors re-verified by me on live 460738cc. Do not print the home directory, do not read the file, and do not let this line claim writes that did not happen.