@bli-cockpit/memory-mcp 0.1.2 → 0.1.4

package/README.md

@@ -96,9 +96,19 @@ every machine:
 - **Print nothing, or one whole block.** No "no memories found" line — the model
   would reason about it, and an empty record and an unreachable store would look
   the same to it. Zero hits is data and prints nothing.
-- **One stderr receipt per run**, on every branch:
-  `[bli-memory hook] prompt {"status":"empty","reason":"no_hits","hits":0,"elapsed_ms":140}`.
-  Counts and reason labels only — never a prompt, a memory, a path or a token.
+- **One stderr receipt per run**, on every branch, one of three shapes
+  (BLI-3664, `hooks/log-line.ts`):
+  `[bli-memory] prompt ok {"hits":0,"elapsed_ms":140,"deadline_ms":3000}`,
+  `[bli-memory] prompt skipped {"reason":"no_prompt"}`, or
+  `[bli-memory] prompt failed {"reason":"dashboard_unreachable","elapsed_ms":2201,"deadline_ms":3000}`.
+  `reason` on `skipped`/`failed` is always one of a closed set — `timeout`,
+  `http_<status>`, `unpaired`, `dashboard_unreachable`, `bad_response`,
+  `no_prompt`, plus three Stop-only local skips (`reentrant`, `no_transcript`,
+  `redaction_failed`) — never a stack trace, never Tower's own error text,
+  never a prompt, a memory, a path or a token. A `failed` outcome also gets a
+  one-line `systemMessage` (the same JSON-on-stdout shape the Supermemory
+  plugin's own banner uses), because Claude Code does not surface a hook's
+  stderr anywhere a person reads it.
 
 `hook stop` sends the last user/assistant exchange (at most 12 KB, tail-read so
 a 40 MB transcript costs nothing) through the collector's own redactor —

package/dist/door.d.ts

@@ -31,6 +31,13 @@ export interface DoorResponse {
     body: Record<string, unknown>;
     /** Set when the request never produced a JSON answer at all. */
     transportError: string | null;
+    /**
+     * The CLOSED classification of `transportError`, `null` when there was none.
+     * `doorReason` reads this — never the free-text message and never
+     * `body.error` — so a hook's stderr line can never carry provider-controlled
+     * or exception-message text (BLI-3664).
+     */
+    transportKind: "timeout" | "network" | "malformed" | null;
 }
 export interface DoorRequest {
     session: MemorySession;
@@ -42,5 +49,18 @@ export interface DoorRequest {
     timeoutMs?: number;
 }
 export declare function postMemoryDoor(request: DoorRequest): Promise<DoorResponse>;
-/** The reason label for a failed door call: the refusal's own, or `transport`. */
-export declare function doorReason(response: DoorResponse): string;
+/**
+ * The CLOSED reason label a hook's stderr line may print for a failed door
+ * call (BLI-3664). Deliberately never `response.body["error"]` or a raw
+ * exception message — both are provider/dashboard-controlled free text, and a
+ * hook's log line is metadata-only. Four members, closed:
+ *
+ *  - `timeout` — the request itself was aborted on our own budget.
+ *  - `dashboard_unreachable` — a transport failure that was NOT a timeout
+ *    (DNS, TLS, connection refused).
+ *  - `bad_response` — Tower answered with a status but a body that was not
+ *    readable JSON.
+ *  - `http_<status>` — Tower gave a normal HTTP answer that was not 2xx.
+ */
+export type DoorFailureReason = "timeout" | "dashboard_unreachable" | "bad_response" | `http_${number}`;
+export declare function doorReason(response: DoorResponse): DoorFailureReason;

package/dist/door.js

@@ -49,11 +49,13 @@ export async function postMemoryDoor(request) {
         });
     }
     catch (error) {
+        const timedOut = isTimeoutError(error);
         return {
             ok: false,
             status: 0,
             body: {},
-            transportError: describeTransportError(error, request.timeoutMs),
+            transportError: describeTransportError(error, request.timeoutMs, timedOut),
+            transportKind: timedOut ? "timeout" : "network",
         };
     }
     finally {
@@ -71,29 +73,41 @@ export async function postMemoryDoor(request) {
             status: response.status,
             body: {},
             transportError: `Tower answered ${response.status} with a body this server could not read as JSON.`,
+            transportKind: "malformed",
         };
     }
