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.
This commit is contained in:
+72
-30
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user