session 2026-08-25 evening: Tarbuckle wired across five surfaces; PENDING-151 steps 1 and 2 both run

Session state, memory rotation, KG (6 lines), Symmetria ledger, daily note, and the
governance filed this evening: PENDING-159 closed on option 1, PENDING-160 (the harness
gap, at the jurist's direction), PENDING-161 (a false premise in a placed ruling), and
PENDING-151 amendments 1 and 2.

Active Session rotated. ⚠ The demoted block carries a deliberately-preserved false claim —
the stale STEWARD OWES line, marked by a live STATE-CLAIM and agreed as next session's
first act. Carried forward explicitly in the new block and the marker's claims: text
updated to name its new home, so the rotation did not discharge it as a side effect. That
trap is filed as a /wrap-up §3 patch proposal in the harvest register.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J6hZXNYSxEfZseBGTni4sf

claude/memory/skill-harvest-register.md

@@ -548,3 +548,20 @@ finalising a note the hook already created, so `SKELETON` is the natural source.
 ⚠ **Why this is filed as a detector rather than a ladder entry.** The verification ladder is **FROZEN** under REVIEWED-123 and takes no additions from any source until the trial is graded, so it could not go there regardless. But the freeze is not the reason: even unfrozen, this is a rule that fires only if someone remembers it while writing a control, and the measured retrieval for that class is ~10%. The failure it prevents was caught **by the controls running on every invocation**, not by anyone recalling a rule — which is itself the argument for routing it to a detector.
 
 ⚠ **Honest limit on the detector, stated before it is built:** it catches a fixture naming a file *currently dirty*. It would NOT have caught today's case at the moment the control was written, because `FOOL-SEED-RULE.md` was clean then and dirtied minutes later. The detector's real firing moment is **the drift-check run**, where it would flag "this control's fixture is now dirty" — a warning, not a block. **Filed with that limit on its face rather than discovered after building.**
+
+## Proposed 2026-08-25 evening wrap — awaiting steward
+
+| # | kind | skill | proposal | firing moment | routing |
+|---|---|---|---|---|---|
+| — | patch | `/wrap-up` §3 | **Rotation must not discharge a claim by side effect.** Demoting the Active Session block moves whatever it carries into `MEMORY-reference.md`. Tonight that block held a deliberately-preserved false claim (`STEWARD OWES: place REVIEWED-127`), marked by a live `STATE-CLAIM` and agreed as next session's first act. **A blind rotation would have made the claim invisible while its falsifier kept firing — a gate reporting FALSIFIED forever with nothing left to correct.** Proposed step: before demoting, grep the block for `STATE-CLAIM`/`DEFERRED-DECISION` slugs and for anything the session agreed to carry; if found, restate it in the new block and update the marker's `claims:` text to name its new home. | **at `/wrap-up` §3, which already exists** — the rotation itself is the trigger | named step in `/wrap-up` (the strong routing tier) |
+
+**Why `[PROPOSAL]` and not the FIX lane:** it adds a *required check* to a skill rather than
+changing what the skill records, and the classification test's first clause ("what the
+executor may do without asking") is arguable either way. The lane is provisional and its own
+instruction is *when in doubt, propose*. ⚠ Also: the hazard it addresses is **visibility of an
+open item**, which is the hard floor's subject — filing it in the lane would be deciding a
+floor question in the executor's favour.
+
+⚠ **Caught by doing it, not by inspection.** The trap was noticed only while writing the
+rotation code and asking what happened to the line. Nothing in `/wrap-up` would have surfaced
+it, which is the argument for the step.