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
|
## 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
|
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
|
reply — a consult (`/heid*`), a question to a peer agent, a request
|
||||||
awaiting an answer — and you do **not** already have an althing
|
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
|
inbox") is backed by a real notification, not by hoping the operator
|
||||||
prompts again.
|
prompts again.
|
||||||
|
|
||||||
Scope: only messages where you're waiting on a response. Pure
|
Scope of the *arm-on-dispatch* rule: it fires for any message where
|
||||||
fire-and-forget posts (an FYI ping, a post-1.0 downstream-consumer
|
you're waiting on a response (a pure fire-and-forget FYI doesn't
|
||||||
announcement) don't need a monitor. When the exchange is done, sign
|
*oblige* a fresh arm) — but under the keep-armed default the monitor is
|
||||||
off (`/althing:sign-off`) so monitors don't accumulate — stop a stuck
|
typically already up regardless. Do **not** sign off after each
|
||||||
one with `althing-light-monitor --stop`, never `pkill` (that kills
|
exchange (that fights the default); sign off (`/althing:sign-off`) at
|
||||||
every agent's monitor, not just yours).
|
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
|
## Development workflow shapes
|
||||||
|
|
||||||
@@ -236,23 +249,42 @@ For work an AFK agent will implement off a contract.
|
|||||||
irreversible dispatch authorization. See § "Issue → AFK dispatch
|
irreversible dispatch authorization. See § "Issue → AFK dispatch
|
||||||
hygiene (Sleipnir)" for the gate's hard requirements.
|
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.
|
> **concept** (heid refinement optional) → **contract** → **contract
|
||||||
2. Heid consult on the issue (`/heid`).
|
> review** → **TDD slices** (all of them) → **heid code-review** →
|
||||||
3. `/vor` — or `/vor-frame` (ask too shapeless to draft a `/vor`
|
> **fixup** → **heid bug-hunt** → **fixup** → **merge/commit**
|
||||||
questionnaire) or `/vor-cross` (cross-frontier peer in the loop) —
|
|
||||||
if the ask warrants a pre-contract design pass. Skip when the
|
As numbered stages:
|
||||||
frame is already crisp.
|
|
||||||
4. Write the contract.
|
1. **Concept.** Frame the work. A heid consult (`/heid`) or a `/vor` /
|
||||||
5. Heid contract review (`/heid-contract-review`).
|
`/vor-frame` / `/vor-cross` pass is *optional refinement* — take it
|
||||||
6. Fixup the contract per triaged findings.
|
when the ask warrants it, skip it when the frame is already crisp.
|
||||||
7. TDD implement (`/tdd`) — red-green-refactor against the contract.
|
2. **Contract.** Write the `.contract.md` (graphify the blast radius
|
||||||
8. Heid code review (`/heid-code-review`) — code-vs-contract drift.
|
first per the rule above).
|
||||||
9. Fixup the code per triaged findings.
|
3. **Contract review.** `/heid-contract-review`, then **fixup** the
|
||||||
10. Commit if clean.
|
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
|
## Tooling preferences
|
||||||
|
|
||||||
@@ -389,7 +421,8 @@ section doesn't cover.
|
|||||||
|
|
||||||
This section is Corviduo's **operational cadence layer on top of that
|
This section is Corviduo's **operational cadence layer on top of that
|
||||||
policy**: which commits become releases and at what tier (tier-bar
|
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,
|
differ on cadence or tier choice, this section governs; for format,
|
||||||
contract semantics, pre-release staging, and release mechanics, the
|
contract semantics, pre-release staging, and release mechanics, the
|
||||||
policy governs. Operator ruling (2026-07-02): pre-1.0 **milestone
|
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.
|
Brokkr pings worldtree-dev / galdrabok-dev / sleipnir-dev / etc.
|
||||||
when a post-1.0 minor lands.
|
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
|
**Patch, pre-release, and dev bumps are at agent discretion.** Apply
|
||||||
part of the work.
|
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
|
**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
|
1. Identify that the work warrants a non-patch bump per the
|
||||||
tier-bar test (release-note / push-notification / blog-post).
|
tier-bar test (release-note / push-notification / blog-post).
|
||||||
@@ -592,10 +633,11 @@ paragraph, or am I just accumulating substantive work?
|
|||||||
|
|
||||||
### Mechanics every bump
|
### Mechanics every bump
|
||||||
|
|
||||||
0. **If non-patch, get operator approval first** per the § *Operator
|
0. **If minor or major (an `X` or `Y` field change), get operator
|
||||||
approval required for any non-patch bump* rule above. Do not
|
approval first** per the § *Operator approval required for minor +
|
||||||
proceed to step 1 until the operator has explicitly approved the
|
major bumps only* rule above. Do not proceed to step 1 until the
|
||||||
minor or major bump. (Patch bumps skip this step — apply
|
operator has explicitly approved the minor or major bump. (Patch,
|
||||||
|
pre-release/alpha/beta/rc, and dev bumps skip this step — apply
|
||||||
autonomously.)
|
autonomously.)
|
||||||
1. Edit `pyproject.toml` (or equivalent project-file) version field.
|
1. Edit `pyproject.toml` (or equivalent project-file) version field.
|
||||||
2. Run `uv lock` (Python) or equivalent so the lockfile records the
|
2. Run `uv lock` (Python) or equivalent so the lockfile records the
|
||||||
|
|||||||
Reference in New Issue
Block a user