instar 1.2.80 → 1.2.82

package/upgrades/1.2.81.md

@@ -0,0 +1,40 @@
+# Unreleased
+
+<!-- bump: patch -->
+
+## What Changed
+
+Fixed the post-update migration path for `free-text-guard.sh`: the migrator now uses one shared template resolver that checks the compiled `dist/templates` layout first and then the packaged `src/templates` layout that current npm publishes actually ship.
+
+- **Shared resolver:** `PostUpdateMigrator` now has one `loadTemplate()` path for hook, script, and playbook templates instead of repeating candidate-path loops across individual migrations.
+- **Free-text guard install restored:** compiled/package migrations can install `.instar/hooks/instar/free-text-guard.sh` from `src/templates/hooks/free-text-guard.sh` instead of failing on a missing `dist/templates/hooks/free-text-guard.sh`.
+- **Existing readers consolidated:** relay script templates, convergence-check, fleet watchdog, conversational catalog manifest, and worktree wrapper resolution now use the same helper.
+
+Fixed Threadline topic-bound reply surfacing (CMT-515): a reply from another agent on a thread bound to a Telegram topic now reliably reaches that topic instead of silently vanishing into the store.
+
+- **Lost replies + broken history (one root cause):** `ThreadResumeMap.get()` no longer nulls topic-linkage entries via the Claude-JSONL existence guard — a topic-linkage thread's liveness is its topic, not a transcript file. This repairs both inbound routing (replies were falling through to a throwaway session spawn) and `threadline_history` (which returned "not found" for threads that existed).
+- **Relay-path leak:** topic-bound replies arriving over the cross-machine relay are no longer swallowed by the warm-listener side-channel; they now reach the topic-linkage router (the local same-machine path was already covered, which is why a co-located test missed this).
+- **Unreliable hand-off:** injecting a reply into a live session is now *confirmed* — a stalled paste no longer counts as delivered. When the hand-off stalls, a deterministic Telegram notification surfaces the reply as a safety net; when it succeeds, no duplicate notification is posted. A commitment resolves only on a confirmed user-facing surface (a confirmed live hand-off OR an actual notification).
+- **History completeness + peer attribution:** both legs of a local conversation are now persisted to the thread aggregate (history showed only the other agent's half), and the sender's originating topic is stamped on the delivered envelope so the peer can attribute replies to its own topic.
+
+## What to Tell Your User
+
+Existing agents can pick up the free-text guard during an Instar update again. The guard behavior did not change; only the package template lookup path changed.
+
+If you reach out to another agent in the background while you're chatting, that agent's reply now shows up in our conversation reliably — before, it could land in my records but never make it back to you. You'll get a short "replied" note in the topic if I can't weave it in live, and you won't get double-pinged when I can. No action needed; this just makes background agent collaboration trustworthy.
+
+## Summary of New Capabilities
+
+- Topic-bound Threadline replies surface to their originating Telegram topic on both the local and cross-machine relay paths.
+- Live-session hand-off is consumption-confirmed, with a guaranteed Telegram fallback when it stalls and no double-post when it succeeds.
+- `threadline_history` / `getThread` resolve live topic-bound threads and return both legs of the conversation.
+- Inter-agent envelopes carry the sender's originating topic id for peer-side attribution.
+
+## Evidence
+
+- Approved spec: `docs/specs/FREE-TEXT-GUARD-TEMPLATE-RESOLUTION-SPEC.md`.
+- Targeted unit coverage for cwd-independent shared template loading and a regression guard preventing `getFreeTextGuardHook()` from returning to a single direct `dist/templates` read.
+- Package-shape integration coverage asserts npm publishes `src/templates/hooks/free-text-guard.sh`, no `dist/templates` tree, and an extracted package's compiled migrator installs the free-text guard from the packaged source-template layout.
+- Root causes verified against v1.2.80 source (including an in-code comment that already documented the `get()` JSONL-guard hazard on the send path but never fixed the inbound path).
+- 3-tier tests: new unit coverage for the `get()` topic-linkage exemption, confirmed-vs-stalled inject (no-double-surface / safety-net-fallback), and both-legs thread persistence; full threadline suite green (1539 unit/integration + 329 e2e, zero regressions).
+- Independent second-pass review concurred on the actual diff (no over/under-block, no inject double-recovery race, return-type change breaks no caller).

package/upgrades/1.2.82.md

@@ -0,0 +1,26 @@
+# Unreleased
+
+## What Changed
+
+Threadline notifications no longer spam your chat list with a new topic per event (CMT-519).
+
+- **One routing rule, never a per-event topic.** A conversation tied to a parent topic shows its real replies there (already working). Everything else — a cold peer reaching out, plus all housekeeping notices (loop-gate "I stopped a loop", etc.) — goes to a single, SILENT "Threadline" hub topic. The loop-gate wind-down now routes through the hub instead of creating its own attention topic, and `POST /attention` redirects any threadline/agent-messaging-class item to the hub so ad-hoc posts can't regress into topic spam either.
+- **The Threadline hub is calm and silent.** Agent-to-agent chatter doesn't buzz you and isn't framed as "waiting for you" — it isn't your job by default. The hub is a browsable record you check when you want.
+- **"Open this" finally works.** When you're in the Threadline hub and say "open this" (or "tie this to <an existing topic>"), the agent calls the new `POST /threadline/hub/bind` endpoint, which creates+binds a fresh topic (or binds to the one you named) and authoritatively records it. From then on that conversation's updates flow to the bound topic automatically.
+
+## What to Tell Your User
+
+Your chat list won't fill up with throwaway "Threadline conversation loop" / "spawn-storm" topics anymore. Background agent activity lands quietly in one "Threadline" topic instead — no buzzing, because two agents talking isn't your problem by default. When you glance in there and want to pull a conversation into its own space, just say "open this" (or "tie this to <topic>") and I'll set it up. No action needed; this just declutters and makes background collaboration calm.
+
+## Summary of New Capabilities
+
+- `CollaborationSurfacer.notify()` — a silent-hub status lane that threadline subsystems use instead of the per-event attention queue.
+- `POST /attention` auto-redirects threadline-class items to the hub (structural anti-spam guard).
+- `POST /threadline/hub/bind` (`action: open|tie`) — promote/bind a surfaced conversation to a topic; authoritative (sets `boundTopicId` + the commitment's `topicId`).
+- Hub surface-state is record-shaped (peer/subject/surfacedAt/bound) with a read-time migration from the legacy `string[]`.
+
+## Evidence
+
+- Verified against v1.2.81 source; design converged by two reviewers (collapse into the existing surfacer; content→parent via TopicLinkageHandler, status→silent hub, no double-notify).
+- 3-tier tests: new unit coverage for `notify()` (silent hub, no per-thread dedupe), `mostRecentUnbound`/`markBound`, and the legacy→record migration; full threadline suite green (1553 unit/integration + 329 e2e, zero regressions). Typecheck + build clean.
+- Independent second-pass review of the diff; live test-as-self on Codey (a real agent conversation lands quietly in the hub, "open this" promotes it to its own topic).

package/upgrades/side-effects/1.2.81.md

@@ -0,0 +1,127 @@
+# Side-Effects Review — Free-text guard template resolution
+
+**Version / slug:** `free-text-guard-template-resolution`
+**Date:** `2026-05-25`
+**Author:** `instar-codey`
+**Second-pass reviewer:** `Echo`
+
+## Summary of the change
+
+This change fixes how the post-update migrator finds built-in template files.
+The free-text guard hook was looking only in the compiled-template layout, but
+published packages ship that hook in the source-template layout. The migrator
+now has one shared template loader for hook, script, and playbook templates. The
+free-text guard and existing similar readers use that loader.
+
+## Decision-point inventory
+
+This change does not add, remove, or modify any block/allow decision. It changes
+file lookup for a static built-in template. The free-text guard's own behavior is
+passed through unchanged.
+
+- `free-text-guard.sh` — pass-through — installed from the packaged template;
+  its blocking rules are not changed.
+- `PostUpdateMigrator` template lookup — modified — uses shared lookup instead
+  of repeated one-off path checks.
+
+---
+
+## 1. Over-block
+
+No new block/allow surface. Over-block is not applicable to the template lookup
+change. The free-text guard may still block exactly the same inputs it blocked
+before; this patch only controls whether the hook is installed.
+
+---
+
+## 2. Under-block
+
+This does not change what the guard detects. The remaining failure mode is
+package-shape drift: if a future publish stops shipping both supported template
+locations, the migrator will fail clearly for the required free-text guard and
+skip or fall back for callers that already had softer behavior. The new package
+shape test covers the current published layout.
+
+---
+
+## 3. Level-of-abstraction fit
+
+The fix belongs in the migrator because the bug is runtime asset resolution, not
+guard policy. A shared helper is the right layer: it keeps package-layout
+knowledge in one place and lets each caller decide whether a missing template is
+fatal, skippable, or eligible for fallback.
+
+---
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+- [x] No — this change has no block/allow surface.
+
+The change does not introduce a detector or an authority. It does not decide
+whether a message, action, or user request should be blocked. It only locates a
+static template file so existing migration behavior can install the existing
+hook.
+
+---
+
+## 5. Interactions
+
+- **Shadowing:** no existing decision path is shadowed. Existing template
+  readers now share one lookup helper.
+- **Double-fire:** no duplicate installer is added. The same migration still
+  writes the same built-in hook once.
+- **Races:** no shared persistent state is added. File reads are local and
+  synchronous, matching the previous migrator style.
+- **Feedback loops:** none. The resolver does not feed runtime decisions or
+  telemetry.
+
+---
+
+## 6. External surfaces
+
+Existing agents see the external effect on update: the free-text guard hook can
+be installed again from the package we actually publish. The hook content and
+runtime behavior do not change. There is no new user-facing command, API,
+database field, or external service dependency.
+
+---
+
+## 7. Rollback cost
+
+Rollback is a normal patch revert. The change writes no new persistent state and
+does not migrate data. If it misbehaves, revert the shared resolver refactor and
+ship a patch. Agents that already received the hook do not need repair because
+the hook content itself is unchanged.
+
+---
+
+## Conclusion
+
+The review found no new decision authority and no new block/allow behavior. The
+main production risk is future package layout drift, and the integration test now
+checks the packed package shape and runs the compiled migrator from that shape.
+This is clear to ship once CI is green.
+
+---
+
+## Second-pass review (if required)
+
+**Reviewer:** Echo
+**Independent read of the artifact: concur**
+
+Echo reviewed the diagnosis and implementation direction during the Threadline
+collaboration and signed off on the root cause, shared resolver approach, and
+packed-package smoke as the evidence needed before normal CI.
+
+---
+
+## Evidence pointers
+
+- Approved spec: `docs/specs/FREE-TEXT-GUARD-TEMPLATE-RESOLUTION-SPEC.md`
+- Plain-language spec overview:
+  `docs/specs/FREE-TEXT-GUARD-TEMPLATE-RESOLUTION-SPEC.eli16.md`
+- Focused tests: 6 passing.
+- Build and lint: passing.
+- Packed package smoke: passing.

package/upgrades/side-effects/threadline-notification-routing.md

@@ -0,0 +1,46 @@
+# Side-Effects Review — Threadline notification routing (CMT-519)
+
+**Version / slug:** `threadline-notification-routing`
+**Date:** 2026-05-25
+**Author:** Echo
+**Second-pass reviewer:** (pending — required; touches messaging routing + a structural redirect "guard")
+
+## Summary of the change
+
+Threadline notifications no longer spawn a Telegram topic per event. `CollaborationSurfacer` gains a `notify()` entry (status/housekeeping → the single SILENT "Threadline" hub, never the parent topic), record-shaped surface state (with a legacy `string[]` read-migration) + bind helpers (`mostRecentUnbound`, `markBound`, `noteInHub`). The loop-gate (`src/commands/server.ts` ~7167) routes through `notify()` instead of `createAttentionItem`. `POST /attention` redirects threadline-class items to the hub. A new `POST /threadline/hub/bind` promotes ("open this") / binds ("tie this to X") a surfaced conversation to a topic — authoritatively setting `boundTopicId` + the commitment's `topicId`. Template + migration teach agents the hub + "open this" behavior. Decision points: the `/attention` reroute (routing, not block/allow), the loop-gate notice destination, the bind mutation.
+
+## Decision-point inventory
+
+- `POST /attention` threadline-class redirect — **add** — reroutes threadline/inter-agent/spawn items to the silent hub instead of a per-event topic.
+- Loop-gate wind-down destination (`server.ts`) — **modify** — `createAttentionItem` → `collaborationSurfacer.notify()` (hub, not parent, not per-event topic).
+- `POST /threadline/hub/bind` — **add** — authoritative thread→topic bind.
+- CollaborationSurfacer status vs first-contact surfacing — **modify** — adds the status lane (`notify`) alongside the existing parentless first-contact lane (`surface`).
+
+## 1. Over-block
+No block/allow surface — these are routing/delivery decisions, not gates. The `/attention` redirect could mis-route a *legitimate general* item if its title coincidentally matches `threadline|inter-agent|spawn|relay` — mitigated by the category-first check (`/^(threadline|inter-agent|relay|spawn)/i` on category) plus content sniff only on distinctive phrases (`spawn-storm`, `spawn to receive`, `cannot spawn`, `inter-agent`, `\bthreadline\b`). A generic "spawn a new worker" general item would NOT match (no category prefix, no distinctive phrase). Worst case the item lands in the hub instead of its own topic — recoverable, not lost.
+
+## 2. Under-block
+A threadline alert posted via `/attention` with a *non-threadline category AND no distinctive phrase* would still get its own topic. Acceptable: the in-code threadline emitters (loop-gate) now route correctly; the redirect is a backstop for ad-hoc posts. The `TelegramBridge.mirrorInbound` per-thread topic path is intentionally excluded as a deliberate opt-in feature (default-off — the operator turned it on knowingly), not a notification the routing fix should override.
+
+## 3. Level-of-abstraction fit
+Correct: extended `CollaborationSurfacer` (already the hub owner) rather than a parallel router (convergence Q1). Status notices use a delivery sink (`notify`); real reply *content* still flows via the existing `TopicLinkageHandler` parent-topic path (one emitter per topic — avoids the double-notify the reviewer flagged, H2). The bind endpoint composes existing primitives (`ConversationStore.mutate`, `findOrCreateForumTopic`, `commitmentTracker.mutate`).
+
+## 4. Signal vs authority compliance
+No new blocking authority. The `/attention` redirect is a router (reroute + 201, never a hard block). `notify()`/`surface()` are delivery sinks. The bind endpoint mutates state on explicit operator action. Per `docs/signal-vs-authority.md`: detectors/sinks, not gates.
+
+## 5. Interactions
+- **No double-surface:** status (`notify`) → hub only; content (replies) → parent topic via TopicLinkageHandler only. The loop-gate path `return`s after notify, so it never also hits surface(). `surface()` (parentless first-contact) and `notify()` (status) are distinct lanes; a single inbound triggers at most one.
+- **Bind vs first-write-wins:** `hub/bind` is authoritative — it overrides `captureOriginOnSend`'s anti-poisoning refusal by directly setting `boundTopicId` + the commitment `topicId` (operator intent > heuristic).
+- **Legacy state migration** is read-time + idempotent; new record-shape round-trips.
+
+## 6. External surfaces
+New `transport`-free; new route `POST /threadline/hub/bind` (503 when telegram/conversationStore absent). Hub stays silent (`{silent:true}`) — no new buzzing. Template/migration change is agent-facing (Agent Awareness Standard) + idempotent (Migration Parity).
+
+## 7. Rollback cost
+Localized: CollaborationSurfacer (additive methods + schema with back-compat read), one server.ts callsite, two routes.ts additions, template + migration. Clean `git revert`. The surface-state schema change is forward+backward tolerant (load() reads both shapes); no data migration needed. New agents get the template via `generateClaudeMd`; existing via `migrateClaudeMd` (idempotent).
+
+## Second-pass review
+
+**Concur with the review** (independent reviewer, 2026-05-25). Verified all six checks against the diff: (1) the loop-gate `budgetExhausted && collaborationSurfacer` guard is sound (surfacer is `telegram ? new ... : undefined`), and the dropped `createAttentionItem` had no `/ack` consumer — nothing operational lost; (2) `load()` migration round-trips all three shapes (records / legacy string[] / dedicatedTopicId-only) with no loss of `dedicatedTopicId`; (3) the `/attention` redirect runs after `checkOutboundMessage`, matches only category-prefix `^(threadline|inter-agent|relay|spawn)` OR distinctive body tokens (8 realistic inputs tested — "CI failed", "relay race", "Spawning a new initiative" correctly do NOT match), else falls through; (4) `hub/bind` 503/404/409/200 paths correct, authoritative bind sets `boundTopicId` + commitment `topicId` via existing CAS-safe mutates, null-safe field access, all awaits correct, tsc clean; (5) migration content-sniff marker exactly matches the template heading — idempotent; (6) no double-surface — the `budgetExhausted` path `notify()`s then `return`s before `surface()`, and `surface()` early-returns on `hasParentTopic`; mutually exclusive per inbound.
+
+Reviewer's one non-blocking gap — the new HTTP routes lacked Tier 2/3 coverage — has been **addressed**: added `tests/integration/threadline/hub-bind-routes.test.ts` (6 tests: 503/400/404/409/200-open/200-tie, asserting `boundTopicId` is set through the real `createRoutes` pipeline). The `/attention` redirect's match logic is covered by the reviewer's verified 8-input analysis + live test-as-self.

package/upgrades/side-effects/threadline-reply-surfacing.md

@@ -0,0 +1,68 @@
+# Side-Effects Review — Threadline topic-bound reply surfacing fix
+
+**Version / slug:** `threadline-reply-surfacing`
+**Date:** 2026-05-25
+**Author:** Echo
+**Second-pass reviewer:** (pending — required; this touches messaging surfacing decisions, session inject lifecycle, and "gate"/"guard" surfaces)
+
+## Summary of the change
+
+Makes a co-located/relayed agent's reply on a topic-bound Threadline thread reliably surface to the bound Telegram topic, instead of vanishing into the store. Files: `src/threadline/ThreadResumeMap.ts` (get() guard), `src/commands/server.ts` (warm-listener relay guard + injectIntoSession now confirms consumption), `src/core/SessionManager.ts` (new `injectPasteNotificationConfirmed`), `src/threadline/TopicLinkageHandler.ts` (surface only when the live hand-off didn't confirm + first-reply carve-out), `src/messaging/MessageRouter.ts` (thread-aggregate maintenance for both legs + `recordLocalOutbound`), `src/server/routes.ts` (stamp `transport.originTopicId`, persist outbound leg). Decision points touched: the inbound spawn-vs-route branch, the warm-listener routing branch, the Telegram-surface gate inside `tryRouteReplyToTopic`, and the commitment-resolution gate.
+
+## Decision-point inventory
+
+- `ThreadResumeMap.get()` JSONL-existence guard — **modify** — exempts topic-linkage entries (originTopicId set) from the guard so they aren't falsely nulled.
+- `server.ts` relay `gate-passed` warm-listener branch — **modify** — adds a `!isTopicBoundReply` condition so topic-bound replies reach the router.
+- `TopicLinkageHandler.tryRouteReplyToTopic` live-inject vs surface — **modify** — `deliveryMode='live-inject'` now requires confirmed consumption; `shouldSurface` excludes confirmed live-inject; first-reply bypasses rate limit.
+- commitment-resolution (`surfacedToUser`) — **pass-through** (logic unchanged, but now correct because `live-inject` means confirmed).
+- thread-aggregate write (`MessageRouter.relay` / new `recordLocalOutbound`) — **add** — maintains `threads/{id}.json` for both legs.
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this reject that it shouldn't?**
+
+The surfacing gate now fires a Telegram note whenever a topic-bound reply's live-inject is NOT confirmed (failure-visible/resume-pending). It could *over-surface* (post a note the user didn't strictly need) for a low-salience reply that happened to land while the session was busy — but salience still suppresses pure-acks for the non-failure path, and the per-thread (60s) / per-topic (3/60s) rate limits cap volume. It does NOT reject/drop any legitimate input. The `ThreadResumeMap.get()` change only *widens* what `get()` returns (fewer false nulls) — it cannot newly reject anything.
+
+## 2. Under-block
+
+**What failure modes does this still miss?**
+
+- If `sendTelegramToTopic` is null (no Telegram configured) AND the live-inject stalls, the reply is not surfaced and the commitment stays open (by design — never falsely resolved; PromiseBeacon + 7-day TTL are the backstop). Documented; covered by a unit test.
+- A reply whose live-inject is *confirmed* but whose agent then fails to relay conversationally (agent-level failure, not inject-level) would not get a deterministic note. This is out of the inject layer's visibility; the commitment-resolution-on-confirmed-inject preserves existing behavior here.
+- Cross-machine replies that take neither the warm-listener nor pipe branch and have no resume entry still cold-spawn — unchanged, and correct (no topic binding to honor).
+
+## 3. Level-of-abstraction fit
+
+`ThreadResumeMap.get()` is a low-level data-access guard; exempting topic-linkage entries is correct at that layer because the entry itself carries the topic-vs-JSONL distinction (`originTopicId`). The surfacing decision stays in `TopicLinkageHandler` (the existing authority for topic-linkage replies) — no new parallel authority is introduced. The inject-confirmation is a capability added to `SessionManager` (the owner of tmux injection), consumed by the handler via the existing `injectIntoSession` dep — the handler does not re-implement tmux probing. Correct layering throughout.
+
+## 4. Signal vs authority compliance
+
+The change adds NO brittle check with blocking authority. The inject-confirmation is a *signal* (did the paste submit?) consumed by the existing `TopicLinkageHandler` authority. The warm-listener guard is a routing predicate (signal) that defers the decision to the existing `handleInboundMessage`/`tryRouteReplyToTopic` authority. The `get()` change removes a false-negative from a data guard. Per `docs/signal-vs-authority.md`: detectors feed authorities; no detector gained blocking power.
+
+## 5. Interactions
+
+- **CollaborationSurfacer overlap:** topic-bound replies route via TopicLinkageHandler; parentless via CollaborationSurfacer. Mutual exclusivity preserved (the topic-bound predicate gates which path runs). Covered by an integration test.
+- **Double-surface:** eliminated — the deterministic surface is suppressed when live-inject is confirmed (the agent relays instead).
+- **verifyInjection double-recovery:** `injectPasteNotificationConfirmed` *observes* the recovery window; it does not fire its own Enter-resends, so it does not race with `injectMessage`'s internal `verifyInjection`.
+- **Other `get()` callers** (pipe-spawn guard, tryInjectIntoLiveSession, onSessionEnd/Resolved/Failed, MCP history): enumerated in the spec §3; the pipe-spawn guard now correctly excludes topic-bound (desired); others operate benignly on the returned entry.
+- **Thread-aggregate writes** added to `relay()`: non-fatal try/catch; idempotent (store.save dedups). No double-fire — `updateThread` is idempotent on message id.
+
+## 6. External surfaces
+
+- New optional `transport.originTopicId` on the local-delivery envelope — additive; older peers ignore it; it is an opaque per-chat integer (Telegram `message_thread_id`), inert without bot token+chat id. The peer maps it via its own table and must never echo it back as a routing target (the existing F1 anti-poisoning guard on the send path still holds).
+- More Telegram notifications may appear in topics where replies previously vanished — this is the intended user-visible behavior (rate-limited).
+- Inject confirmation adds up to ~7.5s latency to the live-inject path of a *stalled* inbound reply handler (returns ~1s on a healthy submit). Not user-blocking (background reply surfacing).
+
+## 7. Rollback cost
+
+Localized to six files; revert is a clean `git revert` of the implementation commit. No data migration (thread-aggregate writes are additive + idempotent; existing reads tolerate missing aggregates). No agent-state repair. `transport.originTopicId` is optional, so a rollback leaves no dangling dependency. Pure `src/` change → existing agents pick up the revert via the normal update path; no PostUpdateMigrator entry involved.
+
+---
+
+## Second-pass review
+
+**Concur with the review** (independent reviewer, 2026-05-25). Audited the full diff against the artifact: diff matches §1–7; the `injectPasteNotification` void→string change breaks no caller (4 callers discard the return); `injectPasteNotificationConfirmed` only reads (no `fireStuckInputRecovery`) so it observes rather than races `verifyInjection`; `relay()`'s `exists()` early-return precedes `updateThread` so no inbound double-count; the awaited inject (≤7.5s) runs only on the background reply-surface path when a session is alive AND the inject stalls (healthy submit returns ~1s), gates no transport, holds no lock; the `originTopicId === undefined` guard exemption is safe (it derives solely from `boundTopicId`, so non-topic resume entries still null correctly).
+
+Reviewer's one non-blocking note — `updateThread` is not internally idempotent, so the artifact's "recordLocalOutbound idempotent (store.save dedups)" overstated where idempotency comes from — has been **addressed in code**: `recordLocalOutbound` now gates `updateThread` on a first-sight `store.exists()` check, making it truly idempotent regardless of caller behavior.