@agfpd/iapeer 0.4.12 → 0.4.14

package/CHANGELOG.md

@@ -0,0 +1,225 @@
+# Changelog
+
+All notable changes to **@agfpd/iapeer** are documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+> The public repository begins at the **Initial public release (0.2.98, 2026-06-18)**.
+> Versions before 0.2.98 predate the public repo (private development) and are not itemized here.
+
+## [Unreleased]
+
+### Changed
+
+- Fact-actualized the repo docs against the current code: pty-only (tmux references removed),
+  no canary/forensics in postmortem diagnostics, and the legacy `runtime`-mirror drop.
+
+### Added
+
+- This changelog.
+
+## [0.4.13] - 2026-06-20
+
+### Fixed
+
+- `verify --fix` now strips the legacy `runtime` mirror from **every** profile that still
+  carries it, not only the ones that triggered a warning — completes the fleet-wide cleanup.
+
+## [0.4.12] - 2026-06-20
+
+### Fixed
+
+- `migrateProfileRuntimeField` strips any legacy `runtime` field, so `verify --fix` cleans
+  the whole fleet.
+
+## [0.4.11] - 2026-06-20
+
+### Changed
+
+- Local peer profiles no longer write the legacy `runtime` mirror — `default_runtime` is the
+  single field (Phase-3, local half). A read-fallback still understands older profiles that
+  carry only `runtime`.
+
+## [0.4.10] - 2026-06-20
+
+### Changed
+
+- The registry (`peers-profiles.json`) no longer writes the legacy `runtime` mirror
+  (Phase-3, registry half).
+
+### Removed
+
+- Two proven-dead internal symbols (audit safe-cuts).
+
+## [0.4.9] - 2026-06-20
+
+### Removed
+
+- **tmux removed entirely — the foundation is now pty-only.** The tmux launch / delivery /
+  occupancy paths and the retired tmux→pty burn-in observer are gone; session hosting runs
+  through the pty supervisor (which owns the pty, the pane-log, and the delivery socket).
+  `render.ts` is kept as a shared leaf.
+
+## [0.4.8] - 2026-06-20
+
+### Fixed
+
+- The supervisor self-heals a pane-log that was unlinked out from under a live session
+  (Defect 2).
+
+## [0.4.7] - 2026-06-20
+
+### Fixed
+
+- An unreadable hosted pane-log is no longer treated as composer-busy — fixes an IAP
+  delivery stall.
+
+### Added
+
+- Ping-pong hero demo GIF in the README.
+
+## [0.4.6] - 2026-06-19
+
+### Fixed
+
+- Unified omitted-runtime resolution across `new` / `attach` / `compact`.
+
+## [0.4.5] - 2026-06-19
+
+### Fixed
+
+- `init` declares all installed agentic runtimes (parity with `create`).
+
+### Changed
+
+- README: moved "What makes it different" above Quick start; polished the Bypass Permissions
+  security disclosure.
+
+## [0.4.4] - 2026-06-19
+
+### Fixed
+
+- Clear the virgin-Claude bypass-accept + project-MCP first-run dialogs (unblocks a
+  fresh-machine boot).
+- Release scripts push explicitly with `git push origin main --follow-tags`.
+
+### Changed
+
+- Alias namespace `/alias-*` → `/alias_*` (Telegram slash-command constraint).
+
+### Added
+
+- Clean-install first-run dialog reference in docs/07 (EN + RU).
+
+## [0.4.3] - 2026-06-19
+
+### Added
+
+- FU13: targeted CLI argument errors — no more generic help-wall dump.
+
+### Fixed
+
+- onboard: marketplace add no longer shows a bare red "failed" on a transient first run.
+
+### Changed
+
+- docs/07: note the one-time double-run when upgrading from a pre-cascade (<0.4.2) version.
+
+## [0.4.2] - 2026-06-19
+
+### Added
+
+- **FU12: `iapeer update` cascades the whole stack** — foundation + every installed runtime +
+  the memory provider in one command. The foundation goes first and is health-checked; a hard
+  foundation failure aborts the cascade.
+
+## [0.4.1] - 2026-06-19
+
+### Added
+
+- Per-package ecosystem docs scaffolded to a stable host path `~/.iapeer/docs/<pkg>/`, with a
+  host-context docs pointer in the system prompt (FU6).
+- Global host-doctrine stub `~/.iapeer/IAPEER.md` scaffolded on install (FU11).
+- CI-status + dynamic license badges in the README (FU10).
+- A no-empty-acks instruction on the agent tool surface.
+
+### Changed
+
+- Polish batch: onboard summary ANSI, advisory install commands, help/list formatting, the
+  create-runtime prompt.
+- Dropped `bot_username` from the telegram-interface example and fixtures.
+
+## [0.4.0] - 2026-06-18
+
+### Added
+
+- `iapeer uninstall` — symmetric, namespace-safe foundation removal (S4).
+- Onboard wizard hardening (S1–S3): host-runtime detection threading `--runtime` to memory
+  init, the notifier scheduler and Telegram as default steps, visual polish with honest
+  slow-step labels.
+
+### Fixed
+
+- install: exact-pin cache-bust + keychain heads-up.
+
+## [0.3.0] - 2026-06-18
+
+### Added
+
+- **Public one-line installer** (`curl -fsSL … | sh`) with GitHub Pages hosting — `install.sh`
+  is deployed from `main` so the served script is identical to source.
+- **Onboard wizard (Ink TUI)** — first slice behind an opt-in flag, then feature-complete and
+  default; `install.sh` stops launching onboard directly.
+
+### Changed
+
+- README documents both install paths (one-liner + manual).
+
+## [0.2.99] - 2026-06-18
+
+### Added
+
+- Ship `docs/` in the npm package (excluding `docs/internals`).
+
+### Changed
+
+- README: humans also take part in the terminal via `iapeer attach`.
+
+## [0.2.98] - 2026-06-18
+
+Initial public release — the foundation core of the iapeer multi-agent ecosystem.
+
+### Added
+
+- **Data layer** — identity (`<runtime>-<personality>`), registry (`peers-profiles.json`,
+  single-writer), storage (the `~/.iapeer` layout with atomic writes), codec (the IAP envelope).
+- **Always-on router daemon** — a canonical HTTP-MCP Streamable router exposing the single
+  agent tool `send_to_peer`; dual-listen — a `0600` unix socket for same-host local callers and
+  a TCP loopback for real MCP clients.
+- **Warm-on-demand lifecycle** — wake-on-miss, idle-reap, zombie-sweep, fresh-vs-resume by
+  death cause, a crash-loop guard, and a durable decision log.
+- **Launch primitive + runtime adapters** — Claude, Codex, Telegram, and notifier; layered
+  system-prompt composition; launchd plist rendering.
+- **Install / onboard chain** and the `iapeer` CLI (create, init, list, verify, status, send,
+  attach, update, and more).
+- **Heterogeneous peers** — AI agents (Claude, Codex), humans (Telegram), and services
+  (timer = cron, watcher = event) are all first-class and addressed the same way.
+
+[Unreleased]: https://github.com/agfpd/iapeer/compare/v0.4.13...HEAD
+[0.4.13]: https://github.com/agfpd/iapeer/compare/v0.4.12...v0.4.13
+[0.4.12]: https://github.com/agfpd/iapeer/compare/v0.4.11...v0.4.12
+[0.4.11]: https://github.com/agfpd/iapeer/compare/v0.4.10...v0.4.11
+[0.4.10]: https://github.com/agfpd/iapeer/compare/v0.4.9...v0.4.10
+[0.4.9]: https://github.com/agfpd/iapeer/compare/v0.4.8...v0.4.9
+[0.4.8]: https://github.com/agfpd/iapeer/compare/v0.4.7...v0.4.8
+[0.4.7]: https://github.com/agfpd/iapeer/compare/v0.4.6...v0.4.7
+[0.4.6]: https://github.com/agfpd/iapeer/compare/v0.4.5...v0.4.6
+[0.4.5]: https://github.com/agfpd/iapeer/compare/v0.4.4...v0.4.5
+[0.4.4]: https://github.com/agfpd/iapeer/compare/v0.4.3...v0.4.4
+[0.4.3]: https://github.com/agfpd/iapeer/compare/v0.4.2...v0.4.3
+[0.4.2]: https://github.com/agfpd/iapeer/compare/v0.4.1...v0.4.2
+[0.4.1]: https://github.com/agfpd/iapeer/compare/v0.4.0...v0.4.1
+[0.4.0]: https://github.com/agfpd/iapeer/compare/v0.3.0...v0.4.0
+[0.3.0]: https://github.com/agfpd/iapeer/compare/v0.2.99...v0.3.0
+[0.2.99]: https://github.com/agfpd/iapeer/releases/tag/v0.2.99

