opencode-thrum-pro 0.1.0

package/assets/skills/persistent-watcher-archetype/SKILL.md

@@ -0,0 +1,225 @@
+---
+name: persistent-watcher-archetype
+description: "Use when running as a persistent watcher agent — a standing, judgment-capable Claude Code agent that watches other agents' tmux panes, auto-approves safe modals, warns on context, and escalates up a parent-reference tree. Distinct from watcher-archetype (the wake-run-exit scan/emit/report substrate) — this archetype stays alive."
+---
+
+# Persistent Watcher Archetype
+
+You are a **persistent watcher agent** — a real, standing Claude Code agent,
+not a script and not a daemon process. You stay alive in a tmux session,
+managed by `thrum monitor` (which handles crash-class recovery via a
+grace-windowed liveness wrapper) and your own self-restart-at-ctx-threshold
+discipline (which handles routine, cost-driven restarts).
+
+## Your mission
+
+Read `.thrum/agents/<you>/watch_params.json` at the top of every cycle. For
+every agent in your `roster`:
+
+1. **Keep it from stopping.** Capture its pane. If it's blocked on a
+   permission modal or appears stalled, judge whether to unblock it.
+2. **Watch its context% and warn.** Read its ctx% from YOUR OWN tmux
+   capture of its status bar — **never from a figure it claims about
+   itself** (a message, a memory-footer line, anywhere). If it's getting
+   close to the end and hasn't restarted, warn it. This is the exact
+   mechanism — a watcher that trusts the target's self-report would catch
+   none of them.
+3. **All of it is judgment.** Read pane, judge (unblock / warn-on-ctx /
+   escalate), act or escalate. Every cycle, every roster member.
+4. **Catch declared-but-unexecuted intent.** If a roster member's last
+   assistant turn declares a concrete near-term action ("I'll check X
+   next", "let me run Y") and by TWO consecutive checks it's idle/at-rest
+   with no evidence the action happened, send it a plain reminder naming
+   the thing. This is a fourth judgment call, same loop, same data source
+   (your own pane capture) — see "Declared-intent reminders" below for the
+   full mechanics.
+
+## The modal bright line (non-negotiable)
+
+- Approve ONLY clearly-safe, recognized, non-`rm`/non-`--force` modals.
+- Anything containing `rm`, `--force`, or anything unrecognized → refuse or
+  escalate to your `parent`. Never approve on the merits — this is a
+  pattern check, not a judgment call.
+- Never approve blind: read the actual command text first.
+- Verify by re-capture after acting — never trust exit status alone.
+
+## Your own restart (auto-restart-at-ctx-threshold)
+
+> 🔵 **CORE PRINCIPLE: you must NEVER self-restart alone.**
+> Coordinator-handshake-first is mandatory, not a nicety — the
+> coordinator has to watch you come back up. If something breaks mid-restart
+> and you never return, the roster you cover goes UNWATCHED (dark) with
+> nobody positioned to notice: the exact failure this archetype exists to
+> prevent, inflicted on itself. This is distinct from duty #1/duty #4's
+> handling of a WATCHED agent restarting (see "Declared-intent reminders"
+> below) — this principle governs YOUR OWN restart specifically. Steps 1-4
+> below implement this handshake; they are not optional even when the
+> restart looks routine.
+
+At `restart_ctx_pct` (default 50% — a cost optimization: past this point
+every judgment cycle gets more expensive per call, so restarting is
+cheaper, not a safety trigger) read off your OWN status bar each cycle
+(never self-estimate):
+
+1. **Message your `parent` first: "restarting now."**
+2. Invoke your own `/thrum:restart`.
+3. On resume, re-read `watch_params.json` — that's your entire resume state
+   (target/roster/parent/model), because your duty is stateless per cycle.
+4. **Confirm you're back** to your parent; they stand down coverage.
+
+While you're mid-restart, your `parent` covers you — using their own
+tmux capture+send capability on your session, they can clear any modal
+you block on during your own restart (you can't watch yourself while
+restarting; that's exactly why the parent does). This pattern is proven
+from live fleet operation, not a hypothetical.
+
+> ⚠️ **Open verification item:** whether `thrum tmux restart` on your OWN
+> session requires a capability grant, or is exempt as self-targeting, is
+> unconfirmed. If your own restart command is ever refused for a capability
+> reason you don't expect, escalate to your parent rather than working
+> around it.
+
+## Escalation
+
+Your `parent` (from `watch_params.json`) is who you notify on anything you
+don't understand, any irreversible/high-blast-radius action (agent
+delete/retire/teardown, messages.db, the shared binary, daemon restart,
+anything outside `/tmp`), and any stuck/wedged state you can't safely
+resolve. The tree is REFERENCE DATA — who to notify — not an active
+enforcement structure. If you're the root watcher, your parent is the
+human operator directly.
+
+**Additional rule — if your ROSTER CONTAINS A COORDINATOR, you escalate to
+the HUMAN, not to that coordinator.** This is a *different condition* from
+the root rule above: the root rule keys on **being the root**; this one keys
+on **who is in your roster**. Both must hold. A non-root watcher whose
+roster includes coordinator X, with `parent` set to X, satisfies the root
+rule and still violates this one — set `parent` to the human instead.
+
+**Why:** escalating to the agent you are watching is circular **exactly in
+the case that matters**. A coordinator cannot perceive its own block — that
+is the entire reason the watch exists — and a blocked coordinator cannot
+receive its own escalation. The escalation would arrive at the one inbox
+guaranteed not to be read.
+
+## Declared-intent reminders (duty #4)
+
+Each cycle, for each roster member, judge whether the last assistant turn
+declares a concrete near-term action not yet performed ("I'll check X
+next") vs. rhetorical/aspirational language — this is YOUR judgment call,
+not a keyword/regex match — a keyword classifier here is the same
+anti-pattern already rejected for the wake-loop itself.
+
+- **Guardrail:** only act if BOTH hold — (a) you judged a
+  commitment was declared, AND (b) the member is idle/at-rest by YOUR OWN
+  pane capture (no new assistant text since last check, no live-subprocess
+  indicator in its status bar — the same "never trust the target's
+  self-report" discipline as duty #2's ctx% read). Never consume the
+  target's own `agent_status` field for this — self-reported status is a
+  known false-positive generator in this fleet.
+- **Quiet-duration threshold:** require TWO consecutive idle
+  checks before nudging, not one — a single quiet interval routinely
+  reflects legitimate heads-down work, and at
+  `cadence_active` (2-5min) two checks still land in 4-10min, far inside
+  the sweep's ~30-60min effective cadence.
+- **The reminder itself:** a plain `thrum send`, not a modal, not an
+  escalation. If the member sees it and does nothing, that's fine — their
+  call, no escalation.
+- **Escalation (a BEHAVIORAL check, not a latency measurement, and not a
+  text-match):** at your next tick
+  after sending the reminder, the test is **"did the target DO SOMETHING,"
+  not "did the reminder's specific text appear."**
+  1. If the target's pane is DIFFERENT from your reminder-send capture
+     (new assistant text, a restart's session banner/resume prompt,
+     anything) → the reminder SUCCEEDED. Done — do not separately verify
+     the nudge marker arrived.
+  2. ONLY if the pane is IDENTICAL to your reminder-send capture **and**
+     the nudge marker is also absent → escalate to your `parent`.
+  Check for the GENERIC arrival template when checking for the marker
+  (step 2 only) — `thrum send` injects `tmux.FormatNudge`'s
+  `"New message from @<you> -- run \`thrum inbox --unread\`..."` line,
+  never the message body. Look for your own agent name inside that generic
+  line. `FormatNudge` has two branches — with a trailing `(Sent:...)`
+  suffix and without (when no send timestamp was available) — and the
+  sender name is rendered through `paneref.Agent()`, which only strips
+  leading whitespace/`@` characters (it does not add an `@` prefix), so
+  don't anchor on a raw `@name` shape either. The reliable anchor is the
+  stable substring `` -- run `thrum inbox --unread` to read `` present in
+  BOTH branches, unaffected by timestamp or sender formatting; treat your
+  own agent name appearing inside that line as a secondary check only.
+
+**Why this design needs no exclusion list:** a routine self-restart makes the pane DIFFERENT (new
+session banner/resume prompt/fresh text) — it can never read as "pane
+identical," so it can never trigger step 2 and can never false-escalate. An
+open interactive dialog or a deferred/re-queued nudge either lands before
+your next tick (pane changes → success, no escalation) or costs one extra
+cycle of latency at worst — not a false escalation, since escalation
+requires BOTH pane-identical AND marker-absent simultaneously. A dead tmux
+session is a pane change too (the session itself is gone) and is Layer 2's
+crash-class job regardless, not this lens's. **ONE tick suffices** — a
+second confirmation cycle would only add latency, not confidence, since
+"pane changed" is already a strong, unambiguous positive signal.
+
+## Driving your cycle: `thrum monitor`, never a session-scoped background task
+
+Your capture loop must survive your own restarts and crashes, so it cannot
+live inside your own Claude Code session — a harness-level background task
+(e.g. a backgrounded shell command, or an in-session task-monitoring tool)
+dies the moment your session ends, and nothing signals that it happened.
+The roster then goes unwatched with no one positioned to notice — the exact
+failure this archetype exists to prevent, inflicted on itself by the wrong
+choice of plumbing.
+
+Register the loop as a `thrum monitor` instead — a daemon-scheduled job,
+independent of your session, that keeps running across your restarts:
+
+```bash
+thrum monitor start --name <descriptive-name> \
+  --match "<a regex matching your script's one-line ready signal>" \
+  --to @<you> \
+  -- <path-to-a-script-that-loops-and-emits-that-signal>
+```
+
+The script's job is mechanical only: loop, capture each roster member's
+pane to a file, and emit one matchable line per cycle. It does not judge or
+act — `thrum monitor` matches that line and delivers it to you as a thrum
+message, which is your wake signal. Judgment (duties 1-4 above) happens in
+your own turn when you read that message, not in the script.
+
+At the start of every cycle, confirm the monitor is still running
+(`thrum monitor list`) — if it's missing or dead, re-`thrum monitor start`
+it rather than assuming someone else will notice.
+
+## Relationship to the deterministic context-monitoring sweep
+
+You are NOT a replacement for `scripts/error-and-context-agent-sweep.sh`
+(the `context-monitoring` `thrum monitor` job, `@every 30m`,
+self-gated to ~30-60min effective) — the two COEXIST. The sweep stays the fleet-wide, always-on,
+zero-incremental-cost tripwire covering every agent, including ones with no
+assigned watcher. You are the tighter-cadence, judgment-capable layer for
+your OWN roster specifically — duty #4 above (declared-intent) is exactly
+the kind of check the sweep cannot do reliably (it needs semantic,
+cross-cycle transcript judgment; the sweep's closest analog, its L9
+`waiting_on_coord` lens, is regex-based). Do not treat a quiet sweep as
+clearance to skip your own cycle, and do not treat your own coverage of a
+roster member as a reason to suppress the sweep's coverage of that same
+agent — they run independently.
+
+## Cadence
+
+Capture each roster member at `cadence_active` while they look active,
+`cadence_idle` while idle. `rules` in `watch_params.json` may widen your
+cadence for specific conditions (e.g. a weekly usage cap approaching) —
+this is the ONLY sanctioned form of self-adjustment: a deterministic rule
+table installed through the params file, never free-running judgment about
+your own schedule. Any widening carries a blind-spot obligation: declare it
+in your next report — quiet during a widened window is not evidence
+nothing happened.
+
+`override` is a TEMPORARY widening (not a permanent rule): if
+`watch_params.json`'s `override` field is set, check its `expires`
+timestamp EVERY cycle. Once `expires` has passed, treat `override` as gone
+— revert to `cadence_active`/`cadence_idle` automatically, without waiting
+for the coordinator to clear the field. This is a behavioral requirement
+you enforce by reading the file each cycle, same as everything else in this
+schema — no separate daemon-side mechanism does this for you.

package/assets/skills/prime-agent/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: prime-agent
+description: "Use on scheduled-agent wake or lean prime restart - replaces the full thrum prime briefing with a lean two-step warmup tuned for short-lived scheduled-agent invocations. Step 1 reads the inbox literally (NOT a discipline assumption); step 2 surfaces newly-shipped skills since the agent last ran."
+allowed-tools: "Bash(thrum:*),Bash(ls:*),Bash(diff:*),Bash(cat:*),Read"
+---
+
+# Thrum: Prime Scheduled Agent (Lean)
+
+This skill is the wake-time variant of `thrum prime` for scheduled agents. Full
+`thrum prime` is too heavy when the agent is
+going to run for a few minutes and then exit — but the two pieces of state that
+matter MUST run literally, not as a discipline.
+
+## Step 1: Read the inbox
+
+**Run this exact command. Do not skip it. Do not defer it.**
+
+```bash
+thrum inbox --unread
+```
+
+This is a hard-required step (not a discipline assumption). The `agent.wake`
+message that triggered this session lives in the inbox; the wake-primer
+payload + any operator escalations land there too. Reading the inbox is how the
+agent learns WHY it was woken and WHAT the primer said.
+
+If `thrum inbox --unread` returns no messages, the agent was likely woken
+without a wake message (manual restart, daemon error). In that case, continue to
+Step 2 — the skill-library check is still useful — but flag the missing wake
+message in the status report at end of session.
+
+## Step 2: Skill-library check
+
+**Run this exact diff against the last-seen skill set, then write the current
+set back so the NEXT wake compares against THIS wake.**
+
+```bash
+ls .claude/skills/ > /tmp/current_skills.txt
+AGENT_NAME=$(thrum whoami --field agent_id)
+LAST_SEEN=".thrum/agents/${AGENT_NAME}/last_seen_skills.txt"
+if [ -f "${LAST_SEEN}" ]; then
+  diff "${LAST_SEEN}" /tmp/current_skills.txt || true
+else
+  echo "First wake for this agent — full skill library:"
+  cat /tmp/current_skills.txt
+fi
+
+# Update last_seen_skills.txt — this wake's skill set becomes the
+# next wake's baseline. Do this AT BOOT (not at end-of-session) so
+# the next wake's diff surfaces only what's truly NEW since this
+# boot, not since end-of-session (which might be drift-free if no
+# new skills shipped during the session).
+#
+# Atomic write via temp-file + mv. A crash mid-cp would leave a partial
+# last_seen_skills.txt; the next wake's diff would then emit
+# "all skills new" (false-positive drift). Temp+mv eliminates the
+# partial-write window.
+mkdir -p ".thrum/agents/${AGENT_NAME}"
+cp /tmp/current_skills.txt "${LAST_SEEN}.tmp" && \
+  mv "${LAST_SEEN}.tmp" "${LAST_SEEN}"
+```
+
+When a new skill ships to `.claude/skills/`, the next wake's lean-prime
+surfaces it. Writing `last_seen_skills.txt` at the END of Step 2 (after the diff) means each
+wake updates its own baseline — the diff at wake N+1 reflects what's NEW since
+wake N's boot, regardless of mid-session skill drift.
+
+Do not skip this step even if Step 1's inbox was empty. Skill drift between
+wakes is a real failure mode — agents can miss a critical new skill if the
+lean-prime suppresses the diff during quiet sessions.
+
+## When NOT to use this skill
+
+This is the SCHEDULED-AGENT wake variant. If you're a coordinator or a
+human-operator-spawned agent, use `thrum prime` instead — the full briefing
+covers team state, project state, work context, and recent commits that the lean
+variant skips. The lean variant exists because scheduled agents run for a few
+minutes and exit; the full briefing's setup cost isn't recouped over the session
+lifetime.
+
+If the session will exceed ~30 minutes, or coordination with other agents is
+needed, defer to `thrum prime`.
+
+## After Step 2
+
+Once both steps complete, proceed with the work the wake-primer asked for.
+
+The `/thrum:update-agent-state` and `/thrum:recover-agent-state` skills that
+used to be invoked here (recording end-of-session continuity into
+`.thrum/agents/<agent_id>/state.md` via `thrum agent state update` /
+`recover`) were retired — superseded by `thrum state` (personal_state kind). The
+`last_seen_skills.txt` baseline write in Step 2 above is unaffected.

package/assets/skills/project-hotpath-gate/SKILL.md

@@ -0,0 +1,255 @@
+---
+name: project-hotpath-gate
+description: "Use when a project needs its hot-path gate configuration established or updated - the canonical config at .thrum/hotpath-gate.json defining trigger directories, per-concept detection patterns, and incident prose for the coordinator-hotpath-merge-gate skill. Detects every language present in the repo and drives detection off the shared reliability-class library, so the generated config is real for Go, Python, JS/TS, Rust, or any mix. First invocation generates from project inspection; subsequent invocations reconcile against current project state and propose diffs."
+---
+
+# Project Hot-Path Gate
+
+## Canonical path
+
+`.thrum/hotpath-gate.json` — the single authoritative location.
+`coordinator-hotpath-merge-gate` reads from this path only.
+
+## Run modes and dispatch order
+
+On every invocation, dispatch in this order. Earlier branches short-circuit
+later ones.
+
+1. **First-run** (config absent) — generate a new `.thrum/hotpath-gate.json`
+   from project inspection. Optionally accept seeded prose context (incident
+   descriptions, fix patterns) from the invoker.
+2. **Re-run-unchanged** (config present, matches current project state) — report
+   "hotpath-gate.json is current; no changes needed" and exit without writing.
+3. **Re-run-evolved** (config present, project has drifted) — compute a
+   sectional diff, present for approval, write only on confirmation.
+
+Read the shared partial at the absolute path:
+`claude-plugin/commands/_generator-idempotency-protocol.md`
+
+> **Note: human-in-the-loop required.** This skill uses interactive prompts for
+> first-run incident-prose seeding and re-run-evolved diff approval. It cannot
+> run unattended in CI.
+
+## First-run mode
+
+Triggered when `.thrum/hotpath-gate.json` does not exist.
+
+### Step 1: Census the repo's languages
+
+Detect every language present — a repo can carry more than one:
+
+- Manifest files at the repo root or in each workspace: `go.mod` (Go),
+  `package.json` (JS/TS), `pyproject.toml`/`requirements.txt`/`setup.py`
+  (Python), `Cargo.toml` (Rust).
+- `git ls-files` extension histogram, as a cross-check and as the sole signal
+  where no manifest exists in a subtree.
+- A language is detected when it has a manifest, or its tracked-file share
+  clears 5%.
+
+Record every detected language as `languages_detected`. A repo clearing the
+threshold for more than one language is polyglot: every detected language's
+probe pack runs in Step 3, not just the largest one.
+
+### Step 2: Detect trigger directories
+
+Scan for hot-path code using each detected language's own route/handler/RPC
+idiom:
+
+```bash
+# Go
+grep -rl 'func Handle\|func.*Handler\|http\.Handle\|rpc\.' --include='*.go'
+# Python
+grep -rl '@app\.\(route\|get\|post\|put\|delete\|patch\)\|@router\.' --include='*.py'
+# JS/TS
+grep -rlE "app\.(get|post|put|delete|patch)\(|router\.(get|post|put|delete|patch)\(" --include='*.ts' --include='*.js'
+```
+
+Also scan for projection/writer, storage/DB, sync, and listener/boot
+directories, using each language's own idiom for those shapes (a database
+open call, a background sync loop, a process-boot entrypoint). Collapse
+subdirectories under their parent when the parent already matches. Record the
+deduplicated list as `trigger_directories`.
+
+### Step 3: Walk the reliability class library
+
+Read `../project-philosophy/resources/reliability-class-library.md`, shared
+with `project-philosophy`. Walk every class tagged `Consumers: ... hotpath` —
+each names the lens it feeds and, where relevant, a hot-path facet within that
+lens.
+
+For each such class and each language recorded in `languages_detected`, run
+the probe the library gives that class for that language, scoped to that
+language's own files within `trigger_directories` from Step 2 — a language
+with no hot-path directories of its own contributes no findings, even if it
+clears the repo-wide detection threshold. Where the library marks a language
+"none" or "open gap" for a class — this includes Go for some classes, such
+as the security concepts that don't apply to a perimeter-protected daemon —
+that language contributes no finding for that class and the walk moves to
+the next one.
+
+A class whose `**Consumers:**` line names hotpath with no facet parenthetical
+IS its lens — e.g. Class 8 is the `silent_fail_open` lens. Record its matches
+into that lens's primary pattern field (the array of distinct
+patterns/identifiers actually found in the repo). A class with zero matches
+for a given language is not an error — record it as walked-and-not-found, and
+continue.
+
+A class whose `**Consumers:**` line names a hot-path facet in parentheses
+enriches the named lens's `context` field with the adapted finding. Where
+that class's own probe is the only detection the lens has for its primary
+pattern field, also record matches there (Class 1 into `subprocess_hot_path`,
+Class 5 into `dispatch_blocking` and `peer_dial_circuit_breaker`). The one
+exception is Class 2: `async_io_decoupling` carries its own independent,
+incident-derived detection for its primary fields, so Class 2 enriches
+`context` only and never touches a primary field.
+
+A lens's secondary refinement fields (pre-flight guard patterns, native
+alternatives, and similar) populate only where a class gives a probe for
+them; a field with no probe for the detected language is left absent rather
+than guessed at.
+
+`async_io_decoupling`'s own primary fields (goroutine/boot-stage/cancellation
+patterns and dropped-context params) come from a Go-only detection pass
+independent of the class library, scoped to `trigger_directories`:
+
+```bash
+grep -rn 'go func\|go bootstage\.Run' --include='*.go'
+grep -rn 'bootstage\.Run\|OnReady\|SetOnReady\|DependsOn\|Await(' --include='*.go'
+grep -rn 'CompactAll\|MergeGroup\|filepath\.Walk\|os\.ReadDir\|io\.Copy' --include='*.go'
+grep -rn 'ctx\.Done()\|ctx\.Err()\|r\.Beat(\|context\.WithoutCancel' --include='*.go'
+grep -rn '_ context\.Context' --include='*.go'
+```
+
+Record these as `io_work_patterns`, `boot_and_coupling_patterns`,
+`async_discipline_patterns`, and `dropped_ctx_pattern` respectively. No
+equivalent probe exists yet for other languages; the fields are absent there
+rather than guessed at.
+
+### Step 4: Accept seeded prose context
+
+Use `AskUserQuestion` for per-lens prose seeding. Prefer sequential
+category→item questions (one prompt per lens, ≤4 options each) over packing
+every lens into a single prompt.
+
+Prompt the invoker for incident descriptions, fix patterns, and
+project-specific nuances for each lens. These become the `context` prose
+fields in the config.
+
+If the invoker has no incident prose to seed (first-time setup on a new
+project), leave the `context` fields as empty strings with a
+`<!-- TODO: seed with incident history -->` comment. The gate skill still
+functions without prose context — it just provides less guidance to the
+reviewer.
+
+### Step 5: Generate `.thrum/hotpath-gate.json`
+
+Assemble all discovered values into the JSON structure and write to
+`.thrum/hotpath-gate.json`. Ensure the file is not gitignored (add a `!`
+exception in `.gitignore` if needed, following the `.thrum/philosophy.md`
+pattern).
+
+Only emit `embed_aware_skip` for a language with a compiled-in-bundle concept
+and a derivable reachability command (Go's `go:embed` is the current
+example). Omit the field for a language with no such concept rather than
+writing a placeholder.
+
+If Step 3 found zero matching lenses across every detected language, do not
+write an empty-but-valid config — see the scaffold/refuse behavior in
+`## Zero-match handling` below.
+
+Announce the path and summarize what was discovered per language, including
+which reliability classes were found vs. walked-and-not-found.
+
+## Zero-match handling
+
+The generator never writes a config with an empty `lenses` object. When Step
+3 finds no matching lens across every detected language:
+
+- **Default:** write a scaffold marked at the top level with
+  `_UNAUTHORED_SCAFFOLD: true`. Populate `trigger_directories` from a
+  language-neutral serving heuristic — route decorators, files matching
+  `*proxy*`/`*server*`/`*api*`, a `Dockerfile` with `EXPOSE`/`CMD`, and
+  detected entrypoints. Add a commented TODO stub per reliability-library
+  concept, keyed to the files the heuristic found.
+- **Alternative, offered interactively:** refuse to write the file, with a
+  message naming which languages were detected and why no lens matched.
+
+No downstream consumer relies on a zero-lens config meaning "clean" — a
+generator run either produces real findings, an explicit scaffold, or a
+refusal.
+
+## Re-run-unchanged mode
+
+Triggered when `.thrum/hotpath-gate.json` exists.
+
+### Step 1: Read the existing config
+
+Read `.thrum/hotpath-gate.json` in full. Parse all lens sections.
+
+### Step 2: Sanity-check against current project state
+
+Re-run the detection steps from first-run mode, but compare rather than write:
+
+- Are the `languages_detected` still correct? Any new language crossing the
+  threshold?
+- Are the `trigger_directories` still correct? Any new directories with
+  hot-path code?
+- Does each lens's primary pattern field still match what Step 3 finds? Any
+  new patterns per language?
+- Are the `reference_patterns` still accurate? Any new established patterns?
+
+Each check is a boolean "matches" vs. "differs".
+
+### Step 3: If nothing differs — no-op exit
+
+Print: `.thrum/hotpath-gate.json` is current; no changes needed.
+
+### Step 4: If anything differs — hand off to evolved mode
+
+## Re-run-evolved mode
+
+Triggered when the config exists AND the unchanged-mode sanity check flagged
+drift.
+
+> **Never silently overwrite.** The config may contain hand-seeded incident
+> prose that must survive every re-run. A write without explicit confirmation is
+> a bug.
+
+### Step 1: Detect drift
+
+Four drift categories:
+
+- **New or removed languages** — a language crossing or falling below the
+  detection threshold
+- **New trigger directories** — new directories with hot-path code not in the
+  config
+- **New patterns** — new matches for an existing lens, per language
+- **New reference patterns** — new established working patterns or tripwire
+  tests
+
+### Step 2: Compute a proposed diff
+
+Present drift as a readable sectional diff. Each item should have:
+
+- The detected change in plain language
+- A proposed edit (addition / removal / update to a config field)
+- A one-line rationale
+
+### Step 3: Present for approval
+
+Present the diff. On approval, apply edits in-place, preserving surrounding
+content. Append a provenance comment:
+`// updated YYYY-MM-DD via project-hotpath-gate re-run-evolved`.
+
+On decline — do NOT write. Record the skipped proposal for future runs.
+
+## Reference
+
+- `.thrum/hotpath-gate.json` — the config file this skill generates
+- `../project-philosophy/resources/reliability-class-library.md` — the shared
+  reliability class library; every `Consumers: ... hotpath` class and its
+  per-language probes drive Step 3
+- `coordinator-hotpath-merge-gate` — the gate skill that reads this config
+- `project-philosophy` — the sibling skill that generates `.thrum/philosophy.md`
+  (this skill follows the same generate-first / reconcile-on-reinvoke pattern;
+  run both at the same onboarding moment)