opencode-thrum-pro 0.1.16 → 0.1.18

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-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 /
@@ -362,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.
@@ -439,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