---
name: generous-bound-is-free-when-the-poll-exits-early
description: "A timeout guarding an early-exit poll costs a green run NOTHING, so tightness buys no speed and only manufactures load flakes; and the elapsed wait must ride the red, because at-budget vs under-budget is what tells bound-expiry from real failure."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: ad8d3ea6-75c8-4bdd-8c1a-ff1cd6b81927
  modified: 2026-08-04T21:12:59.695Z
---

A bound on a loop that **returns the instant its predicate goes true** is spent ONLY by
a run that never gets there. Raising it slows no passing run; the entire cost is how
long a genuine failure takes to declare. So a tight bound on such a poll buys nothing
and manufactures load flakes — and a tight bound on a *control* arm is worse, because it
makes an honest success race a deadline that exists for a different arm's benefit.

**Why:** three separate rows in the same package carried the same shape (2026-08-04).
`psyche_real_bound_kill_soft_budget_e2e`'s positive control fired a ~60ms child through
the 1s bound that existed to make ten KILLS cheap (measured: min 50 / median 60 / max
157 ms, so ~6x margin at worst) — one assert-FAIL in seven golden Windows legs. The
teardown family then produced two more at the same magic number: a 10s poll on an
ASYNCHRONOUS termination (`TerminateJobObject` returns before the tree is gone) at
`daemon.rs` grandchild row and `resident_service_e2e.rs:434`. Same defect, three sites,
one number nobody had re-derived per arm.

**How to apply:**
- Ask per ARM, never per test: what must finish inside this bound, and is that the thing
  the bound exists for? A kill bound and a success bound are different numbers.
- Prefer a generous bound + early exit over a tight one. State in the comment that a
  green run pays none of it, or someone will "optimize" it back down.
- **Carry the elapsed wait into the failure message.** A wait sitting AT the budget
  cannot distinguish "never happened" from "still in flight"; a wait well under it can.
  Without that number both diagnoses read identically — which is how this family
  produced reds nobody could classify.
- A raise is not a fix, and must not be reported as one. It converts a fast ambiguous
  flake into a slow loud failure; say that, and state the falsifier (here: a 60ms child
  exceeding 30s would surface as a 30-second stall, not a 1-second coin-flip).
- Per-leg bounds can be swapped through a production seam rather than forked hosts —
  `refresh_manifest` moved the bound while the host kept the counters the assertions
  read. A second host would have reset them and made the closing row vacuous.

Kin: [[intermittent-green-is-zero-information]] (a raise cannot be proven by greens),
[[reap-step-duration-is-not-the-window]], [[a2-golden-r2-specimens]].