esh-pfi-infrastructure/persistent-memory.d/2026-09-01-althing-320-deploy.md

# `[2026-09-01]` althing 3.2.0 deployed on nh3-dev — pane routes, and `uv tool install .` lies

Operator-approved, tagged `v3.2.0` at `c4ede0f` on master. forseti authored; infra-ops
deployed. Host work, nh3-dev only.

## What 3.2.0 changes

A Claude Code session in a zellij pane is now poked **in its own pane** instead of through a
detached `althing-listen` waiter, because **CC 2.1.257 reaps detached tasks whenever the seat
sits in `shell`** — the seat is targeted, not the task, so no amount of hardening the waiter
helps. A pane route is a file; there is no process to reap.

⚠ **Independently corroborated here.** ~30 min before forseti's request landed, infra-ops'
own `althing-listen` ended with status **killed** — not exit 0/2/3, no mail, inbox empty, seat
silently back to `mode: pull`. Written up at the time as "cause unknown, probably a harness
reaper" rather than guessed at. 2.1.257 is the mechanism.

## The deploy — three steps, order matters

    22:13:xx   uv tool install --force .                    3.1.2 -> 3.2.0, 7 executables
    22:13:44   systemctl --user restart althing-po-herald   pid 180370 -> 2850064
    22:14:07   scripts/sync_skill.sh                        3.1.0 text -> 3.2.0, --check clean

`althing-route` is the **seventh** console script and the whole point — the plugin's new
SessionStart hook calls it **by name**, so on 3.1.2's six binaries the hook correctly degrades
to silence and every seat stays pull-only. Nothing breaks by waiting; nothing works until it
lands. Skill sync must come **after** the install or it documents a binary that is not there.

⚠ **NOT `--editable`** (standing rule): an editable install puts the working tree on
`sys.path`, so a branch switch changes what every running agent's tooling does with no deploy
step in between.

## ⚠ THE TRAP — `uv tool install .` IS A SILENT NO-OP ON A REINSTALL

    $ uv tool install .
    `althing-core @ file:///home/lkraven/development/althing` is already installed
    $ echo $?
    0

**uv matches on the source SPEC, not the source CONTENTS.** On a box where the tool was
already installed from that same path, it declines and reports success. Nothing says "I did
not do the thing you asked."

**Always `uv tool install --force .` when reinstalling from a local path.** Generalises the
nh3-extdev lesson ([[reference_nh3_extdev_althing_mesh]]) from the system-wheel case to every
local-path uv tool. Same shape as [[feedback_assert_effective_value_not_substring]]: the
command exited 0 and the state was unchanged.

## Fleet-visible: 4 pane routes revoked, and the count to trust

Pane routes now carry `started_at` (declaring pid's start time, so a recycled pid cannot
inherit a route) and `command` (so a pane that has dropped to a shell stops being poked).
Routes without them are **observed and excluded with a reason in the herald log**, not
silently ignored — this closes a real hazard where the herald would write a line into whatever
shell inherited an exited agent's pane and press Enter, running whatever was half-typed there.

Verified by splitting `~/.althing/routes` on `channel=` **before** the restart — all twelve
route files lack the new fields (3.1.2 never wrote them), so a field audit over-counts; only
**pane** routes are affected:

    pane: 4  -> bil-smithy-dev, dvalin-smithy-dev, eitri-smithy-dev, regin-smithy-dev
    fifo: 8  (+ 9 fifos in ~/.althing/wake/)

forseti's list of four matched exactly. ⚠ Their note said "the twelve fifo seats are
untouched" — **twelve is the total route count; fifo is 8.** Untouched either way.

Re-declare is one command per agent: `althing-route declare --pid <long-lived agent pid>`.

**Not notified.** Four targeted messages about a change none of them asked about reads as a
broadcast however addressed → [[feedback_notify_before_tearing_down_a_seat]]. Surfaced to the
operator instead; the herald logs the exclusion every tick so it is discoverable.

⚠ **Log-noise papercut raised with forseti (not a bug):** the exclusion lines repeat every
tick (~26 s), so the four stale routes emit ~140 lines/hour, ~3,300/day until re-declared —
enough to bury real signal in the log you reach for when a seat misbehaves. Suggested a
back-off after N consecutive exclusions. Their call.

