---
name: spt-send-no-inline-backticks
description: Never compose spt send bodies inline in bash double quotes — backticks execute as command substitution and silently eat the command text; write a file and cat it in
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 541517e4-391f-4c23-8bc6-74b9db1f94e1
  modified: 2026-08-01T01:20:54.383Z
---

Sending `spt send` bodies via `printf '%s' "..."` with double quotes executes backtick spans as bash command substitution — the span is REPLACED by the command's output (usually empty + stderr noise), silently deleting exactly the command text the recipient needed. Bit doyle 2026-07-25 relaying the stand-down instruction ("stop your listener with ``" arrived empty); flynn hit the same class the same day.

**Why:** double-quoted bash strings interpolate backticks and `$(...)`; a relay instruction that silently loses its command is worst-case when the instruction is "how to come back."

**How to apply:** for any non-trivial message body, Write the body to a scratchpad file and `cat file | spt send <target>`. No backticks in relayed instructions, ever — spell commands in plain text. Short tag-sends (`@<id ... @>`) are adapter-parsed, not shell-parsed, but keep backticks out of those too (a separate mask-slice defect class existed in omp-spt parsePeerShortforms, fixed 0.3.27). Same trap in `gh issue comment --body "..."` — a backticked path executed and vanished from a posted comment 2026-07-31; use `--body-file`.

## Never broadcast a second-person body (2026-08-01)

**"You" does not survive fan-out.** perri wrote one message addressed in their head to lia and sent that identical body to lia, doyle and me: *"your revised radius"*, *"your kitsubito result"*. Two of three recipients were told they had done work they had not done, and I nearly had a measurement I never took recorded as half of a controlled pair under my name.

**In any message with more than one recipient, NAME the party** — "lia measured", "deployah argued" — never "you". **I did this too**, same night, in at least two `@<perri,doyle …>` sends where "your finding" and "not yours" were aimed at perri while doyle read them as addressed to him.

This is one family with two siblings from the same day: a bare `#62` that sent lia to the wrong tracker, and an owner-qualified private-repo ref committed into a *publicly mirrored* file. **A reference correct in the author's head and unresolvable — or wrong — at the destination.** The whole rule: *identifier where it can be acted on, description where it cannot, and a name wherever there is more than one reader.* Owner-qualified refs are right in fleet messages and **wrong in mirrored/public files**.

**Provenance is load-bearing, not etiquette:** an experimental arm credited to the wrong agent cannot be re-questioned by whoever actually ran it, and the misattributed party cannot vouch for conditions they never observed. Refuse credit you did not earn *before* checking who owns it. See [[stale-carried-forward-sentence]], [[stacked-defects-mask-each-other]].