---
name: narrowing-an-unconditional-call-must-fail-open
description: "When you gate a call that used to be unconditional, its error path is a behaviour narrowing nobody ruled — an unreadable input must mean DO IT, not skip it; and the gate can also turn a loud diagnostic into a false alarm."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 06835e88-af04-4f9f-9af0-c87b0c06eff7
  modified: 2026-08-20T07:56:12.069Z
---

Two faces, both paid on releases#177 (2026-08-19/20), both about the same act: **putting a
condition in front of a call that previously always ran.**

**Face 1 — the loud arm's precondition (I found this by MEASURING, not by design).** #177 bounds the
engine room's briefing ENQUEUE to once per session; doyle ruled the fix at the enqueue seam and
"NOT at delivery", so my first build left `present_engine_room_briefing()` unconditional. The int
cell's daemon log then showed the second seat driving an EMPTY spool, taking zero rows, and printing
`ENGINE_ROOM_BRIEFING_UNPRESENTED` — the LOUD line that says a session opens WITHOUT its posture
briefing. False, on every ordinary re-attach, about a briefing that had been delivered at the first
seat. A diagnostic whose precondition you just removed becomes a false alarm, and an operator who
learns to ignore it ignores it on the day it is true. So the drive got gated on whether anything is
OWED. doyle ratified the deviation from his own literal wording — it poisons the exact diagnostic
channel IR-50 had just made readable.

**Face 2 — the error path is a narrowing nobody ruled (doyle found this in my code).** My gate read
`pending_count_non_deferred_at(...).unwrap_or(0) > 0`. A spool READ ERROR therefore collapsed to
"nothing owed" and silently skipped a retained row's re-offer — behaviour the unconditional call
never had. **An absent answer is not a zero.** Err must mean `owed = true`: the call fires and its
own arms speak about the broken input.

**Face 3 - the SAME defaulting, inside the witness written to forbid it (doyle found this too,
releases#199, 2026-08-21).** My row-removal stamp printed
`removed.as_ref().map(...).unwrap_or_default()` for BOTH its fields, so a row some other path had
already de-tabled published as an empty endpoint that lived `0ms`. The requirement I had just
authored says AN ABSENCE IS NEVER A VERDICT, and I had built #201 to doyle's ruling that an absent
exit code is NAMED and never rendered as 0 - and then defaulted an absence to zero in the one
diagnostic whose whole job is to keep an absence from being read as a verdict. **A rule you wrote
does not defend the code that states it.** `unwrap_or_default()` on an Option that means "this
fact is unknown" is the same act as `unwrap_or(0)` on an unreadable predicate: it fabricates a
measurement. Census every `unwrap_or_default`/`unwrap_or(0)` in a change whose subject is an
absence - especially in DIAGNOSTICS, which no test reads and which a field reader will believe.

**How to apply:** the moment you write `if <predicate> { thing_that_used_to_always_run() }`, ask two
questions before anything else. (1) What does `thing` SAY when it runs with nothing to do — is one
of its arms loud, and is that arm's sentence still true now that I can reach it with an empty
subject? (2) What does the predicate answer when its input cannot be read — and is that answer a
skip? A gate may only trim where it can PROVE the work is unnecessary; every uncertain input keeps
the old behaviour. Neither face reds: face 1 is a green test beside a lying log line, face 2 is an
error path no test exercises. Related: [[surfaced-payload-names-its-cadence]],
[[correct-fix-deletes-accidental-mitigation]].