-    return { ok: response.ok, status: response.status, body: parsed, transportError: null };
+    return {
+        ok: response.ok,
+        status: response.status,
+        body: parsed,
+        transportError: null,
+        transportKind: null,
+    };
+}
+function isTimeoutError(error) {
+    const name = error?.name;
+    return name === "AbortError" || name === "TimeoutError";
 }
 /**
  * An abort reads as a timeout with its budget named, because "The operation was
- * aborted" tells an operator nothing about which limit they hit.
+ * aborted" tells an operator nothing about which limit they hit. This message
+ * is for a human reading `server.ts`'s MCP tool error text, never for a hook's
+ * stderr line — `doorReason` below never reads it.
  */
-function describeTransportError(error, timeoutMs) {
-    const name = error?.name;
-    if (name === "AbortError" || name === "TimeoutError") {
+function describeTransportError(error, timeoutMs, timedOut) {
+    if (timedOut) {
         return timeoutMs
             ? `Tower did not answer within ${timeoutMs} ms; the request was abandoned.`
             : "The request was aborted before Tower answered.";
     }
     return error instanceof Error ? (error.message.split("\n")[0] ?? "unknown") : String(error);
 }
-/** The reason label for a failed door call: the refusal's own, or `transport`. */
 export function doorReason(response) {
-    if (response.transportError)
-        return "transport_failed";
-    const label = response.body["error"];
-    if (typeof label === "string" && label.trim())
-        return label.trim();
+    if (response.transportKind === "timeout")
+        return "timeout";
+    if (response.transportKind === "network")
+        return "dashboard_unreachable";
+    if (response.transportKind === "malformed")
+        return "bad_response";
     return `http_${response.status}`;
 }

package/dist/hooks/log-line.d.ts

@@ -0,0 +1,80 @@
+/**
+ * The one line every hook run prints to stderr, and the one sentence Claude
+ * Code shows a person on `failed` (BLI-3664).
+ *
+ * Before this file, `run.ts` printed `{status, reason, ...}` where `reason`
+ * was whatever the hook body happened to produce — including, for a door
+ * failure, `doorReason(response)`'s old behaviour of echoing
+ * `response.body["error"]` straight from Tower. Across 580 real transcripts
+ * that line was never actually read (`docs/reports/supermemory-reachability-
+ * 2026-09-05.md` §6): stderr from a Claude Code hook is not captured in the
+ * transcript at all, so a BLI Memory outage and a quiet turn with nothing to
+ * recall were indistinguishable to anyone who was not tailing this process's
+ * stderr live. The fix is two mechanisms, not one:
+ *
+ *  1. **stderr, on every branch, one line, one shape.** `buildLogLine` below.
+ *     This is what an operator tailing a launchd-style log — or a future
+ *     collector upload of hook logs — can grep.
+ *  2. **`systemMessage`, on `failed` only.** Claude Code does not surface a
+ *     hook's stderr as a visible line; the Supermemory plugin's own banner
+ *     (`~/.claude/plugins/.../recall-directive.js`) is a JSON object on
+ *     STDOUT carrying a `systemMessage` field (`hooks/stdin.js:writeOutput`,
+ *     `console.log(JSON.stringify(data))`). `buildSystemMessage` produces the
+ *     same shape so a real failure — not a quiet turn — is the one case a
+ *     person actually sees something.
+ *
+ * **The reason vocabulary is closed and lives HERE, in one module.** Six
+ * members answer the ticket's own question (can a timeout, a 5xx, a dead
+ * dashboard and "nothing to say" be told apart?): `timeout`, `http_<status>`,
+ * `unpaired`, `dashboard_unreachable`, `bad_response`, `no_prompt`. Three more
+ * cover skip states that are local to one hook and never touch the network —
+ * `reentrant` (Stop, re-entrant), `no_transcript` (Stop, nothing to read yet)
+ * and `redaction_failed` (Stop, the masking pass itself failed) — kept as
+ * their own fixed literals rather than folded into a network bucket, because
+ * calling a re-entrant Stop hook `bad_response` would tell an operator a
+ * request failed when nothing was even attempted. Every one of the nine is a
+ * compile-time literal from OUR OWN code; none of them is `response.body`
+ * text, an `error.message`, or a stack trace (`door.ts`'s `doorReason` already
+ * enforces that at the source for the network four). `toLogReason` maps every
+ * other internal reason string this package can produce onto one of the nine,
+ * and anything it does not recognise — a future reason nobody wired in here —
+ * falls back to `bad_response` rather than printing unbounded text.
+ */
+import type { HookEvent, HookOutcome, HookStatus } from "./contract.js";
+import type { DoorFailureReason } from "../door.js";
+export declare const HOOK_LOG_TAG = "[bli-memory]";
+/** The closed set. Nine literals plus the parameterised `http_<status>` family. */
+export type HookLogReason = DoorFailureReason | "unpaired" | "no_prompt" | "reentrant" | "no_transcript" | "redaction_failed";
+/** The word printed after the event name. `empty` (ran fine, nothing to say) prints as `ok`. */
+export type HookLogWord = "ok" | "skipped" | "failed";
+export declare function logWordFor(status: HookStatus): HookLogWord;
+/**
+ * Normalises any reason string this package can produce into the closed set.
+ * A door failure already arrives normalised (`door.ts`'s `doorReason`), so
+ * this is mostly a lookup table for the handful of purely local reasons —
+ * plus a safe, named default for anything this table has not been taught.
+ */
+export declare function toLogReason(reason: string): HookLogReason;
+/**
+ * The one stderr line for one hook run. Exact shape per status:
+ *
+ *   [bli-memory] <hook> ok      {hits?, saved?, chars?, masked?, elapsed_ms, deadline_ms}
+ *   [bli-memory] <hook> skipped {reason}
+ *   [bli-memory] <hook> failed  {reason, elapsed_ms, deadline_ms}
+ *
+ * Metadata only — counts and a closed reason label, never a memory's text,
+ * never a path, never the device token.
+ */
+export declare function buildLogLine(event: HookEvent, outcome: HookOutcome, elapsedMs: number, deadlineMs: number): string;
+/**
+ * One short sentence for a `failed` outcome only, in the JSON envelope the
+ * host actually renders (`{"systemMessage": "…"}` on stdout — see the
+ * Supermemory mechanism cited in this file's header). `null` on every other
+ * branch: `ok`/`empty` already say their piece through the injected block,
+ * and `skipped` is a deliberate no-op nobody needs interrupted for.
+ */
+export declare function buildSystemMessage(outcome: HookOutcome): string | null;
+/** Renders one JSON block to stdout — the only shape a hook may emit there
+ * besides plain injected context. Used by `run.ts` on `failed` only, so the
+ * "one block or nothing" stdout contract for every other branch is untouched. */
+export declare function renderSystemMessageBlock(message: string): string;

package/dist/hooks/log-line.js

@@ -0,0 +1,174 @@
+/**
+ * The one line every hook run prints to stderr, and the one sentence Claude
+ * Code shows a person on `failed` (BLI-3664).
+ *
+ * Before this file, `run.ts` printed `{status, reason, ...}` where `reason`
+ * was whatever the hook body happened to produce — including, for a door
+ * failure, `doorReason(response)`'s old behaviour of echoing
+ * `response.body["error"]` straight from Tower. Across 580 real transcripts
+ * that line was never actually read (`docs/reports/supermemory-reachability-
+ * 2026-09-05.md` §6): stderr from a Claude Code hook is not captured in the
+ * transcript at all, so a BLI Memory outage and a quiet turn with nothing to
+ * recall were indistinguishable to anyone who was not tailing this process's
+ * stderr live. The fix is two mechanisms, not one:
+ *
+ *  1. **stderr, on every branch, one line, one shape.** `buildLogLine` below.
+ *     This is what an operator tailing a launchd-style log — or a future
+ *     collector upload of hook logs — can grep.
+ *  2. **`systemMessage`, on `failed` only.** Claude Code does not surface a
+ *     hook's stderr as a visible line; the Supermemory plugin's own banner
+ *     (`~/.claude/plugins/.../recall-directive.js`) is a JSON object on
+ *     STDOUT carrying a `systemMessage` field (`hooks/stdin.js:writeOutput`,
+ *     `console.log(JSON.stringify(data))`). `buildSystemMessage` produces the
+ *     same shape so a real failure — not a quiet turn — is the one case a
+ *     person actually sees something.
+ *
+ * **The reason vocabulary is closed and lives HERE, in one module.** Six
+ * members answer the ticket's own question (can a timeout, a 5xx, a dead
+ * dashboard and "nothing to say" be told apart?): `timeout`, `http_<status>`,
+ * `unpaired`, `dashboard_unreachable`, `bad_response`, `no_prompt`. Three more
+ * cover skip states that are local to one hook and never touch the network —
+ * `reentrant` (Stop, re-entrant), `no_transcript` (Stop, nothing to read yet)
+ * and `redaction_failed` (Stop, the masking pass itself failed) — kept as
+ * their own fixed literals rather than folded into a network bucket, because
+ * calling a re-entrant Stop hook `bad_response` would tell an operator a
+ * request failed when nothing was even attempted. Every one of the nine is a
+ * compile-time literal from OUR OWN code; none of them is `response.body`
+ * text, an `error.message`, or a stack trace (`door.ts`'s `doorReason` already
+ * enforces that at the source for the network four). `toLogReason` maps every
+ * other internal reason string this package can produce onto one of the nine,
+ * and anything it does not recognise — a future reason nobody wired in here —
+ * falls back to `bad_response` rather than printing unbounded text.
+ */
+export const HOOK_LOG_TAG = "[bli-memory]";
+export function logWordFor(status) {
+    if (status === "skipped")
+        return "skipped";
+    if (status === "failed")
+        return "failed";
+    return "ok"; // "ok" and "empty" both read as "ok" — empty is data, not a failure.
+}
+/**
+ * Normalises any reason string this package can produce into the closed set.
+ * A door failure already arrives normalised (`door.ts`'s `doorReason`), so
+ * this is mostly a lookup table for the handful of purely local reasons —
+ * plus a safe, named default for anything this table has not been taught.
+ */
+export function toLogReason(reason) {
+    switch (reason) {
+        // Already-closed door failures (door.ts), including any `http_<status>`.
+        case "timeout":
+        case "dashboard_unreachable":
+        case "bad_response":
+            return reason;
+        // Pairing / credential (session.ts's `SessionFailure`).
+        case "session_file_missing":
+        case "session_file_unreadable":
+        case "session_file_invalid":
+        case "session_missing_token":
+            return "unpaired";
+        // The host's own payload could not be used (stdin.ts's `StdinFailure`).
+        case "no_stdin":
+        case "stdin_empty":
+        case "stdin_timeout":
+        case "stdin_too_large":
+        case "stdin_unreadable":
+        case "stdin_malformed":
+            return "bad_response";
+        // The prompt hook's own empty-prompt skip.
+        case "no_prompt":
+            return "no_prompt";
+        // Stop-only local skips (stop.ts / transcript.ts / redact.ts).
+        case "reentrant":
+            return "reentrant";
+        case "no_transcript_path":
+        case "transcript_unreadable":
+        case "transcript_no_exchange":
+            return "no_transcript";
+        case "redaction_failed":
+            return "redaction_failed";
+        // The run-level deadline race (run.ts).
+        case "deadline_exceeded":
+            return "timeout";
+        default:
+            // A door's `http_<status>` template literal, or an unexpected
+            // `hook_threw:<Name>` — the request happened but produced something
+            // this hook could not act on. Never the raw string past this point.
+            if (reason.startsWith("http_"))
+                return reason;
+            return "bad_response";
+    }
+}
+/**
+ * The one stderr line for one hook run. Exact shape per status:
+ *
+ *   [bli-memory] <hook> ok      {hits?, saved?, chars?, masked?, elapsed_ms, deadline_ms}
+ *   [bli-memory] <hook> skipped {reason}
+ *   [bli-memory] <hook> failed  {reason, elapsed_ms, deadline_ms}
+ *
+ * Metadata only — counts and a closed reason label, never a memory's text,
+ * never a path, never the device token.
+ */
+export function buildLogLine(event, outcome, elapsedMs, deadlineMs) {
+    const word = logWordFor(outcome.status);
+    const fields = word === "skipped"
+        ? { reason: toLogReason(outcome.reason) }
+        : word === "failed"
+            ? { reason: toLogReason(outcome.reason), elapsed_ms: elapsedMs, deadline_ms: deadlineMs }
+            : {
+                ...(outcome.hits === undefined ? {} : { hits: outcome.hits }),
+                ...(outcome.saved === undefined ? {} : { saved: outcome.saved }),
+                ...(outcome.chars === undefined ? {} : { chars: outcome.chars }),
+                ...(outcome.masked === undefined ? {} : { masked: outcome.masked }),
+                elapsed_ms: elapsedMs,
+                deadline_ms: deadlineMs,
+            };
+    return `${HOOK_LOG_TAG} ${event} ${word} ${JSON.stringify(fields)}\n`;
+}
+/**
+ * One short sentence for a `failed` outcome only, in the JSON envelope the
+ * host actually renders (`{"systemMessage": "…"}` on stdout — see the
+ * Supermemory mechanism cited in this file's header). `null` on every other
+ * branch: `ok`/`empty` already say their piece through the injected block,
+ * and `skipped` is a deliberate no-op nobody needs interrupted for.
+ */
+export function buildSystemMessage(outcome) {
+    if (outcome.status !== "failed")
+        return null;
+    return `BLI Memory: ${failureSentence(toLogReason(outcome.reason))}`;
+}
+function failureSentence(reason) {
+    if (reason.startsWith("http_")) {
+        return `Tower refused the request (${reason.slice("http_".length)}).`;
+    }
+    switch (reason) {
+        case "timeout":
+            return "Tower did not answer in time.";
+        case "dashboard_unreachable":
+            return "Tower is unreachable from this machine.";
+        case "bad_response":
+            return "Tower's response could not be understood.";
+        case "unpaired":
+            return "this machine is not paired with Tower — run `cockpit login`.";
+        case "redaction_failed":
+            return "the turn could not be safely redacted before saving.";
+        case "no_transcript":
+        case "reentrant":
+        case "no_prompt":
+            // Skip-only reasons; `buildSystemMessage` never reaches these because
+            // none of them is produced on a `failed` outcome. Named rather than
+            // asserted unreachable, so a future change that DID route one through
+            // `failed` still gets a sentence instead of a crash.
+            return "the recall did not run.";
+        default:
+            // Unreached: the `http_` family returned above and every other member
+            // is handled. A safe sentence, never a crash, if that ever changes.
+            return "something went wrong.";
+    }
+}
+/** Renders one JSON block to stdout — the only shape a hook may emit there
+ * besides plain injected context. Used by `run.ts` on `failed` only, so the
+ * "one block or nothing" stdout contract for every other branch is untouched. */
+export function renderSystemMessageBlock(message) {
+    return JSON.stringify({ systemMessage: message });
+}

package/dist/hooks/run.d.ts

@@ -14,14 +14,22 @@
  *     this prompt" and any other non-zero as an error it shows the person. A
  *     memory recall may never do either.
  *  3. **stdout discipline.** Nothing is written until the hook has finished and
- *     produced a whole block. A partial injection is worse than none.
- *  4. **One stderr receipt per run, on every branch.** `[bli-memory hook]
- *     <event> {status, hits|saved, elapsed_ms, reason}` — metadata only, never a
- *     prompt, a memory, a path or a token. A hook that only logged failures
- *     could not answer "did recall work at all today?", which is the question
- *     an operator actually asks.
+ *     produced a whole block. A partial injection is worse than none — with
+ *     ONE exception, added in BLI-3664: a `failed` outcome also gets a single
+ *     `{"systemMessage": "…"}` JSON block, because that is the one shape
+ *     Claude Code actually renders to a person (see `log-line.ts`'s header).
+ *     Every other status's stdout is exactly as before.
+ *  4. **One stderr receipt per run, on every branch.** `[bli-memory] <event>
+ *     ok|skipped|failed {…}` (`log-line.ts:buildLogLine`) — metadata only,
+ *     never a prompt, a memory, a path or a token, and a `reason` drawn from a
+ *     closed set. A hook that only logged failures could not answer "did
+ *     recall work at all today?", which is the question an operator actually
+ *     asks — and across 580 real transcripts this line was the ONLY place
+ *     that question could ever have been answered, because Claude Code does
+ *     not surface a hook's stderr anywhere a person or a transcript reads
+ *     (`docs/reports/supermemory-reachability-2026-09-05.md` §6, BLI-3664).
  *
- * Why an unpaired machine is `skipped no_session` and not an error: an intern
+ * Why an unpaired machine is `skipped unpaired` and not an error: an intern
  * who has not run `cockpit login` yet has three registered hooks and no
  * credential, and that state must be quiet in the transcript and loud in the
  * log. Same for a machine whose token was revoked — the door answers 401, the
@@ -30,7 +38,7 @@
 import type { FetchImpl } from "../door.js";
 import { type HookEvent, type HookOutcome, type HookPayload } from "./contract.js";
 import type { StopHookOptions } from "./stop.js";
-export declare const HOOK_LOG_TAG = "[bli-memory hook]";
+export { HOOK_LOG_TAG } from "./log-line.js";
 export interface RunHookDeps {
     env?: NodeJS.ProcessEnv;
     cwd?: string;

package/dist/hooks/run.js

@@ -14,14 +14,22 @@
  *     this prompt" and any other non-zero as an error it shows the person. A
  *     memory recall may never do either.
  *  3. **stdout discipline.** Nothing is written until the hook has finished and
- *     produced a whole block. A partial injection is worse than none.
- *  4. **One stderr receipt per run, on every branch.** `[bli-memory hook]
- *     <event> {status, hits|saved, elapsed_ms, reason}` — metadata only, never a
- *     prompt, a memory, a path or a token. A hook that only logged failures
- *     could not answer "did recall work at all today?", which is the question
- *     an operator actually asks.
+ *     produced a whole block. A partial injection is worse than none — with
+ *     ONE exception, added in BLI-3664: a `failed` outcome also gets a single
+ *     `{"systemMessage": "…"}` JSON block, because that is the one shape
+ *     Claude Code actually renders to a person (see `log-line.ts`'s header).
+ *     Every other status's stdout is exactly as before.
+ *  4. **One stderr receipt per run, on every branch.** `[bli-memory] <event>
+ *     ok|skipped|failed {…}` (`log-line.ts:buildLogLine`) — metadata only,
+ *     never a prompt, a memory, a path or a token, and a `reason` drawn from a
+ *     closed set. A hook that only logged failures could not answer "did
+ *     recall work at all today?", which is the question an operator actually
+ *     asks — and across 580 real transcripts this line was the ONLY place
+ *     that question could ever have been answered, because Claude Code does
+ *     not surface a hook's stderr anywhere a person or a transcript reads
+ *     (`docs/reports/supermemory-reachability-2026-09-05.md` §6, BLI-3664).
  *
- * Why an unpaired machine is `skipped no_session` and not an error: an intern
+ * Why an unpaired machine is `skipped unpaired` and not an error: an intern
  * who has not run `cockpit login` yet has three registered hooks and no
  * credential, and that state must be quiet in the transcript and loud in the
  * log. Same for a machine whose token was revoked — the door answers 401, the
@@ -31,8 +39,9 @@ import path from "node:path";
 import { resolveContainerTag } from "../container-tag.js";
 import { loadMemorySession } from "../session.js";
 import { HOOK_BUDGETS, } from "./contract.js";
+import { buildLogLine, buildSystemMessage, renderSystemMessageBlock } from "./log-line.js";
 import { readHookPayload } from "./stdin.js";
-export const HOOK_LOG_TAG = "[bli-memory hook]";
+export { HOOK_LOG_TAG } from "./log-line.js";
 /**
  * Runs one hook and returns its outcome. The caller (`index.ts`) exits 0
  * regardless — the return value is for tests and for the receipt.
@@ -44,19 +53,22 @@ export async function runHook(event, deps = {}) {
     const stdout = deps.stdout ?? process.stdout;
     const stderr = deps.stderr ?? process.stderr;
     const outcome = await raceDeadline(() => resolveOutcome(event, deps), budget.totalMs);
+    const elapsedMs = now() - started;
     // stdout is written once, here, and only for a complete block.
     if (outcome.stdout.length > 0) {
         stdout.write(`${outcome.stdout}\n`);
     }
-    stderr.write(`${HOOK_LOG_TAG} ${event} ${JSON.stringify({
-        status: outcome.status,
-        reason: outcome.reason,
-        ...(outcome.hits === undefined ? {} : { hits: outcome.hits }),
-        ...(outcome.saved === undefined ? {} : { saved: outcome.saved }),
-        ...(outcome.chars === undefined ? {} : { chars: outcome.chars }),
-        ...(outcome.masked === undefined ? {} : { masked: outcome.masked }),
-        elapsed_ms: now() - started,
-    })}\n`);
+    else {
+        // The one exception to "one block or nothing": a `failed` outcome still
+        // prints nothing to the model (no additionalContext), but DOES get a
+        // `systemMessage` block, which is a status banner, not a memory. Every
+        // other status's stdout is unchanged from before BLI-3664.
+        const systemMessage = buildSystemMessage(outcome);
+        if (systemMessage) {
+            stdout.write(`${renderSystemMessageBlock(systemMessage)}\n`);
+        }
+    }
+    stderr.write(buildLogLine(event, outcome, elapsedMs, budget.totalMs));
     return outcome;
 }
 async function resolveOutcome(event, deps) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bli-cockpit/memory-mcp",
-  "version": "0.1.2",
+  "version": "0.1.4",
   "private": false,
   "description": "BLI Memory — an MCP server for the memory layer BLI owns (save, search, update, forget).",
   "type": "module",
@@ -28,7 +28,7 @@
     "start": "node dist/index.js"
   },
   "dependencies": {
-    "@bli-cockpit/telemetry-core": "0.1.27",
+    "@bli-cockpit/telemetry-core": "0.1.28",
     "@modelcontextprotocol/sdk": "^1.29.0",
     "zod": "^4.3.6"
   },