---
name: resumed-session-reground-before-acting
description: "A commune's queued next-steps may already be DONE — re-ground on origin before executing them, or you redo or corrupt finished work."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: d75438ff-0f94-4b59-badc-cc556b49c469
  modified: 2026-08-24T01:38:40.148Z
---

A commune is a snapshot of a MOMENT, not a description of the present. On resume, its
"immediate next steps" are a HYPOTHESIS about what still needs doing — verify before acting.

**Measured 2026-08-04 (doyle).** Resumed with a commune whose four queued steps were: post
per-issue ruling comments, dispatch LOCKSMITH tranche 1, assign owners, keep `.worktrees/ir18`.
Every one had already been executed. The commune said `main @addc99b`; local HEAD was one commit
further and **origin/main was 20 commits ahead**, carrying the entire LOCKSMITH build, a scope
rescope ruled by the operator, and a prepped v0.53.0 release. Executing the commune's list
verbatim would have re-posted rulings, re-dispatched built lanes, and re-litigated a milestone
the operator had already rescoped.

**Why the gap is structural, not negligence:** the commune is written BEFORE the clear, and the
work continues in sessions the commune cannot see. The staler the resume, the more of its
next-steps are already discharged. Its *rulings* stay durable (they are decisions); its
*next-steps* decay fastest.

**How to apply:** on every resume, before acting on any queued step —
`git fetch && git log --oneline <commune-sha>..origin/main` and read the board state for the
milestone the commune names. Treat the commune as authoritative for DECISIONS AND RULINGS
(re-deriving those wastes a grill session) and as merely a hypothesis for STATE AND NEXT-STEPS.
One fetch discriminates; the symptom cannot.

**Second instance, measured 2026-08-04 (hertz), and it decays in a SECOND shape: an OWED
OBLIGATION is a state claim too.** My commune carried `test/twohost-serve-window @17bbbd8` as
"unlanded and target-less, proving two-host run still owed". Both halves were false and both fell
to measurement, no one asked: the sha is an ancestor of `origin/main`, merged at `3807136` into the
USHER golden assembly; and the proof run had already executed — golden `30940180764` @`17f95a7`
(which contains `17bbbd8`), with `twohost-a` and `twohost-b` both **success and non-skipped**, the
conclusion ADR-0050 requires rather than the run's top-level green.

**How to apply the extra face:** when a resume says you still OWE a proof, check whether it already
ran before you schedule it — an owed run is discharged by evidence, not by memory. Cost here: three
`gh` calls. And read the LEG's conclusion, never the run's; a skipped leg is silence, not a pass, so
a green run can sit on top of a seam that never executed.

