instar 1.3.454 → 1.3.455

package/src/scaffold/templates.ts

@@ -1404,11 +1404,14 @@ Create worktrees for collaborator repos with \`instar worktree create <branch>\`
 instar test-as-self --no-roundtrip                  # deploy + verify only (no bot needed)
 instar test-as-self --bot-token <secret-drop-id>    # + a real Telegram round-trip via a throwaway bot
 instar test-as-self --keep                          # leave the throwaway running for inspection
+instar test-as-self --slack                          # Slack permission demonstration (each principal+request → expected decision + audit entry)
 \`\`\`
 
 **Structural guards (you cannot foot-gun these):** \`--target\` can never be your canonical agent home or a protected agent (e.g. Bob); \`--bot-token\` refuses a raw token on the command line — pass a Secret Drop ID and the token is retrieved in-memory, never via argv. It emits a single JSON report; exit 0 = all steps PASS.
 
-**Proactive trigger:** when you're about to ship or just shipped a change touching the deploy/lifeline/server-startup path, run this against a throwaway home first — don't guess from logs.
+**\`--slack\` — the test-as-self-for-Slack demonstration (credential-free):** extends the throwaway-agent primitive from "is the agent alive?" to "does it enforce the RIGHT decision for each (principal, request) pair?". It runs the deterministic scenario suite through the SAME observer the live Slack adapter calls (resolver → permission gate → decision ledger) and asserts BOTH the verdict AND that the matching audit/ledger entry landed — "verified, not narrated". No Slack tokens, no throwaway deploy. The same suite is reachable over HTTP: \`GET /permissions/scenario-suite\` (logic-only view) and \`POST /permissions/scenario-suite/run\` (audit-asserting). Exit 0 = every row produced its expected decision AND its audit entry.
+
+**Proactive trigger:** when you're about to ship or just shipped a change touching the deploy/lifeline/server-startup path, run this against a throwaway home first — don't guess from logs. When you touch the Slack org permission system (\`src/permissions/\`), run \`instar test-as-self --slack\` (or \`POST /permissions/scenario-suite/run\`) to prove the gate still enforces every (principal, request) row.
 `;
 
   if (hasTelegram) {

package/upgrades/1.3.455.md

@@ -0,0 +1,46 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+When two registrations for the same agent name existed on the Threadline relay — a live one and a
+stale leftover (a "dead twin") — a sender resolving that name could land on the dead one, and its
+messages silently vanished (delivered-but-never-received). The fix is in the client name resolver
+(`ThreadlineClient`): each known agent now carries a live/offline flag (sourced from the live
+presence status the relay already reports), name resolution **prefers the single live registration**,
+re-discovers a stale cache so a dead twin can't win, and — when two registrations are *genuinely*
+both live (a real two-machine agent, or an impostor) — surfaces a disambiguation prompt instead of
+silently guessing. A companion change removes the dead code (`loadOrCreateIdentityKeys`) that minted
+the orphan identity which became the dead twin in the first place, so no new duplicates are created
+fleet-wide. No relay deploy is required — the relay already reported the right information; the client
+was discarding it.
+
+## What to Tell Your User
+
+If another agent reported that messages to you were "going through on their side but never arriving"
+— the classic symptom of a wedged agent-to-agent channel — this fixes it: your peer's software now
+resolves your name to your live address instead of a stale duplicate. You don't need to do anything;
+it takes effect after your agent updates and restarts. In the meantime, a peer can always reach you
+by addressing your exact routing fingerprint instead of your name. If a peer ever gets an "ambiguous
+agent name" prompt, that's intentional — it means two live registrations share your name, and they
+should pick by fingerprint.
+
+## Summary of New Capabilities
+
+This is a reliability/correctness fix, not a new feature — agent-to-agent name resolution now lands
+on the live registration and never silently delivers to a dead duplicate. Agents also stop creating
+an unused orphan identity file on boot.
+
+## Evidence
+
+- 17 unit tests drive the real on-path resolver (`ThreadlineClient.resolveAgent` / `findAgentByName`):
+  live-vs-dead → resolves live; two-online → surfaces ambiguity; offline-only cache → re-discovers;
+  merge retains crypto keys; rate-limit early-resolve; partial-match parity.
+- 1 relay-backed end-to-end test stands up a real relay with a live + a dead "echo" and asserts a
+  sender resolves the name to the live fingerprint, never the dead twin.
+- 12 `ThreadlineBootstrap` unit tests (incl. "does NOT create identity-keys.json" + a CI guard that
+  the orphan-minting cannot be re-introduced). Typecheck clean; 1693 existing threadline tests green.
+- Spec (converged iter 3, approved): `docs/specs/threadline-duplicate-identity-resolution.md`;
+  side-effects review with independent second-pass CONCUR.

package/upgrades/side-effects/slack-test-as-self-harness.md

@@ -0,0 +1,155 @@
+# Side-Effects Review — test-as-self for Slack (permission demonstration harness)
+
+**Version / slug:** `slack-test-as-self-harness`
+**Date:** `2026-06-09`
+**Author:** `Echo (instar-dev agent)`
+**Second-pass reviewer:** `not required (Tier 1)`
+
+## Summary of the change
+
+Pillar 4 / milestone 4 of the Slack org permission system (`SLACK-ORG-INTEGRATION-SPEC.md` §8).
+This is a **test/demonstration harness over the EXISTING `SlackPermissionGate`** — it adds no
+new runtime decision logic. It extends the existing `SlackScenarioHarness` (six gate-direct rows,
+decision-only) with: (a) two more scenario rows — a granted-member-floor (→ allow/`floor-granted`)
+and an unregistered outsider (→ refuse/`unregistered`) — completing the deterministic
+credential-free subset; (b) a `StaticGrantStore` (deterministic fixture mirroring
+`MandateBackedGrantStore`) and a `CastUserLookup` registry resolver, both plain test doubles that
+feed the existing gate; (c) `runAuditedScenarioSuite`, which drives every row through the SAME
+`SlackPermissionObserver` the live `SlackAdapter._handleMessage` calls (resolver → gate →
+`PermissionDecisionLedger`) and asserts BOTH the verdict AND the matching audit-ledger entry
+("verified, not narrated"). It exposes an executable surface: `POST /permissions/scenario-suite/run`
+and `instar test-as-self --slack`. Files: `src/permissions/testing/SlackScenarioHarness.ts`,
+`src/server/routes.ts`, `src/commands/test-as-self.ts`, `src/cli.ts`, `src/scaffold/templates.ts`,
+plus three new test files and two updated test files.
+
+## Decision-point inventory
+
+This change touches NO runtime decision point. Every component invokes the existing gate and
+reads the existing ledger; nothing gates, blocks, filters, or constrains agent behavior.
+
+- `SlackPermissionGate.evaluate` — **pass-through** — unchanged; the harness only calls it.
+- `buildSliceZeroGate()` (test helper) — **modify** — now constructs the gate with a
+  `StaticGrantStore`. Deny-by-default for everyone except the single Grace fixture, so no
+  existing row's verdict changes; it solely enables the `floor-granted` path for the new row.
+- `StaticGrantStore` / `CastUserLookup` — **add** — test fixtures (a `GrantStore` and a
+  `UserLookup` test-double). No authority; they only supply inputs to the existing gate.
+- `POST /permissions/scenario-suite/run` / `test-as-self --slack` — **add** — read-only/dev
+  executable wrappers that run the suite into a throwaway temp dir and return a report.
+
+---
+
+## 1. Over-block
+
+No block/allow surface — over-block not applicable. The harness asserts the existing gate's
+verdicts; it never itself rejects any input. (The gate's own over/under-block behavior is what
+the harness *measures*, and is governed by the gate's own spec, unchanged here.)
+
+---
+
+## 2. Under-block
+
+No block/allow surface — under-block not applicable. One harness-level honesty note: if a future
+gate change altered a verdict, the suite would catch it as a row mismatch (that is the point — it
+is a regression wall). The audit-assertion half also catches the subtler failure where a verdict
+is returned but the ledger write silently fails.
+
+---
+
+## 3. Level-of-abstraction fit
+
+Correct layer. This is a **demonstration/test harness** sitting ABOVE the gate, deliberately
+driving the production observe path (`SlackPermissionObserver`) rather than re-implementing it.
+It reuses the real `SlackPermissionGate`, real `SlackPermissionObserver`, real
+`SlackPrincipalResolver`, and real `PermissionDecisionLedger`. The `StaticGrantStore` is the
+deterministic, credential-free mirror of `MandateBackedGrantStore` (the live A4 path needs a
+PIN-gated signed mandate that cannot run in CI) — it implements the SAME `GrantStore` interface
+so the gate's `floor-granted` branch is exercised identically; only the grant's provenance
+differs (a fixture vs a signed mandate), which is exactly the deterministic-vs-live seam (§8.3).
+
+---
+
+## 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 harness/route/CLI hold no authority. They invoke the existing gate and read its ledger. The
+`StaticGrantStore` is a test fixture feeding the existing gate, not a new authority. Nothing here
+makes a brittle blocking decision.
+
+---
+
+## 5. Interactions
+
+- **Shadowing:** none. The harness runs the gate in isolation; it does not sit in any live
+  message path. (The full-pipeline test invokes `_handleMessage` directly in a test process with
+  a fake bot token — it never touches a real Slack workspace.)
+- **Double-fire:** none. The audit-asserting run uses its OWN ledger in a fresh temp dir, so it
+  cannot collide with the live `/permissions/decisions` ledger or any live observer.
+- **Races:** none. Each suite run is hermetic (its own temp state dir).
+- **Feedback loops:** none. The behavior baseline (`RelationshipBehaviorStore`) is NOT wired into
+  the harness observer, so running the suite writes no durable baseline that could feed back into
+  the live anomaly scorer.
+
+---
+
+## 6. External surfaces
+
+- **Other agents / users / external systems:** none. No real Slack tokens, no network calls to
+  Slack (the fake-token reaction/user-lookup calls inside `_handleMessage` fail closed with
+  `invalid_auth` and are swallowed — they are best-effort UI sugar, not assertions).
+- **Persistent state:** none in the running agent. The audit-asserting suite writes its ledger
+  into `os.tmpdir()`, never `ctx.config.stateDir`; an integration test explicitly asserts the
+  returned `ledgerPath` is not under the route's configured state dir.
+- **CLAUDE.md template:** the agent template's `## Test-As-Self` section gains a documented
+  `--slack` line + the two HTTP endpoints (Agent Awareness Standard). New agents receive it via
+  `init`; this is a doc surface, not runtime behavior — see Migration Parity note in the conclusion.
+- **Timing/runtime conditions we don't control:** none — the suite is fully deterministic
+  (heuristic classifier + static baselines + static grants + injectable nothing-from-network).
+
+---
+
+## 7. Rollback cost
+
+Pure additive code + tests + docs. Rollback = revert the commit and ship a patch. No persistent
+state to migrate (the suite's only writes are throwaway temp dirs). No agent-state repair. No
+user-visible regression during the rollback window (this is a maintainer/dev demonstration tool,
+not a user-facing capability). The one behavior tweak (`buildSliceZeroGate` gains a grant store)
+is confined to the test harness and is deny-by-default for all but the Grace fixture.
+
+---
+
+## Conclusion
+
+The review found no decision-point surface and no signal-vs-authority concern: every component
+invokes the existing gate and reads the existing ledger. The change's value is precisely that it
+makes the gate's governance *watchable and self-verified* — each (principal, request) row produces
+its expected verdict AND its matching audit entry, through the same observer the live adapter uses.
+The deterministic-vs-live seam is honest (the live-Slack-workspace layer is explicitly out of scope
+and remains operator-driven). All three test tiers are green; `tsc` and `lint` are clean. Clear to
+commit (Tier 1). **Migration Parity note:** the only agent-installed artifact touched is the
+CLAUDE.md template doc line for a dev-only tool — the route + CLI ship as compiled dist that every
+agent receives automatically on update; no `PostUpdateMigrator` entry is warranted for a doc line
+on a maintainer-only surface (consistent with how the existing `/permissions/scenario-suite` route
+is treated).
+
+---
+
+## Second-pass review (if required)
+
+Not required — Tier 1 (a test/demonstration harness with no block/allow surface and no session
+lifecycle / gate / sentinel / watchdog runtime change).
+
+---
+
+## Evidence pointers
+
+- `tests/unit/slack-scenario-audit-harness.test.ts` — 16 tests (cast, fixtures, both decision
+  boundaries per row, audit-entry assertion, durable-ledger read-back).
+- `tests/integration/slack-permission-pipeline.test.ts` — 3 tests (every row through
+  `_handleMessage` → observer → ledger; granted-member + unregistered-outsider live-path rows).
+- `tests/integration/permissions-routes.test.ts` — updated; `GET /permissions/scenario-suite`
+  (8 rows) + `POST /permissions/scenario-suite/run` (verdict AND audit per row).
+- `tests/e2e/slack-scenario-suite-route.test.ts` — 2 tests (feature alive: 200 + full green report).
+- CLI smoke: `node dist/cli.js test-as-self --slack` → all 8 rows `audit✓`, `VERDICT: PASS`, exit 0.

package/upgrades/side-effects/threadline-dup-identity-pr1-resolver.md

@@ -0,0 +1,162 @@
+# Side-Effects Review — Threadline duplicate-identity resolver (PR1: client live-preference)
+
+**Version / slug:** `threadline-dup-identity-pr1-resolver`
+**Date:** `2026-06-09`
+**Author:** `Instar Agent (echo)`
+**Second-pass reviewer:** `independent reviewer subagent — CONCUR (Phase 5; high-risk: name→fingerprint dispatch resolution)`
+
+## Summary of the change
+
+Closes the duplicate-identity silent-drop class on the exact path a sender uses
+(`threadline_send` → `ThreadlineClient.resolveAgent` → `findAgentByName`). Driven by the
+converged spec `docs/specs/threadline-duplicate-identity-resolution.md` (changes A/B/C).
+Single file touched: `src/threadline/client/ThreadlineClient.ts`. (A) `KnownAgent` gains an
+`online` flag, merged — never replaced — from the relay's `discover_result.status` (the relay
+already derives that status from live presence; the client was discarding it). (B)
+`findAgentByName` prefers the single live registration among same-name rows in both the exact and
+partial branches, and still throws ambiguity when ≥2 are online (never silently picks). (C)
+`resolveAgent` re-discovers once (cooldown-gated, rate-limit-aware) when the cached match is
+offline, so a stale dead twin can be superseded by a live one. Tests: 17 unit on the real
+resolver + 1 relay-backed e2e (live-vs-dead echo → resolves to live).
+
+## Decision-point inventory
+
+- `ThreadlineClient.findAgentByName` (name → fingerprint resolution) — **modify** — adds a
+  live-registration preference before the existing ambiguity throw; the throw is preserved for
+  genuinely-ambiguous (≥2 online, or all offline >1) cases.
+- `ThreadlineClient.resolveAgent` (cache → re-discover orchestration) — **modify** — adds one
+  cooldown-gated re-discovery when the resolved match is offline.
+- `ThreadlineClient.discover` (relay discovery wait) — **modify** — adds a rate-limit-filtered
+  early-resolve so a throttled re-discovery fails fast instead of hanging to the 10s timeout.
+- `ThreadlineClient` discover-result ingestion — **modify** — merge (not replace) so a keyless
+  discovery frame cannot strip crypto keys; map `status` → `online`.
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this change reject that it shouldn't?**
+
+No new block/allow surface. The one place resolution can now *fail* where it previously
+"succeeded" is when ≥2 same-name rows are simultaneously online — but that failure is the
+existing ambiguity throw, which is the correct, pre-existing behavior (require `name:fingerprint`).
+A legitimately-multi-machine agent (two keys, both online) now gets that loud ambiguity rather
+than an arbitrary pick — intended, and the error text points at the disambiguation syntax + saved
+nicknames. No legitimate single-recipient send is newly rejected: a live-vs-dead pair now resolves
+(previously it threw or silently dropped); a single offline peer still resolves (returns the
+offline fingerprint, preserving offline-queue semantics).
+
+---
+
+## 2. Under-block
+
+**What failure modes does this still miss?**
+
+Name discovery remains trust-on-first-use and unauthenticated at the relay (the `name` is not
+cryptographically bound — pre-existing, documented in the spec's §Security). If the real agent is
+genuinely offline AND only an impostor with the same name is online, the exactly-one-online rule
+will prefer the impostor — but ONLY during a real outage of the genuine agent (an impostor cannot
+make itself the *only* online "echo" while the real one is connected, because presence is keyed per
+fingerprint). This is a pre-existing TOFU property the change makes more deterministic in that
+narrow window; the spec records it and leaves room for a future `verified`-fingerprint tiebreak.
+Not closed here by design.
+
+---
+
+## 3. Level-of-abstraction fit
+
+**Is this at the right layer?**
+
+Yes — and this is the headline correction from convergence. v1 of the spec put the fix at the
+relay's `RegistryStore.search()` ORDER BY, which is OFF the instar send path (the client ingests
+discovery into a fingerprint-keyed Map and resolves locally). The fix belongs in the client
+resolver — the lowest layer that actually decides name → fingerprint for a send — and it CONSUMES
+a signal the relay already produces (live `status`) rather than re-implementing liveness. No new
+parallel gate; it feeds off existing infrastructure.
+
+---
+
+## 4. Signal vs authority compliance
+
+**Required reference:** docs/signal-vs-authority.md
+
+- [x] No — this change produces/consumes a selection signal; it has no brittle blocking authority.
+
+The change is a *selection preference* (prefer the live registration). It never silently picks
+among multiple live registrations — it surfaces the existing ambiguity throw for the operator/caller
+to disambiguate. No message is blocked, dropped, or rewritten. Liveness is sourced from the relay's
+live-presence-derived `status`, not a brittle local heuristic.
+
+---
+
+## 5. Interactions
+
+- **Shadowing:** the online-preference runs *before* the existing ambiguity throw in
+  `findAgentByName`; it does not shadow the throw — it narrows when the throw fires (only ≥2 online,
+  or >1 all-offline). The `fingerprintPrefix` (`name:fingerprint`) path still wins ahead of both,
+  unchanged.
+- **Double-fire:** the offline re-discovery is gated by a per-name 30s cooldown
+  (`lastRediscoverByName`), so a burst of sends to an offline target cannot re-query the relay
+  repeatedly; the existing cache-miss re-discovery path is unchanged (not cooldown-gated).
+- **Races:** `discover()` now registers an `error` listener alongside `discover-result`; both share
+  a `settled` guard + `cleanup()` so a late frame after either fires is a no-op. The error listener
+  filters strictly on `code === RATE_LIMITED`, so an unrelated error frame (e.g. a concurrent send's
+  `RECIPIENT_OFFLINE`) cannot spuriously resolve discovery (unit-tested).
+- **Feedback loops:** none — discovery output feeds resolution, not back into discovery (the
+  cooldown bounds the one re-query).
+
+---
+
+## 6. External surfaces
+
+- **Other agents:** the merge-not-replace fix actually PREVENTS a latent regression — a keyless
+  discovery frame no longer strips a peer's cached crypto keys, so E2E `send()` to a
+  previously-keyed peer is not downgraded to plaintext. Name-resolved sends to freshly-discovered
+  peers continue to use the relay plaintext-authenticated path (transport TLS + Ed25519), unchanged.
+- **External systems:** none. No relay deploy (the relay already sends live status). No HTTP route
+  added or changed. No config knob, no dashboard surface, no CLAUDE.md template change (transparent
+  correctness fix).
+- **Persistent state:** none — `knownAgents` and `lastRediscoverByName` are process-local, never
+  persisted. No DB/ledger/migration.
+- **Timing:** the offline re-discovery adds at most one discovery round-trip (≤ the 10s discover
+  timeout, and fails fast on rate-limit) per resolve when the cached match is offline and the
+  cooldown allows.
+
+---
+
+## 7. Rollback cost
+
+Pure client-side code change in one file. Rollback = revert the PR; `findAgentByName`/`resolveAgent`
+return to throw-on-ambiguity / cache-hit behavior. No persistent state, no data migration, no agent
+state repair. Reaches the fleet on the next server/session restart after auto-update activates (the
+in-memory cache self-heals on restart). No user-visible regression during the rollback window.
+
+---
+
+## Conclusion
+
+The review produced no design changes beyond what convergence already folded in. The change is a
+narrowly-scoped, single-file client resolver fix that consumes an existing relay signal, never
+silently picks among live registrations, and carries a comprehensive on-path test suite (17 unit +
+1 relay-backed e2e, all green; 1693 existing threadline tests unaffected; typecheck clean). High-risk
+classification (name→fingerprint dispatch resolution) triggers the Phase-5 second-pass review below.
+
+---
+
+## Second-pass review (if required)
+
+**Reviewer:** independent reviewer subagent
+**Independent read of the artifact: concur**
+
+Audited the actual implementation against the spec, both test files, the relay wire contract
+(`relay/types.ts`), and the route callsite (`routes.ts:17500-17626`). Confirmed grounded in code:
+the merge provably retains `publicKey`/`x25519PublicKey` (keyless frame → `??` keeps existing);
+`pickSingleOnline` returns the single online match and the ambiguity throw fires for ≥2-online in
+BOTH the exact and partial branches; `resolveAgent` re-discovers only on an offline match, returns
+the offline fingerprint when still offline (no 404), and propagates the ambiguity throw (caught at
+the route as a 500 with disambiguation guidance); `discover()` early-resolves only on
+`code===RATE_LIMITED`. Four findings, all MINOR: the `online===undefined` case (now covered by added
+tests), a `status`-absent frame mapping to `online:false` (harmless — `status` is non-optional on the
+wire), a vestigial `status` property on the stored object (no consumer reads it), and an artifact
+test-count miscount (now corrected to 17). No over-block, no authority creep, no external-surface
+change. Clear to ship.

package/upgrades/side-effects/threadline-dup-identity-pr2-orphan-removal.md

@@ -0,0 +1,89 @@
+# Side-Effects Review — Threadline orphan-identity removal (PR2: stop minting identity-keys.json)
+
+**Version / slug:** `threadline-dup-identity-pr2-orphan-removal`
+**Date:** `2026-06-09`
+**Author:** `Instar Agent (echo)`
+**Second-pass reviewer:** `not required (Tier 1 — dead-code removal, no decision surface)`
+
+## Summary of the change
+
+Removes `ThreadlineBootstrap.loadOrCreateIdentityKeys` and the now-dead `identityKeys` field
+from `ThreadlineBootstrapResult` (change D of the converged spec
+`docs/specs/threadline-duplicate-identity-resolution.md`). That function minted an orphan
+`threadline/identity-keys.json` keypair on every agent boot, independent of the canonical
+`identity.json` — the exact artifact that became the dead "echo" twin polluting the relay. Its
+output was consumed nowhere (verified: zero `.identityKeys` readers in `src/` and `tests/`;
+`server.ts` never destructures it). The handshake and relay-client paths source identity via
+`HandshakeManager.getOrCreateIdentity()` / `IdentityManager` (canonical `identity.json`) and are
+untouched. Files: `src/threadline/ThreadlineBootstrap.ts` (remove function, field, call, return,
+two now-unused imports, the orphan-only constant) + `tests/unit/threadline/ThreadlineBootstrap.test.ts`
+(delete the orphan-file persistence/permissions/corrupted-regeneration tests, drop the
+`result.identityKeys` assertions, add a "does NOT create identity-keys.json" test + a CI guard that
+`loadOrCreateIdentityKeys` is absent from the file).
+
+## Decision-point inventory
+
+- No decision point. This removes a write-only code path (`loadOrCreateIdentityKeys`) that gated
+  nothing, blocked nothing, and whose output fed nothing. Pure dead-code removal.
+
+---
+
+## 1. Over-block
+
+No block/allow surface — over-block not applicable.
+
+## 2. Under-block
+
+No block/allow surface — under-block not applicable.
+
+## 3. Level-of-abstraction fit
+
+Correct layer: the orphan keypair was a vestige of an older identity model superseded by
+`IdentityManager` (canonical `identity.json`). Removing the minting function (not the on-disk file)
+is the minimal, right-altitude change. #479 deliberately fenced off this removal as needing its own
+spec ("deleting risks the handshake path"); this PR is that spec's change D, and the handshake-path
+risk is rebutted with evidence — `HandshakeManager.getOrCreateIdentity()` reads
+`{stateDir}/threadline/identity.json`, never the orphan `identity-keys.json` (verified).
+
+## 4. Signal vs authority compliance
+
+- [x] No — this change has no block/allow surface (dead-code removal).
+
+## 5. Interactions
+
+- **Shadowing / double-fire:** none — the removed function had no callers beyond the single
+  bootstrap call site, and its result flowed nowhere.
+- **Races:** none — it only wrote an unused file; removing it removes one boot-time fs write.
+- **Feedback loops:** none.
+- Existing `identity-keys.json` files already on disk become permanently inert (they already were —
+  nothing read them since #479). They are NOT deleted by this change (a destructive fleet file-sweep
+  is tracked separately, out of scope).
+
+## 6. External surfaces
+
+- **Other agents / relay:** strictly improves coherence — no new orphan identity is ever minted, so
+  the duplicate-registration source is closed fleet-wide. No new orphan can be registered on the relay.
+- **Persistent state:** stops creating one unused file per agent. Existing inert files left in place
+  (no migration). No DB/ledger change.
+- **External systems / config / dashboard / CLAUDE.md template:** none.
+
+## 7. Rollback cost
+
+Pure code-deletion. Rollback = revert the PR; `loadOrCreateIdentityKeys` is reinstated and resumes
+writing the (unused) file. No data migration, no agent-state repair, no user-visible regression.
+
+---
+
+## Conclusion
+
+Dead-code removal closing the source of the duplicate-identity artifact, paired with the companion
+client resolver fix (PR1). No decision surface, no external behavior change beyond ceasing to write
+an unused file. The #479 handshake-risk fence is rebutted with verified evidence. 12 bootstrap unit
+tests green (including the new "no orphan file" assertion + CI guard); typecheck clean; no other
+consumer of the removed field exists. Tier 1: small, low-risk, second-pass not required.
+
+---
+
+## Second-pass review (if required)
+
+**Reviewer:** not required (Tier 1 — dead-code removal, no block/allow or lifecycle decision surface).