@agfpd/iapeer 0.4.13 → 0.4.15

package/CHANGELOG.md

@@ -0,0 +1,254 @@
+# 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]
+
+## [0.4.15] - 2026-06-21
+
+### Fixed
+
+- Ephemeral idle-reap no longer kills a **working** session mid-turn. An armed ephemeral
+  worker (one that has sent its reply) was reaped after 20s of *transcript* silence, but the
+  transcript goes quiet during a long model generation — so a still-working worker was killed
+  mid-turn. The reap now folds in the pane-log (TUI render-stream) mtime, so "quiet" means the
+  turn truly ended: a working session is never reaped, while an idle one still reaps in ~20s
+  (keeping the ephemeral serial conveyor draining promptly).
+
+## [0.4.14] - 2026-06-21
+
+### Fixed
+
+- **Completed the bot_username cutover.** The telegram sender-guard (`hasTelegramPresence`)
+  now keys on `interfaces.telegram.bot_username` (the cutover's binding key) instead of the
+  legacy `bot`; the host registry was regenerated from the per-cwd source of truth, dropping
+  the stale `interfaces.telegram.bot` field across the fleet. telegram-runtime already
+  resolved on `bot_username`, so the foundation guard was the last consumer of `bot`.
+- `recordDrift` (verify / reconcile) now compares the `interfaces` passport with an
+  order-insensitive canonical compare, so a source↔derived divergence is detected and healed
+  by `verify --fix` — the class that had let the derived registry silently keep a field
+  removed from the source of truth.
+
+### 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.
+- Unified the README to the fleet documentation style.
+
+### Added
+
+- This changelog (Keep a Changelog), shipped in the npm package.
+- HD hero GIF in the README (1440×726 — sharper terminal text).
+
+## [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.15...HEAD
+[0.4.15]: https://github.com/agfpd/iapeer/compare/v0.4.14...v0.4.15
+[0.4.14]: https://github.com/agfpd/iapeer/compare/v0.4.13...v0.4.14
+[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.13",
+  "version": "0.4.15",
   "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/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/lifecycle/index.ts

@@ -12,7 +12,7 @@
 // before any wake or reap. wakeOrSpawn refuses a launchd peer; superviseTick and
 // sweepZombies skip it. Only daemon-owned (no-plist) peers are managed here.
 
-import { existsSync, mkdirSync, readFileSync, readdirSync, rmSync, writeFileSync } from 'fs'
+import { existsSync, mkdirSync, readFileSync, readdirSync, rmSync, statSync, writeFileSync } from 'fs'
 import { homedir } from 'os'
 import { join } from 'path'
 import { spawnSync } from 'child_process'
@@ -74,20 +74,21 @@ export interface LifecycleConfig {
   crashLoopWindowSecs: number
   /** wake_policy:ephemeral M2 — the quiet window (seconds of activity-proxy silence)
    *  after which an ARMED ephemeral session (it has sent its outbound reply) is
-   *  reaped. Long enough for the post-reply housekeeping writes (operative notes)
-   *  to keep resetting it; far below idleSecs. ASSUMPTION (by design): the
-   *  transcript mtime is a LIVENESS proxy — "no longer writing" — not a semantic
-   *  "done" signal. */
+   *  reaped. Kept SHORT so the M3 serial conveyor drains the peer's next queued task
+   *  promptly once its session is truly idle. "Quiet" here is BOTH the transcript proxy
+   *  AND the pane-log (TUI render-stream) silent — the pane-log advances ~1s while the
+   *  TUI renders a turn (generation OR a tool), so a still-working session is NEVER
+   *  reaped mid-turn even though the transcript is momentarily quiet (the live incident
+   *  this fixes: an armed worker generating its next step >20s was reaped at age=29s). */
   ephemeralQuietSecs: number
   /** wake_policy:ephemeral — the UNARMED idle bound (seconds): an ephemeral session
    *  that never armed (finished silently / lost its arm to a daemon-restart window)
-   *  is reaped after this much activity-proxy silence. Live case: a worker that
-   *  ended silently without its final outbound stalled its M3 FIFO for the FULL
-   *  generic idleSecs (1 h) — with serial drain that blocks the whole conveyor per
-   *  silent worker. Bound chosen ≫ the legitimate silent-tool case
-   *  (sleep-180) and ≪ idleSecs. DOCUMENTED RISK: an ephemeral worker whose tool
-   *  stays silent longer than this MID-TASK is reaped and its consumed queue item
-   *  is lost — ephemeral workers must emit activity (or their reply) within it. */
+   *  is reaped after this much TRUE-idle silence (transcript AND pane-log both quiet).
+   *  Live case: a worker that ended silently without its final outbound stalled its M3
+   *  FIFO for the FULL generic idleSecs (1 h) — with serial drain that blocks the whole
+   *  conveyor per silent worker. Bound chosen ≫ a brief no-output gap and ≪ idleSecs.
+   *  A still-WORKING silent-tool worker keeps the pane-log fresh via the TUI render, so it
+   *  is no longer reaped mid-task — only a genuinely idle/wedged session crosses this. */
   ephemeralUnarmedIdleSecs: number
 }
 
@@ -343,6 +344,21 @@ export function clearEphemeralArmed(cfg: LifecycleConfig, identity: string): voi
   }
 }
 
