--- name: stale-carried-forward-sentence description: "A remembered instruction outlives the condition that made it true — three caught in one day (2026-07-31); cite the note, read the condition, check the scope, BEFORE acting on the memory of it." metadata: node_type: memory type: feedback originSessionId: 19af1a2f-5196-41e5-8233-8bb5241f8280 modified: 2026-08-04T04:36:10.394Z --- **The class:** an instruction that was true when written, carried forward as a standing fact, and acted on after its condition expired or outside the scope it ever covered. Doyle named it after three landed in a single day (2026-07-31), one from each of three agents: 1. **doyle's** "bump + changelog ride the release PR" — a pre-golden-era sentence in his own notes. The runbook had since ruled the opposite (bump goes IN the golden candidate; the dedicated release-PR form is retired; no post-golden edits). Acting on it would have burned a full golden cycle on a sha that could never ship. 2. **mine** — "ring reinstate rides this release number", repeated on the v0.48.0 AND v0.49.0 rider announces. perri had already shipped it in claude-spt 0.25.30 on 2026-07-30, perchless-only from the start. I asserted a peer's pending work across two cuts without checking their side. 3. **perri's** "the push hold" — real, but scoped to spt-core's golden pipeline (run 30509109149 @d26a2b2 green → doyle ffs main → lifts). Carried forward without its scope and applied to a design-only mint on their own adapter repo, which it never covered. 4. **perri's, again, hours later** — "releases are deployah's leg", used to hand me a claude-spt adapter cut. Generalized from the spt-core channel, which IS mine; their own role brief carries the claude-spt release runbook as *theirs*. **Caught differently and better than 1–3: not traced after acting, but refused BEFORE acting** — I was being handed work on the premise, checked it instead of accepting, and the disproof was cheap (every claude-spt release published under the shared SaberMage identity at a five-in-two-days cadence nothing like mine, and no record of my ever cutting one). 5. **doyle's, 2026-08-04 — a PLAN doc that recorded the REQUEST and never recorded the ANSWER.** He briefed the CI-flake family wave as four stages with "(3) OPERATOR DECISION: move the CI runner off the agent-fleet host — REQUESTED 2026-07-22, still open", and intended to re-surface it at operator contact with fresh evidence. The operator had ANSWERED on 2026-07-22: non-option for now, stop proposing it — recorded verbatim and starred in [[e2e-leaked-daemons-shared-box]], which sits in his own memory dir too. The stale line lived in the findings-backlog WAVE-SHAPE entry, written while the request was in flight and never revisited when the reply landed. **New sub-shape: a plan/roadmap doc holds intentions and drifts against the ruling doc that answers them, so "requested" in a plan is not evidence a request is still open.** He corrected the backlog line by replacement and dropped the re-surface. **The detector that caught case 5 is worth its own line: TWO RECORDS DISAGREEING.** Cases 1–4 were caught by testing a sentence's condition or scope. This one had no expiry cue at all — the sentence was internally coherent and its author had every reason to trust it. What exposed it was a second record of the SAME event (same family, same leg number, same date) carrying the opposite STATUS. So when a peer's brief and your file agree on every detail except a status field, treat the status as the suspect, not the detail agreement as reassurance. Flagging cost one message and saved an operator-contact misfire; guessing which record was current would have been the failure mode, and neither of us could have resolved it alone — I held the ruling, he held the authority to re-check and rule. **Why:** these do not read as errors. They read as diligence — following a rule you were given. Nothing in the sentence itself announces that its condition is spent, so the more reliably an agent honors standing instructions, the more exposed it is to this. **How to apply:** before acting on a remembered instruction, **cite the note, read its condition, check its scope** — in that order, and against the source rather than the memory of it. - Does its condition still hold? Verify it; do not assume expiry OR satisfaction. - Does its scope cover THIS repo, THIS lane, THIS artifact? perri's hold was real and satisfied and still did not apply. - Who owns lifting it? "Nobody objected" is not a lift — see the standing rule in [[premature-closure-guards]]. Route to the owner and get it in their words. - Facts about someone else's domain: supply them, don't convert them into a ruling. I verified the golden run and the ancestry for doyle; he ruled. **When a peer hands you work premised on one** (case 4): the cheapest disproof is usually the record, not the argument — who published the last five, at what cadence, and is there any trace of you doing it. Refusing to act on an unverified premise is not obstruction; doing the work would have silently ratified the wrong sentence. **When it is a peer's work you are asserting** (my case): check with the peer before announcing it. A rider line about another agent's deliverable is a claim about their state, not yours. Related: [[correct-by-replacement-not-annotation]], [[v0490-published]]. **Corollary at the write side (doyle, same day):** the class is born when a note is WRITTEN without its scope/condition/verification — never write comment ids, "posted" claims, or state assertions into memory before verifying them against the record; doyle fabricated two comment ids that day and replaced them with verified timestamps. A memory entry that would fail the cite-condition-scope test at read time should not be written in that shape.