Page journal (PJ-8): silent capture through the product — owner never durably learns an entry was written; parent files edited without approved shape

[davewaring]

Summary

Through the real BrainDrive product (gateway + web client), the model can write a journal entry and the owner never durably learns it happened. The web client shows only a transient "Using memory edit..." status while the tool runs; once the stream finishes there is no persistent artifact in the chat confirming the write. Separately, and in the same code path, the model sometimes edits a parent file (e.g. plan.md) without going through the approved edit shape.

Evidence

Stage-4 live runtime check, 2026-09-05, BrainDrive commit 3cdd47a:

• Silent capture: capture_told failed on 4 of 4 capture cells tested, across both models run (GPT-5.6 Luna, GLM-5.2). Offline (harness-only, not through the product) the same cells passed capture-and-tell every time.
• Parent-file edits without approved shape: Luna touched plan.md on relationships/advice (recheck); GLM on relationships/create.
• Pattern held on a third model (DeepSeek V4 Flash 0731): silent capture 2/2, parent-file edits on 3 of 12 cells.
• No trust flags on any of the three models — this is a UX/confirmation gap, not a data-integrity failure.

Root cause (hypothesis)

The capture-and-tell rule lives in run-journal.md, which the model reads by tool call mid-conversation — it is not part of the bootstrap system prompt. The product's base AGENT.md instruction ("After writing or updating owner-facing artifacts, tell the owner…") is in the bootstrap prompt, and models still skip it under real multi-turn product conditions. Three independent models exhibited the same behavior, pointing at the product's prompt/tool surface rather than any one model's instruction-following.

Fix bar

A persistent tool receipt in the chat UI satisfies PJ-8. Prose confirmation from the model ("I've added this to your journal...") is not required. What's required is that the owner has a durable, visible record in the chat/UI that the entry was written, surviving past the transient "Using memory edit..." status. The same fix should ensure parent-file edits happen only through the approved edit shape (or are made visible/reviewable the same way).

Suggested scope (non-binding)

• Chat stream / web client: replace or supplement the transient tool-running status with a persistent, post-write receipt (a chat message or UI element that remains after the turn, naming what was written).
• Confirm the receipt satisfies PJ-8 regardless of whether the model also emits prose about the write.
• Investigate the parent-file-edit path so edits go through the approved shape consistently (may be a related but distinct code path).

Out of scope

• The offline harness's inflated capture-and-tell compliance (system-prompt splicing vs. the product's tool-read) is a test-harness instrument gap, not a product defect — tracked separately.