session 2026-08-31: PENDING-164 AMENDMENT 2 + PENDING-171; two addenda; two MEMORY.md claims corrected

The wrap's own findings, none of which were the session's subject:

PENDING-168 ADDENDUM 1 — the /wrap-up §1.6 FIX lane is PROVISIONAL until a
steward-jurist check-in that its own index calls due. Batch 1 closed 2026-08-02;
29 days, no check-in, and one executor-classified FIX applied past the boundary.
The deferral machinery reported "5 tracked, none due" because nobody ever gave
the check-in a DEFERRED-DECISION block. Filed one with a past trigger; the
drift-check now reports 1 of 6 COME DUE. Proved by readback.

PENDING-104 ADDENDUM 2 — two live executors today, detected by neither. A
sibling session read an mtime, worked out this session was concurrent rather
than previous, and stopped rather than write to PENDING.md. The wake digest had
drawn the opposite inference from the same fact.

MEMORY.md: the Fool line asserted NOTHING WIRED — false on all three clauses;
statusLine has been running tarbuckle-body.py for six days. Ladder N-now is 44,
not 51, and falling. Both verified against the substrate, not relayed — the
sibling's counts were off in both directions.

Today's one harvest candidate filed as PROPOSAL rather than applied, on the
lane's own suspension rule, and it corrects a banked proposal's mechanism: a
required-section check derived from the SKELETON constant cannot detect the
drift, because SKELETON is the copy that is wrong.

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

PENDING.md

@@ -6498,3 +6498,53 @@ Two things follow, and they point opposite ways. **The check fired correctly**
 
 **Files affected:** `scripts/prior-art.py` (`OWNED_HOSTS`, `owned_repos`, `controls`); `scripts/governance-mcp.py` if the delegate's proof surface changes.
 **Awaiting:** Steward authorization.
+
+---
+
+### PENDING-168 — ADDENDUM 1: the FIX lane's own check-in fired 29 days ago and the deferral machinery cannot see it
+**Date:** 2026-08-31
+**Tag:** [HARDENING] — the ask is already discharged below; this records why.
+
+**The instance.** REVIEWED-85 authorized the `/wrap-up` §1.6 FIX lane as **PROVISIONAL**, until a steward–jurist check-in *"after the first batch or one month, whichever comes first."* `skill-harvest-fix-lane-index.md` says in its own words: **"Batch 1 is complete, so the check-in is due."** Batch 1 completed **2026-08-02**. **No check-in is recorded. 29 days.**
+
+**⚠ And the lane kept running past its own boundary.** Two changes were applied after batch 1 closed: the 2026-08-24 `## Corrections` addition (**authorized** — direct steward instruction on jurist reasoning, and the index says so on its face) and the 2026-08-08 `Instruments` field, which was **executor-classified** under a lane whose authorization had lapsed into overdue-review. The classification was probably right on the merits; that is not the point. **The lane's own text says *"Until that review, treat a borderline call as [PROPOSAL]"*, and a lapsed provisional authorization makes every call borderline.**
+
+**⚠ The finding is not the lapse — it is that the machinery built for exactly this could not see it.** `governance-drift-check.py` reported today: `✓ deferred decisions: 5 tracked, none due`. **A green line, while a condition that fired four weeks ago sat unmarked.** The check-in was never given a `DEFERRED-DECISION` block, so it lived in the same prose the drift-check counts and refuses to classify — one of the **143** prose deferral mentions it reports as un-machine-readable. This is PENDING-168's thesis reaching its own governance apparatus: *a condition that can only be honoured by remembering will be broken*, and the instrument that would have remembered was not told.
+
+**⚠ It is also PENDING-157's class from the other side.** The lane has no resolution state, so "check-in done" has no expressible form; the only way the index could record its own discharge is prose that nothing reads.
+
+**Discharged in this act, not proposed:**
+
+<!-- DEFERRED-DECISION: fix-lane-provisional-checkin
+     since: 2026-08-02
+     trigger: date 2026-08-02
+     owner: steward
+-->
+
+The block is filed with a trigger date **already in the past**, deliberately, so the drift-check reports it **DUE on the next run** rather than quietly waiting. Agenda is already written and needs nothing from the executor: `skill-harvest-fix-lane-index.md` §*Check-in agenda* carries both items, the second folded in by REVIEWED-86 Q4 (*the record is not just written, it is read*).
+
+**Consequence adopted for this session, before the finding was convenient.** Today's one harvest candidate — the `daybook-ensure.py` SKELETON missing the `## <Project>` heading `/wrap-up` §7.5 specifies — is filed as a **[PROPOSAL] in the skill-harvest register, not applied through the lane**, on the lane's own suspension rule. It would otherwise have been a clean FIX with an exact 2026-08-24 precedent.
+
+**Files affected:** `PENDING.md` (this block). No skill or script changed.
+**Awaiting:** the steward–jurist check-in itself, now machine-surfaced.
+
+---
+
+### PENDING-104 — ADDENDUM 2: two live executors, and nothing in the apparatus detects it
+**Date:** 2026-08-31
+**Tag:** [HARDENING]
+
+**ADDENDUM 1** recorded the executor's filing silently corrupting a checker's view of that same filing — one writer, one reader, one file. **Today produced the two-writer form, and it was caught by a party rather than by a mechanism.**
+
+**What happened.** Two Claude Code sessions were live simultaneously on 2026-08-31. The sibling session woke, read the digest's claim that *"PREVIOUS SESSION DID NOT WRAP"*, **checked the substrate instead of believing it** — the transcript was still growing and had committed to `dotfiles` one minute into that wake — and correctly concluded the other session was not previous but **concurrent**. It then **stopped before touching the pulling thread**, on the explicit ground that two sessions appending to `PENDING.md` is ADDENDUM 1's class in its worst form. Its ledger records `dotfiles is ahead 1 … the sibling's, not mine to push.`
+
+**That is the right behaviour and it is exactly why it should not be relied on.** Nothing detected the collision. No lock, no lease, no warning at wake. It was avoided because one session read a timestamp attentively and drew an inference the digest itself had drawn wrongly. **The next session need only be slightly less careful, or slightly less lucky, and two appends interleave in the one file the whole governance model routes through.**
+
+**⚠ The digest's own line was the near-miss.** *"PREVIOUS SESSION DID NOT WRAP"* is a **negative state-claim with no falsifier** — PENDING-158's class, in the instrument that every session reads first. It was right that no wrap existed and wrong about why, and the wrong half is the dangerous one: a session that believes the other is finished has no reason not to write.
+
+**Corroboration this addendum did not have to look for:** the sibling also held back **two substrate corrections** rather than racing this session's memory write — including that `MEMORY.md` asserted the Fool `NOTHING WIRED — no statusLine, no script, §13.1 spec unwritten` while `settings.json` has been running `tarbuckle-body.py` as `statusLine` all along. **Correct restraint cost the record four hours of a false claim in the file loaded at every wake.** Both corrections were verified against the substrate and applied at this wrap; ⚠ the sibling's own counts (7 scripts, 6 state files) were off in both directions against the measured 5 and 7, which is why they were **re-measured rather than relayed**.
+
+**Not filed as a new item, deliberately** — this is ADDENDUM 1's mechanism with the writer count changed, and a separate number would split one class across two dockets. **Also a datum for PENDING-89**: the digest and the sibling are differently positioned readers, and the sibling caught what the digest asserted. Constraint 6 working, on a day it was not being tested.
+
+**Files affected:** none.
+**Awaiting:** Steward authorization — the option space is not drafted here, because whether concurrent sessions are worth a mechanism is a steward judgement about how often two are run at once, which the executor cannot observe.