package/README.md

@@ -1,13 +1,15 @@
 # iapeer
 
-**Host-level core for a team of AI agents on one machine.**
+**The foundation for a team of AI agents on one machine.**
 
 [![CI](https://github.com/agfpd/iapeer/actions/workflows/ci.yml/badge.svg)](https://github.com/agfpd/iapeer/actions/workflows/ci.yml)
 [![npm](https://img.shields.io/npm/v/@agfpd/iapeer)](https://www.npmjs.com/package/@agfpd/iapeer)
 [![license](https://img.shields.io/npm/l/@agfpd/iapeer)](./LICENSE)
 [![platform](https://img.shields.io/badge/platform-macOS-lightgrey)](#quick-start)
 
-iapeer keeps a team of AI agents, humans, and services on one host **always reachable — every one of them a single message away.** Each participant is a **peer**: a Claude Code or Codex CLI agent, a person on Telegram, or a scheduler/watcher service. Any agent reaches any other with one call — `send_to_peer(<name>, <text>)` — and a peer that is asleep is still reachable: the daemon wakes it and delivers. Agents on Claude and on Codex — different AI runtimes from different vendors — talk as equal peers; humans take part over Telegram, or directly in the terminal — attached to a peer's live session with `iapeer attach`.
+iapeer keeps a team of AI agents, humans, and services on one host always reachable, every one a single message away. Each participant is a **peer**: a Claude Code or Codex CLI agent, a person on Telegram, or a scheduler/watcher service. Any agent reaches any other with one call, `send_to_peer(<name>, <text>)`; if the recipient is asleep, the daemon wakes it and delivers.
+
+Agents on Claude and on Codex are different AI runtimes from different vendors, yet they talk as equal peers. Humans take part over Telegram, or directly in the terminal by attaching to a peer's live session with `iapeer attach`.
 
 <p align="center">
   <img src=".github/assets/iapeer-pingpong.gif" width="800" alt="A person messages one peer on Telegram; heterogeneous peers (Claude + Codex) relay a baton over one protocol and report back to Telegram.">
@@ -30,8 +32,8 @@ recipient peer  — asleep? the daemon wakes it and delivers on wake
 ## What makes it different
 
 - **Real interactive CLI sessions, not headless one-shots.** Each AI peer is a full Claude Code or Codex CLI session, not a disposable `claude -p` / `codex exec` call (as of 2026-06-15, `claude -p` no longer counts against the subscription's main usage limits).
-- **Warm-on-demand lifecycle.** A live session answers fast; after about an hour idle the daemon closes it; the next message brings it back with its context resumed. The message flow drives the lifecycle — not a human's presence.
-- **One identity across runtimes, with one memory.** A peer's `personality` is decoupled from its runtime — the same peer runs on Claude or Codex, switched with a command. By default (set up by `iapeer onboard`) it carries one shared memory (iapeer-memory) keyed to the personality, not the runtime: one personality, one memory, whatever runtime it runs on.
+- **Warm-on-demand lifecycle.** A live session answers fast; after about an hour idle the daemon closes it; the next message brings it back with its context resumed. The message flow drives the lifecycle, not a human's presence.
+- **One identity across runtimes, with one memory.** A peer's `personality` is decoupled from its runtime: the same peer runs on Claude or Codex, switched with a command. By default (set up by `iapeer onboard`) it carries one shared memory (iapeer-memory) keyed to the personality, not the runtime — one personality, one memory, whatever runtime it runs on.
 - **Heterogeneous peers, one protocol.** AI agents, humans (Telegram), and services (timer = cron, watcher = event) are all first-class, addressed the same way over an always-on MCP daemon that exposes exactly one tool, `send_to_peer`.
 
 ## Quick start
@@ -91,9 +93,9 @@ Agents reach each other with `send_to_peer`; you can also message any peer over
 
 ## Bypass Permissions mode
 
-⚠️ **iapeer runs your Claude and Codex peers in bypass-permissions / no-sandbox mode — they execute tools (shell commands, file edits, network calls) without asking you to approve each action.** This is by design: a peer is a background, headless session with no human watching its terminal, so there is no one to answer a per-tool permission prompt. The launcher starts Claude with `--dangerously-skip-permissions` and Codex with `--dangerously-bypass-approvals-and-sandbox`, and **auto-accepts the one-time "accept bypass mode" screen on your behalf** the first time a peer boots on a fresh machine.
+**Warning: iapeer runs your Claude and Codex peers in bypass-permissions / no-sandbox mode — they execute tools (shell commands, file edits, network calls) without asking you to approve each action.** This is by design: a peer is a background, headless session with no human watching its terminal, so there is no one to answer a per-tool permission prompt. The launcher starts Claude with `--dangerously-skip-permissions` and Codex with `--dangerously-bypass-approvals-and-sandbox`, and **auto-accepts the one-time "accept bypass mode" screen on your behalf** the first time a peer boots on a fresh machine.
 
-What this means for you, stated plainly:
+What this means for you:
 
 - A peer can run any command its runtime can run — read and write files anywhere in your home directory, install software, make network calls — with **no confirmation step**. There is no sandbox between an agent and your machine.
 - You are trusting the model's judgment, and the doctrine you give each peer, the same way you would trust a developer with a shell on your account.
@@ -118,4 +120,4 @@ Planned, not yet built:
 
 ## License
 
-Apache-2.0. Platform: macOS / launchd. iapeer is the foundation core of a larger ecosystem; runtime and capability plugins build on top of it.
+Apache-2.0. Platform: macOS / launchd. iapeer is the foundation of a larger ecosystem; runtime and capability plugins build on top of it.

package/docs/03-peers-runtimes-identity.md

@@ -102,7 +102,7 @@ Identity has two storage places, and it matters which is authoritative.
 
 The profile fields split into three classes by who owns them:
 
-- **Identity core** — `personality`, `default_runtime`, `runtimes`, `description`, `intelligence`, `initial_prompt`. Owned by the core and the lifecycle. The `initial_prompt` field is the seed for a fresh session's first turn. The `runtime` field beside `default_runtime` is a synchronized copy for compatibility with old readers; both are written consistently.
+- **Identity core** — `personality`, `default_runtime`, `runtimes`, `description`, `intelligence`, `initial_prompt`. Owned by the core and the lifecycle. The `initial_prompt` field is the seed for a fresh session's first turn. The legacy `runtime` field beside `default_runtime` is no longer written — a read-fallback still understands older profiles that carry only `runtime`.
 - **Private plugin config** — sections like `expansion` (shortcut aliases), `notifier` (the scheduler peer's settings), and others, one per plugin. Read only from the local profile, never projected into the registry.
 - **Public passport** — the `interfaces` section (e.g. `interfaces.telegram.bot`). These are routing attributes, and they're projected into the registry.
 

package/docs/04-lifecycle-and-daemon.md

@@ -81,7 +81,7 @@ An agent with no activity for longer than an hour is slept on the next superviso
 
 **Wake serialization.** Several messages may hit a sleeping agent at once; one attempt should bring it up, or two competing sessions would be born. The daemon takes a lock on waking a given peer — the rest wait for the first to be ready.
 
-**Postmortem diagnostics.** At the moment a session dies the supervisor records its cause (exit code / signal) — what an ordinary "is the process alive" check misses. For this a separate canary holds a blocking connection to the supervisor and, on a session's death, writes the circumstances — memory, swap, process list, diagnostic reports — to a log.
+**Postmortem diagnostics.** At the moment a session dies the supervisor records its cause (exit code / signal) to a log — what an ordinary "is the process alive" check misses.
 
 ## The boundary: claude/codex vs infrastructure
 

package/docs/13-architecture-and-contract.md

@@ -29,7 +29,7 @@ The adapter's key properties:
 
 Routers skip all the TUI phases: they have no boot dialogs, no readiness markers, no delivery confirmation, no control commands. Their liveness is held by launchd, not a wake by the daemon.
 
-The production mechanism for hosting TUI sessions is the **pty supervisor**: a supervisor daemon owns the session's pty and its pane log, and delivery onto input goes through its socket. tmux remains only an internal dev branch (the shadow branch) and doesn't figure at the user level.
+The production mechanism for hosting TUI sessions is the **pty supervisor**: a supervisor daemon owns the session's pty and its pane log, and delivery onto input goes through its socket.
 
 ## The runtime-package contract
 

package/docs/14-configuration-and-logs.md

@@ -71,8 +71,6 @@ The daemon's supervisory tick is fixed — once a minute, not configurable.
 A few more variables the system reads but that aren't set in normal operation:
 
 - `NOTIFIER_FALLBACK_TARGET` — a fallback recipient for notifier signals; the core resolves it into the peer's plist at onboarding (no hardcode), the operator doesn't set it by hand.
-- `IAP_TMUX_PASTE_SETTLE_MS`, `IAP_TMUX_SUBMIT_TIMEOUT_MS` — delivery timings in the internal tmux dev branch; production uses the pty supervisor ([13 — Architecture and contract](13-architecture-and-contract.md)), so they aren't needed outside development.
-- `IAPEER_SHADOW_PATH` — the `PATH` for a shadow-fidelity run (an internal development tool).
 
 ## Logs and diagnostics
 
@@ -84,8 +82,8 @@ The daemon keeps three durable logs in `~/.iapeer/logs/iapeer/`:
 
 ### Postmortem diagnostics
 
-The cause of a session's death (exit code / signal) the supervisor records at the moment of death — what an ordinary "is the process alive" check misses. A separate canary holds a connection to the supervisor and, on a session's death, writes the circumstances to `exits.log`: memory, swap, top processes by consumption, system diagnostic reports. It's the material for answering "why did the agent die".
+The cause of a session's death (exit code / signal) the supervisor records at the moment of death to `exits.log` — what an ordinary "is the process alive" check misses. It's the material for answering "why did the agent die".
 
 ### Full Disk Access
 
-To read system diagnostic reports, the `iapeer` binary needs Full Disk Access (FDA) — a macOS permission. `iapeer status` shows whether FDA is granted and hints at what to do if not. Without FDA, peers will hit TCC prompts when accessing protected folders and third-party app containers.
+The `iapeer` binary needs Full Disk Access (FDA) — a macOS permission. `iapeer status` shows whether FDA is granted and hints at what to do if not. Without FDA, peers will hit TCC prompts when accessing protected folders and third-party app containers.

package/docs/README.md

@@ -2,7 +2,7 @@
 
 [Русский](ru/README.md) · **English**
 
-iapeer is the core of a multi-agent system on one host. It maintains a registry of participants, a single router daemon for messaging between them, and a set of commands to manage participants: create, start, sleep, restart, connect to external channels.
+iapeer is the foundation of a multi-agent system on one host. It maintains a registry of participants, a single router daemon for messaging between them, and a set of commands to manage participants: create, start, sleep, restart, connect to external channels.
 
 A participant in the system is called a **peer**. A peer can be an AI agent (Claude, Codex), a human (over Telegram), or a service process (a scheduler, a watcher). iapeer doesn't distinguish them by nature at the transport level — they're all addressed the same way and exchange messages over one protocol.
 
@@ -81,7 +81,7 @@ The sections are layered: from "install and use" to "understand the architecture
 
 Built and working: the single router daemon, the messaging protocol (IAP), the peer registry, identity and its ABI, the lifecycle (wake, sleep, restart, supervision), runtime adapters for Claude, Codex, Telegram, and notifier, host install and onboarding, Telegram connection, the memory slot, and capability plugins.
 
-Planned on top of the core: a package-compatibility graph, a whole-team health doctor, and an interactive coordination interface. Until those exist, coordination operations live in the `iapeer` CLI.
+Planned on top of the foundation: a package-compatibility graph, a whole-team health doctor, and an interactive coordination interface. Until those exist, coordination operations live in the `iapeer` CLI.
 
 ## Roadmap
 

package/docs/ru/03-/320/277/320/270/321/200/321/213-/321/200/320/260/320/275/321/202/320/260/320/271/320/274/321/213-/320/270/320/264/320/265/320/275/321/202/320/270/321/207/320/275/320/276/321/201/321/202/321/214.md

@@ -102,7 +102,7 @@ PEER_IDENTITY = PEER_RUNTIME + "-" + PEER_PERSONALITY
 
 Поля профиля делятся на три класса по тому, кто ими владеет:
 
-- **Ядро идентичности** — `personality`, `default_runtime`, `runtimes`, `description`, `intelligence`, `initial_prompt`. Этим владеет ядро и жизненный цикл. Поле `initial_prompt` — затравка первого хода свежей сессии. Поле `runtime` рядом с `default_runtime` — это синхронная копия для совместимости со старыми читателями; оба пишутся согласованно.
+- **Ядро идентичности** — `personality`, `default_runtime`, `runtimes`, `description`, `intelligence`, `initial_prompt`. Этим владеет ядро и жизненный цикл. Поле `initial_prompt` — затравка первого хода свежей сессии. Легаси-поле `runtime` рядом с `default_runtime` больше не пишется — фолбэк при чтении всё ещё понимает старые профили, где есть только `runtime`.
 - **Приватная конфигурация плагина** — секции вроде `expansion` (шорткаты-алиасы), `notifier` (настройка пира-планировщика) и прочие, по одной на плагин. Читаются только из локального профиля, в реестр не попадают.
 - **Публичный паспорт** — секция `interfaces` (например `interfaces.telegram.bot`). Это атрибуты маршрутизации, и они проецируются в реестр.
 

package/docs/ru/04-/320/266/320/270/320/267/320/275/320/265/320/275/320/275/321/213/320/271-/321/206/320/270/320/272/320/273-/320/270-/320/264/320/265/320/274/320/276/320/275.md

@@ -81,7 +81,7 @@
 
 **Сериализация пробуждений.** На спящего агента может прилететь несколько сообщений сразу; поднять его должна одна попытка, иначе родятся две конкурирующие сессии. Демон берёт блокировку на пробуждение конкретного пира — остальные ждут готовности первой.
 
-**Посмертная диагностика.** Супервизор в момент смерти сессии фиксирует её причину (код выхода / сигнал) — это то, что обычная проверка «жив ли процесс» не ловит. На этот случай отдельный сторож (canary) держит блокирующее соединение с супервизором и при смерти сессии записывает обстоятельства — память, swap, список процессов, отчёты диагностики — в журнал.
+**Посмертная диагностика.** Супервизор в момент смерти сессии фиксирует её причину (код выхода / сигнал) в журнал — это то, что обычная проверка «жив ли процесс» не ловит.
 
 ## Граница: claude/codex против инфраструктурных
 

package/docs/ru/13-/320/260/321/200/321/205/320/270/321/202/320/265/320/272/321/202/321/203/321/200/320/260-/320/270-/320/272/320/276/320/275/321/202/321/200/320/260/320/272/321/202.md

@@ -29,7 +29,7 @@
 
 Роутеры пропускают все TUI-фазы: у них нет загрузочных диалогов, маркеров готовности, подтверждения доставки и контрольных команд. Их живость держит launchd, а не пробуждение демоном.
 
-Продакшен-механизм хостинга TUI-сессий — **pty-супервизор**: супервизор-демон владеет pty сессии и её pane-логом, через его сокет идёт доставка на ввод. tmux остаётся только внутренней dev-ветвью (shadow-branch), на пользовательском уровне не фигурирует.
+Продакшен-механизм хостинга TUI-сессий — **pty-супервизор**: супервизор-демон владеет pty сессии и её pane-логом, через его сокет идёт доставка на ввод.
 
 ## Контракт рантайм-пакета
 

package/docs/ru/14-/320/272/320/276/320/275/321/204/320/270/320/263/321/203/321/200/320/260/321/206/320/270/321/217-/320/270-/320/266/321/203/321/200/320/275/320/260/320/273/321/213.md

@@ -71,8 +71,6 @@
 Ещё несколько переменных система читает, но в обычной эксплуатации их не задают:
 
 - `NOTIFIER_FALLBACK_TARGET` — запасной адресат для сигналов notifier; ядро резолвит его в плист пира при онбординге (без хардкода), вручную оператор его не выставляет.
-- `IAP_TMUX_PASTE_SETTLE_MS`, `IAP_TMUX_SUBMIT_TIMEOUT_MS` — тайминги доставки во внутренней tmux dev-ветви; на проде используется pty-супервизор ([13 — Архитектура и контракт](13-архитектура-и-контракт.md)), вне разработки не нужны.
-- `IAPEER_SHADOW_PATH` — `PATH` для shadow-fidelity прогона (внутренний инструмент разработки).
 
 ## Журналы и диагностика
 
@@ -84,8 +82,8 @@
 
 ### Посмертная диагностика
 
-Причину смерти сессии (код выхода / сигнал) супервизор фиксирует в момент смерти — это то, что обычная проверка «жив ли процесс» не ловит. Отдельный сторож (canary) держит соединение с супервизором и при смерти сессии записывает в `exits.log` обстоятельства: память, swap, процессы по потреблению, системные отчёты диагностики. Это материал для ответа на вопрос «почему агент умер».
+Причину смерти сессии (код выхода / сигнал) супервизор фиксирует в момент смерти в `exits.log` — это то, что обычная проверка «жив ли процесс» не ловит. Это материал для ответа на вопрос «почему агент умер».
 
 ### Full Disk Access
 
-Чтобы читать системные отчёты диагностики, бинарю `iapeer` нужен Full Disk Access (FDA) — разрешение macOS. `iapeer status` показывает, выдан ли FDA, и подсказывает, что делать, если нет. Без FDA пиры будут натыкаться на запросы TCC при доступе к защищённым папкам и контейнерам сторонних приложений.
+Бинарю `iapeer` нужен Full Disk Access (FDA) — разрешение macOS. `iapeer status` показывает, выдан ли FDA, и подсказывает, что делать, если нет. Без FDA пиры будут натыкаться на запросы TCC при доступе к защищённым папкам и контейнерам сторонних приложений.

package/docs/ru/README.md

@@ -2,7 +2,7 @@
 
 **Русский** · [English](../README.md)
 
-iapeer — ядро мультиагентной системы на одном хосте. Он держит реестр участников, единый демон-роутер для обмена сообщениями между ними и набор команд, которыми участниками управляют: создают, запускают, усыпляют, перезапускают, подключают к внешним каналам.
+iapeer — основа мультиагентной системы на одном хосте. Он держит реестр участников, единый демон-роутер для обмена сообщениями между ними и набор команд, которыми участниками управляют: создают, запускают, усыпляют, перезапускают, подключают к внешним каналам.
 
 Участник системы называется **пиром**. Пиром может быть AI-агент (Claude, Codex), человек (через Telegram) или служебный процесс (планировщик, наблюдатель). iapeer не различает их по природе на уровне транспорта — все они адресуются одинаково и обмениваются сообщениями через один протокол.
 
@@ -81,7 +81,7 @@ iapeer send assistant --message "привет, ты на связи?"
 
 Построено и работает: единый демон-роутер, протокол обмена сообщениями (IAP), реестр пиров, идентичность и её ABI, жизненный цикл (пробуждение, усыпление, перезапуск, надзор), рантайм-адаптеры для Claude, Codex, Telegram и notifier, установка и онбординг хоста, подключение Telegram, слот памяти и capability-плагины.
 
-Запланировано поверх ядра: граф совместимости пакетов, доктор здоровья всей команды и интерактивный интерфейс координации. Пока этих надстроек нет, координационные операции живут в CLI `iapeer`.
+Запланировано поверх основы: граф совместимости пакетов, доктор здоровья всей команды и интерактивный интерфейс координации. Пока этих надстроек нет, координационные операции живут в CLI `iapeer`.
 
 ## Планы
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agfpd/iapeer",
-  "version": "0.4.12",
+  "version": "0.4.14",
   "description": "Foundation core for the iapeer multi-agent ecosystem: identity, registry, storage, codec.",
   "license": "Apache-2.0",
   "author": "agfpd",
@@ -28,6 +28,7 @@
     "src",
     "bin",
     "docs",
+    "CHANGELOG.md",
     "tsconfig.json",
     "!src/**/*.test.ts",
     "!docs/internals/**"

package/src/cli/index.ts

@@ -1545,10 +1545,13 @@ export async function runCli(argv: string[], env: NodeJS.ProcessEnv = process.en
           } else if (warns.length > 0 && flags.json !== true) {
             lines.push(`⚠ ${peer.personality}: ${warns.map(i => i.field).join(', ')}`)
           }
-          // Migration candidate: conformant, but the default_runtime warn fired
-          // (legacy-only field or diverged mirror). Errored profiles are NEVER
+          // Migration candidate (Phase-3): conformant AND still carrying the legacy `runtime` field —
+          // a warn-fired legacy-only/diverged shape OR an in-sync mirror. In Phase-3 ANY `runtime`
+          // field is stripped, so the candidate set is "has a runtime field", not just "warn fired"
+          // (an in-sync mirror does not warn, but must still be cleaned). Errored profiles are NEVER
           // rewritten — migration heals shape, it does not guess at broken data.
-          if (errs.length === 0 && warns.some(i => i.field === 'default_runtime')) {
+          const hasLegacyRuntime = !!raw && typeof raw === 'object' && (raw as Record<string, unknown>).runtime !== undefined
+          if (errs.length === 0 && (warns.some(i => i.field === 'default_runtime') || hasLegacyRuntime)) {
             legacyRuntimeProfiles.push({ personality: peer.personality, cwd: peer.cwd })
           }
         }
@@ -1568,16 +1571,15 @@ export async function runCli(argv: string[], env: NodeJS.ProcessEnv = process.en
           out(`\n${index.peers.length} peers · ${errors} error(s) · ${driftCount} index↔local drift(s)\n`)
         }
         if (flags.fix === true) {
-          // Phase-2 data migration (staged default_runtime story): rewrite conformant
-          // local profiles still on the legacy field shape — the writer now emits
-          // `default_runtime` + the in-sync legacy `runtime` mirror. Runs BEFORE the
-          // reindex so the healed index is projected from migrated locals.
+          // Phase-3 data migration (default_runtime story complete): rewrite conformant local profiles
+          // still carrying the legacy `runtime` field — the writer now emits ONLY `default_runtime` and
+          // STRIPS the mirror. Runs BEFORE the reindex so the healed index is projected from clean locals.
           const migrated: string[] = []
           for (const p of legacyRuntimeProfiles) {
             if (migrateProfileRuntimeField(p.cwd)) migrated.push(p.personality)
           }
           if (migrated.length > 0) {
-            out(`migrated runtime→default_runtime (legacy mirror kept): ${migrated.join(', ')}\n`)
+            out(`stripped legacy \`runtime\` mirror (default_runtime only): ${migrated.join(', ')}\n`)
           }
           if (driftCount > 0 || errors === 0) {
             const { healed, missing } = await reindexFromLocals({ env })

package/src/identity/profileStandard.ts

@@ -217,6 +217,23 @@ export function projectProfileToRecord(cwd: string): PeerRecord | null {
   }
 }
 
+/** Order-insensitive structural serialization for comparing the projected OWNER
+ *  passport (`interfaces`) — a nested object whose key ORDER is not semantically
+ *  meaningful. A plain JSON.stringify would flag an order-only difference as drift
+ *  (a legacy upsertPeer write may have stored keys in a different order); canonicalize
+ *  first so only real content divergence is reported — a key added, removed, or changed,
+ *  e.g. a field dropped from the source of truth after a cutover that the derived index
+ *  never re-projected. */
+function canonicalJson(value: unknown): string {
+  if (value === null || typeof value !== 'object') return JSON.stringify(value) ?? 'null'
+  if (Array.isArray(value)) return `[${value.map(canonicalJson).join(',')}]`
+  const obj = value as Record<string, unknown>
+  return `{${Object.keys(obj)
+    .sort()
+    .map(k => `${JSON.stringify(k)}:${canonicalJson(obj[k])}`)
+    .join(',')}}`
+}
+
 /** The index↔local drift for one peer: the fields where the live registry record
  *  disagrees with the projection from the local profile (the self-heal source). Empty
  *  array = in sync. cwd is the registry pointer, never compared. */
@@ -227,6 +244,12 @@ export function recordDrift(indexRecord: PeerRecord, projected: PeerRecord): str
   if (indexRecord.runtimes.join(',') !== projected.runtimes.join(',')) drift.push('runtimes')
   if (indexRecord.description !== projected.description) drift.push('description')
   if (indexRecord.intelligence !== projected.intelligence) drift.push('intelligence')
+  // The OWNER passport (`interfaces`) is projected into the registry, so a divergence
+  // here is real drift — the class that hid the bot_username cutover (source dropped
+  // `interfaces.telegram.bot`, the derived index kept it because nothing compared it).
+  // projectProfileToRecord already replaces interfaces wholesale; comparing it here makes
+  // the desync VISIBLE to verify/reconcile so it can never silently persist again.
+  if (canonicalJson(indexRecord.interfaces) !== canonicalJson(projected.interfaces)) drift.push('interfaces')
   return drift
 }
 

package/src/transport/index.ts

@@ -966,19 +966,21 @@ function validateAttachments(value: readonly string[] = []): Result<string[]> {
 
 // ─── Telegram-domain sender policy ─
 
-/** A SENDER face in the telegram domain: a non-empty interfaces.telegram.bot (the
- *  bot machine-key) in the peer's registry passport. Deliberately bot-ONLY, not
- *  bot|user_id — the bridge picks the SENDING bot from the sender's bot key:
- *  a user_id grants a receive/operator
- *  identity but no ability to send, so a user_id-only sender passing the guard
- *  would still die at the bridge — a late asynchronous failure where the guard
- *  exists to give a synchronous one. The guard passes exactly what the bridge can
- *  deliver. */
+/** A SENDER face in the telegram domain: a non-empty interfaces.telegram.bot_username
+ *  (the bot binding key SINCE the bot_username-cutover) in the peer's registry passport.
+ *  Deliberately bot_username-ONLY, not bot_username|user_id — the bridge picks the SENDING
+ *  bot from the sender's bot_username key: a user_id grants a receive/operator identity but
+ *  no ability to send, so a user_id-only sender passing the guard would still die at the
+ *  bridge — a late asynchronous failure where the guard exists to give a synchronous one.
+ *  The guard passes exactly what the bridge can deliver. (Legacy `bot` was the pre-cutover
+ *  key; it is NO LONGER read here — the source of truth dropped it and telegram-runtime
+ *  resolves the sending bot on bot_username. This guard is the foundation's only consumer
+ *  of the telegram passport, so it moves with the cutover.) */
 export function hasTelegramPresence(record: PeerRecord): boolean {
   const tg = record.interfaces?.telegram
   if (!tg || typeof tg !== 'object' || Array.isArray(tg)) return false
   const t = tg as Record<string, unknown>
-  return typeof t.bot === 'string' && t.bot.trim() !== ''
+  return typeof t.bot_username === 'string' && t.bot_username.trim() !== ''
 }
 
 /** Sender policy for the telegram domain: a peer with NO declared telegram presence
@@ -1000,7 +1002,7 @@ function telegramSenderGuard(
   if (targetRuntime !== 'telegram') return ok(undefined)
   if (hasTelegramPresence(caller.record)) return ok(undefined)
   return err(
-    `telegram policy: sender "${caller.personality}" has no telegram face (no interfaces.telegram.bot in its passport) — message to "${targetPersonality}" NOT delivered; route via a peer that has a telegram bot in its passport, or provision a bot for this sender`,
+    `telegram policy: sender "${caller.personality}" has no telegram face (no interfaces.telegram.bot_username in its passport) — message to "${targetPersonality}" NOT delivered; route via a peer that has a telegram bot in its passport, or provision a bot for this sender`,
   )
 }