opencode-thrum-pro 0.1.15 → 0.1.17

package/assets/commands/thrum-compact-extended.md

@@ -1,18 +1,14 @@
 ---
-description:
-  Stage a comprehensive 16-section snapshot, verify it landed, then send /compact
-  to this agent's OWN tmux pane so it stays alive and resumes at low context. Use
-  for designer/architect-grade work needing wire contracts, capability matrix,
-  and design rationale that the standard /thrum:compact format cannot carry.
+description: "Stage and verify a comprehensive snapshot, settle owned background tasks, then compact this tmux session in place. Use for designer or architect work needing wire contracts, a capability matrix, and design rationale."
 ---
 
 # Compact — Extended (16-section snapshot)
 
 Compose a comprehensive 16-section prose continuation, write it directly to your
 restart file, verify it landed, then send `/compact` to your own tmux pane. Same
-in-place semantics as `/thrum:compact` — the agent stays ALIVE,
-sub-agents/loops/crons survive (confirmed empirically), no session end, no tmux
-kill. The only difference is snapshot grade.
+in-place semantics as `/thrum:compact` — the agent stays ALIVE, its background
+loops and cron schedules survive (confirmed empirically), no session end, no
+tmux kill. The only difference is snapshot grade.
 
 ## When to use extended vs standard
 
@@ -70,7 +66,7 @@ survives even if post-compact orientation fails, so it is read-first and
 self-contained:
 
 > 🔴 ON RESUME — you were COMPACTED, not restarted. Daemon binding is intact
-> (subagents/loops/crons survived). Resume LEAN: this file is delivered inline in the injected briefing (read it FIRST). Expect a
+> (background loops and cron schedules survived). Resume LEAN: this file is delivered inline in the injected briefing (read it FIRST). Expect a
 > `thrum prime --light` briefing already auto-injected by the SessionStart
 > hook; only run `thrum:prime-agent` if it did NOT appear. Do NOT manually run
 > full `thrum prime`. Then continue from §16.
