structure-at-the-write-sitelisted

# Record the Structure at the Site That Knows It ## Problem Somewhere a function knows three things: what happened, whether the damage is bounded, and what was established about the subject. It writes one sentence containing all three, and returns. Downstream, other code needs those facts back. It cannot ask, so it greps: ```ts const UNBOUNDED = /remaining count unknown|abandoned after|stopped after/; const bounded = !UNBOUNDED.test(cause); ``` This works for exactly the messages that existed when the regex was written. It is not a parsing problem — it is an **information-destruction** problem, and the destruction happened at the write site, several files away from where it hurts. The failure is asymmetric in a way that makes it hard to spot: the pattern match does not error, it returns the *wrong* answer, and by construction it returns the answer that corresponds to "none of the known bad phrases were present" — usually the optimistic one. ## Context / Trigger Conditions - A regex, `includes()`, or `startsWith()` over a message/cause/reason string that decides a boolean, an enum, or a branch. - Severity, retryability, or category derived from an error's *text* rather than its type or code. - A structural fact inferred from a *correlated* field: "it reached stage 3, so the object must exist"; "the timestamp is set, so it succeeded". - Two call sites producing messages for the same condition, only one of which matches the downstream pattern. - **The tell:** you