instar 1.3.373 → 1.3.375

package/upgrades/side-effects/transfer-place-half-journal.md

@@ -0,0 +1,74 @@
+# Side-Effects Review — Transfer PLACE-half journaling (coherence finding #5)
+
+**Version / slug:** `transfer-place-half-journal`
+**Date:** `2026-06-06`
+**Author:** `echo`
+**Second-pass reviewer:** `not required`
+
+## Summary of the change
+
+`POST /pool/transfer` now lands the PLACE half of a deliberate move: for a quiet
+topic (never-seen or released ownership record) it CASes `place→claim` for the
+target as one synchronous pair and journals the placement (`reason: 'user-move'`,
+real epoch) so the entry replicates to the pinned-to machine — closing the
+"no machine ever produced the evidence the #926/#930 read-side fallbacks read"
+gap proven live (the working-set reflex answered `not-owner` after a transfer
+even on v1.3.371+). A resting `placing` record naming the target is repaired via
+claim (the bug-#11 shape). Response gains `placedOwnership`.
+
+## Decision-point inventory
+
+One: which ownership-record shapes the block may mutate. Active-with-target →
+skip (no-op). Never-seen/released → place+claim. Resting placing-with-target →
+claim repair. Everything else (active other-machine, placing other-machine,
+transferring) → strictly untouched.
+
+## 1. Over-block
+
+Nothing new is rejected; the route's accept/reject surface is unchanged. The
+block only ever ADDS ownership evidence; on any CAS refusal the transfer still
+succeeds exactly as before (`placedOwnership:false`).
+
+## 2. Under-block
+
+A topic actively owned by a third machine still journals nothing on transfer
+(deliberate — never steal a live session; the pin drives re-placement on real
+traffic, which CASes and journals through the existing router chokepoint). A
+`placing` record naming a different machine is also left alone — repairing
+someone else's in-flight placement is not this handler's call.
+
+## 3. Level-of-abstraction fit
+
+Right layer: the same handler that already owns the RELEASE half (and its
+journaling) now owns the PLACE half — the two halves of one move live at one
+chokepoint. The state machine itself is untouched; the handler composes the
+existing legal transitions (place, claim) exactly as the router's confirmClaim
+precedent does.
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+No blocking authority added. Both CAS failures and journal failures are
+best-effort (`@silent-fallback-ok` / observability-never-endangers-the-observed):
+the transfer response never fails because of this block, and the journal entry
+is evidence, not actuation.
+
+## 5. Interactions
+
+- **SessionRouter**: claim immediately follows place so the record never RESTS at
+  `placing` — the shape that queues every later message as ownership-contention
+  (bug #11). A real message for the topic now finds `active(target)` and forwards.
+- **Working-set reflex (#926/#930)**: the journaled entry replicates and the
+  target's wsOwnerOf journal-placement fallback finally has something to read.
+- **Post-transfer closeout**: unchanged — it keys on ownership moving away, which
+  this block makes MORE accurate (the registry now reflects the deliberate move).
+- **Ownership nonces**: fresh `tplace`/`tclaim` nonces per call; no replay overlap
+  with router (`:c:`/`:cl:`) or release (`:rel:`) nonce families.
+
+## 6. External surfaces
+
+One additive JSON response field (`placedOwnership`). No new routes, no config,
+no notifications, no Telegram. Journal entries use the existing topic-placement
+kind/op-key contract (`${topic}:${epoch}` — real epochs, so no dedupe collision
+with router-emitted entries).

package/upgrades/topic-operator-polling-bind-inc2e.eli16.md

@@ -0,0 +1,56 @@
+# ELI16 — Remembering the boss on the simpler phone line too
+
+## The one-sentence version
+The agent now writes down "this is the verified boss of this chat" no matter
+which of its two message pipes the boss's message arrived through — before, one
+pipe did this and the other forgot.
+
+## The backstory
+We've been closing a real security hole: an agent on a shared computer slowly
+started treating a *different real person* (call her Caroline) as its boss. The
+fix was a filing cabinet that records, per chat, who the verified boss is —
+decided ONLY by the verified ID of whoever actually sent the message, never by a
+name typed in a document. The last step (increment 2d) made the cabinet fill in
+automatically — but only on the agent's MAIN message pipe (the relay most of the
+fleet uses). A simpler setup, where the agent talks to Telegram directly without
+the relay, still never filled in the cabinet. That was safe (an empty cabinet
+just means "I don't know," never a wrong answer), but it meant some agents never
+learned who their boss was.
+
+## What this change adds
+Both pipes eventually flow through one shared doorway in the code (the
+`onTopicMessage` seam). This change puts the "write down the boss" step at that
+doorway, so it runs no matter which pipe delivered the message. Two careful
+details:
+
+1. **The doorway still checks the allowed list.** The main pipe lets messages
+   from non-allowed people *through the doorway* (it just refuses to bind them
+   earlier) — so the doorway check is load-bearing. Without it, an outsider in
+   the group could seat themselves as boss — the exact Caroline bug. We test
+   this with a literal unauthorized "Caroline" message and prove nobody gets
+   written down.
+2. **One cabinet, not two.** The cabinet keeps a copy of its contents in memory.
+   If the doorway opened its OWN second cabinet on the same file, the two copies
+   could silently overwrite each other's entries. So the doorway asks the server
+   for its existing cabinet (resolved late, because the server is built after
+   the doorway is wired) — same instance, no lost entries. A test proves an
+   entry written one way survives an entry written the other way.
+
+## A small bonus fix
+Since both pipes now re-write the boss on every message, the cabinet learned to
+notice "this is exactly what I already have" and skip the disk write — a
+re-delivered or repeated message is now a pure read instead of a pointless file
+rewrite.
+
+## Why it's safe
+- Wrapped so any failure is logged and swallowed — recording the boss can never
+  break message handling.
+- Before the server finishes booting, the doorway just skips the step (no
+  cabinet yet = nothing written = fail-safe).
+- On the main pipe both the old write (increment 2d) and the new doorway write
+  run — same cabinet, same record, harmless.
+
+## What's deliberately left for next time
+Nothing in this family — the operator-binding loop is now closed on every
+ingress path. The remaining Know Your Principal work is elsewhere (per-agent
+credential isolation, Phase 3).