@agfpd/iapeer 0.4.109 → 0.4.111

package/CHANGELOG.md

@@ -10,6 +10,33 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+
+- **Hosted hard teardown reclaims PTY-owned subprocesses, not only the runtime root.**
+  `self-fresh`, stop and reap snapshot ancestry before killing the runtime, including stdio MCP
+  launchers in separate process groups. Start-token and controlling-terminal checks exclude reused
+  PIDs, unrelated processes and detached/shared daemon branches. An isolated real-Codex proof and
+  hermetic regressions cover old-tree exit, fresh MCP calls and sentinel survival. Already-orphaned
+  processes and shared-backend thread shutdown remain outside this bounded cleanup.
+
+- **macOS executable signatures are checked before activation.** Runtime packages
+  must strictly verify compiled and copied staged binaries, repair invalid trusted
+  build artifacts with ad-hoc signing, and re-verify before binary/manifest publication.
+  A lightweight `@agfpd/iapeer/install-signature` helper implements the gate. Foundation
+  install and rollback now sign/verify the staged inode before replacing the binary;
+  runtime install/update also verify installed launchers before provisioning/restart,
+  even when the package/version is already current. Foundation update also verifies
+  its installed binary before activation, including same-version stale-daemon healing.
+  Valid signatures are preserved;
+  failed repair never licenses activation of invalid code.
+
+- **IAP attachments now transfer ownership instead of forwarding fragile source paths.**
+  Every `send_to_peer`, `iapeer send`, and Fleet API send copies regular-file sources
+  into the target peer's durable, content-addressed foundation inbox before an
+  envelope can be accepted. The recipient can read or forward the copy after the
+  sender deletes `/tmp` or otherwise removes the source. Copies live for the
+  recipient peer's lifetime and `iapeer remove` purges its inbox.
+
 ## [0.4.25] - 2026-06-22
 
 ### Fixed

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

@@ -98,4 +98,15 @@ So `stop`, `start`, `new` refuse to touch foreign launchd peers — for those th
 - **`iapeer interrupt`** — interrupt the current turn (Escape) without losing context.
 - **`iapeer self-fresh` / `self-done`** — an agent's self-calls: mark itself for a fresh restart, or quietly finish (for ephemeral workers).
 
+### Process ownership at teardown
+
+Closing a hosted session is a **hard teardown**, not the MCP client's graceful stdin/EOF shutdown.
+Before killing the runtime, the supervisor snapshots its descendants and kills those still attached
+to its controlling PTY, including stdio MCP launchers in separate process groups. Each PID's start
+token and terminal are re-checked before signalling; unrelated processes and detached daemon branches
+are excluded. This also applies to `self-fresh`: finish work and persist the handoff before calling it.
+Processes already orphaned before the snapshot, a concurrent fork/exit race, an unreadable process
+table, and shared-backend threads outside the PTY are not covered by this cleanup. A shared runtime
+daemon needs its own per-thread shutdown protocol; ancestry alone does not authorize killing it.
+
 Behavior by runtime class — [08 — Peer management](08-peer-management.md); ephemeral workers — [10 — Messaging](10-messaging.md).

package/docs/06-storage.md

@@ -26,6 +26,7 @@ The same plugin can store data at both levels: shared in `~/.iapeer/`, peer-boun
 │       └── .iapeer/           (peer-level layout — see below)
 ├── state/
 │   ├── iapeer/                daemon state (router.sock, router.json …)
+│   │   └── attachments/       recipient-owned IAP attachment copies
 │   └── <plugin>/              a plugin's mutable state
 ├── logs/
 │   ├── iapeer/                daemon logs: lifecycle.log, delivery.log, exits.log
@@ -53,7 +54,7 @@ The same plugin can store data at both levels: shared in `~/.iapeer/`, peer-boun
 A few nodes worth highlighting:
 
 - **`peers-profiles.json`** — the registry. Written only through a single writer under the file lock `peers-profiles.lock`; direct editing is forbidden at the core level.
-- **`state/iapeer/`** — where the daemon lives: its local socket `router.sock` and config `router.json`.
+- **`state/iapeer/`** — where the daemon lives: its local socket `router.sock`, config `router.json`, and `attachments/<recipient>/<sha256>/<basename>` inboxes. Attachment inboxes are durable recipient state (not cache); peer removal cleans that recipient's inbox.
 - **`logs/<name>/`** — an infrastructure peer's logs are placed by peer name at the shared level (not in the peer's folder), because it's the output of a launchd service.
 - **`runtimes/<runtime>/`** — dual ownership: the root belongs to the runtime itself (Telegram keeps bot tokens and poll state here), while the `plugins/<plugin>/` subfolder is the plugins' space, holding their config under this runtime.
 - **`docs/<package>/`** — on-host reference docs, one folder per ecosystem package (see below).

package/docs/07-install-and-update.md