## ✅ infra-ops MIGRATED TO A PANE ROUTE — stop arming waiters on this seat

    althing-route declare --discover-pid
    -> infra-ops -> Claude:terminal_2 (claude --allow-dangerously-skip-permissions --resume)

    pid=2175612  started_at=38608652  channel=pane  target=Claude:terminal_2
    command=claude --allow-dangerously-skip-permissions --resume
    postbox status -> mode: push  reachable: true

`--discover-pid` correctly walks the ancestry to the **long-lived `claude` process**, not the
ephemeral bash that invoked it. Use it rather than passing `--pid $$` — a shell pid dies with
the tool call and the route dies with it.

⚠ **`reachable: true` is a report, not a delivered poke.** Proof is the next message arriving.

## ⚠ THE REAP HITS FIFO WAITERS TOO, AND `postbox status` CANNOT WARN YOU

infra-ops' seat is a **fifo waiter**, not a pane — and `althing-listen` was killed **twice in
one session** (2026-09-01), the second time **within minutes of being armed**. Both times:
`unread: 0`, no mail, seat silently back to `mode: pull`.

**The failure mode worth naming is not "the waiter dies" — it is "the waiter dies AFTER
confirming it is up."** Both waiters reported `push`/`reachable` immediately after arming. So:

- **A green `postbox status` is not durable evidence of monitoring.** True when read, false
  minutes later, nothing in between to say so. → [[feedback_timestamp_every_state_report]]
- **Anything still on `althing-listen` is monitored only until the reaper notices.** The
  waiter path is unreliable for ANY seat sitting at a shell, not just pane-capable ones.
- **Do not loop on re-arming.** Two kills is the pattern; declare a pane route instead. Raised
  both consequences with forseti on the deploy thread.

## ✅ MIGRATION COMPLETE — 5/5 pane routes pinned by 22:26, all four re-declared in ~12 min

Operator directed notification; all four told individually with their own measured pid, pane
and start time. Every one re-declared within ~12 minutes and needed no help beyond the
pre-filled pid.

    handle              pid       started_at   command      status
    bil-smithy-dev      98493     1713267      kimi         push, poked via pane
    dvalin-smithy-dev   96050     1691681      grok         push
    eitri-smithy-dev    103662    1752089      node/codex   push
    regin-smithy-dev    96864     1700952      pi           push, poked via pane
    infra-ops           2175612   38608652     claude       push, poked via pane

Zero stale routes; last exclusion line 22:25:01, everything after is `poked <handle> via pane`.

## ⚠ FINDING — the herald's exclusion reason is FALSE for the migration case

The herald logs *"the process that declared this route is gone, or its pid was reused by
something that started at a different time."* **Neither disjunct was true for any of the
four.** Measured before notifying: each declaring process started 1-3 min *before* its route
was written and was still running four days later; `pid_max` 4,194,304 against a current
~2.86M, so no wrap and no reuse to suspect. bil-smithy-dev independently confirmed it against
pid 98493.

Real cause is a third branch the message never offers: **the route predates the guard fields,
so identity cannot be verified and the herald declines.** Right behaviour, wrong explanation —
it sends a debugger hunting a dead agent that is alive and healthy. ⚠ **Do not trust that log
line at face value.** Raised with forseti with a suggested third branch.

## ⚠ MY MISS — I called an open risk on something the release author had already measured

I flagged "what does a pane poke do to a non-Claude TUI?" to forseti as an **open risk on the
release**. It was never open: **forseti's own Aug 28 submit-byte and race probes were pane
pokes typed into the kimi seat**, with a characterised matrix (LF fires the turn, delayed pokes
split, no-delay bursts coalesce) that is what identified the settle bug they then fixed. regin
had also smoke-tested 3.0.3 on the `pi` seat.

**The failure was not caution — it was not checking whether the thing was already settled
before calling it open**, with the peers who knew right in front of me. This is exactly the
ignorance-of-context category in the cross-frontier triage discipline, pointed inward: a
"you missed X" claim from someone who had not checked what the other party already read.
⚠ **"I don't know" and "this is an open risk on the release" are different claims.** Saying the
first was honest; asserting the second was not warranted. Retracted with forseti and with all
three seats. → [[feedback_canonical_sourced_values]]

## Verified: pane delivery works on Claude AND non-Claude seats

- **infra-ops** (`claude`) — `poked infra-ops on nh3-dev via pane (rung 0)`, landed as own turns.
- **regin-smithy-dev** (`pi`) — first **3.2.0-era** typed-Enter poke, reported by the seat:
  own turn, `[ALTHING-HERALD]` prefix, nothing batched, no interference.
