---
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]].

## ⚠ The rule UNDERSTATED the hazard: an inline body EXECUTES, so a message can MUTATE A TREE (doyle, 2026-08-22)

This entry said backticks "silently eat the command text". That is the *benign* half. **The span is
RUN.** Composing a `spt send` body inline, I wrapped two technical terms in backticks; bash
command-substituted both:

- `mspdbsrv.exe` → "command not found", leaving a HOLE where the process name should have been. The
  recipient inferred it from context and flagged that he had inferred it — the message arrived
  *plausible and incomplete*, which is the same family as every instrument-that-never-ran defect.
- `cargo clean -p spt-net` → **IT RAN.** 4599 files, 4.8 GiB removed from the ROOT checkout's pool,
  unintended and unauthorised, noticed only when I read my own tool output afterwards.

**So a message body is not text — it is a command line.** Damage was bounded (source untouched;
rebuild cost in a tree nobody was building in; a peer's separate evidence in another worktree
unaffected) and that was luck, not design: the same slip around a `rm`, a `git checkout --`, or a
`reset` spends something that does not come back.

**I broke this rule while writing a message about measurement discipline**, on a "quick" body, having
used the file form all session for long ones. That is the tell: the exception is always the short
message, because the file step feels disproportionate to the payload — and the payload's length has
nothing to do with the hazard.

**The rule, with no exception for short bodies:** compose EVERY send body to a scratchpad file and
`spt send <target> < file`. Never `printf "..." | spt send`. Same for `gh issue comment` — use
`--body-file`. If a body is short enough that a file feels silly, it is short enough to write without
backticks; use plain words for command names.

Kin: [[send-body-from-file-not-inline]] (the positive form) ·
[[a-bare-cd-silently-repoints-every-later-read]] (scaffolding that acts while you attend to the verb).