instar 1.3.374 → 1.3.375

package/upgrades/{1.3.374.md → 1.3.375.md}

@@ -5,6 +5,17 @@
 
 ## What Changed
 
+The verified topic operator is now recorded automatically on BOTH inbound
+ingress paths (Know Your Principal standard, security-build increment 2e — the
+final operator-binding gap). Increment 2d covered only the lifeline-forward
+route; the adapter long-poll (no-lifeline) path never bound. The bind now lives
+at the shared `onTopicMessage` seam (`wireTelegramRouting`), guarded by
+`isAuthorizedSender` — load-bearing there, because the seam also fires for
+unauthorized senders. The seam resolves the server's own store instance
+late-bound (a second instance on the same file would lose updates between the
+two in-memory caches), and `TopicOperatorStore.setOperator` now skips the disk
+write when the record is unchanged (per-message re-binds become pure reads).
+
 `POST /pool/transfer` of a QUIET topic (never-seen or released ownership
 record) previously journaled NOTHING: the placement pin is router-local and
 the handler's release half only fires when the router itself held ownership.
@@ -25,6 +36,12 @@ other in-flight shape is left strictly untouched.
 
 ## What to Tell Your User
 
+Nothing user-facing changes. Foundation wiring (experimental) for the identity
+isolation security work: the agent now learns its verified operator from
+authorized inbound messages no matter how its Telegram connection is set up.
+Only authorized senders are ever recorded, and a recording failure never
+affects message handling.
+
 Nothing proactively — this is internal coherence plumbing. If they previously
 moved a quiet conversation between machines and the receiving machine couldn't
 fetch its files, that path now works: the move itself writes the ownership
@@ -35,6 +52,14 @@ record and it travels to the receiving machine automatically.
 
 ## Summary of New Capabilities
 
+- Operator auto-bind at the `onTopicMessage` convergence seam (covers the
+  polling path; authorized senders only; fail-soft; pre-boot messages bind
+  nothing, fail-safe).
+- `AgentServer.getTopicOperatorStore()` — public accessor for the seam's
+  late-bound store resolution.
+- `TopicOperatorStore.setOperator` idempotency: identical record → no disk
+  write.
+
 - Quiet-topic transfers journal ownership evidence (place + claim halves, real
   epochs, `reason: 'user-move'`) that replicates to the pinned-to machine —
   unblocking its working-set fetch reflex (#930 fallback finally has a producer).
@@ -45,6 +70,15 @@ record and it travels to the receiving machine automatically.
 
 ## Evidence
 
+Verified by 6 Tier-1 unit tests (`topic-operator-polling-bind`: authorized
+binds, unauthorized Caroline refusal, null store / getter throw / setOperator
+throw all fail-soft with routing continuing, missing uid no-op), 2 Tier-1 store
+tests (idempotent skip both sides), and 3 Tier-2 integration tests
+(`topic-operator-polling-bind`: full Caroline replay through the seam,
+single-instance no-clobber across two topics on disk, pre-construction →
+post-construction lifecycle). All 60 existing topic-operator/session-context
+canaries and 13 e2e lifecycle tests stay green. Clean `tsc --noEmit`.
+
 - `tests/integration/pool-placement-transfer-routes.test.ts` — 6 new boundary
   tests: quiet/never-seen (both halves journaled, record lands `active`),
   self-owned (release + place + confirm, 3 entries), active-other (never

package/upgrades/side-effects/topic-operator-polling-bind-inc2e.md

@@ -0,0 +1,62 @@
+# Side-effects review — Topic Operator polling-path auto-bind (Know Your Principal #898, increment 2e)
+
+## What this change does
+Closes the auto-bind gap #909 documented: the adapter long-poll (no-lifeline)
+ingress path never bound the verified operator. The bind now lives at the
+`onTopicMessage` seam in `wireTelegramRouting` (src/commands/server.ts) — the
+convergence point BOTH ingress paths reach — so a no-lifeline install learns its
+operator too. Three coordinated pieces:
+
+- `wireTelegramRouting` gains a late-bound `getTopicOperatorStore` parameter
+  (the `getHubDeps` precedent in the same function) and an additive bind block
+  early in the callback: an AUTHENTICATED + AUTHORIZED sender is recorded as the
+  topic's verified operator.
+- `AgentServer.getTopicOperatorStore()` — public read-only accessor so the seam
+  resolves the server's OWN store instance at message-time.
+- `TopicOperatorStore.setOperator` idempotency guard: an identical record skips
+  the disk write (both paths re-bind per message; unchanged = pure read).
+
+## The load-bearing security property
+The seam fires for unauthorized senders too — the lifeline path only skips its
+own bind, it does not drop the message. So the `isAuthorizedSender` check INSIDE
+the seam bind is load-bearing: without it, an unauthorized group member could
+seat themselves as operator (the cross-principal "Caroline" bug). The
+integration Caroline replay proves the refusal — an unauthorized sender with
+`firstName: "Caroline"` cannot displace the bound operator.
+
+## Why the SAME store instance (the lost-update hazard)
+`TopicOperatorStore` caches its map in memory (`this.cache`). A second instance
+on the same file would hold a divergent cache: a record written through one
+instance disappears from the other's next full-map save. The original Inc-2e
+scout suggested constructing a fresh store inside the callback — that design is
+REJECTED here for exactly this reason. Instead the seam resolves
+`AgentServer.getTopicOperatorStore()` late-bound (module-level `_agentServerRef`
+assigned right after construction; the server is built long after routing is
+wired). The integration no-clobber test pins the invariant.
+
+## Blast radius (hot path — reviewed carefully)
+- **Additive + fail-soft.** The bind block is wrapped in try/catch; a getter
+  error, store error, or missing uid logs and falls through — message routing
+  is never affected. Proven by unit tests (getter throws / setOperator throws /
+  null store → handleCommand still runs).
+- **Pre-construction window.** Messages arriving before `_agentServerRef` is
+  assigned bind nothing (getter → null). Fail-safe: no binding means "unknown",
+  never a wrong operator. Lifecycle test covers the transition.
+- **Lifeline double-bind.** On the lifeline path both the routes-side bind
+  (#909) and the seam bind run — same instance, same record; the new
+  idempotency guard makes the second a no-op read.
+- **Disk-write reduction (behavior change, benign).** `setOperator` with a
+  byte-identical record no longer rewrites the file. Callers only ever read the
+  returned record or the store state — both unchanged. Existing store tests
+  (12) stay green; 2 new tests pin both sides (identical skips, changed
+  writes).
+- **No new route / config key / dependency.** `wireTelegramRouting` is now
+  exported (test seam only; no runtime caller change beyond the two existing
+  callsites gaining the getter argument).
+
+## No-allowlist trust model (unchanged, documented)
+`isAuthorizedSender` semantics are #909's: with no `authorizedUserIds`
+allowlist, every authenticated sender is accepted, so the operator is the
+most-recent authenticated sender. Consistent with the existing trust model;
+the uid is Telegram-authenticated, never a content name
+(`TopicOperatorStore.setOperator` enforces that by construction, #904).

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).