memory: the sixth instrument error, and the one that consumed an operator approval

Corrects my own framing from earlier today. I told the operator D-0010's /clear
"cost nothing by luck of the delivery mechanism". svos-dev verified the code:
bifrost.py:1322 prefixes every relayed string with the card id, so a slash
command never begins the line. pane_send STRUCTURALLY cannot execute a harness
command in a target pane -- a property, not luck.

Which makes the card worse than a misroute. It promised "type /clear into
terminal_2 and clear booth-dev's context"; that effect was never achievable at
all. The executed event then recorded {"sent": true} -- true about the bytes,
false about the effect. Three defects in one approved action, and only the
first was visible.

Recorded because it is the sharpest instance of the day's pattern and the only
one that cost something outside an agent's triage time: it consumed an OPERATOR
APPROVAL. Vuong approved an action believing it would take effect and the
system told him it had.

General form worth carrying beyond SVOS: {"sent": true} is a claim about
transmission, never about effect. Any receipt that cannot distinguish the two
will eventually report success for something that did not happen.

persistent-memory.d/2026-09-22-instrument-errors.md

@@ -69,3 +69,41 @@ session will read it, not left as a lesson someone remembers.
 
 Related: [[2026-09-21-booth-two-dead-controls]] — same family, found by the
 operator rather than by me, because I read templates instead of rendering them.
+
+## Addendum — the sixth, and the one that cost an operator approval
+
+`[2026-09-22, later]` Found by svos-dev verifying a mechanism I had merely
+inferred, and it corrects my own framing.
+
+I told the operator that D-0010's `/clear` "cost nothing by luck of the delivery
+mechanism". **It was not luck.** `svos/server/bifrost.py:1322` composes
+`typed_text=f"[MIRANDA {card_id}] {text}"` — every relayed string is prefixed
+with the card id, so a slash command never begins the line and the receiving
+harness reads it as prose. **`pane_send` structurally cannot execute a harness
+command in a target pane.** A property of the tool, on every send.
+
+Which makes the card worse than a misroute. It promised: *"Approve to type
+/clear into terminal_2 and clear booth-dev's context."* **That effect was never
+achievable** — not with the right pane, not with identity resolved perfectly.
+And the executed event recorded `{"sent": true}`: true about the bytes, false
+about the effect.
+
+Three defects in one approved action — wrong pane, an impossible promise, and a
+receipt reporting success for an outcome that never occurred. Only the first was
+visible to anyone.
+
+**Why this one is the sharpest of the set.** Every other instrument error here
+cost an agent some triage time. This one *consumed an operator approval*: Vuong
+approved an action believing it would take effect, and the system reported that
+it had. A receipt that describes the bytes rather than the outcome is the same
+class as `restic ls`'s header line or systemd's `●` — an instrument reporting
+cleanly about something it never checked — but pointed at the human whose
+judgement the whole approval gate exists to capture.
+
+The general form, worth carrying beyond SVOS: **`{"sent": true}` is a claim
+about transmission, never about effect.** Any receipt that cannot distinguish
+the two will eventually report success for something that did not happen.
+
+Fix is svos-dev's (identity asserted where telemetry can claim the pane,
+disclosed as title-only where it cannot; and `pane_send` refusing or the card
+declaring text whose leading token is a harness command it cannot deliver).