@@ -148,6 +144,12 @@ lines) re-resolves identity (the Bash tool does NOT persist shell state across
 calls, so earlier steps' variables are gone), verifies the snapshot on disk, and
 only then fires `/compact` — all in ONE call so nothing depends on a prior block.
 
+Before Step 4, settle owned background tasks. In Claude Code, inspect the running-task list,
+wait for active sub-agents, list Monitors with `thrum monitor list`, stop your own
+Monitors, and stop or wait for background shells. In other runtimes, use only
+existing task controls; skip this check if none exist. Send only when none remain;
+if one cannot be settled, report and hold without sending.
+
 ```bash
 SNAPSHOT="<PASTE SNAPSHOT_PATH FROM STEP 3>"
 NONCE="<PASTE SNAPSHOT_NONCE FROM STEP 3>"
@@ -341,7 +343,7 @@ is synchronous.
 ## How resume works
 
 After `/compact` the SAME process and session survive — the daemon binding is
-intact (that is why your sub-agents, loops, and crons kept running). Full
+intact (that is why your background loops and cron schedules kept running). Full
 `thrum prime` rebuilds identity + binding + full briefing for a NEW session; none
 of that is needed here. Resume LEAN, in this order:
 
@@ -361,8 +363,8 @@ of that is needed here. Resume LEAN, in this order:
    complete - please continue" prompt on the daemon right behind `/compact`; it
    is delivered once the pane is idle after compaction, so a turn starts even
    with an empty inbox.
-3. **Continue** from §16. Reconnect to your still-live sub-agents, loops, and
-   crons rather than re-dispatching.
+3. **Continue** from §16. Reconnect to your still-live background loops and
+   cron schedules rather than re-dispatching them.
 
 Runtime-specific compaction-recovery hooks (if this runtime has any) are
 documented in that runtime's own plugin tree (its hooks manifest and

package/assets/commands/thrum-compact.md

@@ -1,9 +1,5 @@
 ---
-description:
-  Stage a standard 11-section snapshot, verify it landed, then send /compact to
-  this agent's OWN tmux pane so it stays alive (subagents, loops, crons survive)
-  and resumes at low context. Use for in-place context relief when you do NOT
-  want to kill the session.
+description: "Stage and verify a standard snapshot, settle owned background tasks, then compact this tmux session in place. Use for context relief when you want to keep the current session."
 ---
 
 # Compact — Snapshot Then Compact In Place
@@ -11,16 +7,16 @@ description:
 Compose a standard 11-section prose continuation, write it directly to your
 restart file, verify it landed, then send `/compact` to your own tmux pane.
 Unlike `/thrum:restart` and `/thrum:sleep`, compact does NOT end your session and
-does NOT kill your tmux pane — the agent stays ALIVE. Any sub-agents, background
-loops, and cron schedules you own keep running across the compaction (confirmed
-empirically). After compaction you Read your snapshot by hand and re-prime lean.
+does NOT kill your tmux pane — the agent stays ALIVE. Any background loops and
+cron schedules you own keep running across the compaction (confirmed empirically).
+After compaction, read your snapshot by hand and re-prime lean.
 
 ## When to Use
 
 - Your context is high and you want relief WITHOUT losing the live session —
-  you own sub-agents, a background loop, or a cron that must survive.
-- You are mid-task and a fresh session (which loses in-flight sub-agent handles
-  and scheduler state) would be more expensive than a compaction.
+  you own a background loop or a cron schedule that must survive.
+- You are mid-task and a fresh session would disrupt a scheduled loop or cron
+  that you own.
 
 For context-exhaustion or stuck-state cases where a FRESH session is the right
 answer — or where the coordinator should move you — use `/thrum:restart`. For
@@ -72,7 +68,7 @@ survives even if post-compact orientation fails, so it is read-first and
 self-contained:
 
 > 🔴 ON RESUME — you were COMPACTED, not restarted. Daemon binding is intact
-> (subagents/loops/crons survived). Resume LEAN: this file is delivered inline in the injected briefing (read it FIRST). Expect a
+> (background loops and cron schedules survived). Resume LEAN: this file is delivered inline in the injected briefing (read it FIRST). Expect a
 > `thrum prime --light` briefing already auto-injected by the SessionStart
 > hook; only run `thrum:prime-agent` if it did NOT appear. Do NOT manually run
 > full `thrum prime`. Then continue from §9.
@@ -148,6 +144,12 @@ lines) re-resolves identity (the Bash tool does NOT persist shell state across
 calls, so earlier steps' variables are gone), verifies the snapshot on disk, and
 only then fires `/compact` — all in ONE call so nothing depends on a prior block.
 
+Before Step 4, settle owned background tasks. In Claude Code, inspect the running-task list,
+wait for active sub-agents, list Monitors with `thrum monitor list`, stop your own
+Monitors, and stop or wait for background shells. In other runtimes, use only
+existing task controls; skip this check if none exist. Send only when none remain;
+if one cannot be settled, report and hold without sending.
+
 ```bash
 SNAPSHOT="<PASTE SNAPSHOT_PATH FROM STEP 3>"
 NONCE="<PASTE SNAPSHOT_NONCE FROM STEP 3>"
@@ -275,7 +277,7 @@ your pane goes idle, which only happens if you stop acting now.
 ## How resume works
 
 After `/compact` the SAME process and session survive — the daemon binding is
-intact (that is why your sub-agents, loops, and crons kept running). Full
+intact (that is why your background loops and cron schedules kept running). Full
 `thrum prime` rebuilds identity + binding + full briefing for a NEW session; none
 of that is needed here. Resume LEAN, in this order:
 
@@ -295,8 +297,8 @@ of that is needed here. Resume LEAN, in this order:
    complete - please continue" prompt on the daemon right behind `/compact`; it
    is delivered once the pane is idle after compaction, so a turn starts even
    with an empty inbox.
-3. **Continue** from §9. Reconnect to your still-live sub-agents, loops, and
-   crons rather than re-dispatching.
+3. **Continue** from §9. Reconnect to your still-live background loops and
+   cron schedules rather than re-dispatching them.
 
 Runtime-specific compaction-recovery hooks (if this runtime has any) are
 documented in that runtime's own plugin tree (its hooks manifest and

package/assets/commands/thrum-prime.md

@@ -1,4 +1,5 @@
 ---
+name: prime
 description: Load AI-optimized session context
 ---
 

package/assets/skills/configure-roles/SKILL.md

@@ -116,7 +116,6 @@ which is single-variant):
 | tester       | Writes and runs tests, verifies acceptance criteria  |
 | deployer     | Handles builds, releases, deployment operations      |
 | documenter   | Creates and maintains documentation                  |