+/** mtime (ms) of a hosted session's pane-log (`<logDir>/<identity>.log`) — the RAW TUI
+ *  render byte-stream the supervisor appends for the session's whole life. It advances
+ *  ~1s while the TUI is rendering a turn (the "esc to interrupt" elapsed counter ticks
+ *  during BOTH model generation AND a tool run) and goes quiet at the prompt. So it is
+ *  the truest active-turn liveness signal — the SAME mtime telegram-runtime reads for its
+ *  typing/activity indicator — and unlike the transcript proxy it does NOT go quiet during
+ *  a long model generation (no JSONL write until the message completes). null if absent. */
+function paneLogMtimeMs(cfg: LifecycleConfig, identity: string): number | null {
+  try {
+    return statSync(join(cfg.logDir, `${identity}.log`)).mtimeMs
+  } catch {
+    return null
+  }
+}
+
 function deathsPath(cfg: LifecycleConfig, identity: string): string {
   return join(cfg.stateDir, `${identity}.deaths`)
 }
@@ -1147,6 +1163,9 @@ export interface SuperviseDeps {
   /** Liveness seam (default: the real `sessionAlive` = pty-host OR tmux-fallback). Tests inject a
    *  fixed verdict so the idle path is exercised hermetically — no live tmux/pty session needed. */
   sessionAlive?: (sock: string, identity: string) => boolean
+  /** Pane-log mtime seam (default: the real pane-log file mtime). Tests inject a controlled value to
+   *  exercise the ephemeral active-turn vs idle distinction without a real pane-log on disk. */
+  paneLogMtime?: (identity: string) => number | null
 }
 
 export function superviseTick(cfg: LifecycleConfig, deps: SuperviseDeps = {}): SuperviseOutcome[] {
@@ -1154,6 +1173,7 @@ export function superviseTick(cfg: LifecycleConfig, deps: SuperviseDeps = {}): S
   const nowMs = deps.nowMs ?? Date.now()
   const activityMtime = deps.newestActivityMtime ?? ((rt: string, c: string) => getAdapter(rt as Runtime).newestActivityMtime(c))
   const isAlive = deps.sessionAlive ?? sessionAlive
+  const paneLogMt = deps.paneLogMtime ?? ((identity: string) => paneLogMtimeMs(cfg, identity))
   const verbose = superviseLogVerbose(env)
   // Pane-log volume cap (launch/cmdlog.ts capPaneLogs): the per-identity pane-log
   // (<logDir>/<identity>.log) is the RAW TUI byte stream pipe-pane/the supervisor
@@ -1241,17 +1261,31 @@ export function superviseTick(cfg: LifecycleConfig, deps: SuperviseDeps = {}): S
     } catch {
       /* no adapter for this runtime yet → wokeAt baseline */
     }
