[HARDENING] File PENDING-157: the deferral schema has no resolution state

The steward's scope point on yesterday's discharge, taken. Renaming the key closed
one trigger; the next will need the same hand-rename by whoever is in session. If
census 01 found decay is how gates fail here, a schema that cannot express "answered"
is what produces the decay, and renaming keys one at a time is living with it.

Filed while there is exactly ONE instance and three tracked deferrals remain. The
window matters: once a second is renamed by habit the convention is established and
the schema question stops being asked. Filed, not built — that was the direction.

Carries a sharper half the rename surfaced: resolution must be unsatisfiable without
a pointer, so a discharge that records THAT a gate closed but not WHAT closed it
becomes impossible to express rather than merely discouraged. Plus two conditions on
the recommendation (resolved blocks stay counted as a closed ledger; a dangling
pointer is a register-integrity defect) and three required controls.

Also writes the missing reverse pointer into FOOL-BONES §6. The discharge block
already pointed at the derivation record and 06b3d8b's message named it; the record
did not point back. Written at both ends now — one direction only is how a successor
learns a gate was closed but never why.

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

PENDING.md

@@ -4930,3 +4930,33 @@ and obeyed, which is the described-not-invoked class that had the link canary ha
 a first firing is observed on the live path* — since (b) is now run and (a) would re-derive it.
 
 **Awaiting:** Steward authorization.
+
+---
+
+## PENDING-157 — The deferral schema has no resolution state, so every discharge is a hand-rename
+**Date:** 2026-08-25
+**Tag:** [HARDENING]
+**Summary:** `DEFERRED-DECISION` declares `since` / `owner` / `trigger` / `discriminator` and nothing for *answered*, so a decision that has been taken can only be closed by deleting the block (losing the record) or renaming its key by hand (losing machine-checkability, and depending on the reflex the mechanism exists to replace).
+
+**Rationale.** Today `fool-beacon-derivation-run-once` fired for real, the act ran, and the block was closed by renaming it to `DISCHARGED-DECISION`. That worked, and it is per-instance. The next trigger to come due will need the identical manual rename, performed correctly, by whoever happens to be in session.
+
+This is the shape census 01 already found: **decay, not construction, is how gates fail here.** A schema that cannot express "answered" *produces* the decay — the only alternatives it offers are erasing the record or a reflex, and a reflex is precisely what a trigger mechanism is built to stop relying on. Renaming keys one at a time is how one lives with the defect rather than fixing it.
+
+⚠ **Filed now, deliberately, while there is exactly one instance.** Three tracked deferrals remain checkable; the moment a second one comes due and is renamed by habit, the convention is established and the schema question stops being asked. That is the window this item exists to beat, and the reason it is filed rather than deferred.
+
+**The sharper half — a status field alone is not enough.** The genuine failure available here is a discharge that records *that* a gate closed but not *what* closed it: six months on, a reader learns a decision was answered and cannot find the answer. So resolution should be **unsatisfiable without a pointer** — the schema should make an undocumented discharge impossible to express, not merely discouraged.
+
+**Options.**
+1. **`resolved: YYYY-MM-DD — <pointer>` field, required to be non-empty, parser skips resolved blocks for due-ness but still parses and validates them.** The key stays `DEFERRED-DECISION`; nothing is renamed; the block remains machine-readable forever.
+2. `status: open | resolved | superseded`, same pointer requirement. More expressive, more surface.
+3. Keep the rename convention and document it. Cheapest; leaves the reflex in place, which is the thing being complained about.
+
+**Recommendation: (1), with two conditions.**
+- **The parser must keep counting resolved blocks and report them as a closed ledger**, not drop them silently. A discharge that vanishes from the report is its own species of decay — the register would show three tracked deferrals and no evidence a fourth was ever answered.
+- **A resolved block whose pointer is missing or unresolvable must be reported as a defect**, in the same register-integrity lane that already catches an amendment which replaced the record it amends. Same failure family: a record that closes over its own history.
+
+**Verification required before it is trusted** (per the standing rule that an absence is not evidence until the instrument is shown able to detect presence): a positive control that a resolved block with a past-date trigger is **not** reported due; a negative control that an *unresolved* block with the same past date **is**; and a third that a resolved block with an empty or dangling pointer is flagged.
+
+**Files affected:** `scripts/governance-drift-check.py` (parser, due-ness, register-integrity lane, selftest); `PENDING.md` — the one existing `DISCHARGED-DECISION` block reverts to `DEFERRED-DECISION` with `resolved:` set, which is also the migration's own test case.
+
+**Awaiting:** Steward authorization. **Not urgent, and not open-ended:** the condition that makes it urgent is a second trigger coming due, and there are three that can.

claude/governance/fool/seed/FOOL-BONES-2026-08-25.md

@@ -103,7 +103,32 @@ updated. **Internal to the rule, affects no value in this record**, and §5b bin
 edit touches the rule before it fires. Owed as a `[FIX]` alongside the
 `abandonment` → `retirement` harmonization.
 
-## 6 · What has NOT happened
+## 6 · The trigger that fired this
+
+This derivation had **no trigger of any kind** until 2026-08-24 — no cron, no launchd, no
+scheduled agent, and not a tracked deferral. An authorized, dated, irreversible, run-once
+act resting entirely on someone remembering. A `DEFERRED-DECISION` block was added that
+day and proven by positive control (with the date temporarily set to the past, the checker
+announced it by name).
+
+**It fired for real at the 2026-08-25 wake**, naming `fool-beacon-derivation-run-once`
+under COME DUE — the first time the mechanism carried a live firing rather than a
+rehearsal. That is what put this derivation in front of the executor.
+
+It is now **discharged**, in `~/dotfiles/PENDING.md`, by renaming the key to
+`DISCHARGED-DECISION` — `governance-drift-check.py`'s parser has no `resolved:` field, so
+a taken decision would report COME DUE forever. Commit `06b3d8b`. Verified after: the
+checker went from *"1 of 4 have COME DUE"* to *"3 tracked, none due"*.
+
+⚠ **The per-instance rename is not a fix.** A schema with no resolution state is what
+produces the decay; renaming keys one at a time is how one lives with it. Filed as
+**PENDING-157 `[HARDENING]`** against the schema itself, deliberately before a second
+trigger comes due and gets renamed by reflex.
+
+*(Written at both ends: the discharge block points here, and this points back. Pointing
+one way only is how a successor learns that a gate was closed but never why.)*
+
+## 7 · What has NOT happened
 
 - No soul generated. §8 (proportions — still *"low, fixed"* with no number), §8a (body
   design) and §9 remain unbuilt.