-| monitor      | Watches system health, reports anomalies             |
 | orchestrator | Drives plan execution across agents (single-variant) |
 
 ### 4b: Autonomy Level Per Role

package/assets/skills/coordinator-hotpath-merge-gate/SKILL.md

@@ -89,10 +89,11 @@ the one resource it cannot replace and leaves no durable verdict artifact.
 **Only run it yourself when there is NO gate-role agent available**, and say so
 explicitly in the merge record so the gap is visible rather than invisible.
 
-**Verdicts are artifacts:** the runner saves them to
-`<gate-reports-dir>/<ISO-week>/<date>/<gate-slug>/` (the project's gate-reports directory) and commits them BEFORE
-removing any worktree. A verdict that exists only in a message cannot be audited
-later.
+**Verdicts are one log line:** the runner appends ONE line (date, gate, candidate SHA,
+target SHA, verdict, one short reason) to `dev-docs/gate-log.md` and commits it. That
+line is the only record a gate keeps; the verdict itself travels in the report message.
+Never commit per-gate report directories, logs, archives or evidence (owner ruling 2026-10-17:
+once a gate has decided and the candidate is landed or rejected, its output is deleted).
 
 ## Gate dispatch preamble
 
@@ -462,10 +463,18 @@ circuit-breaker — **BLOCKING**. Peer call with timeout but no circuit-breaker
 **Triage:**
 `git diff main...HEAD --name-only | xargs grep -n '{peer_call_patterns}'`
 
+## Test impact selection plan (per-merge gate)
+
+Owner ruling, verbatim: "default ON as soon as it lands, no side-by-side; safety net = daily full gate + RDP load/regression test before deploy".
+
+Run the per-merge test lanes through the repository's test-impact-selection plan wrapper (the gate role's documented
+command, taking `--base`, `--head` and `--lane`), not the bare full-lane runner. It runs the plan, prints the `TIS_PLAN` line, and passes `--producer-rc` to the runner. Quote the `TIS_PLAN` line in the
+verdict. FULL (`decision=FULL RUN`) is the normal fallback: a plan error or any fail-closed reason runs the whole lane. For a per-landing gate, a FULL RUN fallback means the full NON-race lane, never race-all.
+
 ## Lens 11 — Census classification coverage (mandatory test, not a pattern check)
 
-**Why:** `go test ./...` never runs in Pass-3 — targeted-test selection is
-scoped to files the diff touches, and `internal/daemon/rpc/testcensus` is an ad
+**Why:** `go test ./...` never runs in Pass-3 — test impact selection
+(the plan wrapper) is scoped to files the diff touches, and `internal/daemon/rpc/testcensus` is an ad
 hoc test target nothing routes to. A merge that adds a `state.NewState(...)`
 call site in an `internal/daemon/rpc/*_test.go` file (test-fixture setup, not a
 handler) can leave it unclassified and desync the frozen census snapshot with

package/assets/skills/coordinator-maintaining-memory/SKILL.md

@@ -5,6 +5,8 @@ description: "Use when the coordinator writes a role-rule, captures an observati
 
 # Coordinator memory discipline
 