+    const ephemeral = isEphemeralPeer(s.cwd)
+    if (ephemeral) {
+      // FOLD IN the pane-log (TUI render-stream) mtime for ephemeral peers. The transcript
+      // proxy goes QUIET during a long model generation (no JSONL write until the message
+      // completes), so the short ephemeral windows below mis-read mid-generation as "done"
+      // and reap the worker MID-TURN (live incident 2026-06-20: Index reaped age=29s while
+      // generating the next step after a tool_result). The pane-log advances ~1s while the
+      // TUI renders a turn (model generation OR a tool run — the "esc to interrupt" elapsed
+      // counter ticks) and goes quiet only at the prompt, so it is the truer active-turn
+      // signal. max() means "quiet" iff BOTH are silent — it can only DELAY a reap, never
+      // cause an earlier one, so the pipeline serial-drain (idle → quiet → reaped) is
+      // preserved while a working session is never killed mid-turn.
+      const plMt = paneLogMt(s.identity)
+      if (plMt !== null) mt = Math.max(mt, plMt)
+    }
     const ageSecs = Math.floor((nowMs - mt) / 1000)
     // wake_policy:ephemeral M2 — die-after-reply: an ARMED ephemeral session (the
     // daemon routed its outbound reply) is reaped after a QUIET window, checked
-    // BEFORE the idle branch (quiet ≪ idle). Quiet = the activity proxy stayed
-    // silent for ephemeralQuietSecs — post-reply housekeeping (operative-note
-    // writes) keeps resetting it, so the worker finishes its bookkeeping first.
-    // NOT armed (still mid-task, e.g. a long silent tool run) → the ordinary
-    // idle bound below is its only reaper. Deliberate, policy-driven death:
-    // NO .idle-reaped (an ephemeral peer never resumes) and NO recordDeath
-    // (the crash-loop ring counts faults, not policy reaps).
-    if (isEphemeralPeer(s.cwd) && hasEphemeralArmed(cfg, s.identity) && ageSecs > cfg.ephemeralQuietSecs) {
+    // BEFORE the idle branch (quiet ≪ idle). Quiet = transcript AND pane-log both
+    // silent for ephemeralQuietSecs — a still-rendering turn keeps the pane-log fresh,
+    // so the worker finishes its turn first; post-reply housekeeping also resets it.
+    // NOT armed (still mid-task) → the ordinary idle bound below is its only reaper.
+    // Deliberate, policy-driven death: NO .idle-reaped (an ephemeral peer never resumes)
+    // and NO recordDeath (the crash-loop ring counts faults, not policy reaps).
+    if (ephemeral && hasEphemeralArmed(cfg, s.identity) && ageSecs > cfg.ephemeralQuietSecs) {
       killSession(sock, s.identity)
       clearEphemeralArmed(cfg, s.identity)
       removeSessionState(cfg, s.identity)
@@ -1274,8 +1308,11 @@ export function superviseTick(cfg: LifecycleConfig, deps: SuperviseDeps = {}): S
     // silent-finish path is `iapeer self-done` (arm without waking anyone —
     // the invariant «нет пустых пробуждений» stays intact); this branch only
     // bounds the damage when a worker does neither. Policy reap: NO .idle-reaped
-    // (ephemeral never resumes), NO recordDeath (the ring counts faults).
-    if (isEphemeralPeer(s.cwd) && ageSecs > cfg.ephemeralUnarmedIdleSecs) {
+    // (ephemeral never resumes), NO recordDeath (the ring counts faults). The pane-log
+    // fold-in above also covers this branch: a STILL-WORKING unarmed worker (a silent
+    // tool, no reply yet) keeps the pane-log fresh via the TUI render, so it is no longer
+    // reaped mid-task — only a genuinely idle/wedged unarmed session crosses this bound.
+    if (ephemeral && ageSecs > cfg.ephemeralUnarmedIdleSecs) {
       killSession(sock, s.identity)
       clearEphemeralArmed(cfg, s.identity)
       removeSessionState(cfg, s.identity)

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`,
   )
 }