🔧 Auto-commit from sysupdate on 2026-07-05 22:41

claude/memory/session-ledger-2026-07-05.md

@@ -16,6 +16,8 @@ metadata:
 
 ## Open horizons
 
+- 2026-07-05 — **Repo CLAUDE.md files + frontmatter census + freshness mechanism.** Drafted `chamber-library/CLAUDE.md` + `studium-engine/CLAUDE.md` (pointer-style; chamber=governed, engine=D-1; uncommitted, for steward review). Ran the read-only frontmatter census → `chamber-library/_curation/frontmatter-census-2026-07-05.md`: **332 non-Loeb, only 11 (3%) conformant**; 204 missing ≥1 un-fabricatable provenance field; 109 no-frontmatter. **Loeb (952) OUT of the sweep** — their v2 frontmatter comes at Region 4 reconversion (steward-confirmed; matches the map). Migration plan drafted (generative-from-spec; phased M/P/C; honest-unknown marker needs ratification) — sweep is `[needs-authorization]`. **Freshness → skill-harvest register:** event-based `/wrap-up` check (challenged the steward's count-threshold: pointer docs → count fires on noise; event = tool/discipline/governance/term change) + optional git staleness canary (prompts, never auto-writes). All uncommitted (chamber can't push — skemantix down).
+
 - **Engine (build day, Opus):** V0 + N0 — the two contracts, together (plan §7). V0 = verifier contract + pre-registered thresholds → routes to the jurist (the one named D-1 exception). N0 tree contract must exist before any hand touches the Loeb extractor rebuild (reciprocal obligation, §3.4). N1 can proceed while V0 sits with the jurist.
 - **Corpus:** Region 1.1 — the exclusion path, test-first, surfaced for jurist ratification (chamber corpus-work-map-2026-07-05).
 - **Held literal question:** normalizer@N "unaltered" — engineering (D-1) or doctrine ("the bound must name the edition")? Will the jurist gate V0 clean, or does "what counts as the same words" surface an unanticipated ruling?

claude/memory/skill-harvest-register.md