+> **Before writing or editing any memory or state entry, use the `memory-current-rule` skill:** a memory states only the CURRENT rule (exceptions allowed), never a timeline of rulings, corrections or reversals, and every touch re-examines the whole memory.
+
 As coordinator, write role-rules (when the user corrects your judgment),
 capture observations about agent behavior, and periodically note
 project-state changes. Common memory operations (write command shape, body

package/assets/skills/coordinator-merging-code/SKILL.md

@@ -111,6 +111,20 @@ preamble.
 
 **Do not duplicate lens definitions here.** Point at them and keep the order.
 
+## 0a. OVERBUILD CHECK — first step, before any gate
+
+Before a product branch goes to a gate, run one judgment-tier sub-agent with
+`resources/overbuild-check-prompt.md` from this skill's folder. Fill in the
+ask (issue, plan, dispatch message), later rulings and gate findings, the trunk
+ref, the branch tip and the owner's report.
+
+- **PROPORTIONATE:** continue to §1.
+- **OVERBUILT:** send the findings to the owner for the simplest version, with
+  a files-and-lines plan first. Do not dispatch a gate.
+- **UNCLEAR:** read the findings against source and decide.
+
+Test-only, docs and tooling branches skip this step.
+
 ## 1. PRECONDITION — dual review, and it is NOT the gate
 
 Two axes, run in parallel, on the branch: **code-quality** and **spec-compliance /
@@ -250,9 +264,10 @@ executed half is **scoped to the change**:
   acceptable (a targeted run misses cross-test races). Never on primary (the
   shared fleet build box) — it is CPU-heavy; run it on the gate box.
 - The fast structural checks on the merged tree — `gate-ban-check`,
-  `gate-omitempty-check`, `gate-lockspan-check`, `gate-marker-diff`,
-  `gate-stamp-protocol-check`, `gate-plugin-bundle-leaks` (seconds each; they
-  catch banned flags, `omitempty` drift, lock-span, marker and stamp drift
+  `gate-omitempty-check`, `gate-lockspan-check`, `gate-sourcetree-check`,
+  `gate-marker-diff`, `gate-stamp-protocol-check`, `gate-plugin-bundle-leaks`
+  (seconds each; they catch banned flags, `omitempty` drift, lock-span,
+  shipped code that needs a source-tree-only file, marker and stamp drift
   regardless of the change; `gate-plugin-bundle-leaks` self-skips when no plugin
   path changed).
 - The `merge-base --is-ancestor` fast-forward check (§6).
@@ -361,12 +376,12 @@ agreeing (`rev-parse origin/<branch>` and `ls-remote`). **Assert the branch TIP*
 
 ## 7. AFTER THE MERGE — four things, none optional
 
-1. **The verdict artifact.** The runner saves verdicts to
-   `<gate-reports-dir>/<ISO-week>/<date>/<gate-slug>/` (the project's gate-reports directory) and **commits them
-   BEFORE removing any worktree.** Save → commit → then destroy. A verdict that
-   exists only in a message cannot be audited later. The artifact must be able to
-   carry a `CLEAN-WITH-GATE-FIXES` outcome, and when one applies it cites the
-   `GATE-AUTHORED` commit SHA.
+1. **The gate-log line.** The runner appends ONE line (date, gate, candidate SHA, target
+   SHA, verdict, one short reason) to `dev-docs/gate-log.md` and commits it. That line is
+   the only record a gate keeps: never commit per-gate report directories, logs, archives
+   or evidence, and delete the gate's output once you confirm the candidate landed or was
+   rejected (owner ruling 2026-10-17). The line must be able to carry a `CLEAN-WITH-GATE-FIXES`
+   outcome, and when one applies it cites the `GATE-AUTHORED` commit SHA.
 2. **The efficacy row**, in the hotpath-gate efficacy log — required for
    **every** trigger-dir merge, including `SKIPPED_WITH_EVIDENCE` rows and
    orchestrator-run merges. The log measures gate **coverage**, not just outcomes.
@@ -438,7 +453,7 @@ hides staleness.
 - `coordinator-hotpath-merge-gate` · `coordinator-philosophy-merge-gate` — the lenses
 - `coordinator-running-review-cycles` — the dual-review cycle feeding §1
 - `coordinator-branch-split-on-block` — when a gate blocks one concern of a bundled branch
-- the gate-reports README — the artifact contract
+- `dev-docs/gate-log.md` — the one-line-per-gate record
 - `.thrum/hotpath-gate.json` · `.thrum/philosophy.md` — the configs; read these, not prose
 
 ## Project-specific rules (already loaded)

package/assets/skills/coordinator-merging-code/resources/overbuild-check-prompt.md

@@ -0,0 +1,60 @@
+# Overbuild check — sub-agent prompt
+
+Give this whole file to one judgment-tier sub-agent, with the inputs filled in.
+It is read-only and takes about 10 minutes.
+
+---
+
+You are checking whether a branch built more than it was asked to build. Work
+read-only in the repository named below: read files and run `git log`,
+`git diff`, `git show` and `grep`. Do not build, run tests, edit, check out,
+commit or push.
+
+## Inputs
+
+- Repository and trunk ref: `<REPO>`, `<TRUNK_REF>`
+- Branch tip: `<TIP_SHA>`
+- What was asked (the spec): `<ISSUE TEXT, PLAN PATH, DISPATCH MESSAGE>`
+- Later rulings and gate findings that changed the ask, if any: `<LIST>`
+- The owner's "tip ready" report: `<TEXT>`
+
+## Steps
+
+1. Read the ask. Write down, in your own notes, the list of behaviours it asks
+   for. Nothing else counts as asked unless a later ruling or gate finding in
+   the inputs adds it.
+2. Read the change: `git diff --numstat <TRUNK_REF>...<TIP_SHA>`, the full
+   diff, and every commit message (`git log <TRUNK_REF>..<TIP_SHA>`).
+3. For each production file and each new function, type or field, trace it to
+   one behaviour in the ask. Anything that does not trace is a finding unless a
+   commit message, a ruling or a gate finding gives a concrete reason.
+4. Look for these patterns:
+   - **Invented scenario:** code that handles a case the ask never mentions,
+     with no reproduction, log, failing test or gate finding showing the case
+     happens.
+   - **Duplicate machinery:** a new cache, lock, retry loop, deadline, queue,
+     state or helper. Search the codebase for an existing one that does the
+     same job; if one exists, the new one is a finding.
+   - **Bundled feature:** a separate behaviour carried inside the fix.
+   - **Unrequested guard:** a new refusal, deadline, bound, cap or
+     authorization check that the ask did not request.
+   - **Test volume:** more test lines than production lines is fine only when
+     each test checks a distinct behaviour. Flag tests that check the same
+     behaviour twice, tests that pin an old path or a past revision, and tests
+     for an invented scenario.
+5. Estimate what the simplest version that does exactly the ask would keep.
+
+## Report (one page)
+
+- **Verdict:** PROPORTIONATE (send to the gate), OVERBUILT (send back), or
+  UNCLEAR (the coordinator decides).
+- **Sizes:** production lines and test lines added, and your estimate for the
+  simplest version.
+- **Findings:** a numbered list. For each give the pattern, `file:line`, why it
+  does not trace to the ask, whether a commit or ruling gives a reason, and
+  what the simplest version would do instead.
+- **Keep:** anything that looks large but is justified, with the reason, so it
+  is not cut by mistake.
+
+When the ask is thin (one line), say so and treat findings as pointers for the
+coordinator to check, not as automatic rejections.

package/assets/skills/coordinator-philosophy-merge-gate/SKILL.md

@@ -62,10 +62,11 @@ the one resource it cannot replace and leaves no durable verdict artifact.
 **Only run it yourself when there is NO gate-role agent available**, and say so
 explicitly in the merge record so the gap is visible rather than invisible.
 
-**Verdicts are artifacts:** the runner saves them to
-`<gate-reports-dir>/<ISO-week>/<date>/<gate-slug>/` (the project's gate-reports directory) and commits them BEFORE
-removing any worktree. A verdict that exists only in a message cannot be audited
-later.
+**Verdicts are one log line:** the runner appends ONE line (date, gate, candidate SHA,
+target SHA, verdict, one short reason) to `dev-docs/gate-log.md` and commits it. That
+line is the only record a gate keeps; the verdict itself travels in the report message.
+Never commit per-gate report directories, logs, archives or evidence (owner ruling 2026-10-17:
+once a gate has decided and the candidate is landed or rejected, its output is deleted).
 
 ## Gate dispatch preamble
 

package/assets/skills/implementer-maintaining-memory/SKILL.md

@@ -5,6 +5,8 @@ description: "Use when the implementer writes a role-rule after user correction,
 
 # Implementer memory discipline
 
+> **Before writing or editing any memory or state entry, use the `memory-current-rule` skill:** a memory states only the CURRENT rule (exceptions allowed), never a timeline of rulings, corrections or reversals, and every touch re-examines the whole memory.
+
 You are the implementer. Your memory discipline is intentionally narrow: you
 READ rules at session start and you WRITE rules when the user corrects your judgment
 mid-implementation. Refactoring opportunities, lessons learned, design questions

package/assets/skills/memory-curate/SKILL.md

@@ -8,6 +8,8 @@ license: "Apache-2.0"
 
 # memory-curate — edges, status, hierarchy
 
+> **Before writing or editing any memory or state entry, use the `memory-current-rule` skill:** a memory states only the CURRENT rule (exceptions allowed), never a timeline of rulings, corrections or reversals, and every touch re-examines the whole memory.
+
 Load this sub-skill from `thrum-memory` (umbrella) when relationships between
 memories matter — supersession, parent/child structure, comment threads, or
 related-context grouping.

package/assets/skills/memory-current-rule/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: memory-current-rule
+description: "Use BEFORE writing or editing ANY memory - thrum memory create/update, thrum state set, a file-based memory, a memory index line (MEMORY.md), or a restart snapshot. A memory states only the CURRENT rule, never a timeline of rulings, corrections and reversals. Also use to audit or rewrite existing memories; written so a helper agent can apply it with no other context."
+---
+
+# A memory states the current rule, never its history
+
+A memory written as a timeline ("X; later corrected to Y; exception Z; Z
+reversed") is worse than no memory. The reader has to rebuild what is true now,
+often rebuilds it wrong, and then acts on a rule that no longer holds.
+Exceptions are fine. Reversals, and layers of revisions, are not.
+
+This applies to every store: `thrum memory`, `thrum state`, file-based memories
+and their indexes, and restart snapshots.
+
+## Every time you touch a memory
+
+Whenever you create, edit, append to or merge a memory, examine the WHOLE memory,
+not just your change. If any part of it is a timeline, a stale version of a rule,
+or a summary that disagrees with the body, rewrite the whole memory to the
+current rule in the same edit.
+
+## The shape
+
+```text
+<Rule, present tense, one or two sentences, with its full scope:
+ which roles, runtimes, repos, peers, boxes or paths it covers.>
+<Exceptions as part of the rule: "except X, where Y". An exception that ends
+ on a condition says so: "until <bead/event>; check it before applying".>
+Owner, date and one short quote of the CURRENT ruling (optional).
+
+Why: <the reason, short>
+How to apply: <as many bullets as the rule needs: every still-current
+ precondition, command, control and bound>
+```
+
+A memory that carries several independent rules (a reader could need one without
+the others) keeps each as its own headed section in this shape, or is split into
+separate memories that link to each other. Never collapse independent rules into
+one sentence, and never drop a rule because it is not the title's rule.
+
+## What stays and what goes
+
+Stays:
+- The current rule, its full scope words, and its current exceptions.
+- The current ruling's owner, date and one short quote.
+- The reason. A past incident stays only if, without it, the Why would be empty
+  or the rule would look optional; keep it to two lines.
+- Every still-current precondition, command, control and bound.
+
+Goes:
+- Replaced statements, their quotes and their dates.
+- "First X, then Y" narratives of how the rule changed.
+- An exception that no longer applies.
+- Evidence (file:line, probes, controls) that only supported a replaced
+  statement. Never keep evidence for a rule that no longer holds.
+- Markers: "UPDATE", "CORRECTED", "SUPERSEDED", "REVERSED", "STRICKEN",
+  "later", "(late)", strikethrough.
+
+## Scope is part of the rule
+
+Never shorten scope words (which repo, role, runtime, peer, box, path). A rule
+that loses its scope is a different rule. For anything about authorization,
+peering, capability or access, read the project's security model before
+rewriting and keep every scope qualifier word for word.
+
+## Every summary must agree with the body
+
+A memory can have several summaries; find them all and make each match the
+rewritten body:
+- File memory: its front-matter `description:`, its line in the main index
+  (e.g. MEMORY.md), and its line in any secondary index (e.g.
+  MEMORY-reference.md). Grep the file name in every index.
+- `thrum memory`: its `--title` and `--oneline`. Find related entries with
+  `thrum memory search <topic>`; rewrite with `thrum memory update <id>`.
+- `thrum state`: the value of every key that restates the rule. When a file
+  memory names a state key, read it and keep the two identical.
+
+In an index, one entry is one `[text](file.md)` link. Rewrite only that entry's
+text; never touch the entries that share its line. Follow any format contract the
+index states about itself (caps, demotion), except that an index entry which
+annotates a memory as superseded or corrected is itself a timeline and must be
+rewritten or removed.
+
+## Rewriting a memory, step by step
+
+1. Read the memory in full, every memory it links to, and every memory on the
+   same topic (search by topic, not only by title). If it names a live source
+   (a config key, skill, template, bead), read that too: when the live source is
+   newer, it decides the current rule, and the memory should say "read X at the
+   moment of use" instead of restating X.
+2. List, privately, every distinct statement it makes, with its date or position.
+3. Decide the current rule POINT BY POINT, not file by file. For each point,
+   take the latest owner statement on that point. A later statement REPLACES an
+   earlier one only when it covers the same scope. If it covers a narrower scope,
+   it is an exception, and the earlier statement still governs everywhere else.
+   If two statements have the same scope and no clear order, mark the memory
+   AMBIGUOUS, change nothing, and report the exact question for the owner.
+4. Rewrite the memory in the shape above, one section per independent rule.
+5. Rewrite every summary (see above) to match.
+6. If another memory states the same rule: move every still-current point from
+   it into the memory you keep, then reduce it to a one-line body
+   ("Merged into <name>.") and re-point or remove its index entries. Never reduce
+   a memory to a pointer before its current points have moved.
+7. Self-check (all must be yes):
+   - A reader could act correctly after reading only the first section.
+   - Each rule is stated once, with no earlier version beside it.
+   - Every summary says the same thing as the body.
+   - No other memory states a different version of the rule.
+   - No scope word, current exception, precondition or reason was lost.
+8. Report each memory as REWRITTEN, MERGED INTO x, AMBIGUOUS (question) or
+   UNCHANGED (why), with one line saying which rules were kept, dropped (and
+   why) or moved (and where).
+
+Never invent a rule. When unsure whether a statement is still current, ask.
+
+## Auditing a store
+
+Grep the store for the markers above and for topics that more than one memory
+covers, then follow the steps for each hit. Grep finds only marked memories, so
+also read memories that share a topic with a hit.

package/assets/skills/memory-maintenance/SKILL.md

@@ -5,6 +5,8 @@ description: "Use when an agent needs to update, delete, supersede, or audit an
 
 # Maintaining thrum memory entries
 
+> **Before writing or editing any memory or state entry, use the `memory-current-rule` skill:** a memory states only the CURRENT rule (exceptions allowed), never a timeline of rulings, corrections or reversals, and every touch re-examines the whole memory.
+
 This skill carries the canonical lifecycle operations on existing memory entries
 — edit, delete, supersede, history audit.
 

package/assets/skills/memory-write-discipline/SKILL.md

@@ -5,6 +5,8 @@ description: "Use when an agent needs to capture a new memory entry — a rule,
 
 # Writing thrum memory entries
 
+> **Before writing or editing any memory or state entry, use the `memory-current-rule` skill:** a memory states only the CURRENT rule (exceptions allowed), never a timeline of rulings, corrections or reversals, and every touch re-examines the whole memory.
+
 This skill carries the canonical write-command shape + content discipline shared
 by every role that writes memory. Per-role skills
 (researcher/coordinator/implementer-maintaining-memory) reference this skill for