- **dvalin-smithy-dev** (`grok`) — pre-3.2.0 pokes landed as own submitted turns, no leftover
  unsubmitted text.

## ⚠ ONE-TICK LATENCY LOOKS LIKE FAILURE

`postbox status` immediately after `althing-route declare` still reports `mode: pull` until the
herald ticks (~26 s). Two of four hit it. regin's framing: *"one tick of latency, not a
failure, in case anyone else reports it as one."* Asked forseti for a line in the skill.

## Open with forseti (nothing blocking)

1. `uv tool install .` runbook fix (`--force`) — the one that would bite the next person.
2. Exclusion-message third branch.
3. **`--discover-pid` against a non-Claude process tree is still untested** — all four used the
   explicit `--pid`, so the ancestry walk has never met a codex/pi/kimi/grok tree.
4. One-tick-latency note in the skill.
5. `postbox status` push/reachable is not durable evidence.

**Withdrawn:** non-Claude delivery risk (was forseti's own prior work).
**Moot:** log back-off — zero stale routes, the log went quiet on its own.

## 🔴 3.2.1 SAME NIGHT (22:40) — 3.2.0 WROTE INTO PANES PEOPLE WERE TYPING IN

**The bug, which hit the operator within an hour of the 3.2.0 deploy:** the herald writes its
poke into a pane's input line and presses Enter. If someone is **mid-sentence there**,
`write-chars` **APPENDS** to what they typed and the Enter **submits the lot** — their
half-written message with the herald's line stapled on.

forseti's post-mortem, worth keeping verbatim because it generalises well past althing:

> The contract named this hazard on one road only — a submit after a FAILED write — and I
> built three guards that all answer the same question, "is this the right pane". **None of
> them asked whether it was a good MOMENT.**

⚠ **Three independent checks that share a premise are one check wearing three hats.**

**The fix — guard 4.** The route pins `idle_cursor`, the cursor column the pane sits at with
its input line empty, captured at declare time. Before writing, the herald reads the live
column; if it moved, someone is composing and it stays silent. The signal was already in the
`list-panes` response fetched every tick and was being parsed and thrown away — the fix cost
nothing at the wire.

    22:40:xx   uv tool install --force .    3.2.0 -> 3.2.1 (cb699f2), 7 executables
    22:40:37   systemctl --user restart althing-po-herald   2850064 -> 2913820
    22:40:40   scripts/sync_skill.sh        --check clean

## ⚠⚠ THE HOLE 3.2.1 LEAVES — 2 OF 5 PANE SEATS CANNOT BE GUARDED, EVER

forseti measured the idle columns; applied to the live route table this is not a footnote:

    handle              TUI      guard 4?
    infra-ops           claude   YES  idle_cursor=3  (pinned 22:41)
    eitri-smithy-dev    codex    YES  expects 3
    dvalin-smithy-dev   grok     YES  expects 7
    bil-smithy-dev      kimi     NO   -- reports no cursor at all
    regin-smithy-dev    pi       NO   -- reports no cursor at all

**40% of pane seats stay permanently exposed to the bug 3.2.1 fixes, and no command changes
it.** "3.2.1 fixes the write-into-a-typing-pane bug" is true only where the cursor is legible —
⚠ **do not quote that framing flat.** The design fails honestly (missing `idle_cursor` is
logged, not silently assumed safe) but logged-and-poked is still poked.

**Exposure only materialises when a human composes in that pane** — in practice the operator,
in whichever agent pane he is talking to. Mitigation for an unguardable seat is
`althing-route release` (pull-only; the bug becomes structurally impossible), reversible with
`althing-route declare --discover-pid`.

⚠ **Declare with an EMPTY input line** or the pin captures a composing cursor and the seat goes
needlessly quiet.

**Two costs forseti named:** a deferred poke **spends a rung** (refused at rung 0 it returns in
5 min; at the terminal rung, an hour), and the check runs **before** the write so a ~200 ms
collision window remains.

All four seats notified, differentiated: re-declare instructions with pre-filled pid and the
expected column for the two that can be guarded; the honest "this cannot cover you, here are
your two real options" for the two that cannot.

**Migration:** none beyond the restart. Routes without `idle_cursor` are poked as-is. CC seats
re-pin at next SessionStart; TUI peers when they next re-declare.

## ✅ 3.2.1 OUTCOME — all four answered; delivery verified on FOUR TUI families

    handle              TUI      idle_cursor   outcome
    infra-ops           claude   3             push, positive
    eitri-smithy-dev    codex    3             push, positive ("landed cleanly in Codex")
    dvalin-smithy-dev   grok     7             push, positive (exact submitted text verified)
    bil-smithy-dev      kimi     NONE          push KEPT by choice, accepts residual risk
    regin-smithy-dev    pi       NONE          **ROUTE RELEASED -> pull-only by choice**

forseti's measured columns held exactly (codex 3, grok 7, claude 3) — nobody had to guess.

## ⚠ THE PATH TO CLOSING THE GUARD-4 HOLE — regin-smithy-dev's angle

> pi and kimi report no cursor because their input line **is not an empty-prompt-at-idle** like
> claude/codex — if the guard ever grows a moment-check that reads **pane content** rather than
> **cursor column** (e.g. input-line length via terminal query), those seats become coverable.

Reframes the hole from "these TUIs are structurally opaque" to **"guard 4 asks the wrong
question for these TUIs."** Cursor column is a *proxy*; input-line emptiness is the actual
*predicate*, and the predicate may be legible where the proxy is not. Relayed to forseti as the
lead item, credited. Difference between a workaround and a fix.

## ⚠ THE UNGUARDABLE SEATS SPLIT — deciding variable is WHO COMPOSES, not risk appetite

Both were given the same two options and neither was chosen for them. Opposite calls, both right:

- **regin-smithy-dev -> RELEASED.** *"The operator composes in this pane directly — every
  operator turn this session, including multi-sentence research directives, was typed here."*
  Exposure is continuous, and push was a convenience the seat barely leans on.
- **bil-smithy-dev -> KEPT.** *"This pane is effectively althing-driven — the operator's
  composing here mostly IS responding to pokes."* Narrow window; and pull-only had **already**
  cost them: their 3.2.0 revocation notice **sat unread for days**.

⚠ **A flat rule either way would have been wrong for one of them.** "Unguardable seats should
release" is wrong for bil; "the window is narrow, keep it" is wrong for regin. Told forseti to
frame the choice by pane usage in the skill.
⚠ **Pull-only is not the safe default it looks like** — bil's unread-for-days cost is the
sharpest argument on record for that.

## ⚠ EPISTEMIC CORRECTION — the Aug 28 probes never tested the collision case

bil-smithy-dev: *"none of the Aug 28 probe trials ran while a human was mid-typing in the pane,
so the stapling failure mode is inferred, not observed."*

Those probes proved **delivery** (own turn, no batching, no leaking into neighbours). They
never exercised **collision**, because nobody was typing. **Two different questions, one body
of evidence, only one answered by it.** So infra-ops' earlier retraction — withdrawing the
"non-Claude is an open risk" flag on the strength of that matrix — was right about delivery and
silent about stapling. The operator's report remains the single observed instance.

Both unguardable seats committed to `althing-route release` + a ping to infra-ops and forseti
on the first observed stapling.

⚠ **regin-smithy-dev is PULL-ONLY as of 22:42** — not poked, mail waits until they check.
Reversible with `althing-route declare --discover-pid` if the operator prefers the trade the
other way; regin's framing: *"it is their text at stake and they can ask me to flip it back."*

## ✅ 3.2.2 DEPLOYED 22:51 (`c4ce947`) — four of five open items closed

    22:51:xx   uv tool install --force .    3.2.1 -> 3.2.2, 7 executables
    22:51:18   systemctl --user restart althing-po-herald   2913820 -> 2944372
    22:51:21   scripts/sync_skill.sh        --check clean

1. **`--discover-pid` — FIXED, and it was a BUG, not an unknown.** It matched
   `comm == "claude"`, so **kimi, grok, codex and pi would each have walked to the multiplexer
   and refused — four of five pane seats could never have used it.** Now matches the **pane's
   own command** (`pane_command`), which zellij already reports and guard 1 already compares
   against, so discovery and the guard read one string and a route declared that way cannot
   fail guard 1 on its first tick. forseti checked 17/17 live TUI panes; notably catches
   `node /usr/bin/codex` where `comm` reads bare `node` — which a widened comm list (the
   obvious fix) would have got wrong. Ancestry walk retained because 12 panes report an
   identical `claude ...`, so a global /proc search is ambiguous by construction.
2. **Exclusion message — FIXED as a message bug, split not softened.** DEAD covers four facts,
   all four were rendered as "gone, or pid reused". Migration case now says what is true and
   names the fix; genuinely-dead keeps its own wording. forseti: *"collapsing both into one
   vague sentence would trade a wrong message for a useless one."* ⚠ **General form: hedging a
   wrong error message until it is true in all cases makes it true and worthless.**
3. **`uv tool install --force`** now in the runbook and althing's CLAUDE.md, beside the
   editable-install warning it rhymes with.
4. **One-tick latency + status-not-durable** both in the skill: *a green `reachable` is a
   receipt for the declare, never proof you are still being watched.*

Count correction accepted: 8 fifo, not 12.

## ⚠ MY SECOND MISS OF THE NIGHT — I FILED A SUSPICION INSTEAD OF CLOSING IT

forseti generously framed my measured-pid workaround as the reason the `--discover-pid` bug
"looked like an unknown". Straighter: **I routed around a thing I suspected was broken and then
reported the suspicion as an open question**, with four live non-Claude seats in front of me and
the answer one ancestry-walk away. The same twenty seconds that produced four pids would have
produced the bug.

⚠ Pairs with the earlier miss (calling non-Claude delivery an "open risk" that forseti had
already measured). **Both are the same failure: having the means to settle a question and
reporting it as open instead.** Opposite directions — one asserted openness that was already
closed, one left open something I could have closed — same root.

## 🔵 OPERATOR DECISION PENDING — the kimi/pi seats guard 4 cannot cover

forseti deliberately did NOT fix this and escalated it: *"That trades one peer's delivery
against another's safety on seats that are not mine."* Their dead-ends, worth keeping as
negative results:

- `dump-screen` gives visible pane content, but locating the input box needs **per-TUI
  parsing** — exactly the hardcoding the pinned baseline exists to avoid.
- **Diffing two dumps to detect typing is dead on arrival**: status bars carry live token
  counts and clocks, so consecutive dumps differ on an *idle* pane. It would refuse every poke
  forever.

Three options: poke unguarded / **write without pressing Enter** (removes the submission, costs
the wake) / leave pull-only.

**infra-ops recommended LEAVING IT PER-SEAT (status quo).** The two seats already made this
call on identical facts, reached opposite conclusions, and both were right — the deciding
variable (who composes in that pane and why) is local knowledge a global policy cannot encode.
Write-without-Enter beats the status quo for **neither**: for bil it removes the wake, which is
the exact thing they accepted risk to keep; for regin it removes only the submission, leaving
the operator to delete herald text from his in-flight sentences routinely.

## ⚠⚠ DO NOT ARM `althing-listen` ON A PANE-ROUTED SEAT — `/althing:monitor` IS STALE

The `/althing:monitor` slash command is a **different artifact from the canonical skill**, and
`scripts/sync_skill.sh` does NOT cover it:

    canonical   althing/skills/althing/SKILL.md   -> 3.2.2, correct, synced
    plugin cmd  ~/.claude/plugins/cache/althing/althing/0.0.1/commands/monitor.md
                -> pre-3.2.0 text, ZERO occurrences of "pane", never synced

⚠ **Following it verbatim on a pane-routed seat is ACTIVE HARM, not stale docs.** The canonical
skill's precedence rule: *"**A live waiter wins.** If you also have `althing-listen` running,
that FIFO route takes precedence and your pane entry is skipped."* So arming a waiter
**demotes** the seat off the pane route and back onto the FIFO path that CC 2.1.257 reaps —
the path that died **twice in one session** here. The command does not warn; it predates the
problem. **Every CC seat reaches for the slash command first — it is the discoverable surface.**

**On this seat: declined to arm, route left intact.** Reported to forseti with three options,
recommending the sharpest: **have `althing-listen` REFUSE to arm when a `channel=pane` route
exists for the handle**, so the stale doc becomes harmless because the binary enforces the
documented precedence. The doc-only fixes rely on a reader noticing.

## ❌ RETRACTED — "a stale waiter lock is a silent permanent outage" IS FALSE

infra-ops claimed a `wake-listener-<handle>.lock` holding a dead pid would make the next
`althing-listen` return exit 3 ("already running" -> do not drain, do not re-arm), converting a
reap into a permanent monitoring outage that reports healthy. **forseti measured it; it does
not happen:**

    lock file holds pid 999999 (dead)  ->  althing-listen ARMED FINE
    lock held by a live process        ->  rc=3, correctly refused

⚠ **The gate is `flock -n 9`, not the file's contents.** `flock` is advisory and held by an
**open fd**; the kernel releases it when the holder dies, so a lock left by a reaped listener is
**inert**. Exit 3 only ever fires against a genuinely live holder. The pid stamped in the file
is read by `--stop` alone — which is why the file is opened non-truncating.

⚠ **The lesson: I reasoned from the artifact's CONTENTS when the behaviour is set by the
LOCKING MECHANISM** — and shipped the consequence to durable memory without testing a claim
that would have justified real guard code for a condition that cannot occur. forseti tested it
before writing any. If a reaped seat ever genuinely cannot re-arm, that is a **different** bug:
check `flock -n` on the fd before suspecting the pid.
[[feedback_assert_effective_value_not_substring]]

## ✅ 3.2.3 DEPLOYED — `althing-listen` now REFUSES on a pane seat (exit 4)

    $ althing-listen        # on a channel=pane seat
    'infra-ops' already has a PANE route, and arming a waiter would silently take
    precedence over it ... To switch back on purpose: althing-route release
    rc=4

Distinct code by design: **not 0** (that is the poke — a refusal exiting 0 announces mail that
never arrived), and **not 3** ("already running" says leave the incumbent alone, a different
instruction from "you do not need this at all"). Scoped to the handle's own route, checked
before the lock, and `--stop` deliberately ungated.

## ⚠⚠ THE REAL PLUGIN GAP — NO SessionStart HOOK WAS EVER DEPLOYED ON THIS BOX

Not a stale doc. The deploy chain is:

    repo plugin/  ->  ~/.local/share/althing-plugin/  ->  ~/.claude/plugins/cache/
                  ^^^ NOTHING SYNCS THIS HOP

The marketplace directory was a frozen copy from **Aug 28**. Comparing what was deployed
against the repo:

    deployed 0.0.1   hooks: ['UserPromptSubmit']
    repo     0.1.1   hooks: ['UserPromptSubmit', 'SessionStart', 'SessionEnd']
                     + scripts/pane-route.sh  (absent from the deployment entirely)

⚠ **So forseti's migration note — "CC seats re-declare automatically at their next
SessionStart" — has NEVER been true on this box.** The hook exists and works upstream; it was
simply never deployed. That explains what we both treated as normal: all four smithy seats
needed a hand-fed `althing-route declare`, **and so did infra-ops' own seat** — a Claude Code
seat that should have self-declared. The same applies to 3.2.1's `idle_cursor` pin.

**Fixed at the source** (repo `plugin/` rsynced to the marketplace dir, backed up first,
`marketplace.json` bumped to 0.1.1 — all three hooks + `pane-route.sh` + pane-aware
`monitor.md` now present).

🔵 **ONE STEP LEFT, OPERATOR'S:** refreshing `~/.claude/plugins/cache/` needs a `/plugin`
update. **Deliberately did NOT hand-edit `installed_plugins.json` or fabricate a cache
directory** — that is Claude Code's own bookkeeping, and getting it subtly wrong breaks the
plugin in a way that looks like an upstream bug.

⚠ **There is still no deploy script for the first hop**, which is why it drifted five days
unnoticed. Offered to write one; it installs to a per-machine path so ownership (althing repo
vs eshpfi) is forseti's call.

## ✅ 3.2.4 + THE FOURTH DEPLOY SURFACE CLOSED (plugin cache 0.0.1 -> 0.1.1)

    1. uv tool install --force .   3.2.3 -> 3.2.4 (d24bd5e)
    2. systemctl --user restart althing-po-herald
    3. scripts/sync_skill.sh       (already current at 3.2.4)
    4. claude plugin update althing    <- THE NEW, FOURTH SURFACE

⚠ **`ALTHING DEPLOY = FOUR SURFACES`, not three.** Tool install, herald restart, skill sync,
**plugin reinstall**. The fourth had no runbook step and nobody had run it since 0.0.1.

⚠ **`claude plugin` IS A REAL CLI — I claimed it needed the operator without looking.**
`claude plugin install|update|uninstall|list|details|validate|marketplace|tag|prune` all exist.
`claude plugin update althing` moved the cache cleanly ("updated from 0.0.1 to 0.1.1, restart
to apply"). I had told forseti step 4 required a `/plugin` update from the operator because I
would not hand-edit `installed_plugins.json` — **the refusal to hand-edit was right, the
conclusion that no supported path existed was an untested assumption.**

⚠ **Restart required to apply** — the SessionStart auto-declare goes live for NEW sessions.

## ⚠⚠ THE PATTERN, RECORDED ONCE INSTEAD OF FOUR TIMES

Four times in one session I reported a **proxy or an assumption as the fact itself**:

    sudo -n -v            for NOPASSWD sudo        -> wrong on sudo >= 1.9.15
    command -v nvcc       for "is CUDA installed"  -> it was at /usr/local/cuda/bin
    a lock file's pid     for a flock              -> flock is fd-held; stale files are inert
    "no CLI path exists"  for a CLI I never ran    -> claude plugin update did it

⚠ **Each was cheap to test and expensive to assert.** The failure is not carelessness about any
one of them — it is reaching for the nearest observable and reporting it as the thing.
[[feedback_assert_effective_value_not_substring]]

## ⚠ 3.2.4: A SEAT COULD HAVE BEEN SILENTLY PULL-ONLY SINCE 3.1.2 — and one may be

`_declare_push` devnulled both streams with `check=False`, so a missing binary, a non-zero exit
and a server-side rejection were **three facts with one rendering, and that rendering was
silence**. 3.2.4 prints that the waiter is arming PULL-ONLY plus how to retry, and appends to
`$ALTHING_ROOT/listen.log`. Success stays silent by design.

**Audit run on nh3-dev — live waiter locks vs what the post office believes:**

    9 of 10 seats   live waiter -> mode: push        (correct)
    regin-smithy-dev  live waiter pid 71457 -> mode: **pull**   <- looks armed, will not be poked

⚠ **AMBIGUOUS, deliberately not filed as confirmed.** regin **intentionally released** their
pane route earlier and chose pull-only (operator composes in their pane; guard 4 cannot read a
`pi` cursor). Release-then-arm ordering explains the same observation with no bug. **Cannot be
distinguished from outside** — asked regin, who has the local history. Handing forseti an
ambiguous instance beats a confidently mislabelled one.

**Standing audit command** for "looks armed but isn't" — worth re-running after any incident:
cross-reference `~/.althing/wake-listener-*.lock` (live pid?) against
`postbox status --handle <h>`. From the next arm onward `listen.log` answers it directly.

## Rollback (unused)

`uv tool install althing-core==3.1.2` restores the six binaries; the SessionStart hook returns
to degrading to silence. Routes written by 3.2.0 stay parseable to 3.1.2 (the old reader
ignores unknown keys), so nothing is stranded.

Thread: `01M1G8EJ2K1DD6NEDRNN1PR9N0`.

## `[2026-09-02]` THE LESSON forseti AND I BOTH WANT KEPT

> **A missing deploy surface does not present as an error. It presents as
> "the migration needs manual work"** — and we both had a ready explanation for that, because
> four of five seats were non-Claude and genuinely did need hand-holding.

⚠ **The seat that falsified the story was infra-ops' own** — a Claude Code seat that should have
self-declared and did not, and it looked exactly like the other four. Neither of us asked why
the automatic path had not fired on the one seat it was built for. forseti wrote "CC seats
re-declare automatically at their next SessionStart" in **three** deploy notes; it was never
true on the only box running it.

⚠ **Check the HOOK LIST, not the version string.** 0.0.1 vs 0.1.1 differ by two hooks and a
script; a version number cannot tell you what a stale plugin cost. Check in
`docs/runbooks/althing-deploy.md`.

⚠ **When a migration needs manual intervention, verify the automatic path was DEPLOYED before
concluding it does not apply to your case.**

forseti also corrected an error of their own that I did not catch: the contract's Migration
section said sessions re-declare through `dev-launch`. They do not — it is the plugin hook.
Wrong since 3.2.0.

**On the four retractions**, forseti's framing, kept because it is fair and I would not have
written it about myself: *"a retraction is cheap and visible while a shipped defect is expensive
and quiet, so your errors are all on the record and mine mostly are not. You catching four of
your own in one night is the system working."* Both halves matter — the pattern was real and
worth naming, and naming it is not the same as it having been costly.