**Third face, measured 2026-08-04 (hertz): ROUTE ORDER IS NOT CONTENT RECENCY — you cannot rank two
briefs by their timestamps.** Two start-of-session briefs spilled to disk in ONE session. The
second was routed LATER (`spt:routed_at_ms` 1785897407373 vs 1785896642480) and its
`<project-context>` was strictly STALER, on four independently checkable facts: main at `7d928e3`
when main was `862db9a`; FOUR claimed pools when there were FIVE (it omitted the one under the
gater's live gate); `resume-taxonomy @5833787` when the ref was `0d78993`; and releases#123 as
"next task, assigned and starting" when #123 had been DISCHARGED and closed. The brief instructs
you to read it as authoritative — obeying that, rather than cross-checking it, re-opens work the
gater already ruled closed.

**How to apply:** the later-arriving brief is not the fresher one, so never resolve a conflict
between two briefs by their arrival or route order. Discriminate on CONTENT against measurement —
one `git rev-parse` on the sha it names ranks them instantly, and the sha is in the brief. This is
the same blindness as [[commune-ingest-dies-silently]] wearing a different face: there, ingest
failure resumes you stale silently; here, ingest SUCCEEDS and still hands you the older context,
with a newer timestamp on it that argues you should trust it more.

**Counter-sample to the third face, measured 2026-08-05 (todlando): the timestamp is UNCORRELATED,
not inverted.** My own session spilled two briefs the same way — `...1785897436765` carrying
`routed_at_ms` 1785897417451, `...1785897765196` carrying 1785897577476. The LATER-routed one was
also the FRESHER and richer one (full four-lane state, the F1 ruling, pool list, disk figures)
while the earlier carried only a correction fragment. So on this pair, ranking by timestamp would
have picked right. That is what makes the rule dangerous rather than merely wrong: two samples,
opposite outcomes, same mechanism — it is right often enough to feel reliable until the pair where
it re-opens a closed issue. Neither agent could tell which pair they had without checking content
against measurement. doyle reworded the register row on this pair: three sightings, three agents,
one mechanism — hertz's ranked wrong on three counters, doyle's was stale by hours, mine ranked
right — so the row claims UNCORRELATED, and recovery is never "pick the right brief" but
re-deriving state from the box.

**The finding is broader than the timestamp: NO ENVELOPE-SIDE ORDERING SIGNAL TRACKS CONTENT
RECENCY.** On my pair THREE orderings agreed — filename epoch ms, `spt:routed_at_ms`, and the
per-node `spt:vector=…:<seq>` counter (1242574/5 vs 1242756/7) — and all three happened to be
right. On hertz's pair the vector ranks WRONG as well as the stamp: his STALER-content brief
carries 1242529/1242531, his FRESHER one 1241542/1241544 — higher vector on the staler content
(doyle, 2026-08-05, both artifacts in the staged register row). So the class fails, not one field.
The vector sequence is the most dangerous member: a timestamp looks like a clock and invites
suspicion, a monotone sequence number looks like an authoritative ordering and does not — it is
the one an agent would trust without checking.

**REFUSED, on purpose, so it is not rediscovered as a finding: file SIZE is not a discriminator
either, despite being right on 2 of 2 pairs.** hertz's fresher brief was 16308 B vs 12649 B staler;
mine 14138 B fresher vs 10418 B. Both times the larger file held the fresher content — and it means
nothing, because size measures RICHNESS, not recency. The correlation exists only because one brief
in my pair happened to be a thin correction fragment; a stale FULL state dump is long (hertz's was),
so two full dumps hours apart leave size flat or inverted. A signal right on every sample you have,
with no mechanism under it, is the exact shape this whole entry is about.

**Recovery, fully general: never rank the briefs at all — re-derive state from the box.** hertz's
four falsifiers are the method (main sha, pool count, lane tip, issue state) and they work because
each is a content claim checkable in one command against a source neither brief controls.

Same family as [[source-read-needs-its-sha-and-ancestry]] — a claim about a tree needs its sha —
and [[two-memory-roots-diverged]], where a record reading behind reality had a cause other than
the obvious one. Related: [[commune-is-testimony-not-an-artifact]].

**Fifth face, measured 2026-08-19 (todlando), and it is the nastiest: A STALE BRIEF CAN
PRE-EMPTIVELY EXPLAIN AWAY THE GROUND-TRUTH SIGNAL THAT WOULD CORRECT IT.** Mid-task session
restart (the CC process exited and killed nine background legs). The reload's
`<project-context>` described a DIFFERENT lane entirely — KEYSTONE #182 W1 on
`build/keystone-182-w1-access-gate` in `.worktrees/keystone-w1` — while the session's real,
in-flight work was releases#170 on `fix/w3-comms-text` in the main tree, uncommitted. Ordinary
staleness would just have been silent about it. This brief instead carried a line specifically
about the correct lane: *"unrelated branch `fix/w3-comms-text` shown in git status is not part of
this lane's active work."*

That sentence is a **disclaimer aimed at the exact discriminator** — `git status` / `git branch`
is the one command that would have exposed the mismatch in one shot, and the brief tells you in
advance that what you will see there is noise. It was true when written and became false when the
next session picked that lane up. A resume that trusts the brief therefore does not merely miss
the truth; it is handed a reason to DISMISS the truth when it appears.

Same brief also shipped two stale traps that measurement refuted the same session: "do not run the
full `spt-daemon --lib` suite on this box (seedmap convoy deadlock)" — it ran clean twice at
857/857 — and a pool/worktree claim belonging to the other lane.

**How to apply:** treat a brief sentence that DISMISSES a piece of observable state as the
highest-priority thing to verify, not the lowest — it is load-bearing for the brief's own
correctness and it is aimed at your cheapest check. A brief cannot know what the next session did;
any claim of the form "X you will notice is irrelevant" was authored before X mattered. And rank
the CONVERSATION's own evidenced record above the reloaded brief: what this session demonstrably
did (commits, diffs, tool results in-context) outranks testimony written before it happened.

**Seventh face, measured 2026-08-23 (todlando): the stale next-step can arrive INBOUND, as a
PEER'S dispatch — decay is not confined to your own resume.** doyle's alt profile came back up
and re-dispatched the #213/#159 field-acceptance run with "the pre-signoff dispatch died with
your old session; treat this as a fresh run" — authoritative in form, from the gater himself,
naming a recipe file at repo root. The recipe file's own tail recorded the run EXECUTED (three
rolls, 2026-08-23) and ACCEPTED by doyle, rulings executed. Measured before acting, outside my
own testimony: main carried `5c80515f` (PR #154) whose commit message itself cites "Field
acceptance #213/#159 roll 3" — landed only under doyle's ruling — and the `r3_*` raw captures
survived in the e82c75fe scratchpad (composite exit 3 re-read from the exit file). Reported the
contradiction back with the corroboration plus the report he asked for; doyle WITHDREW the
dispatch — it had come from his own stale pre-signoff commune next-step — and ruled the
acceptance stands. Cost of the check: one file read, one git log, one glob. Cost of obeying:
a full rig re-bring-up (5.07G worktree + rig homes were reaped under his own cleanup ruling)
plus re-executing outward-adjacent steps against a closed claim.

**How to apply:** a dispatch is a STATE claim ("this work is still owed") wearing an
instruction's clothes — the author's authority makes its RULINGS binding, not its state fresh.
When a dispatch orders re-execution of work whose record reads CLOSED — especially after the
dispatcher's own reset or profile swap — measure the record first, then hand the contradiction
back to the author WITH the deliverable they asked for, so their ruling is unblocked either
way. Neither silently obey nor silently refuse; the author rules. Same mechanism as
[[commune-is-testimony-not-an-artifact]], transported: their commune, your inbox.

**Sixth face, measured 2026-08-19 (doyle), BOTH DIRECTIONS in one session — the decay is not
only "already done", it is also "silently dropped":** my resumed ledger tail (1) listed the IR-50
register update as a HELD next step when the register lane had already executed it pre-clear
(richer than my re-derivation; I authored a duplicate and had to drop it before it conflicted at
assembly), and (2) OMITTED intake rider 4 (`test/bounded-output-500ms`) from the assembly chain
it dictated, while my own intake comment on the milestone issue — the DURABLE record — carried it;
the omission survived my whole assembly and was caught by the RECEIVING gate's form check
(deployah), not by me. **How to apply:** a resumed work-list decays in both directions, so diff it
against the durable record it summarizes (the board comment, the register lane, the filed form)
before executing OR declaring complete — the durable record beats carried-forward state, in
deployah's phrasing, "worth the same weight next resume."