@@ -60,7 +60,7 @@ On a fresh macOS host the first install → onboard → peer launch surfaces a h
 **Three things you do (these cannot be automated):**
 
 1. **Log in to the runtimes — before onboard.** Sign in to Claude Code and Codex first. Their login screen is a browser OAuth flow that no headless peer can drive, so iapeer deliberately does **not** auto-answer it; a runtime that is installed but not signed in makes a peer fail its first wake loudly. `iapeer onboard` warns when it finds an unauthenticated runtime.
-2. **Login keychain password — once, during install.** The install code-signs the binary with a stable local identity so Full Disk Access survives updates; macOS asks for your login keychain password the one time that identity is created. It is expected (the installer announces it). If declined, the binary still works — TCC prompts would just recur on updates.
+2. **Login keychain password — once, during install.** The install code-signs the staged binary with a stable local identity so Full Disk Access survives updates; macOS asks for your login keychain password the one time that identity is created. It is expected (the installer announces it). If declined, install may use a verified ad-hoc signature (TCC prompts may recur). Signature verification itself is mandatory: an unrepairable build aborts before replacing the installed binary.
 3. **Full Disk Access — a manual grant, no prompt.** macOS TCC cannot be set by any flag, env var, or script. Without it, a peer reading or writing a TCC-protected path (an iCloud Obsidian vault, Desktop, Documents, Downloads) silently fails with EPERM — no prompt, no hang. Grant it in **System Settings → Privacy & Security → Full Disk Access** (`~/.iapeer` itself is under `$HOME` and needs nothing); onboard prints the reminder.
 
 Gatekeeper does not gate the locally-built CLI run from a terminal (no quarantine attribute). Verified live on a truly-virgin Claude config (claude 2.1.183): the theme picker, folder-trust, the bypass-permissions accept (cursor stepped to "Yes"), and the project MCP-server approval all auto-clear in sequence, the peer reaches its input prompt, and a second launch on the same config is dialog-free; the Codex folder-trust / update auto-clearing likewise (an owner's clean-machine install + an isolated first-boot test).
@@ -78,7 +78,7 @@ A bare `iapeer update` updates the **whole host stack** in one command — the c
 
 **1. Core (foundation)** — and it ABORTS the cascade on a hard failure (never update runtimes onto a broken core):
 
-1. Learns the target version from npm. If the installed one already matches and there's no `--force` — it does nothing.
+1. Learns the target version from npm. If the installed one already matches and there's no `--force`, it verifies the installed executable signature without repairing it; a valid, version-consistent daemon needs no restart. An invalid binary is refused, including before recovery of a stale live daemon.
 2. Downloads and builds the new binary via `npm pack`, not `npx` (the binary doesn't rebuild itself).
 3. Restarts the daemon onto the new binary.
 4. Restarts the infrastructure launchd jobs the core owns (`com.iapeer.*` — the `timer`, `watcher`, Telegram routers), moving them onto the just-replaced binary. It's the JOBS that restart, not the runtimes' package code — that's the next step. If the daemon didn't come up in step 3, this is skipped.
@@ -90,7 +90,7 @@ A bare `iapeer update` updates the **whole host stack** in one command — the c
 
 Runtimes and memory are **best-effort**: a component failure is reported and the rest still run; the command exits non-zero if anything failed. Agentic peers (Claude/Codex) pick up new core doctrine lazily on their next wake.
 
-`iapeer update --foundation-only` does just step 1 (the narrow case). A pinned `iapeer update <version>` is **core-only** by design — a version pin is core-specific (downgrade, or pin a proven version, deeper than one rollback step).
+`iapeer update --foundation-only` does just the foundation leg, including infrastructure-job re-registration when the binary/daemon changes; it narrows package updates, not process restarts. A pinned `iapeer update <version>` has the same **core-only** scope — a version pin is core-specific (downgrade, or pin a proven version, deeper than one rollback step).
 
 > **Upgrading from before the cascade (< 0.4.2).** The cascade is driven by the *installed* binary, so the very first `iapeer update` from a pre-cascade version runs the OLD (foundation-only) logic: it upgrades the core to the cascade-capable binary but does not yet cascade runtimes + memory. Run `iapeer update` once more — now the new binary cascades the rest. This is a one-time bootstrap; from 0.4.2 onward it is a single command. (A fresh install lands on a cascade-capable binary directly, so it never needs the double run.)
 

package/docs/10-messaging.md

@@ -23,6 +23,18 @@ iapeer send assistant --message "..." --topic "release" --from claude-reviewer
 
 The `--from` flag sets the sender (`<runtime>-<name>`); by default it's the identity of the current folder's peer. `--attachment` is repeatable. `--message-file`, with the body from a file or stdin, is handy for long, multi-line messages.
 
+## Attachment ownership
+
+An attachment argument is a **source path**, not the delivered path. `routeSend` opens every source as a regular file and copies its bytes into the target peer's foundation-owned inbox before it builds the envelope:
+
+```text
+~/.iapeer/state/iapeer/attachments/<recipient>/<sha256>/<basename>
+```
+
+The envelope contains these absolute inbox paths. Therefore an `ok`/`delivered`/`queued` result also means that every attachment already has a readable recipient copy; the sender may immediately delete or rename its source. A missing, unreadable, or non-regular source fails the send before delivery. Re-sending an inbox file to a third peer makes another copy in that third peer's inbox.
+
+The copy is recipient-owned state, not cache: it is not age-GCed and lives for the recipient peer's lifetime. `iapeer remove <recipient>` removes the complete inbox. Removing the sender, cleaning `/tmp`, restarting the daemon, draining an ephemeral queue, and bridge history rotation do not remove it.
+
 ## The delivery path
 
 The daemon finds the recipient in the registry and selects its endpoint first. With no explicit `runtime`, the endpoint is always the recipient's `default_runtime`; liveness of other declared runtimes does not change that choice. An explicit `runtime` selects that exact surface. The daemon then looks at the selected endpoint's state:

package/docs/12-cli-reference.md

@@ -61,7 +61,7 @@ The full list of `iapeer <command>`. General rules: `--help` / `-h` anywhere in
 | `send <target> (--message <text> \| --message-file <f\|->) [--from <id>] [--runtime <r>] [--attachment <path>]… [--topic <t>]` | Manual IAP send over the same path as `send_to_peer`. |
 | `confirm-send <id> [--runtime <rt>]` | Deliver a held send ([origin guard](18-origin-guard.md)): as addressed, or `--runtime` redirects it to the origin channel. No re-send of the message text. |
 
-`--message-file -` reads the body from stdin. `--attachment` is repeatable. `--from` defaults to the current folder's peer identity.
+`--message-file -` reads the body from stdin. `--attachment` is repeatable and names an absolute source file; the router copies it into recipient-owned state before accepting the send. `--from` defaults to the current folder's peer identity.
 
 ## Launch and runtimes
 

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

@@ -13,6 +13,7 @@ The system's behavior rests on these:
 - **A single registry writer.** `peers-profiles.json` is written only through one writer under a file lock. Direct writing of the file is forbidden at the core level — this rules out races.
 - **Liveness is defined by a peer's live session.** A peer is alive if and only if it has a live session under the supervisor. This isn't a separate state flag that can desync, but an observable fact.
 - **`delivered` ⟺ landed in a live session.** Delivery success means the message was accepted by a live session (the daemon waited for confirmation). If it didn't confirm — the daemon treats the session as dead rather than lying about success.
+- **Attachments are copied before routing.** Caller paths are only sources. Before an envelope can be accepted as delivered or queued, `routeSend` copies every attachment into the target peer's foundation-owned inbox and puts those copy paths into the envelope. A later delete, rename, or cleanup of the caller's source cannot break the received attachment. The copies live for the lifetime of the recipient peer and `iapeer remove <peer>` removes that inbox.
 - **The source of truth is the local profile.** The registry is a reprojectable projection of the peer profiles. On a divergence, the profile wins.
 - **The binary is installed on the host.** The daemon runs from the installed `~/.local/bin/iapeer`, not from a source working tree. An update is replacing the binary and restarting the daemon onto it.
 
@@ -82,6 +83,49 @@ Commands like `prepare`, `interface`, `bot`, `doctor` are the package's own inte
 - **`install-runtime <runtime>`** determines the npm package (from the built-in registry or the `--package` flag), installs it via `npx`, then provisions the declared peer set.
 - **`update-runtime <runtime>`** compares the manifest version with npm; when behind, it reinstalls, re-provisions, and restarts the runtime's peers with the standard `stop`/`start`.
 
+### Executable signature before activation (macOS)
+
+A successful Bun compile or executable copy does not guarantee a valid Mach-O
+signature. Each package owns this gate on **every** self-install path (compile and
+copy-self), including direct `npx` installs outside the foundation:
+
+1. Build/copy to a sibling temporary file and set its executable permissions.
+2. Run `/usr/bin/codesign --verify --deep --strict <tmp>`. Preserve a valid signature
+   unchanged, including certificate-backed signatures used for stable TCC grants.
+3. For an invalid/unsigned **installer-owned build artifact**, repair with
+   `/usr/bin/codesign --force --sign - <tmp>` and repeat strict verification.
+4. Only after verification succeeds, atomically rename the file over the installed
+   binary and publish the new manifest. On failure, remove the temporary file, exit
+   non-zero, and leave the previous binary and manifest unchanged.
+
+The optional lightweight helper `ensureExecutableSignature` is exported from
+`@agfpd/iapeer/install-signature`; a package may implement the same contract locally.
+It throws on verification/repair failure, skips shebang script launchers and non-macOS
+hosts, and supports injected command runners for hermetic tests. Its repair mode is
+for trusted installer artifacts, **not** a general authenticity check or a way to
+trust arbitrary modified installed code. Stable certificate signing for TCC is a
+separate concern; signature validity is fail-closed even if stable signing is soft.
+
+The foundation additionally verifies installed runtime launchers before provisioning
+or restart, including already-installed/already-latest paths. This secondary gate
+is verify-only: it reports invalid signatures rather than re-signing live binaries.
+It cannot replace the package's pre-rename gate, since launchd may reopen a binary
+as soon as the package publishes it.
+
+Foundation install and rollback apply the same staged validity gate before binary
+replacement. Stable local-certificate signing happens on the staged inode; a
+certificate-signing failure can fall back to a verified ad-hoc signature, but an
+unrepairable executable is never activated. Repair is not guaranteed for malformed
+Bun output: a strict-validation failure aborts safely and requires a working build.
+The update orchestrator also verify-only checks the installed foundation binary before
+daemon activation, including the same-version stale-daemon recovery path.
+
+The shipped `scripts/proof-install-signature.ts` exercises the actual package CLI
+installer and native codesign in disposable paths (requires the existing local signing
+identity). It includes refusal/state preservation, verify-only runtime gates and
+rollback. Update lifecycle calls are injected: this proof never restarts the host daemon
+and is not a deployed-health acceptance.
+
 ## The capability-plugin standard
 
 A capability plugin adds an ability to a peer without being a runtime. The distinction is clear: a runtime is a peer's mode of presence, a plugin is an ability on top of a runtime.

package/docs/15-fleet-api.md

@@ -203,10 +203,10 @@ What the headline states look like on the stream: a peer **waking** is `ev=wake`
 `POST /fleet/v1/send` — deliver a message through the same routing path as the `send_to_peer` tool (wake-on-miss, queueing, delivery log — identical semantics):
 
 ```json
-{ "personality": "boris", "message": "…", "runtime": "claude", "topic": "…", "from": "nova" }
+{ "personality": "boris", "message": "…", "runtime": "claude", "topic": "…", "attachments": ["/tmp/report.pdf"], "from": "nova" }
 ```
 
-`from` is optional: a full `<runtime>-<personality>`, or a bare personality (its default runtime). Default: the **single natural-intelligence peer** of the registry — a GUI-originated message is the human's. With zero or several natural peers the request is refused (`400`) with an instruction to pass `from`.
+`from` is optional: a full `<runtime>-<personality>`, or a bare personality (its default runtime). Default: the **single natural-intelligence peer** of the registry — a GUI-originated message is the human's. With zero or several natural peers the request is refused (`400`) with an instruction to pass `from`. `attachments`, when present, is the same array of absolute source paths as the MCP tool; the shared `routeSend` path copies them into the recipient inbox before acceptance.
 
 Not part of the *command* API, deliberately: **attach** (a terminal handoff — a client opens the system terminal with `iapeer attach <peer>`), registry/host **admin verbs** (`create`/`remove`/`update`/`uninstall` — will be added when a client actually needs them). The **human-approval broker** now lives under `/fleet/v1/approvals*` (`GET` the queue / one item, `POST /<id>/(approve|deny)`) with the `approval-request` / `approval-resolved` SSE `ev` kinds and the `approvals` snapshot field above — the full contract is **docs/17-approval**. The **notice board** lives under `/fleet/v1/notices*` (`GET` the board / one item — **read-only**: a notice is one-way and has nothing to resolve) with the `notice-raised` SSE `ev` kind and the `notices` snapshot field above — the full contract is **docs/19-notices**.
 

package/docs/18-origin-guard.md

@@ -30,7 +30,7 @@ verbatim as og-1a2b3c4d (expires in 15 min).
 Do not re-send the message text — confirm-send delivers the held message.
 ```
 
-Both exits cost one shell command and **zero message regeneration**: the held send carries the full original input (message, topic, attachments).
+Both exits cost one shell command and **zero message regeneration**: the held send carries the original message/topic/runtime and recipient-owned copies of every attachment. Copying happens before the hold is persisted, so deleting a caller's temporary sources during the 15-minute decision window cannot break `confirm-send`.
 
 ```bash
 iapeer confirm-send og-1a2b3c4d                 # deliver as addressed (intentional cross-channel)
@@ -48,7 +48,7 @@ State is on disk (it must survive daemon restarts and short-lived CLI processes)
 ```text
 ~/.iapeer/state/iapeer/origin/
   state.json          # (agent → human → {rt, inboundTs, answeredTs}) — last-wins, atomic writes
-  pending/<id>.json   # held sends, verbatim; lazily GC'd past the pending TTL
+  pending/<id>.json   # held sends; attachment fields already name recipient-inbox copies
 ```
 
 ## Scope and non-interference

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

@@ -98,4 +98,15 @@
 - **`iapeer interrupt`** — прервать текущий ход (Escape), не теряя контекст.
 - **`iapeer self-fresh` / `self-done`** — самовызовы агента: пометить себя на свежий перезапуск или тихо завершиться (для эфемерных воркеров).
 
+### Владение процессами при закрытии сессии
+
+Закрытие управляемой сессии — **жёсткое завершение**, а не протокол мягкого закрытия stdin/EOF
+клиентом MCP. До остановки рантайма супервизор снимает дерево его потомков и завершает тех,
+кто ещё принадлежит его управляющему PTY, включая stdio MCP в отдельных группах процессов.
+Перед сигналом повторно проверяются время рождения PID и терминал; чужие процессы и ветви
+отсоединённых демонов исключены. Это относится и к `self-fresh`: работу и хендофф завершают до самовызова.
+Уже осиротевшие до снимка процессы, гонка параллельного порождения/выхода, недоступная таблица
+процессов и потоки общего бэкенда вне PTY этой очисткой не покрываются. Общему демону рантайма
+нужен собственный протокол закрытия отдельного потока; одно лишь родство не разрешает убивать его.
+
 Поведение по классам рантаймов — [08 — Управление пирами](08-управление-пирами.md); эфемерные воркеры — [10 — Обмен сообщениями](10-обмен-сообщениями.md).

package/docs/ru/06-/321/205/321/200/320/260/320/275/320/265/320/275/320/270/320/265.md

@@ -26,6 +26,7 @@
 │       └── .iapeer/           (раскладка уровня пира — см. ниже)
 ├── state/
 │   ├── iapeer/                состояние демона (router.sock, router.json …)
+│   │   └── attachments/       копии IAP-вложений, принадлежащие получателям
 │   └── <плагин>/              изменяемое состояние плагина
 ├── logs/
 │   ├── iapeer/                журналы демона: lifecycle.log, delivery.log, exits.log
@@ -53,7 +54,7 @@
 Несколько узлов стоит выделить:
 
 - **`peers-profiles.json`** — реестр. Пишется только через единственного писателя под файловой блокировкой `peers-profiles.lock`; прямое редактирование запрещено на уровне ядра.
-- **`state/iapeer/`** — здесь живёт демон: его локальный сокет `router.sock` и конфигурация `router.json`.
+- **`state/iapeer/`** — здесь живёт демон: его локальный сокет `router.sock`, конфигурация `router.json` и inbox-каталоги `attachments/<получатель>/<sha256>/<имя-файла>`. Inbox — долгоживущее состояние получателя, а не кэш; удаление пира очищает его inbox.
 - **`logs/<имя>/`** — журналы инфраструктурных пиров кладутся по имени пира на общем уровне (а не в папке пира), потому что это вывод службы под launchd.
 - **`runtimes/<рантайм>/`** — двойное владение: корень принадлежит самому рантайму (Telegram держит здесь токены ботов, состояние опроса), а подпапка `plugins/<плагин>/` — это пространство плагинов, где лежит их конфиг под этим рантаймом.
 - **`docs/<пакет>/`** — справочные доки на хосте, по одной папке на каждый пакет экосистемы (см. ниже).

package/docs/ru/07-/321/203/321/201/321/202/320/260/320/275/320/276/320/262/320/272/320/260-/320/270-/320/276/320/261/320/275/320/276/320/262/320/273/320/265/320/275/320/270/320/265.md

@@ -60,7 +60,7 @@ iapeer status
 **Три пункта на тебе (автоматизировать нельзя):**
 
 1. **Залогинься в рантаймы — ДО onboard.** Войди в Claude Code и Codex заранее. Их экран логина — браузерный OAuth, который headless-пир не пройдёт, поэтому iapeer НАМЕРЕННО его не авто-отвечает; установленный, но не залогиненный рантайм роняет первый wake пира громко. `iapeer onboard` предупреждает, если найдёт неаутентифицированный рантайм.
-2. **Пароль логин-связки — один раз, при install.** Install подписывает бинарь стабильной локальной идентичностью, чтобы Full Disk Access пережил обновления; macOS один раз спросит пароль логин-связки при создании этой идентичности. Это ожидаемо (инсталлер анонсирует). При отказе бинарь всё равно работает — просто TCC-промпты будут повторяться на апдейтах.
+2. **Пароль логин-связки — один раз, при install.** Install подписывает временный бинарь стабильной локальной идентичностью, чтобы Full Disk Access пережил обновления; macOS один раз спросит пароль логин-связки при создании этой идентичности. Это ожидаемо (инсталлер анонсирует). При отказе возможна проверенная ad-hoc-подпись (TCC-промпты могут повторяться). Проверка валидности обязательна: неисправимая сборка прерывает установку до замены установленного бинаря.
 3. **Full Disk Access — ручной грант, без промпта.** macOS TCC нельзя выставить ни флагом, ни env, ни скриптом. Без него пир, читающий/пишущий TCC-защищённый путь (iCloud Obsidian vault, Desktop, Documents, Downloads), тихо падает с EPERM — без промпта, без зависания. Выдай в **System Settings → Privacy & Security → Full Disk Access** (`~/.iapeer` сам под `$HOME` и ничего не требует); onboard напомнит.
 
 Gatekeeper не гейтит локально собранный CLI, запускаемый из терминала (нет quarantine-атрибута). Проверено живьём на по-настоящему виргин-конфиге Claude (claude 2.1.183): theme-picker, folder-trust, принятие bypass-permissions (курсор шагнут на «Yes») и аппрув проектных MCP-серверов авто-снимаются по очереди, пир доходит до строки ввода, а повторный запуск на том же конфиге — уже без диалогов; codex folder-trust / update — аналогично (clean-install владельца + изолированный first-boot тест).
@@ -78,7 +78,7 @@ iapeer update --force           # переустановить, даже есл
 
 **1. Ядро (фундамент)** — и оно ПРЕРЫВАЕТ каскад при жёсткой ошибке (не обновлять рантаймы на сломанное ядро):
 
-1. Узнаёт нужную версию из npm. Если установленная уже совпадает и нет `--force` — ничего не делает.
+1. Узнаёт нужную версию из npm. Если установленная уже совпадает и нет `--force`, проверяет подпись установленного бинарника без переподписания; валидный демон с актуальной версией не требует рестарта. Невалидный бинарник отклоняется, в том числе до восстановления демона со старой версией.
 2. Скачивает и собирает новый бинарь через `npm pack`, а не `npx` (бинарь не пересобирает себя сам).
 3. Перезапускает демон на новый бинарь.
 4. Перезапускает launchd-джобы инфраструктуры, которыми владеет ядро (`com.iapeer.*` — роутеры `timer`, `watcher`, Telegram), переводя их на заменённый бинарь. Перезапускаются именно ДЖОБЫ, а не пакетный код рантаймов — это следующий шаг. Если демон на шаге 3 не поднялся, шаг пропускается.
@@ -90,7 +90,7 @@ iapeer update --force           # переустановить, даже есл
 
 Рантаймы и память — **best-effort**: ошибка компонента сообщается, остальные всё равно отрабатывают; код возврата ненулевой, если что-то упало. Агентские пиры (Claude/Codex) подхватывают новую доктрину ядра лениво на следующем пробуждении.
 
-`iapeer update --foundation-only` делает только шаг 1 (узкий случай). Запиненный `iapeer update <версия>` — **только ядро** by design: пин версии специфичен для ядра (откат глубже одного шага или фиксация проверенной версии).
+`iapeer update --foundation-only` выполняет только foundation-плечо, включая перерегистрацию инфраструктурных jobs при изменении бинарника/демона: сужается обновление пакетов, а не область рестартов процессов. Запиненный `iapeer update <версия>` имеет ту же область **только ядро**: пин версии специфичен для ядра (откат глубже одного шага или фиксация проверенной версии).
 
 > **Обновление с версии до каскада (< 0.4.2).** Каскад исполняет *установленный* бинарь, поэтому самый первый `iapeer update` со старой версии работает по СТАРОЙ (foundation-only) логике: он поднимает ядро до каскад-способного бинаря, но рантаймы + память пока не каскадит. Запусти `iapeer update` ещё раз — теперь новый бинарь докаскадит остальное. Это разовый bootstrap; начиная с 0.4.2 — одна команда. (Свежая установка сразу ставит каскад-способный бинарь, поэтому двойной прогон ей не нужен.)
 

package/docs/ru/10-/320/276/320/261/320/274/320/265/320/275-/321/201/320/276/320/276/320/261/321/211/320/265/320/275/320/270/321/217/320/274/320/270.md

@@ -23,6 +23,18 @@ iapeer send assistant --message "..." --topic "релиз" --from claude-reviewe
 
 Флаг `--from` задаёт отправителя (`<рантайм>-<имя>`); по умолчанию — идентичность пира текущей папки. `--attachment` повторяемый. `--message-file` с телом из файла или stdin удобен для длинных и многострочных сообщений.
 
+## Владение вложениями
+
+Аргумент вложения — **путь источника**, а не доставленный путь. До сборки конверта `routeSend` открывает каждый источник как обычный файл и копирует его байты в foundation-owned inbox целевого пира:
+
+```text
+~/.iapeer/state/iapeer/attachments/<получатель>/<sha256>/<имя-файла>
+```
+
+В конверт попадают абсолютные пути этих копий. Поэтому исход `ok`/`delivered`/`queued` одновременно значит, что каждое вложение уже имеет читаемую копию получателя; отправитель может сразу удалить или переименовать исходник. Отсутствующий, нечитаемый или необычный файл валит отправку до доставки. Пересылка inbox-файла третьему пиру создаёт отдельную копию в inbox третьего пира.
+
+Копия — состояние получателя, а не кэш: по возрасту не удаляется и живёт столько же, сколько пир-получатель. `iapeer remove <получатель>` удаляет весь inbox. Удаление отправителя, очистка `/tmp`, рестарт демона, дренаж ephemeral-очереди и ротация истории моста её не удаляют.
+
 ## Путь доставки
 
 Демон находит получателя в реестре и сначала выбирает поверхность доставки. Без явного `runtime` это всегда `default_runtime` адресата; живость других объявленных рантаймов выбор не меняет. Явный `runtime` выбирает ровно указанную поверхность. Затем демон смотрит на состояние выбранной поверхности:

package/docs/ru/12-cli-reference.md

@@ -61,7 +61,7 @@
 | `send <цель> (--message <текст> \| --message-file <f\|->) [--from <id>] [--runtime <r>] [--attachment <путь>]… [--topic <t>]` | Ручная отправка IAP по тому же пути, что `send_to_peer`. |
 | `confirm-send <id> [--runtime <rt>]` | Доставить удержанную отправку ([origin guard](18-origin-guard.md)): как адресована, либо `--runtime` перенаправляет её в канал-источник. Без повторной отправки текста. |
 
-`--message-file -` читает тело из stdin. `--attachment` повторяемый. `--from` по умолчанию — идентичность пира текущей папки.
+`--message-file -` читает тело из stdin. `--attachment` повторяемый и задаёт абсолютный путь файла-источника; до принятия отправки роутер копирует его в состояние получателя. `--from` по умолчанию — идентичность пира текущей папки.
 
 ## Запуск и рантаймы
 

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

@@ -13,6 +13,7 @@
 - **Единственный писатель реестра.** `peers-profiles.json` пишется только через одного писателя под файловой блокировкой. Прямая запись файла запрещена на уровне ядра — это исключает гонки.
 - **Живость определяется live-сессией пира.** Пир жив тогда и только тогда, когда у него есть живая сессия под супервизором. Это не отдельный флаг в состоянии, который можно рассинхронизировать, а наблюдаемый факт.
 - **`доставлено` ⟺ легло в живую сессию.** Успех доставки означает, что сообщение принято живой сессией (демон дождался подтверждения). Не подтвердила — демон считает сессию мёртвой, а не лжёт об успехе.
+- **Вложения копируются до маршрутизации.** Пути вызывающего — только источники. Прежде чем конверт может быть принят как delivered или queued, `routeSend` копирует каждое вложение в принадлежащий foundation inbox целевого пира и вкладывает в конверт уже пути копий. Последующие удаление, переименование или очистка исходника не ломают полученное вложение. Копии живут столько же, сколько пир-получатель; `iapeer remove <пир>` удаляет его inbox.
 - **Источник истины — локальный профиль.** Реестр — пересобираемая проекция профилей пиров. При расхождении прав профиль.
 - **Бинарь установлен на хост.** Демон работает с установленного `~/.local/bin/iapeer`, а не из рабочего дерева исходников. Обновление — это замена бинаря и перезапуск демона на него.
 
@@ -82,6 +83,51 @@
 - **`install-runtime <рантайм>`** определяет npm-пакет (по встроенному реестру или флагу `--package`), ставит его через `npx`, затем разворачивает объявленный набор пиров.
 - **`update-runtime <рантайм>`** сверяет версию манифеста с npm; при отставании переустанавливает, заново провизионирует и перезапускает пиров рантайма штатными `stop`/`start`.
 
+### Подпись исполняемого файла до активации (macOS)
+
+Успешная компиляция Bun или копирование исполняемого файла не гарантирует валидную
+Mach-O-подпись. Пакет проверяет её на **каждом** пути self-install (compile и
+copy-self), включая прямую установку через `npx` вне ядра:
+
+1. Собрать/скопировать файл во временный соседний файл, установить права исполнения.
+2. Выполнить `/usr/bin/codesign --verify --deep --strict <tmp>`. Валидную подпись
+   сохранить без изменений, включая сертификатную подпись для стабильных TCC-грантов.
+3. Для невалидного/неподписанного **артефакта сборки, принадлежащего установщику**
+   выполнить `/usr/bin/codesign --force --sign - <tmp>` и повторить строгую проверку.
+4. Только после успешной проверки атомарно заменить установленный бинарь и записать
+   новый манифест. При ошибке удалить временный файл, завершиться ненулевым кодом и
+   оставить прежние бинарь и манифест неизменными.
+
+Необязательный лёгкий helper `ensureExecutableSignature` экспортирован из
+`@agfpd/iapeer/install-signature`; пакет может реализовать тот же контракт локально.
+Он бросает исключение при неуспехе проверки/исправления, пропускает скриптовые лаунчеры с shebang
+и хосты вне macOS, поддерживает внедряемый runner для герметичных тестов. Исправление
+предназначено для доверенных артефактов установщика, **не** для проверки подлинности
+или легитимации произвольно изменённого установленного кода. Стабильная сертификатная
+подпись для TCC — отдельный вопрос; валидность подписи проверяется fail-closed даже
+при мягком отказе стабильного подписания.
+
+Ядро дополнительно проверяет установленные лаунчеры рантайма перед провижном или
+рестартом, включая ветки уже установленного пакета и актуальной версии. Вторичный
+гейт только проверяет: он сообщает о невалидной подписи, не переподписывая живые
+бинарники. Он не заменяет проверку пакетом до rename: launchd может открыть бинарь
+сразу после его публикации установщиком.
+
+Установка и откат ядра применяют тот же гейт к staged-файлу до замены бинаря.
+Стабильное подписывание локальным сертификатом выполняется на временном inode;
+его отказ допускает переход к проверенной ad-hoc-подписи, но неисправимый файл
+никогда не активируется. Исправление произвольно дефектного вывода Bun не
+гарантируется: ошибка строгой валидации безопасно прерывает установку и требует
+рабочей сборки. Оркестратор update также проверяет установленный бинарник ядра без
+переподписания перед активацией демона, включая восстановление старого демона при
+совпадающей версии бинарника.
+
+Поставляемый `scripts/proof-install-signature.ts` проверяет штатный CLI-установщик
+самого пакета и настоящий codesign в одноразовых каталогах (нужна существующая локальная
+подписывающая идентичность). Он покрывает отказ и сохранение состояния, вторичные гейты
+рантаймов и rollback. Lifecycle-вызовы update заменены изолированными зависимостями:
+проверка не перезапускает демон хоста и не является приёмкой здоровья после выкатки.
+
 ## Стандарт capability-плагина
 
 Capability-плагин добавляет пиру способность, не будучи рантаймом. Отличие чёткое: рантайм — способ присутствия пира, плагин — способность поверх рантайма.

package/docs/ru/15-fleet-api.md

@@ -133,10 +133,10 @@ GET /fleet/v1/events?replay=50
 `POST /fleet/v1/send` — доставить сообщение тем же маршрутом, что инструмент `send_to_peer` (wake-on-miss, очереди, delivery-лог — семантика идентична):
 
 ```json
-{ "personality": "boris", "message": "…", "runtime": "claude", "topic": "…", "from": "nova" }
+{ "personality": "boris", "message": "…", "runtime": "claude", "topic": "…", "attachments": ["/tmp/report.pdf"], "from": "nova" }
 ```
 
-`from` опционален: полный `<runtime>-<personality>` или голая personality (её default-рантайм). По умолчанию — **единственный natural-intelligence пир** реестра: сообщение из GUI принадлежит человеку. При нуле или нескольких natural-пирах запрос отклоняется (`400`) с указанием передать `from`.
+`from` опционален: полный `<runtime>-<personality>` или голая personality (её default-рантайм). По умолчанию — **единственный natural-intelligence пир** реестра: сообщение из GUI принадлежит человеку. При нуле или нескольких natural-пирах запрос отклоняется (`400`) с указанием передать `from`. `attachments`, если передан, — тот же массив абсолютных путей источников, что и у MCP-инструмента; общий путь `routeSend` копирует их в inbox получателя до принятия.
 
 Не входит в *командный* API, намеренно: **attach** (передача терминала — клиент открывает системный терминал с `iapeer attach <peer>`), реестровые/хостовые **admin-verb'ы** (`create`/`remove`/`update`/`uninstall` — добавятся, когда появится клиент с реальной потребностью). **Брокер human-approval** теперь живёт под `/fleet/v1/approvals*` (`GET` очередь / один item, `POST /<id>/(approve|deny)`) с видами SSE `approval-request` / `approval-resolved` и полем `approvals` в снапшоте выше — полный контракт в **docs/17-approval**.
 

package/docs/ru/18-origin-guard.md

@@ -30,7 +30,7 @@ verbatim as og-1a2b3c4d (expires in 15 min).
 Do not re-send the message text — confirm-send delivers the held message.
 ```
 
-Оба выхода стоят одну shell-команду и **ноль регенерации сообщения**: удержанная отправка несёт полный исходный ввод (текст, топик, вложения).
+Оба выхода стоят одну shell-команду и **ноль регенерации сообщения**: удержанная отправка несёт исходные текст/топик/рантайм и принадлежащие получателю копии каждого вложения. Копирование идёт до сохранения hold, поэтому удаление временных исходников в 15-минутном окне решения не ломает `confirm-send`.
 
 ```bash
 iapeer confirm-send og-1a2b3c4d                 # доставить как адресовано (кросс-канал намеренный)
@@ -48,7 +48,7 @@ iapeer confirm-send og-1a2b3c4d --runtime web   # доставить то же
 ```text
 ~/.iapeer/state/iapeer/origin/
   state.json          # (агент → человек → {rt, inboundTs, answeredTs}) — last-wins, атомарные записи
-  pending/<id>.json   # удержанные отправки, дословно; ленивый GC после TTL
+  pending/<id>.json   # удержанные отправки; вложения уже указывают на копии inbox
 ```
 
 ## Границы и невмешательство

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agfpd/iapeer",
-  "version": "0.4.109",
+  "version": "0.4.111",
   "description": "Run Claude Code and Codex CLI as local background agents that message each other, wake on demand, and share one memory.",
   "license": "Apache-2.0",
   "author": "agfpd",
@@ -34,6 +34,7 @@
     "src",
     "bin",
     "docs",
+    "scripts/proof-install-signature.ts",
     "CHANGELOG.md",
     "tsconfig.json",
     "!src/**/*.test.ts",
@@ -45,7 +46,8 @@
     "./storage": "./src/storage/index.ts",
     "./identity": "./src/identity/index.ts",
     "./registry": "./src/registry/index.ts",
-    "./codec": "./src/codec/index.ts"
+    "./codec": "./src/codec/index.ts",
+    "./install-signature": "./src/install/signature.ts"
   },
   "scripts": {
     "test": "IAPEER_TEST_SANDBOX=1 bun test",