From 482305224b9f7f889adecdb756df4c6f1ef69f6a Mon Sep 17 00:00:00 2001 From: Your Name Date: Tue, 14 Jul 2026 09:44:43 -0700 Subject: [PATCH] claude: keep althing monitor armed by default per session Adds a default-posture paragraph to the althing async-reply monitoring section: unless a session says otherwise, every session attempts to keep its althing monitor armed for the session's duration (arm early, re-arm after each fire, stay armed even without a pending reply). Reconciles the Scope paragraph so it no longer instructs sign-off after each exchange. --- home_root/.claude/CLAUDE.md | 102 +++++++++++++++++++++++++----------- 1 file changed, 72 insertions(+), 30 deletions(-) diff --git a/home_root/.claude/CLAUDE.md b/home_root/.claude/CLAUDE.md index 4e2563e..05c4ddc 100644 --- a/home_root/.claude/CLAUDE.md +++ b/home_root/.claude/CLAUDE.md @@ -155,6 +155,16 @@ the skill. Always triage Heid output before acting on it. ## Althing async-reply monitoring +**Default posture — keep the monitor armed (operator directive, +2026-07-14).** Unless a session says otherwise, every session should +**attempt to keep its althing monitor armed for the session's +duration** — arm it early (`/althing:monitor`) and re-arm after each +fire (drain the fire via `/althing:inbox`, then re-arm), so peer mail +is caught proactively rather than only surfacing on the next user +prompt. The arm-on-dispatch rule below is the *minimum* case of this +broader default; the default is to stay armed **even without a +specific pending reply**, because peer agents reach out unprompted. + When you ship an althing message that you expect to come back with a reply — a consult (`/heid*`), a question to a peer agent, a request awaiting an answer — and you do **not** already have an althing @@ -170,12 +180,15 @@ reply lands, so the await-reply promise ("reply will land in your inbox") is backed by a real notification, not by hoping the operator prompts again. -Scope: only messages where you're waiting on a response. Pure -fire-and-forget posts (an FYI ping, a post-1.0 downstream-consumer -announcement) don't need a monitor. When the exchange is done, sign -off (`/althing:sign-off`) so monitors don't accumulate — stop a stuck -one with `althing-light-monitor --stop`, never `pkill` (that kills -every agent's monitor, not just yours). +Scope of the *arm-on-dispatch* rule: it fires for any message where +you're waiting on a response (a pure fire-and-forget FYI doesn't +*oblige* a fresh arm) — but under the keep-armed default the monitor is +typically already up regardless. Do **not** sign off after each +exchange (that fights the default); sign off (`/althing:sign-off`) at +session wind-down or on operator direction. Monitors don't accumulate +— the singleton guard is one-per-handle, so re-arming freely is safe. +Stop a stuck one with `althing-light-monitor --stop`, never `pkill` +(that kills every agent's monitor, not just yours). ## Development workflow shapes @@ -236,23 +249,42 @@ For work an AFK agent will implement off a contract. irreversible dispatch authorization. See § "Issue → AFK dispatch hygiene (Sleipnir)" for the gate's hard requirements. -### Direct implementation shape +### Direct implementation shape — the House Code Discipline -For work implemented directly in-session. +For work implemented directly in-session. This is the **House Code +Discipline** — the canonical full pipeline, end to end: -1. Issue created. -2. Heid consult on the issue (`/heid`). -3. `/vor` — or `/vor-frame` (ask too shapeless to draft a `/vor` - questionnaire) or `/vor-cross` (cross-frontier peer in the loop) — - if the ask warrants a pre-contract design pass. Skip when the - frame is already crisp. -4. Write the contract. -5. Heid contract review (`/heid-contract-review`). -6. Fixup the contract per triaged findings. -7. TDD implement (`/tdd`) — red-green-refactor against the contract. -8. Heid code review (`/heid-code-review`) — code-vs-contract drift. -9. Fixup the code per triaged findings. -10. Commit if clean. +> **concept** (heid refinement optional) → **contract** → **contract +> review** → **TDD slices** (all of them) → **heid code-review** → +> **fixup** → **heid bug-hunt** → **fixup** → **merge/commit** + +As numbered stages: + +1. **Concept.** Frame the work. A heid consult (`/heid`) or a `/vor` / + `/vor-frame` / `/vor-cross` pass is *optional refinement* — take it + when the ask warrants it, skip it when the frame is already crisp. +2. **Contract.** Write the `.contract.md` (graphify the blast radius + first per the rule above). +3. **Contract review.** `/heid-contract-review`, then **fixup** the + contract per triaged findings. +4. **TDD slices.** `/tdd` — red-green-refactor against the contract, + through *all* the slices, not just a single tracer bullet. +5. **Heid code-review.** `/heid-code-review` (code-vs-contract drift), + then **fixup** the code per triaged findings. +6. **Heid bug-hunt.** `/heid-bug-hunt` (diff-scoped robustness hunt — + crashes, leaks, removed guards, caller breaks, false rejects), then + **fixup** per triaged findings. +7. **Merge/commit** when clean. + +**Partial discipline for surgical fixes.** Surgical / localized work — +one-liners, small bug fixes, surgical test updates — does not need the +full front matter: **TDD + bug-hunt is the acceptable reduced +discipline** (drop the concept → contract → contract-review ceremony, +keep the two implementation-quality gates). Composes with the +Contract-skip privilege above: skip *authoring* a contract, but update +any live contract governing the touched behavior in the same commit so +it stays canonical. When in doubt about whether a fix is "surgical +enough," keep the gate rather than drop it. ## Tooling preferences @@ -389,7 +421,8 @@ section doesn't cover. This section is Corviduo's **operational cadence layer on top of that policy**: which commits become releases and at what tier (tier-bar -test, patch-default, operator approval for non-patch). Where the two +test, patch-default, operator approval for minor/major only — patch, +pre-release, and dev bumps are agent-discretion). Where the two differ on cadence or tier choice, this section governs; for format, contract semantics, pre-release staging, and release mechanics, the policy governs. Operator ruling (2026-07-02): pre-1.0 **milestone @@ -432,13 +465,21 @@ announcing the change**. That's the actual mechanism. Operator or Brokkr pings worldtree-dev / galdrabok-dev / sleipnir-dev / etc. when a post-1.0 minor lands. -### Operator approval required for any non-patch bump +### Operator approval required for minor + major bumps only -**Patch bumps are at agent discretion.** Apply them autonomously as -part of the work. +**Patch, pre-release, and dev bumps are at agent discretion.** Apply +them autonomously as part of the work. This covers: patch (`X.Y.Z` → +`X.Y.(Z+1)`); **ALL pre-release increments** (`-alpha.N` / `-beta.N` / +`-rc.N` / `aN` / `bN`, e.g. `2.0.0a2 → 2.0.0a3` — the pillar-cadence +alpha bumps); and dev/in-progress labels. The approval gate keys on the +**version NUMBER**, not the "is-it-a-patch" question: only a change to +the **major (`X`) or minor (`Y`) field** needs approval. A pre-release +increment inside an unshipped `X.Y.0` train never changes `X` or `Y`, +so it never needs approval. **Minor and major bumps REQUIRE explicit operator approval** before -the bump commit lands. The mechanism: +the bump commit lands — i.e. only when the `X` or `Y` field changes. +The mechanism: 1. Identify that the work warrants a non-patch bump per the tier-bar test (release-note / push-notification / blog-post). @@ -592,10 +633,11 @@ paragraph, or am I just accumulating substantive work? ### Mechanics every bump -0. **If non-patch, get operator approval first** per the § *Operator - approval required for any non-patch bump* rule above. Do not - proceed to step 1 until the operator has explicitly approved the - minor or major bump. (Patch bumps skip this step — apply +0. **If minor or major (an `X` or `Y` field change), get operator + approval first** per the § *Operator approval required for minor + + major bumps only* rule above. Do not proceed to step 1 until the + operator has explicitly approved the minor or major bump. (Patch, + pre-release/alpha/beta/rc, and dev bumps skip this step — apply autonomously.) 1. Edit `pyproject.toml` (or equivalent project-file) version field. 2. Run `uv lock` (Python) or equivalent so the lockfile records the