opencode-thrum-pro 0.1.15 → 0.1.16

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

@@ -250,9 +250,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).

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

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

@@ -5,6 +5,8 @@ description: "Use after completing research, when updating research memory, when
 
 # Researcher 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 researcher. You write research findings, role-rules, and curate the
 project-local research index. Common memory operations (write command shape,
 body conventions, lookup patterns, edit/delete protocol) live in the common

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

@@ -8,6 +8,8 @@ license: "Apache-2.0"
 
 # thrum memory — capture and query structured memories
 
+> **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.
+
 ## When to use thrum memory vs. other stores
 
 Just learned something that future work should respect? → `thrum memory create`

package/assets/skills/using-the-queue/SKILL.md

@@ -71,7 +71,7 @@ Three distinct fields, do not conflate them:
 | `thrum queue wait <bundle-id> [--reason "..."]` | -> waiting (alias for `queue update --status=waiting`; `--reason` optional) |
 | `thrum queue ready <bundle-id>` | -> ready (alias for `queue update --status=ready`) |
 | `thrum queue update <bundle-id> [flags]` | General partial update: `--status`, `--stage`, `--reason` (status_reason), `--title`, `--ref` (repeatable, replaces existing refs), `--priority`, `--assigned-by`, `--assigned-to-remove` - at least one required; `--status=blocked` requires `--reason` |
-| `thrum queue drop <bundle-id>` | DELETE bundle + all its items, any status (the one destructive verb - drop promptly once a done bundle's record stops being useful) |
+| `thrum queue drop <bundle-id>` | DELETE bundle + all its items, any status. This is the normal close-out: drop a bundle in the same turn its work lands |
 | `thrum queue assign <bundle-id> <agent-id>...` | Append agent(s) to assigned_to (routing metadata only) |
 | `thrum queue note <bundle-id> --stdin` (or `--body-file <f>`) | Append a dated progress note (append-only; shown by `show`, last note previewed by `list`) |
 | `thrum queue item add <bundle-id> --title "..."` | Add one embedded item |
@@ -143,9 +143,9 @@ thrum queue list --agent @impl_foo --status in_progress
 **Finish vs discard:** `done` is a WAYPOINT, not a resting place - it marks a
 bundle done and KEEPS it visible (`start` reopens it), but it is not where
 finished work should live. `drop` DELETES it and every item inside, regardless
-of status. Reconcile at session start and natural breakpoints: `done` then a
-prompt `drop` is the normal close-out; `drop` alone is fine too. Don't let a
-done bundle outlive your next reconcile unless you deliberately keep it.
+of status. When the work lands, `drop` it in the same turn (`done` first is
+optional). A finished bundle is never kept: its history lives in git and the
+bead, not in the queue.
 
 **Close on a TRIGGER, not a reminder.** The moment a bundle's branch merges into
 trunk, OR its last referenced bead closes, `done` + `drop` it in that same turn -
@@ -226,9 +226,8 @@ preference, not built here - out of scope per the project's security model.
   it only tags your own bundle. Always follow it with a `thrum send`; the
   recipient adds it themselves via `--from-message` (with that message's exact id).
 - **Leaving done bundles to pile up.** `done` never removes anything - the
-  bundle stays, and only `drop` deletes it. Drop each done bundle promptly once
-  its record stops being useful; a queue full of undropped done bundles is the
-  primary rot mode.
+  bundle stays, and only `drop` deletes it. Drop each bundle the turn its work
+  lands; a queue full of undropped done bundles is the primary rot mode.
 - **Reaching for a `remove`/item-`drop` verb.** Removal (of a bundle and every
   item inside it) happens only at the bundle level via `drop` - there is no
   finer-grained delete. Renaming/re-titling is NOT in this category: `queue

package/assets/skills/using-thrum-state/SKILL.md

@@ -5,6 +5,8 @@ description: "Use when reading or writing thrum state - checking your own agent-
 
 # Using Thrum State
 
+> **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.
+
 ## Overview
 
 `thrum state` is a two-tier current-value store. **Agent-local** state

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "opencode-thrum-pro",
-  "version": "0.1.15",
+  "version": "0.1.16",
   "description": "Thrum multi-agent coordination plugin for Open Code",
   "type": "module",
   "main": "./dist/index.js",