@@ -325,3 +325,17 @@ The single place proposed skills live so they don't evaporate between sessions.
 | **MEMORY.md deeper-reduction** (proposed 2026-06-08, condition-gated) | **CONDITION NOW MET — authorize the focused pass** | The 06-08 proposal deferred the risky deeper reduction "only if 157KB still trips 'only part loaded'." Tonight the index is **204.5KB vs a 24.4KB load limit** and a PostToolUse hook actively demanded compaction to ~17KB mid-wrap. NOT executed (the proposal explicitly names it "its own focused pass, not a tail-of-session move" — steward-unauthorized). Evidence is now decisive: ~88% of the index doesn't load at wake. Recommend authorizing the focused pass (compress archived one-liners further + move stable reference sections to a consult-on-demand `MEMORY-reference.md`; backup first, as 06-08). | PROPOSED (trigger met; awaiting steward authorization for a dedicated pass) |
 
 *(Two, neither manufactured: the first is the strongest evidence yet for an already-standing proposal plus one earned authoring rule; the second converts tonight's hook pressure into the governed channel rather than a tail-of-session mutation of real memory.)*
+
+### Harvest 2026-07-05 (V0 ratified + exclusion path + repo CLAUDE.md files)
+
+**BUILT + AUTHORIZED + COMMITTED this session:**
+- **`chamber-library/CLAUDE.md`** (`2238b65`, local — skemantix push pending) + **`studium-engine/CLAUDE.md`** (`4ad82d6`, pushed) — steward-authorized 2026-07-05. The two missing project-local orientation docs (ARC already had one; steward-flagged the gap). Pointer-style by design: they carry the *stable* layer (disciplines, governance posture, terminology, tool-fleet groups, layout) and delegate current-state to the trackers they name (corpus-work-map / PENDING / graduation-spec.yaml for chamber; rebuild-plan / charter for the engine). Chamber = governed (NOT D-1); engine = D-1 with the one V0 jurist exception.
+
+**PROPOSED (awaiting steward) — how to keep the CLAUDE.md files fresh:**
+
+| Element | Kind | One-line | Where it lands | Status |
+|---|---|---|---|---|
+| **`/wrap-up` — CLAUDE.md freshness check** | `/wrap-up` patch | At session close, ask: did this session change a **tool** (fleet add/remove), a **discipline** (a tool-evolution-log entry that generalizes), a **governance rule** (a PENDING/REVIEWED shifting posture), or a **term/mechanism** (like the exclusion path today)? → update the relevant repo `CLAUDE.md` line. **Event-based, NOT count-based** (the steward proposed a change-count threshold; challenged: these are POINTER docs, so most repo churn — files graduated, sources pinned, reports regenerated — doesn't touch them; a count fires on noise and misses the real triggers). Rides the §1.6 harvest slot, which already asks "did we change something that should be recorded?". | `~/.claude/skills/wrap-up/SKILL.md` | **BUILT 2026-07-05 (steward-authorized)** — §1.6 4th bullet + provenance note; mechanical-updates-apply / discipline-changes-surface split |
+| **CLAUDE.md staleness canary (git tripwire)** | create (small) OR git hook | If the `scripts/` set or `graduation-spec.yaml` changed but `CLAUDE.md` didn't since, flag "may be stale." Bounded, low-false-positive — the two most CLAUDE.md-relevant change classes. **Prompts; never auto-writes** (a bot rewriting the disciplines is the automation-of-recognition risk — the loop stays load-bearing). Sibling of the proposed **wake-canary** (MEMORY.md pointer-resolution). | git pre-commit / a `/repo-doc-canary` | **PROPOSED (optional; pairs with the wake-canary)** |
+
+*(Two proposals + two docs built. The freshness mechanism is the load-bearing one — it answers the steward's live question and applies this whole session's thesis [storage isn't memory; a protocol that exercises it is] to our own orientation docs. Not manufactured: the docs were just built, so the "how do they stay true" question is real and now. The count-vs-event correction is the substantive contribution — a raw threshold would institutionalize decorative maintenance.)*

claude/skills/wrap-up/SKILL.md

@@ -3,7 +3,7 @@ name: wrap-up
 description: Capture session state for future restoration. The quality of the next wake-up depends entirely on the quality of this wrap-up. Captures not just what we did but what is still pulling, what is the live concern, and what question we want to find still open when we return.
 ---
 
-<!-- Provenance: 2026-05-18 S-cluster §8 fields (REVIEWED-24); 2026-05-26 chaîne-d'union clasp + actionable-resumption-point; 2026-05-27 §1.6 skill-harvest step (PENDING-23); 2026-06-02 §4.0 MemPalace liveness-check before write (steward-authorized; #1495 cold-start drop resilience); 2026-06-05 §6.5 dotfiles session-state commit+push (steward-authorized; paired with wake-up §2.c check). Improvements to this skill are themselves harvested per §1.6 — propose, authorize, record here. -->
+<!-- Provenance: 2026-05-18 S-cluster §8 fields (REVIEWED-24); 2026-05-26 chaîne-d'union clasp + actionable-resumption-point; 2026-05-27 §1.6 skill-harvest step (PENDING-23); 2026-06-02 §4.0 MemPalace liveness-check before write (steward-authorized; #1495 cold-start drop resilience); 2026-06-05 §6.5 dotfiles session-state commit+push (steward-authorized; paired with wake-up §2.c check); 2026-07-05 §1.6 CLAUDE.md-freshness check (steward-authorized). Improvements to this skill are themselves harvested per §1.6 — propose, authorize, record here. -->
 
 # Session Wrap-Up
 
@@ -72,6 +72,8 @@ Drawing on the session and the merged ledger (1.5), ask:
 - **Create?** Did a recurring or hard-won procedure emerge that a *new* skill should carry — something we'd otherwise re-derive next time (a diagnostic method, a build sequence, a review pass)?
 - **Patch?** Did an existing skill prove wrong, incomplete, or stale *in use* this session — a missing step, an instruction that misfired, a reference that drifted?
 - **Retire?** Did a skill, or part of one, prove decorative — named but not load-bearing?
+- **Repo CLAUDE.md fresh?** Did this session change something a project-local `CLAUDE.md` carries — a **tool** added/removed from a repo's fleet, a **discipline** that generalized, a **governance ruling** that shifts the repo's posture, or a **term/mechanism** entering its vocabulary? This is **event-based, not change-count**: a pointer-style CLAUDE.md is untouched by ordinary corpus/state churn (files graduated, sources pinned, reports regenerated), so update it only when the *class of thing it carries* changes. **Mechanical updates** (a fleet line, a term, a pointer) apply at wrap like a tracker; a change to a **discipline or governance posture** is surfaced for steward review, not auto-applied (the same FIX-vs-PROPOSAL split, one level up). <!-- 2026-07-05: CLAUDE.md-freshness check, steward-authorized; keeps repo orientation docs from drifting into the false-confidence they warn against -->
+
 
 The yardstick is the steward's own: *did the steward have to re-explain something a skill could have carried next time?* If yes, that is a harvest candidate.