---
name: a-fallback-that-fires-only-in-release-is-untestable-by-construction
description: "doyle's ruling on the emit_line! interior-newline arm — a debug_assert plus emit-anyway puts the real behaviour in the one build no assert watches and no test looks at; escape instead, and make the escape its own breadcrumb."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 43af483b-6d22-46cb-9d99-8b7713a6ff46
  modified: 2026-08-29T08:15:50.378Z
---

**A `debug_assert` paired with "carry on anyway" does not choose a lenient behaviour — it hides
the behaviour in the only build nobody tests.** doyle ruled this 2026-08-29 on the single-write
emission lane (`REQ-EMIT-SINGLE-WRITE`, `EMISSION-SINGLE-WRITE-JIT.md` §4). The question was what
`emit_line!` should do in RELEASE when the rendered text carries an interior newline — a real case,
not a hypothetical: `servicehost.rs:887` interpolates a captured multi-line tail, so the newline
arrives in a VALUE and no static check can see it.

The rejected option was debug_assert + emit-anyway-as-one-write ("a mis-shaped line beats a lost
diagnostic"). The ruling is **escape** (rewrite the interior newline to the two-character `\n`)
plus the debug_assert, with the escape spelling PINNED in a unit so it cannot drift.

**Why:**
1. Emit-anyway reintroduces exactly the class the lane retires (multi-line text on a single-line
   surface) and does it **only in release** — where no assert watches and no test looks. That is a
   defect that **cannot appear in any build we test**, which is worse than a loud one.
2. The escape is **its own breadcrumb**: a literal backslash-n sitting in a parsed line names the
   offending caller from the ARTIFACT ALONE, no repro needed. That is
   [[absence-needs-sibling-probe]]'s rule applied in advance — build the emitter that would show
   it, before you need to ask whether it happened.
3. Consumers keep parsing one line either way; under emit-anyway a torn token line is **silent
   parse corruption**, which is the failure mode with no symptom at the reader.

**How to apply:** whenever a design reaches "assert in debug, tolerate in release", say out loud
which build carries the real behaviour. If the answer is release, the tolerant branch is the
product and the assert is decoration — so pick a tolerant branch that PRESERVES the invariant
(escape, clamp, truncate-with-marker) rather than one that abandons it, and give it a unit that
runs in the shape release actually takes. Related: [[instrument-soundness-guards]] guard 1 — an
arm whose failure signature is indistinguishable from the thing it guards is a broken instrument;
this is its twin, an arm whose failure is invisible to every instrument by construction.