---
name: signature-match-is-not-root-cause
description: Operator correction 2026-07-19 — I pinned an RCA on a mechanism that reproduced the failure signature byte-for-byte but was NOT what happened; ask how the user actually invoked it before concluding.
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 5327083b-be0b-4d72-8796-780ec5f26dcb
  modified: 2026-07-20T06:57:11.152Z
---

Diagnosing a silent `/sptc:ready` injection failure, I found that a leading newline reproduced the
failing trace **byte-identically** (`skill=0ms`, every other stage normal) and reported it as the root
cause. Operator: *"my input had no whitespace i entered myself. i simply typed `/ready terminus`."*
The real trigger was the bare shortname. My mechanism was a real (latent) bug — but not this bug.

**Why:** the transcript stores CC's CANONICAL `<command-name>/sptc:ready</command-name>`, so it could
not distinguish the two invocation forms. I had an unfalsifiable-from-evidence gap and filled it with
the first mechanism that matched the signature, instead of asking the one cheap question. The
operator's own opening words even said "after `/ready` or `/live`" — the answer was in the request.

**How to apply:**
- A mechanism reproducing the signature is a CANDIDATE, never a conclusion. Ask: does any OTHER
  mechanism produce this same signature? Here at least two did.
- When the failure depends on user input, **ask what they actually typed/clicked** before pinning
  cause. One question beats an hour of bisection.
- Re-read the request for the answer before hunting; users often state the trigger in passing.
- Say plainly when corrected, and record in the artifact (hazard/ADR) which route was real vs merely
  signature-matching, so the next reader doesn't inherit the wrong story. I did this in
  KNOWN-HAZARDS §4.1's cite block.

Companion trap from the same session: my own tooling lied to me twice — MSYS argv path-conversion
turned `/ready terminus` into `C:/Program Files/Git/ready terminus` (only `/sptc:x` survived, because
its colon reads as a path-list), and a `printf` payload produced INVALID JSON (`\U` is not a JSON
escape) that faked the same `skill=0ms`. **Set `MSYS_NO_PATHCONV=1 MSYS2_ARG_CONV_EXCL='*'` for any
leading-slash argv on Windows, and build JSON with a JSON writer, never printf.** Related:
[[v0251-interrupt-watch-window]] (a `2>&1` artifact I also first misread as a real outage).