WEB board

P1 МИГРАЦИЯ: переезд мессенджер/звонкового стека Pi→Oracle — киллер-фича не переживёт выключение Малинки

## Суть одной фразой
P1-миграция: переезд мессенджер/звонкового стека Pi→Oracle (A1), чтобы киллер-фича пережила выключение Малинки.

## Где мы сейчас (13.09.2026)
Веб-прод и телефония мигрированы на A1 (посадки 01.09), репо-пакет телефонии/мессенджеров принят и лежит в l113d (5a750755, приёмка 2178 = GO: 14 provider-facing юнитов, admission-исполняемый, install closure 8/8, RUNBOOK). Прод сейчас = l115j (133fe00c, 13.09 08:50Z). НЕ перенесено: мессенджер-боты (TG/Signal) — ждут холодного cutover в окне владельца; DNS-зона wool2.online (ns1/ns2 = 86.45.55.126) по-прежнему на Малинке; certbot-renewal на A1 и полная батарея на A1-проде не подтверждены.

## План холодного cutover готов (волна 3663, 13.09)
Подготовлен CUTOVER-PLAN.md (пошаговый, фазы 0–6) + OWNER-STEPS.md (детским языком). Порядок строгий:
1. Согласовать окно (UTC) + выбор Telegram-аккаунта worker identity; владелец готов ввести код/2FA (Telethon) и SMS/captcha (Signal) НА A1.
2. Freeze/drain: Pi stop + disable/mask всех целевых юнитов (daemon, Asterisk/SIP на Pi) → live readback Pi=OFF (реальные внешние пробы, не самопроверка) → revoke Pi lease.
3. A1 prepare без старта: установить пакет 5a750755 по RUNBOOK (14 юнитов, admission); ship-dark предзагрузка данных (9.8G telegram-call-native, 2.8G gptbot, 300M bookbot, signal-shim, бинари) на A1 и в сейф заранее.
4. Lease-предусловия до старта: ACTIVE_PASSIVE_COPY_ID задан (oracle), copy id pi≠oracle (дефекты WEB-405 №1/№2).
5. Владелец вводит код/SMS: Telegram fresh StringSession на A1 / Signal register на A1 (номер +353857367035). Singleton-регистрации НЕ копируются — пересоздаются.
6. A1 lease grant → daemon/audio/readiness (null-sink, UID 1001) → Signal adapters → Telegram worker → route/callback switch (sixbyy) → canary → observation (≥ 1 час без ошибок).
7. Откат — зеркальный, за ≤ 2 мин (revoke A1 lease → stop/mask A1 → Pi grant → Pi start → readback Pi=ON).
8. Увод DNS-зоны wool2.online с Малинки на Cloudflare (ns1/ns2 → CF NS) после подтверждения, что прод-зависимостей от Pi нет. Малинка держит bind только для своих хостов.

Правило единственности: ни один provider-facing процесс A1 не стартует, пока Pi не прошёл readback OFF.

## Критерий закрытия
TG и Signal боты работают на A1 (Pi readback OFF, A1 lease активен); контрольное сообщение/звонок прошло; DNS-зона wool2.online обслуживается Cloudflare (dig NS отдаёт CF), Малинка держит bind только для своих хостов; certbot-renewal на A1 и полная батарея на A1-проде подтверждены выводом с цифрами. Только тогда карточку закрыть.

---

## История (старый текст, сохранён ниже)

---

## история (тело до 13.09.2026)

## Суть одной фразой
P1-миграция: переезд мессенджер/звонкового стека Pi→Oracle (A1), чтобы киллер-фича пережила выключение Малинки.

## Где мы сейчас (13.09.2026)
Веб-прод и телефония мигрированы на A1 (посадки 01.09), репо-пакет телефонии/мессенджеров принят и лежит в l113d. Прод сейчас = l115j (133fe00c, 13.09 08:50Z). НЕ перенесено: мессенджер-боты (TG/Signal) — ждут холодного cutover в окне владельца; DNS-зона wool2.online (ns1/ns2) по-прежнему на Малинке; certbot-renewal на A1 и полная батарея на A1-проде не подтверждены.

## Хронология
- 01.09: веб-прод переехал на A1 (PG15.4→PG16, логическая репликация 195/195, флип 07:11Z, 8.8.8.8 отдаёт A1). Телефония переключена на A1 (11:10Z), сквозной синтетический звонок sipp+RTP доказал тракт (INVITE→200 OK, SDP c=129.213.25.105, RTP 495 пакетов в обе стороны).
- 02.09: контрольный звонок владельца на 8000 прошёл после снятия пробросов sip-main/sip-rtp на роутере.
- 06.09: репо-пакет A1-02…A1-08 (волны 2125/2126/2127) → приёмка 2141 NO-GO → 2151 → приёмка 2178 = GO (5a750755: 14 provider-facing юнитов, admission-исполняемый, install closure 8/8, RUNBOOK). Кандидат l113d (репо-часть).
- 12.09 (мойка 3567): веб+телефония на A1, пакет в l113d; остаток — cutover мессенджеров и увод DNS.
- 13.09: прод l115j.

## Карта документов и кода
- План холодного cutover: TGSIGNALCUTOVERPLAN-REPORT.md (волна 2118, VERDICT=PLAN; раздел 9 — шаблон сообщения владельцу).
- Бандлы пакета: TGWORKERA1.bundle (2125), SIGNALA1.bundle (2126), LEASEADMISSION.bundle (2127); приёмки ACCTELEPHONYA1PKG-REPORT.md (2141 NO-GO), ACCTELEPHONYPKG2 (2178 GO).
- Хостовой RUNBOOK — в принятом пакете 5a750755.
- Доказательства телефонии 01.09: /home/ubuntu/waves/evidence/lane8000-call-*.log; DNS-зона /var/cache/bind/db.wool2.online (dynamic, freeze→edit→thaw).

## Остаток (ответственный)
1. Хостовой cold-cutover мессенджеров: TG fresh StringSession + Signal регистрация на A1 в окне владельца (владелец вводит код/SMS); правило единственности — ни один provider-facing процесс A1 не стартует, пока Pi не прошёл readback OFF (координатор + владелец).
2. Увод DNS-зоны wool2.online с Малинки (ns1/ns2) — Cloudflare (координатор).
3. certbot-renewal на A1 + полная батарея на A1-проде — подтвердить цифрами (координатор).
4. Полный физический перенос стека (arm64-артефакты WEB-401, SIP UDP-порты в OCI) — отдельный шаг (координатор).

## Критерий закрытия
Владелец выполнил TG/Signal релогин на A1, A1-lease предоставлен, Pi-процессы readback OFF; DNS-зона уведена с Малинки; certbot-renewal и батарея на A1 подтверждены выводом с цифрами. Только тогда карточку закрыть.

---

## История (старый текст, сохранён ниже)

## 2026-08-31 19:15Z — ступень K11: приёмка ПРИНЯТО: НЕТ, корректирующий круг K12 в полёте
Авторская K11 (ветка wave/web370k11, HEAD 3463b3e6, коммит приёмочного harness 9a1f4bee): pnpm test:web370-k11 28/28, независимый harness 7/7.
Приёмка accweb370k11b (луна, после срезанной фильтром sol-попытки) дала **принято: нет** — три находки:
1. crash/restart исполнителя даёт 18 мутаций вместо одной (повторный вход не идемпотентен);
2. неполный readback подписывается как SAFE_OFF (мусор читается как валидное);
3. TOCTOU-подмена pinned-исполняемого между проверкой sha256 и исполнением.
→ Круг **web370k12** (бриф 1011, база = HEAD автора K11) запущен 19:07Z на A1: идемпотентность через долговечный журнал/фенсинг, readback-обрыв = отказ, исполнение проверенного содержимого (fd), негативные тесты на все три класса.
Эволюция: K1..K10 приняты ранее → K11 автор ✅ / приёмка ❌ → K12 в полёте.

## 2026-08-31 20:30Z — K12 автор сдал: три блокера K11 закрыты
web370k12 (HEAD e9147dda): 18-мутаций-при-restart / readback=SAFE_OFF / TOCTOU воспроизведены на K11 и закрыты. → Приёмка **accweb370k12** (бриф 1028: свой harness на все три контрпримера + новые классы — одновременный двойной запуск, повреждённый журнал, часы назад).

## 2026-08-31 21:00Z — accweb370k12: ПРИНЯТО НЕТ (одна находка) → K13
Takeover после SIGKILL не завершает durable execution: мутация не дублируется (это ✅), но свежая readback-квитанция отвергается из-за расхождения fencing token 1↔2 → CONTAINMENT_INCOMPLETE вместо SAFE_OFF. Остальные новые границы (двойной запуск, битый журнал) fail-closed. → **web370k13** (бриф 1036): квитанции takeover-а валидны под ЕГО токеном, старый токен не принимается за свежий, итог SAFE_OFF. Эволюция: K11 автор ✅/приёмка ❌(3) → K12 закрыл 3/приёмка ❌(1) → K13.

## 2026-08-31 22:35Z — accweb370k13: ПРИНЯТО ✅ кандидат l81 — K-СЕРИЯ ЗАКРЫТА
Независимый process/fault/concurrency harness: kill в разных точках → одна мутация + SAFE_OFF; старый токен отвергается; двойной takeover — один победитель; битый журнал — отказ. Эволюция ступени: K11 (3 дыры) → K12 (закрыл, 1 новая) → K13 (закрыл) → приёмка ✅. Лестница миграции движка доказана до конца.

## 2026-08-31 23:00Z — 🚀 GO owner-а на миграцию: ЭТАП 1 РАЗВЁРНУТ
Owner 22:34Z: «А1 → полноценный прод энтерпрайз-уровня, Малинка → дев. Приступайте».
**A1-нода поднята и зелёная**: сервис nc-a1 (l80 d01218a2, тот же артефакт b640cc4f), enforce-обёртка+аттестация, свой nc-fence-pi (порт 35083, клонирован с Pi с секретами flip-cap/flip-cron), туннельный юнит pi-tunnel (pg 15432→Pi:55432, redis 16379→Pi:6379, autorestart), Redis на Pi (loopback), MULTINODE_ENABLED=1+REDIS_URL, ACTIVE_PASSIVE_COPY_ID=a1. **paid TRUE enforce_ready на A1 против ОБЩЕЙ прод-базы**; lease web370-runtime держит pi → A1 корректно ПАССИВЕН (side-effect-ы не задвоены). Pi-прод не тронут, зелёный.
Дальше: этап 2 (нагрузка/синк-пробы), этап 3 (телефония по K-лестнице), этап 4 (nginx+TLS на A1, 80/443 в UFW по плану аудита, DNS-флип Cloudflare, Pi→dev). Ключ A1→Pi: ~/.ssh/a1-to-pi (добавлен в Pi authorized_keys), egress 2046/tcp открыт.

## 2026-08-31 22:50Z — acctel2return: ПРИНЯТО ✅ кандидат l81 (mock-часть линии возврата)
Единый missed/identity контракт, жатва return_ttl_expired, идемпотентность после аварии — подтверждены независимо. Оговорка приёмки: production-ready станет после прод-стыка (Asterisk h-hook сейчас NoOp) — это этап 3 миграции, за координатором (WEB-401).

## 2026-08-31 23:10Z — этап 4 ПОДГОТОВЛЕН (флип домена = 3 команды)
- TLS: сертификат nb.wool2.online скопирован Pi→A1 (валиден до 24.11) + options-ssl/dhparams; certbot+dns-cloudflare стоит на A1, но CF-токен видит только ecowool/sixbyy — **DNS зоны wool2.online самохостится BIND-ом НА МАЛИНКЕ** (ns1/ns2 = 86.45.55.126).
- nginx на A1: конфиг клонирован с Pi (+log_format masked_query в nginx.conf), nginx -t OK, сервис ВЫКЛЮЧЕН до флипа (80/443 в UFW закрыты).
- **TTL nb-записи снижен 86400→300** в живой зоне (/var/cache/bind/db.wool2.online — динамическая: порядок строго freeze→edit→thaw; /etc/bind/db.wool2.online — СТАРАЯ копия, не она; serial 2026053141). К завтра кэши сойдутся.
- ФЛИП: (1) A1: ufw allow 80,443 + systemctl enable --now nginx; (2) Pi BIND: freeze→nb A→129.213.25.105→thaw; (3) проверка; ОТКАТ = обратная правка, действует за ≤5 мин.
- ⚠️ ВОПРОС owner-у перед переводом Pi в дев: ns1/ns2 всей зоны wool2.online живут на Малинке — надо увести DNS (вариант: Cloudflare-аккаунт, там уже 2 зоны). Egress 443/tcp на A1 открыт (прод-ноде нужен).

## 2026-09-01 06:30Z — ЭТАП 2 МИГРАЦИИ: перенос базы НАЧАТ (без даунтайма)
Гэп-статус отправлен owner-у (он ждал «всё готово» — честно объяснено, что этап 1/4). Факты: Pi-база = PG **15.4** docker (pgvector 0.5.1, 2.6ГБ), A1 = PG 16 → физическая реплика невозможна, выбрана **логическая репликация с апгрейдом до PG16/pgvector 0.6**. Сделано: кластер 16/noteclone на A1:55432 (data-checksums; ловушка: pg_createcluster требует LANG/LC_ALL=C.UTF-8 в env sudo); роль+БД+расширения; пробный дамп через туннель 7м52с/1.03ГБ (мера канала: ~2.2МБ/с uplink Малинки); wal_level=logical на Pi (рестарт контейнера 12с, paid TRUE вернулся); PUBLICATION nc_move (all tables); схема restored (195 таблиц; pg_restore 4 ошибки — проверить, вероятно extension-комменты); GRANT pg_create_subscription; SUBSCRIPTION nc_move_sub (copy_data) — **начальный снапшот идёт** (мониторится фоном).
Окно переключения после синка: stop Pi-app → lag=0 → setval всех sequences (логическая репликация их НЕ переносит!) → nc-a1 на локальную БД → nginx+UFW+DNS-флип. Ожидаемый даунтайм ≤2 мин.

## 2026-09-01 07:35Z — 🚀🚀 ПРОД ПЕРЕЕХАЛ НА A1 (веб-часть миграции ЗАВЕРШЕНА)
Хронология: sync 195/195 (последняя таблица SpendActionReplayReceipt билась в цикле — schema-restore не донёс функции canonical_spend_replay_json/spend_replay_response_hash, а после доноса воркер репликации падал на урезанном search_path; лечение: пересоздание функции со СХЕМНО-КВАЛИФИЦИРОВАННЫМ вызовом public.*) → сверка счётчиков 1-в-1 (Source/Note/User/TSE/SARR/MessageLog) → ОКНО 07:11:02Z: stop Pi-app → sequences(1) → SUBSCRIPTION DISABLE → nc-a1 на локальную 55432 + Redis 6379 → paid TRUE → UFW 80/443 + nginx → BIND nb→129.213.25.105 (гейт на точную форму записи) → 8.8.8.8 отдаёт A1, HTTPS 200. Хвост DNS-кэша: Pi-nginx nb-vhost проксирует на A1 (proxy_ssl_server_name; бэкап конфига .bak-preflip-proxy). Даунтайм ~4 мин. Таймер индексации nc-a1-indexing (2 мин) создан. Lease web370-runtime берётся по требованию — заберётся первым вебхуком. tg-скрипты координатора переключены на A1-базу.
**Малинка = ДЕВ** (note-clone-3010 остановлен; book/blw/почта/DNS-зона нетронуты). ОСТАЛОСЬ: телефония (Asterisk на Pi, отдельный эпик), увод DNS-зоны с Малинки, certbot-renewal на A1, полная батарея на A1-проде.

## 2026-09-01 07:30Z — пост-флип находка №1: голосовые (ПОЧИНЕНО за 7 минут)
Симптом: voice transcription «временный сбой». Корень: nc-fence-pi клонирован с Pi вместе с FENCE_ALLOWED_UID=1000 (uid pi), а на A1 приложение под ubuntu uid=1001 → 403 uid_not_allowed на платном egress. Фикс: FENCE_ALLOWED_UID=1001 + restart. Урок в чек-лист переезда: у клонированных стражей сверять ВСЕ машинно-зависимые привязки (uid/gid/пути/интерфейсы). Второй сигнал из того же лога: admin_defaults_missing_config (messaging/voice/arcade) — существовал и до переезда, отдельная линия.

## 01.09 09:15Z — телефония подключена к A1-проду (Fable)
Стек остаётся на Pi физически (SIP/железо), но переведён на прод-ресурсы A1: a1-db-tunnel.service (Pi:25432→A1:55432, ключ restrict/port-forwarding), telegram-call-native drop-in prod-db.conf (+prod-a1.env: DATABASE_URL prod, TELEGRAM_CALL_ADAPTER_BASE_URL=https://nb.wool2.online), ag-voice/.env.local DATABASE_URL→25432, drop-in prod-a1.conf обоим SIP-юнитам (APP_URL и SIP_EXPERIMENTAL_LIVE_APP_BASE_URL вшиты в unit → drop-in переопределяет). Ловушка: пароль дев-базы ≠ прод-базы (Authentication failed) — URL собирать с паролем A1. Все 3 службы active, 0 ошибок, auth-проба через туннель прошла (MessageLog 6527). Живой звонок запрошен у owner. Полный физический перенос стека на A1 (arm64-артефакты WEB-401, SIP UDP-порты в OCI) — отдельный шаг.
Бэкапы: первый base-снимок hetzbk-prod-a1 закоммичен, ретенция KEEP=5 отработала; корни падений wal-stream: нет .gnupg + нет known_hosts (strict) — оба закрыты.
Owner утвердил следующий этап: реплика БД на A2 + авто-переключение трафика («Да заложи», 09:07Z).

## 01.09 09:35Z — телефония: origin-лок и вернувшийся дев-апп (Fable)
Живой звонок owner-а: 8010 reject / 8011 IVR. Два корня: (1) s2s гейтвея на https://nb.wool2.online режется origin-локом (/sessions/start 403 origin_boundary_rejected) — на Pi он ходил с loopback; (2) мой restart telegram-call-native ПОДНЯЛ обратно note-clone-3010 (дев-апп на дев-базе) через Wants= в 5 юнитах — disable не убирает зависимость. Лечение: дев-апп остановлен, Wants=note-clone-3010 вычищен из юнитов (бэкапы .bak-preprod-20260901), туннель расширен 127.0.0.1:3010→A1:3010 — ВСЁ на Pi, что зовёт localhost:3010, снова прозрачно попадает в прод (точная дореезжая семантика, Host в APP_ALLOWED_HOSTS, loopback-изъятие origin-лока). Gateway banner: App=http://127.0.0.1:3010, 403/origin в логах 0. Повторный звонок запрошен. Диск A1 почищен 96%→87% (4 битых hetzbk-base по 5G от rc=12-цикла).

## 01.09 10:40Z — директива owner-а: ПОЛНЫЙ перенос телефонии на A1 (Fable)
Owner (voice 09:36Z): прод автономный, дев для экспериментов; малинка умрёт → телефония не должна умереть. Тест 8010 «тишина» разгадан: extension привязан к комнате-пруфу MEETINGROOM-1099 (/home/pi/ag-voice/var/meeting-room-sip-proof.json, PIN 0000), голосовой подсказки «введите ПИН» нет — недоработка. Ассистент = 8000.
Перенос начат: user pi на A1; rsync Pi→A1 (asterisk 159M aarch64-сборка, ag-voice 3.8G, tcn-current 303M) через a1-to-pi (egress 2046 разрешён); CPython 3.11.9 собирается на A1 из исходников (Ubuntu 24.04 несёт только 3.12, venv воркера = cp311; тарбол скачан ЧЕРЕЗ Pi — egress A1 закрыт аллоулистом). Обе машины aarch64, glibc Pi 2.36 < A1 2.39 (forward-compat). Впереди: ldd-донос библиотек asterisk, пересборка venv с копией site-packages, порты SIP/RTP в OCI+UFW (в т.ч. egress!), тень-запуск, DNS sip.wool2.online.

## 01.09 10:55Z — звонок 8000 ПРОШЁЛ; найден пропущенный класс переезда: пути хранилищ (Fable)
- Owner: 8000 отвечает, но «не знает тетради». Корень НЕ привязка (notebook 904b27d8 жив, 92 Source): телефония-роут падал EACCES mkdir /home/pi/note-clone/shared/storage/exports/voice-artifacts — в прод-env уцелели 4 Pi-пути: STORAGE_PATH, MEDIA_STORAGE_DIR, PODCAST_STORAGE_DIR, VIDEO_ASSET_STORAGE_DIR. Ломало НЕ только голос: экспорты/медиа/подкасты/видео-ассеты на A1 не писались с флипа. Пути перепатчены на /home/ubuntu/prod/shared/*, бэкапы .env*.bak-storagepaths-20260901, nc-a1 рестартнут (paid TRUE), данные (2.6G storage + 86M video-assets) едут rsync-ом фоном. В чек-лист переезда: грепать env на СТАРЫЕ АБСОЛЮТНЫЕ ПУТИ, не только hosts/флаги.
- Сопутствующее: /sessions/*/events 422 payload_invalid от воркера (дрейф схемы июльского воркера против l81 API) — отдельная мелкая линия.
- Перенос стека: Asterisk 20.19.0 ЗАПУСКАЕТСЯ на A1 (все 300 модулей ldd-чистые, самодостаточная сборка), venv воркера перевешен на собранный /opt/python3.11 (main import ok, ntgcalls ok). Едут node_modules ag-voice (2G) + /home/pi/web (sync-workdir).

## 01.09 11:10Z — 🚀 ТЕЛЕФОНИЯ ЦЕЛИКОМ НА A1 (Fable) — прод автономен
Переключение выполнено: обе SIP-линии (5060 native + 5074 opus-exp, RTP 10000-10020 и 13200-13300) и telegram-call-native работают НА A1 под ubuntu (fence-uid 1001; фикс «fence одно-uid» решён выбором пользователя, код fence не тронут). Юниты адаптированы (ASTERISK_PREFIX + явный APP_URL drop-in-ом — NEXTAUTH_URL из .env перебивал резолвер: порт 3274). DNS sip.wool2.online → 129.213.25.105 (TTL 300), на Pi socat-хвосты 5060/5074 на сутки кэшей. Pi-стек disable, малинка = чистый дев. Endpoint-sync из прод-базы: 3 эндпоинта. Воркер: Telegram DC ESTAB, локальный base_url.
Ловушки в копилку: find_asterisk ищет в $HOME (User сменился → ASTERISK_PREFIX обязателен); resolve_app_url берёт NEXTAUTH_URL раньше APP_URL; venv Debian-python несёт shared libpython (лечится re-home на свой /opt-python); хранилища: storage/video-assets домигрированы (rc=0).
Открыто по телефонии: голосовая подсказка «введите ПИН» на 8010; 422 payload_invalid lifecycle events (дрейф схемы воркер↔l81); мессенджер-боты (bookbot/gptbot) ещё на Pi — следующий кусок «мессенджеры на A1» (owner: «вся телефония, мессенджеры»).

## 01.09 12:50Z — тишина на 8000 после переезда: NAT-адрес (Fable)
Owner: звонок на 8000 через A1-стек — тишина. Корень: OCI 1:1 NAT — asterisk отдавал в SDP приватный 10.0.0.131 (на Pi спасал домашний роутер). Фикс: SIP_NATIVE_EXTERNAL_SIGNALING/MEDIA_ADDRESS=129.213.25.105 + LOCAL_NETS=10.0.0.0/16,127.0.0.0/8 в drop-in обеих линий; в pjsip.conf отрендерились external_* (5060 и 5074). Обе линии перезапущены, повторный звонок запрошен. В чек-лист переноса SIP: за NAT external-адреса ОБЯЗАТЕЛЬНЫ с первого старта.

## 01.09 14:00Z — «тишина 8000» разгадана трафиком; l82 собран (Fable)
tcpdump на A1 во время пробы: до 11:49 телефон owner-а ВООБЩЕ не ходил на A1 (звонок 11:46 умирал локально в Linphone — регистрации не было). 11:49:40 REGISTER → 401 → 200 OK по UDP:5060 (линия native; provisioning-метадата обещала 5074/tcp — фактический клиент на 5060/udp). Контакт после регистрации выпадает по qualify: OPTIONS от A1 к 86.45.55.126:5060 глотает домашний роутер (проброс всё ещё на Pi) — исходящим звонкам не мешает, входящим будет мешать; рекомендация owner-у снять проброс. Повторный звонок запрошен.
Сборка l82 на A2: PACK_OK, артефакт me2-standalone-linux-arm64-0aa0ac8f-20260901T115035Z (sha 360a4c58c7aff95c392fe7b77e1caa4eed0b2b954d1d84562cd572cde0d32cb2), гейт схемы PASS ×2. Посадка — после подтверждения телефонии, чтобы не смешивать проверки.

## 01.09 14:20Z — телефония A1 доказана сквозным синтетическим звонком (Fable)
Инструменты: sipp (UAC+digest, пароль proof7016 из pjsip-generated auth-7016 — НЕ ag701626290 из DB metadata) + самописный RTP-pusher. Доказано: REGISTER 200; INVITE→200 OK с SDP c=129.213.25.105 m=audio 100xx (external-NAT-фикс РАБОТАЕТ, отдаётся публичный addr+порт из диапазона); RTP двусторонний — отправлено 495 пакетов, получено обратно (приветствие ассистента); gateway: «Call from 7016 to ext 8000 ... status=completed». Тракт A1 исправен и автономен. Остаток owner-side: Linphone не согласует media_encryption=sdes (force_avp+optimistic) ИЛИ шлёт медиа не туда; + старый проброс 5060 на домашнем роутере на Pi. Owner-у дан выбор: настроить SRTP/снять проброс ИЛИ принять как есть (пользователей нет). Recording «too small 44b» на стороне сервера — тишина входящего плеча синтетики (norm, я слал constant 0xff).
l82 готов к посадке (артефакт 0aa0ac8f, sha 360a4c58) — ждёт GO owner-а по TG.

## 01.09 13:30Z — телефония: корень = домашний роутер owner (Fable)
Owner: Linphone работал на Pi и дома, и снаружи → регресс от переезда, не телефон. Захваты на A1: A1 шлёт OPTIONS-qualify на 86.45.55.126:5060, ответа нет; телефон не перерегистрируется напрямую. Корень: домашний роутер owner пробрасывает inbound UDP 5060 → малинка (легаси, когда Pi был SIP-сервером); теперь перехватывает трафик телефона, сигнал/медиа от A1 уходят на мёртвую малинку. Мой Pi socat-relay 5060/5074 УБРАН (усугублял: A1 видел источник=малинка). Owner-у отправлен шаг: удалить проброс 5060 на роутере (id=16074), план Б — сменить локальный SIP-порт телефона. Бэкенд A1 доказан рабочим (sipp+RTP-pusher, звук в обе стороны, external_media/rtp_symmetric/rewrite_contact=yes). Ждёт теста owner.

## ДЛЯ НУЛЕВОГО АГЕНТА (обновлено 2026-09-05 UTC)
- **Суть одной строкой:** P1 МИГРАЦИЯ: переезд мессенджер/звонкового стека Pi→Oracle — киллер-фича не переживёт выключение Малинки
- **Текущее состояние:** статус: parked; 2026-08-31 19:15Z — ступень K11: приёмка ПРИНЯТО: НЕТ, корректирующий круг K12 в полёте | Авторская K11 (ветка wave/web370k11, HEAD 3463b3e6, коммит приёмочного harness 9a1f4bee): pnpm test:web370-k11 28/28, независимый harness 7/7. | Приёмка accweb370k11b (луна, после срезанной фильтром sol-попытки) дала принято: нет — три находки: | Эволюция: K1..K10 приняты ранее → K11 автор ✅ / приёмка ❌ → K12 в полёте. | web370k12 (HEAD e9147dda): 18-мутаций-при-restart / readback=SAFEOFF / TOCTOU воспроизведены на K11 и закрыты. → Приёмка accweb370k12 (бриф 1028: свой harness на все три контрпримера + новые классы — одновременный двойной запуск, повреждённый журнал, часы назад). | 2026-08-31 21:00Z — accweb370k12: ПРИНЯТО НЕТ (одна находка) → K13 | Takeover после SIGKILL не завершает durable execution: мутация не дублируется (это ✅), но свежая readback-квитанция отвергается из-за расхождения fencing token 1↔2 → CONTAINMENTINCOMPLETE вместо SAFEOFF. Остальные новые границы (двойной запуск, битый журнал) fail-closed. → web370k13 (бриф 1036): … | 2026-08-31 22:35Z — accweb370k13: ПРИНЯТО ✅ кандидат l81 — K-СЕРИЯ ЗАКРЫТА
- **Кто работал:**
- 2026-09-02T00:31:30.996Z — Fable — [02.09 00:30Z Фабл] Owner удалил на роутере ASUS проброс sip-main (5060→192.168.1.50); попросил удалить и sip-rtp (10000:10020/UDP→192.168.1.50). Следующий шаг owner — контрольный звонок на 8000 (ассистент с A1).
- 2026-09-02T00:36:55.334Z — Fable — [02.09 00:45Z Фабл] КОНТРОЛЬНЫЙ ЗВОНОК OWNER ПРОШЁЛ после удаления пробросов sip-main/sip-rtp на роутере: регистрация, INVITE, приветствие — через A1. Главный owner-блокер переезда звонков снят. Замечания owner: (1) на в
- 2026-09-02T14:26:54.536Z — Fable — [A1 14:30 Фабл] Ступени: 8000/PIN закрыт живым звонком на l91 (WEB-395 done), шлюз с восстановлением аренды посажен (WEB-476 done), D landing zone (WEB-402 done), L DR (WEB-410 done), C провенанс — рецепт сдан (1225, при
- 2026-09-02T15:02:41.558Z — Fable — [A1 15:06 Фабл] OWNER GO (TG 14:59): «переезд телефонии на живое плечо — делай по разумному, откатиться сможем». План 8000→live (LANE8000-CHECKLIST.md): волна 1246-lane8000v2 (A1) — порт lane8000-1164 (bef003530e; audios
- 2026-09-02T19:34:28.085Z — Fable — [A1 20:15 Фабл — сводка для нулевого агента] Телефония на A1 (l92): 8000 turn-based работает; живое плечо WEB-479 — четвёртый круг на приёмке 1321 (после GO: посадка lane8000-land.sh из кандидата, restart ag-sip-native, 
- 2026-09-05T17:35:28.625Z — fable-coordinator — [2026-09-05 17:40Z] Ревизия доски (волна 2040 boardtriage, M1, luna): статус → parked. Основание: нет активности с 2026-08-29; cutover не готов. Если работа жива — верни статус и напиши в тикет, какая волна её ведёт.
- **Ветки/бандлы/отчёты:** ~/.ssh/a1-to-pi; sha: 3463b3e6, 9a1f4bee, e9147dda, d01218a2, b640cc4f, 2026053141, 20260901, 904b27d8
- **KNOWN ISSUES / ТРАБЛШУТИНГ:**
- 3. TOCTOU-подмена pinned-исполняемого между проверкой sha256 и исполнением.
- → Круг web370k12 (бриф 1011, база = HEAD автора K11) запущен 19:07Z на A1: идемпотентность через долговечный журнал/фенсинг, readback-обрыв = отказ, исполнение проверенного содержимого (fd), негативные тесты на все три класса.
- Takeover после SIGKILL не завершает durable execution: мутация не дублируется (это ✅), но свежая readback-квитанция отвергается из-за расхождения fencing token 1↔2 → CONTAINMENTINCOMPLETE вместо SAFEOFF. Остальные новые границы (двойной запуск, битый журнал) fail-closed. → web370k13 (бриф 1036): …
- - ФЛИП: (1) A1: ufw allow 80,443 + systemctl enable --now nginx; (2) Pi BIND: freeze→nb A→129.213.25.105→thaw; (3) проверка; ОТКАТ = обратная правка, действует за ≤5 мин.
- Гэп-статус отправлен owner-у (он ждал «всё готово» — честно объяснено, что этап 1/4). Факты: Pi-база = PG 15.4 docker (pgvector 0.5.1, 2.6ГБ), A1 = PG 16 → физическая реплика невозможна, выбрана логическая репликация с апгрейдом до PG16/pgvector 0.6. Сделано: кластер 16/noteclone на A1:55432 (dat…
- Хронология: sync 195/195 (последняя таблица SpendActionReplayReceipt билась в цикле — schema-restore не донёс функции canonicalspendreplayjson/spendreplayresponsehash, а после доноса воркер репликации падал на урезанном searchpath; лечение: пересоздание функции со СХЕМНО-КВАЛИФИЦИРОВАННЫМ вызовом…
- Симптом: voice transcription «временный сбой». Корень: nc-fence-pi клонирован с Pi вместе с FENCEALLOWEDUID=1000 (uid pi), а на A1 приложение под ubuntu uid=1001 → 403 uidnotallowed на платном egress. Фикс: FENCEALLOWEDUID=1001 + restart. Урок в чек-лист переезда: у клонированных стражей сверять …
- Стек остаётся на Pi физически (SIP/железо), но переведён на прод-ресурсы A1: a1-db-tunnel.service (Pi:25432→A1:55432, ключ restrict/port-forwarding), telegram-call-native drop-in prod-db.conf (+prod-a1.env: DATABASEURL prod, TELEGRAMCALLADAPTERBASEURL=https://nb.wool2.online), ag-voice/.env.local…
- **Эволюция:**
- 2026-09-02 → [02.09 00:30Z Фабл] Owner удалил на роутере ASUS проброс sip-main (5060→192.168.1.50); попросил удалить и sip-rtp (10000:10020/UDP→192.168.1.50). Следующий шаг owner — контрольный звонок на 8000 (ассистент с A1).
- 2026-09-02 → [02.09 00:45Z Фабл] КОНТРОЛЬНЫЙ ЗВОНОК OWNER ПРОШЁЛ после удаления пробросов sip-main/sip-rtp на роутере: регистрация, INVITE, приветствие — через A1. Главный owner-блокер переезда звонков снят. Замечания owner: (1) на вопрос о названии тетради ассистент ответ
- 2026-09-02 → [A1 14:30 Фабл] Ступени: 8000/PIN закрыт живым звонком на l91 (WEB-395 done), шлюз с восстановлением аренды посажен (WEB-476 done), D landing zone (WEB-402 done), L DR (WEB-410 done), C провенанс — рецепт сдан (1225, приёмка 1232 на M4). Открыто в эпике: WEB-4
- 2026-09-02 → [A1 15:06 Фабл] OWNER GO (TG 14:59): «переезд телефонии на живое плечо — делай по разумному, откатиться сможем». План 8000→live (LANE8000-CHECKLIST.md): волна 1246-lane8000v2 (A1) — порт lane8000-1164 (bef003530e; audiosocketTransport, bargeInDetector, stasisS
- 2026-09-02 → [A1 20:15 Фабл — сводка для нулевого агента] Телефония на A1 (l92): 8000 turn-based работает; живое плечо WEB-479 — четвёртый круг на приёмке 1321 (после GO: посадка lane8000-land.sh из кандидата, restart ag-sip-native, D2/D3, звонок owner-а с barge-in). Боты
- 2026-09-05 → [2026-09-05 17:40Z] Ревизия доски (волна 2040 boardtriage, M1, luna): статус → parked. Основание: нет активности с 2026-08-29; cutover не готов. Если работа жива — верни статус и напиши в тикет, какая волна её ведёт.
- 2026-08-31 19:15Z — ступень K11: приёмка ПРИНЯТО: НЕТ, корректирующий круг K12 в полёте
- 2026-08-31 20:30Z — K12 автор сдал: три блокера K11 закрыты
- 2026-08-31 21:00Z — accweb370k12: ПРИНЯТО НЕТ (одна находка) → K13
- 2026-08-31 22:35Z — accweb370k13: ПРИНЯТО ✅ кандидат l81 — K-СЕРИЯ ЗАКРЫТА
- 2026-08-31 23:00Z — 🚀 GO owner-а на миграцию: ЭТАП 1 РАЗВЁРНУТ
- 2026-08-31 22:50Z — acctel2return: ПРИНЯТО ✅ кандидат l81 (mock-часть линии возврата)
- **Следующий шаг:** 2026-08-31 23:00Z — 🚀 GO owner-а на миграцию: ЭТАП 1 РАЗВЁРНУТ | Owner 22:34Z: «А1 → полноценный прод энтерпрайз-уровня, Малинка → дев. Приступайте».

---

## история (тело до 13.09.2026)

## 2026-08-31 19:15Z — ступень K11: приёмка ПРИНЯТО: НЕТ, корректирующий круг K12 в полёте
Авторская K11 (ветка wave/web370k11, HEAD 3463b3e6, коммит приёмочного harness 9a1f4bee): pnpm test:web370-k11 28/28, независимый harness 7/7.
Приёмка accweb370k11b (луна, после срезанной фильтром sol-попытки) дала **принято: нет** — три находки:
1. crash/restart исполнителя даёт 18 мутаций вместо одной (повторный вход не идемпотентен);
2. неполный readback подписывается как SAFE_OFF (мусор читается как валидное);
3. TOCTOU-подмена pinned-исполняемого между проверкой sha256 и исполнением.
→ Круг **web370k12** (бриф 1011, база = HEAD автора K11) запущен 19:07Z на A1: идемпотентность через долговечный журнал/фенсинг, readback-обрыв = отказ, исполнение проверенного содержимого (fd), негативные тесты на все три класса.
Эволюция: K1..K10 приняты ранее → K11 автор ✅ / приёмка ❌ → K12 в полёте.

## 2026-08-31 20:30Z — K12 автор сдал: три блокера K11 закрыты
web370k12 (HEAD e9147dda): 18-мутаций-при-restart / readback=SAFE_OFF / TOCTOU воспроизведены на K11 и закрыты. → Приёмка **accweb370k12** (бриф 1028: свой harness на все три контрпримера + новые классы — одновременный двойной запуск, повреждённый журнал, часы назад).

## 2026-08-31 21:00Z — accweb370k12: ПРИНЯТО НЕТ (одна находка) → K13
Takeover после SIGKILL не завершает durable execution: мутация не дублируется (это ✅), но свежая readback-квитанция отвергается из-за расхождения fencing token 1↔2 → CONTAINMENT_INCOMPLETE вместо SAFE_OFF. Остальные новые границы (двойной запуск, битый журнал) fail-closed. → **web370k13** (бриф 1036): квитанции takeover-а валидны под ЕГО токеном, старый токен не принимается за свежий, итог SAFE_OFF. Эволюция: K11 автор ✅/приёмка ❌(3) → K12 закрыл 3/приёмка ❌(1) → K13.

## 2026-08-31 22:35Z — accweb370k13: ПРИНЯТО ✅ кандидат l81 — K-СЕРИЯ ЗАКРЫТА
Независимый process/fault/concurrency harness: kill в разных точках → одна мутация + SAFE_OFF; старый токен отвергается; двойной takeover — один победитель; битый журнал — отказ. Эволюция ступени: K11 (3 дыры) → K12 (закрыл, 1 новая) → K13 (закрыл) → приёмка ✅. Лестница миграции движка доказана до конца.

## 2026-08-31 23:00Z — 🚀 GO owner-а на миграцию: ЭТАП 1 РАЗВЁРНУТ
Owner 22:34Z: «А1 → полноценный прод энтерпрайз-уровня, Малинка → дев. Приступайте».
**A1-нода поднята и зелёная**: сервис nc-a1 (l80 d01218a2, тот же артефакт b640cc4f), enforce-обёртка+аттестация, свой nc-fence-pi (порт 35083, клонирован с Pi с секретами flip-cap/flip-cron), туннельный юнит pi-tunnel (pg 15432→Pi:55432, redis 16379→Pi:6379, autorestart), Redis на Pi (loopback), MULTINODE_ENABLED=1+REDIS_URL, ACTIVE_PASSIVE_COPY_ID=a1. **paid TRUE enforce_ready на A1 против ОБЩЕЙ прод-базы**; lease web370-runtime держит pi → A1 корректно ПАССИВЕН (side-effect-ы не задвоены). Pi-прод не тронут, зелёный.
Дальше: этап 2 (нагрузка/синк-пробы), этап 3 (телефония по K-лестнице), этап 4 (nginx+TLS на A1, 80/443 в UFW по плану аудита, DNS-флип Cloudflare, Pi→dev). Ключ A1→Pi: ~/.ssh/a1-to-pi (добавлен в Pi authorized_keys), egress 2046/tcp открыт.

## 2026-08-31 22:50Z — acctel2return: ПРИНЯТО ✅ кандидат l81 (mock-часть линии возврата)
Единый missed/identity контракт, жатва return_ttl_expired, идемпотентность после аварии — подтверждены независимо. Оговорка приёмки: production-ready станет после прод-стыка (Asterisk h-hook сейчас NoOp) — это этап 3 миграции, за координатором (WEB-401).

## 2026-08-31 23:10Z — этап 4 ПОДГОТОВЛЕН (флип домена = 3 команды)
- TLS: сертификат nb.wool2.online скопирован Pi→A1 (валиден до 24.11) + options-ssl/dhparams; certbot+dns-cloudflare стоит на A1, но CF-токен видит только ecowool/sixbyy — **DNS зоны wool2.online самохостится BIND-ом НА МАЛИНКЕ** (ns1/ns2 = 86.45.55.126).
- nginx на A1: конфиг клонирован с Pi (+log_format masked_query в nginx.conf), nginx -t OK, сервис ВЫКЛЮЧЕН до флипа (80/443 в UFW закрыты).
- **TTL nb-записи снижен 86400→300** в живой зоне (/var/cache/bind/db.wool2.online — динамическая: порядок строго freeze→edit→thaw; /etc/bind/db.wool2.online — СТАРАЯ копия, не она; serial 2026053141). К завтра кэши сойдутся.
- ФЛИП: (1) A1: ufw allow 80,443 + systemctl enable --now nginx; (2) Pi BIND: freeze→nb A→129.213.25.105→thaw; (3) проверка; ОТКАТ = обратная правка, действует за ≤5 мин.
- ⚠️ ВОПРОС owner-у перед переводом Pi в дев: ns1/ns2 всей зоны wool2.online живут на Малинке — надо увести DNS (вариант: Cloudflare-аккаунт, там уже 2 зоны). Egress 443/tcp на A1 открыт (прод-ноде нужен).

## 2026-09-01 06:30Z — ЭТАП 2 МИГРАЦИИ: перенос базы НАЧАТ (без даунтайма)
Гэп-статус отправлен owner-у (он ждал «всё готово» — честно объяснено, что этап 1/4). Факты: Pi-база = PG **15.4** docker (pgvector 0.5.1, 2.6ГБ), A1 = PG 16 → физическая реплика невозможна, выбрана **логическая репликация с апгрейдом до PG16/pgvector 0.6**. Сделано: кластер 16/noteclone на A1:55432 (data-checksums; ловушка: pg_createcluster требует LANG/LC_ALL=C.UTF-8 в env sudo); роль+БД+расширения; пробный дамп через туннель 7м52с/1.03ГБ (мера канала: ~2.2МБ/с uplink Малинки); wal_level=logical на Pi (рестарт контейнера 12с, paid TRUE вернулся); PUBLICATION nc_move (all tables); схема restored (195 таблиц; pg_restore 4 ошибки — проверить, вероятно extension-комменты); GRANT pg_create_subscription; SUBSCRIPTION nc_move_sub (copy_data) — **начальный снапшот идёт** (мониторится фоном).
Окно переключения после синка: stop Pi-app → lag=0 → setval всех sequences (логическая репликация их НЕ переносит!) → nc-a1 на локальную БД → nginx+UFW+DNS-флип. Ожидаемый даунтайм ≤2 мин.

## 2026-09-01 07:35Z — 🚀🚀 ПРОД ПЕРЕЕХАЛ НА A1 (веб-часть миграции ЗАВЕРШЕНА)
Хронология: sync 195/195 (последняя таблица SpendActionReplayReceipt билась в цикле — schema-restore не донёс функции canonical_spend_replay_json/spend_replay_response_hash, а после доноса воркер репликации падал на урезанном search_path; лечение: пересоздание функции со СХЕМНО-КВАЛИФИЦИРОВАННЫМ вызовом public.*) → сверка счётчиков 1-в-1 (Source/Note/User/TSE/SARR/MessageLog) → ОКНО 07:11:02Z: stop Pi-app → sequences(1) → SUBSCRIPTION DISABLE → nc-a1 на локальную 55432 + Redis 6379 → paid TRUE → UFW 80/443 + nginx → BIND nb→129.213.25.105 (гейт на точную форму записи) → 8.8.8.8 отдаёт A1, HTTPS 200. Хвост DNS-кэша: Pi-nginx nb-vhost проксирует на A1 (proxy_ssl_server_name; бэкап конфига .bak-preflip-proxy). Даунтайм ~4 мин. Таймер индексации nc-a1-indexing (2 мин) создан. Lease web370-runtime берётся по требованию — заберётся первым вебхуком. tg-скрипты координатора переключены на A1-базу.
**Малинка = ДЕВ** (note-clone-3010 остановлен; book/blw/почта/DNS-зона нетронуты). ОСТАЛОСЬ: телефония (Asterisk на Pi, отдельный эпик), увод DNS-зоны с Малинки, certbot-renewal на A1, полная батарея на A1-проде.

## 2026-09-01 07:30Z — пост-флип находка №1: голосовые (ПОЧИНЕНО за 7 минут)
Симптом: voice transcription «временный сбой». Корень: nc-fence-pi клонирован с Pi вместе с FENCE_ALLOWED_UID=1000 (uid pi), а на A1 приложение под ubuntu uid=1001 → 403 uid_not_allowed на платном egress. Фикс: FENCE_ALLOWED_UID=1001 + restart. Урок в чек-лист переезда: у клонированных стражей сверять ВСЕ машинно-зависимые привязки (uid/gid/пути/интерфейсы). Второй сигнал из того же лога: admin_defaults_missing_config (messaging/voice/arcade) — существовал и до переезда, отдельная линия.

## 01.09 09:15Z — телефония подключена к A1-проду (Fable)
Стек остаётся на Pi физически (SIP/железо), но переведён на прод-ресурсы A1: a1-db-tunnel.service (Pi:25432→A1:55432, ключ restrict/port-forwarding), telegram-call-native drop-in prod-db.conf (+prod-a1.env: DATABASE_URL prod, TELEGRAM_CALL_ADAPTER_BASE_URL=https://nb.wool2.online), ag-voice/.env.local DATABASE_URL→25432, drop-in prod-a1.conf обоим SIP-юнитам (APP_URL и SIP_EXPERIMENTAL_LIVE_APP_BASE_URL вшиты в unit → drop-in переопределяет). Ловушка: пароль дев-базы ≠ прод-базы (Authentication failed) — URL собирать с паролем A1. Все 3 службы active, 0 ошибок, auth-проба через туннель прошла (MessageLog 6527). Живой звонок запрошен у owner. Полный физический перенос стека на A1 (arm64-артефакты WEB-401, SIP UDP-порты в OCI) — отдельный шаг.
Бэкапы: первый base-снимок hetzbk-prod-a1 закоммичен, ретенция KEEP=5 отработала; корни падений wal-stream: нет .gnupg + нет known_hosts (strict) — оба закрыты.
Owner утвердил следующий этап: реплика БД на A2 + авто-переключение трафика («Да заложи», 09:07Z).

## 01.09 09:35Z — телефония: origin-лок и вернувшийся дев-апп (Fable)
Живой звонок owner-а: 8010 reject / 8011 IVR. Два корня: (1) s2s гейтвея на https://nb.wool2.online режется origin-локом (/sessions/start 403 origin_boundary_rejected) — на Pi он ходил с loopback; (2) мой restart telegram-call-native ПОДНЯЛ обратно note-clone-3010 (дев-апп на дев-базе) через Wants= в 5 юнитах — disable не убирает зависимость. Лечение: дев-апп остановлен, Wants=note-clone-3010 вычищен из юнитов (бэкапы .bak-preprod-20260901), туннель расширен 127.0.0.1:3010→A1:3010 — ВСЁ на Pi, что зовёт localhost:3010, снова прозрачно попадает в прод (точная дореезжая семантика, Host в APP_ALLOWED_HOSTS, loopback-изъятие origin-лока). Gateway banner: App=http://127.0.0.1:3010, 403/origin в логах 0. Повторный звонок запрошен. Диск A1 почищен 96%→87% (4 битых hetzbk-base по 5G от rc=12-цикла).

## 01.09 10:40Z — директива owner-а: ПОЛНЫЙ перенос телефонии на A1 (Fable)
Owner (voice 09:36Z): прод автономный, дев для экспериментов; малинка умрёт → телефония не должна умереть. Тест 8010 «тишина» разгадан: extension привязан к комнате-пруфу MEETINGROOM-1099 (/home/pi/ag-voice/var/meeting-room-sip-proof.json, PIN 0000), голосовой подсказки «введите ПИН» нет — недоработка. Ассистент = 8000.
Перенос начат: user pi на A1; rsync Pi→A1 (asterisk 159M aarch64-сборка, ag-voice 3.8G, tcn-current 303M) через a1-to-pi (egress 2046 разрешён); CPython 3.11.9 собирается на A1 из исходников (Ubuntu 24.04 несёт только 3.12, venv воркера = cp311; тарбол скачан ЧЕРЕЗ Pi — egress A1 закрыт аллоулистом). Обе машины aarch64, glibc Pi 2.36 < A1 2.39 (forward-compat). Впереди: ldd-донос библиотек asterisk, пересборка venv с копией site-packages, порты SIP/RTP в OCI+UFW (в т.ч. egress!), тень-запуск, DNS sip.wool2.online.

## 01.09 10:55Z — звонок 8000 ПРОШЁЛ; найден пропущенный класс переезда: пути хранилищ (Fable)
- Owner: 8000 отвечает, но «не знает тетради». Корень НЕ привязка (notebook 904b27d8 жив, 92 Source): телефония-роут падал EACCES mkdir /home/pi/note-clone/shared/storage/exports/voice-artifacts — в прод-env уцелели 4 Pi-пути: STORAGE_PATH, MEDIA_STORAGE_DIR, PODCAST_STORAGE_DIR, VIDEO_ASSET_STORAGE_DIR. Ломало НЕ только голос: экспорты/медиа/подкасты/видео-ассеты на A1 не писались с флипа. Пути перепатчены на /home/ubuntu/prod/shared/*, бэкапы .env*.bak-storagepaths-20260901, nc-a1 рестартнут (paid TRUE), данные (2.6G storage + 86M video-assets) едут rsync-ом фоном. В чек-лист переезда: грепать env на СТАРЫЕ АБСОЛЮТНЫЕ ПУТИ, не только hosts/флаги.
- Сопутствующее: /sessions/*/events 422 payload_invalid от воркера (дрейф схемы июльского воркера против l81 API) — отдельная мелкая линия.
- Перенос стека: Asterisk 20.19.0 ЗАПУСКАЕТСЯ на A1 (все 300 модулей ldd-чистые, самодостаточная сборка), venv воркера перевешен на собранный /opt/python3.11 (main import ok, ntgcalls ok). Едут node_modules ag-voice (2G) + /home/pi/web (sync-workdir).

## 01.09 11:10Z — 🚀 ТЕЛЕФОНИЯ ЦЕЛИКОМ НА A1 (Fable) — прод автономен
Переключение выполнено: обе SIP-линии (5060 native + 5074 opus-exp, RTP 10000-10020 и 13200-13300) и telegram-call-native работают НА A1 под ubuntu (fence-uid 1001; фикс «fence одно-uid» решён выбором пользователя, код fence не тронут). Юниты адаптированы (ASTERISK_PREFIX + явный APP_URL drop-in-ом — NEXTAUTH_URL из .env перебивал резолвер: порт 3274). DNS sip.wool2.online → 129.213.25.105 (TTL 300), на Pi socat-хвосты 5060/5074 на сутки кэшей. Pi-стек disable, малинка = чистый дев. Endpoint-sync из прод-базы: 3 эндпоинта. Воркер: Telegram DC ESTAB, локальный base_url.
Ловушки в копилку: find_asterisk ищет в $HOME (User сменился → ASTERISK_PREFIX обязателен); resolve_app_url берёт NEXTAUTH_URL раньше APP_URL; venv Debian-python несёт shared libpython (лечится re-home на свой /opt-python); хранилища: storage/video-assets домигрированы (rc=0).
Открыто по телефонии: голосовая подсказка «введите ПИН» на 8010; 422 payload_invalid lifecycle events (дрейф схемы воркер↔l81); мессенджер-боты (bookbot/gptbot) ещё на Pi — следующий кусок «мессенджеры на A1» (owner: «вся телефония, мессенджеры»).

## 01.09 12:50Z — тишина на 8000 после переезда: NAT-адрес (Fable)
Owner: звонок на 8000 через A1-стек — тишина. Корень: OCI 1:1 NAT — asterisk отдавал в SDP приватный 10.0.0.131 (на Pi спасал домашний роутер). Фикс: SIP_NATIVE_EXTERNAL_SIGNALING/MEDIA_ADDRESS=129.213.25.105 + LOCAL_NETS=10.0.0.0/16,127.0.0.0/8 в drop-in обеих линий; в pjsip.conf отрендерились external_* (5060 и 5074). Обе линии перезапущены, повторный звонок запрошен. В чек-лист переноса SIP: за NAT external-адреса ОБЯЗАТЕЛЬНЫ с первого старта.

## 01.09 14:00Z — «тишина 8000» разгадана трафиком; l82 собран (Fable)
tcpdump на A1 во время пробы: до 11:49 телефон owner-а ВООБЩЕ не ходил на A1 (звонок 11:46 умирал локально в Linphone — регистрации не было). 11:49:40 REGISTER → 401 → 200 OK по UDP:5060 (линия native; provisioning-метадата обещала 5074/tcp — фактический клиент на 5060/udp). Контакт после регистрации выпадает по qualify: OPTIONS от A1 к 86.45.55.126:5060 глотает домашний роутер (проброс всё ещё на Pi) — исходящим звонкам не мешает, входящим будет мешать; рекомендация owner-у снять проброс. Повторный звонок запрошен.
Сборка l82 на A2: PACK_OK, артефакт me2-standalone-linux-arm64-0aa0ac8f-20260901T115035Z (sha 360a4c58c7aff95c392fe7b77e1caa4eed0b2b954d1d84562cd572cde0d32cb2), гейт схемы PASS ×2. Посадка — после подтверждения телефонии, чтобы не смешивать проверки.

## 01.09 14:20Z — телефония A1 доказана сквозным синтетическим звонком (Fable)
Инструменты: sipp (UAC+digest, пароль proof7016 из pjsip-generated auth-7016 — НЕ ag701626290 из DB metadata) + самописный RTP-pusher. Доказано: REGISTER 200; INVITE→200 OK с SDP c=129.213.25.105 m=audio 100xx (external-NAT-фикс РАБОТАЕТ, отдаётся публичный addr+порт из диапазона); RTP двусторонний — отправлено 495 пакетов, получено обратно (приветствие ассистента); gateway: «Call from 7016 to ext 8000 ... status=completed». Тракт A1 исправен и автономен. Остаток owner-side: Linphone не согласует media_encryption=sdes (force_avp+optimistic) ИЛИ шлёт медиа не туда; + старый проброс 5060 на домашнем роутере на Pi. Owner-у дан выбор: настроить SRTP/снять проброс ИЛИ принять как есть (пользователей нет). Recording «too small 44b» на стороне сервера — тишина входящего плеча синтетики (norm, я слал constant 0xff).
l82 готов к посадке (артефакт 0aa0ac8f, sha 360a4c58) — ждёт GO owner-а по TG.

## 01.09 13:30Z — телефония: корень = домашний роутер owner (Fable)
Owner: Linphone работал на Pi и дома, и снаружи → регресс от переезда, не телефон. Захваты на A1: A1 шлёт OPTIONS-qualify на 86.45.55.126:5060, ответа нет; телефон не перерегистрируется напрямую. Корень: домашний роутер owner пробрасывает inbound UDP 5060 → малинка (легаси, когда Pi был SIP-сервером); теперь перехватывает трафик телефона, сигнал/медиа от A1 уходят на мёртвую малинку. Мой Pi socat-relay 5060/5074 УБРАН (усугублял: A1 видел источник=малинка). Owner-у отправлен шаг: удалить проброс 5060 на роутере (id=16074), план Б — сменить локальный SIP-порт телефона. Бэкенд A1 доказан рабочим (sipp+RTP-pusher, звук в обе стороны, external_media/rtp_symmetric/rewrite_contact=yes). Ждёт теста owner.

## ДЛЯ НУЛЕВОГО АГЕНТА (обновлено 2026-09-05 UTC)
- **Суть одной строкой:** P1 МИГРАЦИЯ: переезд мессенджер/звонкового стека Pi→Oracle — киллер-фича не переживёт выключение Малинки
- **Текущее состояние:** статус: parked; 2026-08-31 19:15Z — ступень K11: приёмка ПРИНЯТО: НЕТ, корректирующий круг K12 в полёте | Авторская K11 (ветка wave/web370k11, HEAD 3463b3e6, коммит приёмочного harness 9a1f4bee): pnpm test:web370-k11 28/28, независимый harness 7/7. | Приёмка accweb370k11b (луна, после срезанной фильтром sol-попытки) дала принято: нет — три находки: | Эволюция: K1..K10 приняты ранее → K11 автор ✅ / приёмка ❌ → K12 в полёте. | web370k12 (HEAD e9147dda): 18-мутаций-при-restart / readback=SAFEOFF / TOCTOU воспроизведены на K11 и закрыты. → Приёмка accweb370k12 (бриф 1028: свой harness на все три контрпримера + новые классы — одновременный двойной запуск, повреждённый журнал, часы назад). | 2026-08-31 21:00Z — accweb370k12: ПРИНЯТО НЕТ (одна находка) → K13 | Takeover после SIGKILL не завершает durable execution: мутация не дублируется (это ✅), но свежая readback-квитанция отвергается из-за расхождения fencing token 1↔2 → CONTAINMENTINCOMPLETE вместо SAFEOFF. Остальные новые границы (двойной запуск, битый журнал) fail-closed. → web370k13 (бриф 1036): … | 2026-08-31 22:35Z — accweb370k13: ПРИНЯТО ✅ кандидат l81 — K-СЕРИЯ ЗАКРЫТА
- **Кто работал:**
- 2026-09-02T00:31:30.996Z — Fable — [02.09 00:30Z Фабл] Owner удалил на роутере ASUS проброс sip-main (5060→192.168.1.50); попросил удалить и sip-rtp (10000:10020/UDP→192.168.1.50). Следующий шаг owner — контрольный звонок на 8000 (ассистент с A1).
- 2026-09-02T00:36:55.334Z — Fable — [02.09 00:45Z Фабл] КОНТРОЛЬНЫЙ ЗВОНОК OWNER ПРОШЁЛ после удаления пробросов sip-main/sip-rtp на роутере: регистрация, INVITE, приветствие — через A1. Главный owner-блокер переезда звонков снят. Замечания owner: (1) на в
- 2026-09-02T14:26:54.536Z — Fable — [A1 14:30 Фабл] Ступени: 8000/PIN закрыт живым звонком на l91 (WEB-395 done), шлюз с восстановлением аренды посажен (WEB-476 done), D landing zone (WEB-402 done), L DR (WEB-410 done), C провенанс — рецепт сдан (1225, при
- 2026-09-02T15:02:41.558Z — Fable — [A1 15:06 Фабл] OWNER GO (TG 14:59): «переезд телефонии на живое плечо — делай по разумному, откатиться сможем». План 8000→live (LANE8000-CHECKLIST.md): волна 1246-lane8000v2 (A1) — порт lane8000-1164 (bef003530e; audios
- 2026-09-02T19:34:28.085Z — Fable — [A1 20:15 Фабл — сводка для нулевого агента] Телефония на A1 (l92): 8000 turn-based работает; живое плечо WEB-479 — четвёртый круг на приёмке 1321 (после GO: посадка lane8000-land.sh из кандидата, restart ag-sip-native, 
- 2026-09-05T17:35:28.625Z — fable-coordinator — [2026-09-05 17:40Z] Ревизия доски (волна 2040 boardtriage, M1, luna): статус → parked. Основание: нет активности с 2026-08-29; cutover не готов. Если работа жива — верни статус и напиши в тикет, какая волна её ведёт.
- **Ветки/бандлы/отчёты:** ~/.ssh/a1-to-pi; sha: 3463b3e6, 9a1f4bee, e9147dda, d01218a2, b640cc4f, 2026053141, 20260901, 904b27d8
- **KNOWN ISSUES / ТРАБЛШУТИНГ:**
- 3. TOCTOU-подмена pinned-исполняемого между проверкой sha256 и исполнением.
- → Круг web370k12 (бриф 1011, база = HEAD автора K11) запущен 19:07Z на A1: идемпотентность через долговечный журнал/фенсинг, readback-обрыв = отказ, исполнение проверенного содержимого (fd), негативные тесты на все три класса.
- Takeover после SIGKILL не завершает durable execution: мутация не дублируется (это ✅), но свежая readback-квитанция отвергается из-за расхождения fencing token 1↔2 → CONTAINMENTINCOMPLETE вместо SAFEOFF. Остальные новые границы (двойной запуск, битый журнал) fail-closed. → web370k13 (бриф 1036): …
- - ФЛИП: (1) A1: ufw allow 80,443 + systemctl enable --now nginx; (2) Pi BIND: freeze→nb A→129.213.25.105→thaw; (3) проверка; ОТКАТ = обратная правка, действует за ≤5 мин.
- Гэп-статус отправлен owner-у (он ждал «всё готово» — честно объяснено, что этап 1/4). Факты: Pi-база = PG 15.4 docker (pgvector 0.5.1, 2.6ГБ), A1 = PG 16 → физическая реплика невозможна, выбрана логическая репликация с апгрейдом до PG16/pgvector 0.6. Сделано: кластер 16/noteclone на A1:55432 (dat…
- Хронология: sync 195/195 (последняя таблица SpendActionReplayReceipt билась в цикле — schema-restore не донёс функции canonicalspendreplayjson/spendreplayresponsehash, а после доноса воркер репликации падал на урезанном searchpath; лечение: пересоздание функции со СХЕМНО-КВАЛИФИЦИРОВАННЫМ вызовом…
- Симптом: voice transcription «временный сбой». Корень: nc-fence-pi клонирован с Pi вместе с FENCEALLOWEDUID=1000 (uid pi), а на A1 приложение под ubuntu uid=1001 → 403 uidnotallowed на платном egress. Фикс: FENCEALLOWEDUID=1001 + restart. Урок в чек-лист переезда: у клонированных стражей сверять …
- Стек остаётся на Pi физически (SIP/железо), но переведён на прод-ресурсы A1: a1-db-tunnel.service (Pi:25432→A1:55432, ключ restrict/port-forwarding), telegram-call-native drop-in prod-db.conf (+prod-a1.env: DATABASEURL prod, TELEGRAMCALLADAPTERBASEURL=https://nb.wool2.online), ag-voice/.env.local…
- **Эволюция:**
- 2026-09-02 → [02.09 00:30Z Фабл] Owner удалил на роутере ASUS проброс sip-main (5060→192.168.1.50); попросил удалить и sip-rtp (10000:10020/UDP→192.168.1.50). Следующий шаг owner — контрольный звонок на 8000 (ассистент с A1).
- 2026-09-02 → [02.09 00:45Z Фабл] КОНТРОЛЬНЫЙ ЗВОНОК OWNER ПРОШЁЛ после удаления пробросов sip-main/sip-rtp на роутере: регистрация, INVITE, приветствие — через A1. Главный owner-блокер переезда звонков снят. Замечания owner: (1) на вопрос о названии тетради ассистент ответ
- 2026-09-02 → [A1 14:30 Фабл] Ступени: 8000/PIN закрыт живым звонком на l91 (WEB-395 done), шлюз с восстановлением аренды посажен (WEB-476 done), D landing zone (WEB-402 done), L DR (WEB-410 done), C провенанс — рецепт сдан (1225, приёмка 1232 на M4). Открыто в эпике: WEB-4
- 2026-09-02 → [A1 15:06 Фабл] OWNER GO (TG 14:59): «переезд телефонии на живое плечо — делай по разумному, откатиться сможем». План 8000→live (LANE8000-CHECKLIST.md): волна 1246-lane8000v2 (A1) — порт lane8000-1164 (bef003530e; audiosocketTransport, bargeInDetector, stasisS
- 2026-09-02 → [A1 20:15 Фабл — сводка для нулевого агента] Телефония на A1 (l92): 8000 turn-based работает; живое плечо WEB-479 — четвёртый круг на приёмке 1321 (после GO: посадка lane8000-land.sh из кандидата, restart ag-sip-native, D2/D3, звонок owner-а с barge-in). Боты
- 2026-09-05 → [2026-09-05 17:40Z] Ревизия доски (волна 2040 boardtriage, M1, luna): статус → parked. Основание: нет активности с 2026-08-29; cutover не готов. Если работа жива — верни статус и напиши в тикет, какая волна её ведёт.
- 2026-08-31 19:15Z — ступень K11: приёмка ПРИНЯТО: НЕТ, корректирующий круг K12 в полёте
- 2026-08-31 20:30Z — K12 автор сдал: три блокера K11 закрыты
- 2026-08-31 21:00Z — accweb370k12: ПРИНЯТО НЕТ (одна находка) → K13
- 2026-08-31 22:35Z — accweb370k13: ПРИНЯТО ✅ кандидат l81 — K-СЕРИЯ ЗАКРЫТА
- 2026-08-31 23:00Z — 🚀 GO owner-а на миграцию: ЭТАП 1 РАЗВЁРНУТ
- 2026-08-31 22:50Z — acctel2return: ПРИНЯТО ✅ кандидат l81 (mock-часть линии возврата)
- **Следующий шаг:** 2026-08-31 23:00Z — 🚀 GO owner-а на миграцию: ЭТАП 1 РАЗВЁРНУТ | Owner 22:34Z: «А1 → полноценный прод энтерпрайз-уровня, Малинка → дев. Приступайте».

[2026-08-25 20:00Z] ИНВЕНТАРЬ ФАЗА 1 (read-only, живьём с Pi):
• SIP: ag-sip-native + opus-experimental — supervisor-скрипты /home/pi/ag-voice/infra/sip/ (дерево 3.8G, бэкапы ag-sip-backups/ + ag-voice-backups/ уже есть), env ag-sip-native-opus-experimental.env, AG_REPO_ROOT=/home/pi/web.
• Signal: КАСТОМНЫЙ /usr/local/bin/signal-cli-forked (скрипт 213B-обёртка) + signal-call-tunnel (bin 18MB) — ОБА обязаны попасть в сейф; конфиг/регистрация /home/pi/signal-cli-data (13M, номер +353857367035 — ОДНА регистрация, две живые копии нельзя); shim/pollers /home/pi/signal-shim (604K, node); мосты на PulseAudio (/run/user/1000/pulse) и AudioSocket:4675; вебхуки в app 127.0.0.1:3010 (переезжают вместе с приложением); докер strukturag/nextcloud-spreed-signaling.
• Telegram: bookbot /home/pi/Documents/bookbot (300M, python venv), gptbot /home/pi/Documents/gpt (2.8G), telegram-call-native /home/pi/telegram-call-native (9.8G!, env из /home/pi/web/.env[.local] + worker.env).
• Почта: postfix (на A1 уже есть pre-DNS MAIL-1).
Риски переноса: PulseAudio/аудио-стек на headless A1 (нужен null-sink), одна signal-регистрация и один TG-webhook (строго ship-dark до свитча), 9.8G+3.8G данных — тянуть в M4Ext-сейф и на A1 заранее. iMessage — вне скоупа (Mac-only, M1).
След. шаг: опись секретов по именам (без значений), затем план ship-dark развёртывания на A1.
[2026-08-25 20:04Z] owner: тикет в эпик WEB-282 (parentId выставлен), на задачу — мощная думающая модель (запускается волна web370plan, sol xhigh). Плюс owner-вопрос ёмкости: сколько параллельных звонков выдержат TG/Signal-мосты и не заглушат ли платформы — включён в скоуп волны (анализ по коду, БЕЗ нагрузочного штурма живых платформ — риск бана номера).
[2026-08-25 20:36Z] ПЛАН ГОТОВ (web370plan): полный план переезда стека Pi→A1 (ship-dark, cutover, rollback, аварийный RTO 15м, backup RPO 5м, rehearsal-чеклист) + тикеты-кандидаты. ЁМКОСТЬ ЗВОНКОВ по коду: Telegram=1 параллельный, Signal=1, SIP стартовый cap=5. Отмечены конфликт порта 4675 (AudioSocket) и риски дедупликации Signal. Отчёт A1:WEB370PLAN-REPORT.md — из него завести подтикеты переезда.
[2026-08-26 07:05Z] НАРЕЗКА ГОТОВА (web370plan2): подтикеты WEB370-A.. с DoD, зависимостями, рисками и оценкой в инженерных днях. Первый: WEB370-A инвентарь Pi и карта состояния (1д) — подписанный manifest path/owner/mode/sha256/arch/version/port/secret-name, карта state->backup->restore owner, режим webhook/polling для каждого TG-consumer, iMessage помечен M1-only out of scope. Все platform-facing действия — только после fencing Pi и явного GO owner. Отчёт A1:WEB370PLAN2-REPORT.md.
[2026-08-27 06:50Z] epicmig-сводка (M1) для owner: план появился 25.08 постфактум (WEB370PLAN/PLAN2 на A1), внедрения на Oracle НЕТ (ship-dark/cutover receipts отсутствуют), cutover сейчас NO-GO (не перенесены сервисы/состояние/секреты, singleton-fencing Signal/TG, headless audio, AudioSocket 4675, WEB-318 todo, WEB-387 webhook 403), параллель Pi+Oracle возможна ТОЛЬКО active/passive (одна Signal-регистрация, один TG-вебхук) и не спроектирована; capacity: Telegram=1, Signal=1, SIP cap=5 (код-анализ, не нагрузочный штурм). Полный отчёт: M1 ~/EPICMIG-REPORT.md.
[2026-08-27 01:50Z] ДОКУМЕНТЫ (путь эволюции): нарезка выполнена: THREAD3MIG-REPORT.md (M1) -> тикеты WEB-399..413 (A..O, зависимости в каждом); дизайн: WEB370DESIGN-REPORT.md + WEB370PLAN2-REPORT.md (A1:waves/); статус головы: A=review (WEB-399), B/D=in_progress.

[2026-08-27 ~11:45Z toggle370 — АУДИТ ТУМБЛЕРА (owner напомнил про эту линию после компакта)] Вердикт: ЧАСТИЧНО РЕАЛИЗОВАНО / PRODUCTION NO-GO. Низкоуровневое ядро безопасности тумблера написано и локально проверено; полного продуктового переключателя нет. Полный разбор: A1:/home/ubuntu/waves/TOGGLE370-STATUS.md. Контекст owner 27.08 (восстановлен после компакта): эпик миграции НЕ задевал телефонию/мессенджеры — обвязка переезжает отдельно, с переключателем активной стороны Малинка<->Oracle; ключевой инвариант: НИКОГДА две активные копии (два Asterisk / два TG-бота).

[2026-08-27 ~15:00Z togglefix — ТУМБЛЕР РЕАЛИЗОВАН ship-dark] Прод не применялся (Pi/A1/M1/systemd/routes/credentials не тронуты, next build не запускался). Главный инвариант «никогда две активные копии» enforced в НЕСКОЛЬКИХ слоях: (1) M1 — единственный writer ACTIVE_HOST, grant сериализован, epoch строго растёт, grant поверх holder запрещён; (2) authority принимает ТОЛЬКО подписанный WEB370_CANONICAL_FENCE_PROOF, произвольный текстовый proof отвергается. Полный отчёт: A1:/home/ubuntu/waves/TOGGLEFIX-REPORT.md. Следующий шаг — независимая приёмка с четырьмя злыми тестами (одновременная активация, потеря lease, переключение туда-обратно, падение в середине).

[2026-08-27 ~16:50Z acctoggle NO-GO — приёмка тумблера завершена] ГЛАВНОЕ ХОРОШЕЕ: инвариант «две активные копии» в synthetic race/crash-проверках НЕ нарушен. НО 4 блокера: (1) FENCE PROOF МОЖНО СУЗИТЬ ДО ОДНОГО КОНТРОЛЛЕРА — принимается доказательство, покрывающее не все обязательные плоскости (router/PDU/ACL/Telegram/SIP/edge); (2) EGRESS ФАКТИЧЕСКИ НЕ ЗАКРЫВАЕТСЯ — заявлено в SAFE_OFF, по факту нет (это значит, что погашенная сторона может остаться в сети — прямой риск двойной активности на уровне провайдеров); (3) переход содержит ДЛИТЕЛЬНОЕ окно active_count=0 (безопасно, но недоступность больше необходимой); (4) авторский harness НЕСТАБИЛЕН при повторе. togglefix2 диспатчнута: proof валиден только при покрытии ВСЕХ плоскостей; закрытие egress доказывается РЕАЛЬНОЙ попыткой исходящего соединения, а не декларацией; окно измерить, сократить, зафиксировать SLO; 5 стабильных прогонов подряд; повтор 4 злых тестов + подделка proof + старый epoch.

[2026-08-27 ~18:10Z acctoggle2 NO-GO — EGRESS «закрывался» только на бумаге, доказано реальными пробами] После перехода pi->a1 наш synthetic web370-egress-guard.sh probe вернул deny (гейт считал, что закрыто), НО реальные попытки с пассивной стороны ПРОШЛИ: `nc -zv -w 2 1.1.1.1 53` rc=0 (TCP connect успешен), `dig @1.1.1.1 example.com` NOERROR (DNS ответил); только HTTP на :80 отвалился по таймауту. КОРЕНЬ: текущий gate — listener на 127.0.0.1:14110/24110 (infra/web370/host/web370-egress-guard.sh:17), то есть мы проверяли СВОЮ ЖЕ ЗАГЛУШКУ, а не сеть. Это прямой риск сценария «переключились, а старая сторона осталась в сети» — ровно того, ради чего строится тумблер. togglefix3 диспатчнута: настоящие сетевые ограничения (nft/iptables и/или network namespace/cgroup-net) для процессов обвязки на обеих сторонах; проба ТОЛЬКО внешняя (TCP 53/443, DNS, HTTP) — самопроверка через свой listener запрещена; fail-closed при неприменённых правилах или невыполнимой проверке; повтор 4 злых тестов + подделка proof + старый epoch + 5 стабильных прогонов.

[2026-08-27 ~19:05Z togglefix3 PASS — egress закрывается ПО-НАСТОЯЩЕМУ] Закрыт блокер acctoggle2 (гейт рапортовал deny, а реальные nc/dig с пассивной стороны проходили — проверяли собственный loopback-listener). РЕАЛИЗОВАНО: web370-netns.sh создаёт отдельный network namespace (unshare --net) на каждый synthetic host (pi/a1), подключает veth-парой к host-side маршруту, ставит точечные host NAT/FORWARD; ВСЕ wrapper-процессы, fixture, lease guard и probe запускаются через nsenter в ТОТ ЖЕ namespace. В состоянии DENY внутри namespace ставится реальная цепочка iptables OUTPUT -> WEB370_EGRESS -> REJECT; в ALLOW цепочка удаляется с предварительной проверкой её отсутствия. Loopback listener и локальные TCP-порты БОЛЬШЕ НЕ являются доказательством egress. Заявлено: RESULT PASS (4/4 злых теста + подделка proof + старый epoch + 5 стабильных прогонов + внешние egress-пробы). acctoggle3 диспатчнута — приёмка с заданием ОБОЙТИ защиту: UDP/ICMP, другой порт, IPv6, DNS через 127.0.0.53, уже установленное соединение (рвётся ли), процесс запущенный ДО перехода в DENY; плюс повтор 4 злых тестов, подделка каждой обязательной плоскости proof по очереди, 5 стабильных прогонов своими руками. При GO — прод-runbook и запрос окна у owner.

[2026-08-28 ~01:06Z тумблер — пятый случай класса, найден приёмщиком по моему заданию искать самому]
togglefix6 закрыл подлинность ответа арбитра, предел ожидания и четвёртый случай: полная репетиция 17/17, враждебная матрица 43/43, находок 0.
ПРИЁМКА ACCTOGGLE6 — NO-GO по ПЯТОМУ случаю: контроллер маршрута принимает маршрут по ЛОКАЛЬНЫМ файлам готовности и исхода, не проверяя живость процесса цели. Воспроизведено: при живом арбитре и валидной подписанной аренде МЁРТВАЯ или ПОДМЕНЁННАЯ цель принята как активный маршрут. То есть трафик может уехать в никуда — или к чужому.
Подтверждено закрытым: подлинность ответа арбитра, предел ожидания, четвёртый случай, F1, F2, межхостовой возврат, настоящее сетевое закрытие.
Запущена togglefix7: проверять живость и ЛИЧНОСТЬ самой цели напрямую (цель отвечает и подтверждает, что она — та самая), а не наличие файлов. Доказательства: цель убита -> маршрут не принимается; цель подменена другим процессом на том же адресе -> не принимается; цель жива и та самая -> принимается; медленный/частичный ответ -> безопасное поведение с пределом. Плюс искать ШЕСТОЙ случай самому.
ОКНО ПЕРЕКЛЮЧЕНИЯ НЕ НАЗНАЧАЕТСЯ — решение owner после GO.
ОБЩИЙ КЛАСС, вскрытый ТРЕМЯ приёмками в РАЗНЫХ линиях за ночь 28.08: защита живёт в памяти процесса либо верит файлу вместо живой проверки. Проявления: движок — леджер не даёт «не более одного раза» при одновременных процессах, а идентификатор операции теряется после рестарта (в воспроизведении текст удваивается: `hello!` -> `hello!!`); внутренний вызов — защита от переигровки в памяти, тот же валидный proof принят новым процессом; тумблер — маршрут принимается по локальным файлам готовности/исхода, мёртвая или подменённая цель принята как активная.
ТРИ ВОПРОСА к любой новой защите (внесены в брифы доделок, чтобы закрывать сразу, а не третьим кругом): переживает ли рестарт; держит ли одновременность (атомарно, а не «проверил, потом записал»); жива ли цель НА САМОМ ДЕЛЕ (проверять напрямую, а не по артефакту). Записано в память: guards-must-survive-process-boundary.

[29.08 КАРТА МИГРАЦИИ ДЛЯ «НУЛЕВОГО АГЕНТА» — где что лежит и в каком состоянии]

ДОКУМЕНТЫ И ССЫЛКИ
- Паспорт проекта (опубликован, обновляется): https://bugs.wool2.online/passport — онбординг, топология, что где крутится. Источник: docs/PASSPORT/ в репозитории, публикация скриптом с гейтом чистоты.
- Живое состояние смены: /Users/annakorin/Downloads/OPS-STATUS-LIVE.md на ноуте координатора — прод, аварии, что в кругах.
- Журнал работ: тикет WEB-320.
- Runbook переключения: отчёт WEB413CUT (вердикт NOCOMMIT — документ, не код), /home/ubuntu/waves/WEB413CUT-REPORT.md на A1.

СОСТАВ ЭПИКА (по подзадачам WEB370-*)
WEB-399 [A] инвентарь Pi и карта состояния — review · WEB-402 [D] landing zone и ship-dark baseline — in_progress · WEB-405 [G] аренда активной копии — review, НО см. ниже два открытых дефекта · WEB-407 [I] Telegram user-session и bot singleton — in_progress · WEB-408 [J] SIP ship-dark и жёсткий предел 5 — in_progress · WEB-409 тумблер (гейт подписи) — 9-й круг в работе · WEB-412 репетиция переключения — ждёт зелёного тумблера · WEB-413 само переключение — ждёт решения владельца.

⚠️ ДВА ОТКРЫТЫХ ДЕФЕКТА АРЕНДЫ (оба критичны именно для миграции, подробности в WEB-405)
1. Переменная ACTIVE_PASSIVE_COPY_ID обязательна на проде и её отсутствие НЕ кричит, а тихо переводит копию в пассивный режим: 29.08 это уронило все платные пути на 40 минут (сверка расхода перестала работать -> мертвец -> 503). При переезде на Oracle переменная должна быть задана ДО первого старта, значение oracle.
2. Два ПРОЦЕССА с ОДИНАКОВЫМ copy id не фехтуются — оба считают себя активными и оба выполняют побочные эффекты (probe в WEB-405). Значит гарантия «одна активная копия» держится ТОЛЬКО на различии имён pi/oracle. Копипаста конфига при миграции = две активные копии молча, без единой ошибки в логе.

ЧТО ВЛАДЕЛЕЦ ТРЕБУЕТ ДО ПЕРЕКЛЮЧЕНИЯ (27-28.08): репетиция должна быть ДОКАЗАНА и проведена в окно, когда никто не работает с голосом; будущий прод на Oracle — домен sixbyy.com (НЕ wool2.online); малинка остаётся девом, почта и телефония на ней обязаны продолжать работать.


[BOARDTRIAGE] 29.08: migration map актуальна; до переключения обязательны доказанная репетиция, разные copy id pi/oracle, fencing и окно без голосовой работы. Cutover не объявлять готовым.

[02.09 00:30Z Фабл] Owner удалил на роутере ASUS проброс sip-main (5060→192.168.1.50); попросил удалить и sip-rtp (10000:10020/UDP→192.168.1.50). Следующий шаг owner — контрольный звонок на 8000 (ассистент с A1).

[02.09 00:45Z Фабл] КОНТРОЛЬНЫЙ ЗВОНОК OWNER ПРОШЁЛ после удаления пробросов sip-main/sip-rtp на роутере: регистрация, INVITE, приветствие — через A1. Главный owner-блокер переезда звонков снят. Замечания owner: (1) на вопрос о названии тетради ассистент ответил «issue» — ожидаемо: платный контур прода сейчас 503 (WEB-461), перепроверить после посадки l85b; (2) перебивание не работает → WEB-463; (3) приветствие «this service» вместо Six by Y → WEB-464.

[A1 14:30 Фабл] Ступени: 8000/PIN закрыт живым звонком на l91 (WEB-395 done), шлюз с восстановлением аренды посажен (WEB-476 done), D landing zone (WEB-402 done), L DR (WEB-410 done), C провенанс — рецепт сдан (1225, приёмка 1232 на M4). Открыто в эпике: WEB-401 (C: сборка на A2 + сверка + Storage Box), WEB-413 (O: cutover с owner-GO после C/B4/freeze), WEB-471 (Signal — owner). Мессенджеры пока на Pi.

[A1 15:06 Фабл] OWNER GO (TG 14:59): «переезд телефонии на живое плечо — делай по разумному, откатиться сможем». План 8000→live (LANE8000-CHECKLIST.md): волна 1246-lane8000v2 (A1) — порт lane8000-1164 (bef003530e; audiosocketTransport, bargeInDetector, stasisSnoopIngressSpike, render dialplan по SIP_EXPERIMENTAL_*) на ТЕКУЩИЙ живой шлюз gwleaserecover2-1217 с сохранением lane-secret и монитора аренды + честный сухой старт с AudioSocket/ARI-mock; затем приёмка 1247 → посадка native-only (backup → копия → env с реальным ARI-паролем 600 → restart ag-sip-native) → D1 dialplan/D2 listeners+ARI/D3 логи без звонка → E звонок owner-а с barge-in → F1 откат за 2 мин при любом провале. Opus-стек 5074 не трогаем.

[A1 20:15 Фабл — сводка для нулевого агента] Телефония на A1 (l92): 8000 turn-based работает; живое плечо WEB-479 — четвёртый круг на приёмке 1321 (после GO: посадка lane8000-land.sh из кандидата, restart ag-sip-native, D2/D3, звонок owner-а с barge-in). Боты Pi→A1 (WEB-413): код без секретов принят (1309), ждут ротации токенов owner-ом и лизинга по новому дизайну WEB-405 (authority на A2: 1326 → приёмка → PRODUCTION-GATES). Настройки для пользователя (WEB-481): фикс на приёмке 1320. Signal (WEB-471) и участники митинг-рума (WEB-427) — на стороне owner-а. Cutover O (WEB-413) — после лизинга; owner: без зависимостей от малинки/ноутбуков (кроме FaceTime).

[2026-09-05 17:40Z] Ревизия доски (волна 2040 boardtriage, M1, luna): статус → parked. Основание: нет активности с 2026-08-29; cutover не готов. Если работа жива — верни статус и напиши в тикет, какая волна её ведёт.

[05.09 23:28Z координатор] [06.09 06:20Z координатор | ПЛАН CUTOVER TG/Signal Pi→A1 (2118, luna, `/home/ubuntu/waves/TGSIGNALCUTOVERPLAN-REPORT.md`, VERDICT=PLAN)] Решение: переезд допустим только как ХОЛОДНЫЙ cutover отдельным окном: freeze/drain → Pi stop + disable/mask (всех целевых юнитов, включая daemon и Asterisk/SIP на Pi) → live readback Pi=OFF → revoke Pi lease → A1 prepare без старта → Telegram fresh StringSession на A1 / Signal register на A1 (владелец вводит код/SMS) → A1 lease grant → daemon/audio/readiness → Signal adapters → Telegram worker → route/callback switch (sixbyy) → canary → observation; откат зеркальный. Правило единственности: ни один provider-facing процесс A1 не стартует, пока Pi не прошёл readback. Почему PLAN, не GO: A1 unit-файлы в репо — не полный A1-профиль; signal-cli daemon/install не поставляется репозиторием; unit Telegram без WEB-370 lease gate. Недостающие артефакты A1-01…A1-08 (unit Telegram под A1, install-bundle с venv/NTgCalls, StringSession bootstrap с редакцией секрета, signal-cli бинарь+daemon unit, UDS-набор Signal units, Pulse readiness (UID 1001), lease/host admission для всех daemon/shim с защитой от ручного systemctl start) — оценка ~4–7 инженерных дней. Раздел 9 — шаблон сообщения владельцу (окно UTC, выбор Telegram-аккаунта worker identity, ввод кода/2FA на A1, Signal SMS/captcha). Следующий шаг: волны на A1-02…A1-08 (по одной, Codex luna), затем окно с владельцем.

[06.09 00:02Z координатор] [06.09 08:00Z координатор | 2125 TGWORKERA1 = PASS] Кандидат `cdaef7f8836ef50b7b6687617ca235e37b53f6bc` (luna, A2, база 87111a95; бандл `/home/ubuntu/waves/TGWORKERA1.bundle`, отчёт `TGWORKERA1-REPORT.md`): артефакты A1-02 (unit telegram-call-native под A1 с lease-gate ExecStartPre), A1-03 (install-bundle: раскладка releases/current/shared, venv, pinned requirements, media-квота), A1-04 (bootstrap StringSession с границей ввода кода владельцем и редакцией секрета). Приёмка — вместе с 2126 (signal) и 2127 (lease admission, A1) одним пакетом → l113c/infra-line; хостовая установка на A1 — координатор в окне cutover.

[06.09 00:02Z координатор] [06.09 08:05Z координатор | 2126 SIGNALA1 = PASS_OFFLINE_NO_LIVE] Кандидат `881b28672acaa58e8c141b6fee968f7875b74da4` (luna, A2, база 87111a95; бандл `/home/ubuntu/waves/SIGNALA1.bundle`, отчёт `SIGNALA1-REPORT.md`): артефакты A1-05 (install signal-cli + daemon unit со state dir/номером/socket/backup), A1-06 (UDS-набор units shim/poller/call-poller/bridge с A1-путями, без Restart-петли на «not registered»), A1-07 (Pulse readiness, UID 1001, per-call sink) — проверено офлайн (без живого Signal). Вместе с 2125 (Telegram) и 2127 (lease admission, A1, идёт) → пакет WEB-370 A1-side; приёмка одним заходом; хостовая установка на A1 и регистрация номера — в окне cutover с владельцем.

[06.09 00:09Z координатор] [06.09 08:30Z координатор | 2127 LEASEADMISSION = PASS] Кандидат `7bc6c28334e6195e3cdc0e5b62e69e5239db1a62` (luna, A1, база 87111a95; бандл `/home/ubuntu/waves/LEASEADMISSION.bundle`, отчёт `LEASEADMISSION-REPORT.md`): общий admission-скрипт для ролей telegram-worker/signal-*/sip-native с lease-файлом (activeHost/epoch/TTL/roles), ExecStartPre-отказ exit 78 при чужом хосте/stale/нет lease/роль не разрешена, grant/revoke CLI с readback, тесты (bash -n, admission tests, unit lint, systemd-analyze verify). Вместе с 2125 (Telegram под A1) и 2126 (signal-cli под A1) закрыты A1-02…A1-08 плана 2118. Дальше: пакетная приёмка трёх (2134) и хостовая установка на A1 в окне cutover с владельцем (StringSession/регистрация Signal).

[06.09 01:37Z координатор] [2026-09-06T01:37Z координатор] ПРИЁМКА 2141-acctelephonya1pkg (A1, luna high; убита кэпом 40 мин, отчёт сдан): VERDICT=NO-GO для пакета из трёх кандидатов (2125 TG worker cdaef7f8, 2126 Signal 881b2867, 2127 lease/host admission 7bc6c283). (а) LEASEADMISSION.bundle был 0640 — волна не смогла прочитать 2127 (моя ошибка, исправлено chmod 644); (б) по существу: нет одного admission-скрипта/формата lease (Telegram-юнит зовёт K7-checker напрямую, telegram-call-native.service:30-32, bootstrap-telegram-session.sh:12-32), Signal-юниты ссылаются на /usr/local/libexec/a1-signal-runtime-preflight, который install-signal-cli.sh:213-224 не ставит, большинство provider-юнитов без ConditionPathExists, systemd-analyze verify падает без helper'ов. → Волна 2151-telephonya1pkgfix (A2, luna xhigh, база l113b 02812b90): свести три кандидата в один пакет + закрыть находки + RUNBOOK хостовой установки для координатора. Отчёт: A1 /home/ubuntu/waves/ACCTELEPHONYA1PKG-REPORT.md.

[06.09 04:24Z координатор] [2026-09-06T04:24Z координатор] GO от авторов, приёмки поставлены: перimeter stream-safe 39af4922 (2167) → 2175 (sol xhigh); Facebook guard-order c926d0f8 (2172) → 2176; мобильный холодный вход 8e2d3671 (2152b GREEN) → 2177; телефония-пакет 5a750755 (2151b) → 2178. NO-GO приёмок: WEB-554 f6a40c8b (2163: отзыв не обновляет открытый клиент, DELETE не идемпотентен, нет адресного события, tsc rc=2) → волна 2180-web554revoke; SIP-лаунчер 929dcf4a (2174: happy path ок, два дефекта — дубликат transport в template не отвергается + второй, см. отчёт) → волна 2179.

[06.09 05:06Z координатор] [2026-09-06T05:06Z координатор] ПРИЁМКА 2178-acctelephonypkg2 (A2, sol high): VERDICT=GO на 5a750755 — 14 provider-facing юнитов, один admission executable, install closure 8/8, systemd fixture без ошибок, RUNBOOK. Кандидат l113d (репо-часть). Хостовая установка на A1 = координатор в окне владельца + перелогин TG (Telethon) и Signal владельцем на A1.

[06.09 09:10Z координатор] [2026-09-06T09:09Z координатор] ПОСАЖЕНО: ПРОД = l113d 4c73d845 (09:03Z, без простоя; оба бэкенда ready, paid enforce_ready, edge 200×4; миграции применены (184 в репо), hetzbk l113d-4c73d845 + env-pack, Pi standby → l113d). В составе (21 коммит над l113c): большой PDF — персист чанков короткими idempotent-транзакциями (WEB-086/496/467), периметр stream-safe (WEB-495/093), WEB-554 отзыв тетради, WEB-540 translation claim, WEB-543 customer guard, WEB-559 binary adapter, WEB-567 issuer authority, WEB-558 facebook attempt, WEB-491 mobile cold-start, WEB-370 пакет телефонии (репо-часть). Откат = l113c 0390afc9. На проде после посадки: revive PDF cmtkm80jo… → running (персист прошёл 5-с барьер — наблюдаю до done); big-test всё ещё упирается в бюджет (identity v4 — волна 2229).

[06.09 11:13Z координатор] [2026-09-06T11:13Z координатор] ПРОВЕРЕНО И ПОЧИНЕНО НА ПРОДЕ (nginx A1, 11:13Z): /me2 и /api/me2-bridge/* отдавали 502 — vhost'ы app.sixbyy.com и nb.wool2.online проксировали их на 127.0.0.1:3020 (давно мёртвый отдельный сервис), хотя приложение само обслуживает /me2 (страница) и /api/me2-bridge/{poll,realtime-token,realtime-tool,recent,web-enqueue}. Удалены три location (/me2/, /me2, ^~ /api/me2-bridge/) из обоих vhost (бэкапы /etc/nginx/backups/*.pre-me2fix), nginx -t ok, reload; теперь /api/me2-bridge/recent → 401 (периметр), /me2 → 307 на логин. KNOWN ISSUES: бэкап-копии НЕЛЬЗЯ класть в /etc/nginx/sites-enabled (nginx включает всё по glob → duplicate upstream nc_backend, nginx -t падает; работающий master не страдает). Найдено пост-QA 2279 (A2).

[06.09 13:39Z координатор] [2026-09-06T13:39Z координатор] ОКНО ТЕЛЕФОНИИ 13:31–13:38Z (A1, owner GO): sync-plan.sh --apply 7016 — файлы 508/509/463 скопированы, drop-in 50-web508-reload-persist.conf, reload: PID Asterisk не изменился, контакт 7016 пережил reload, :4080 200; STOP на post-check «AOR 7016 не показывает 90/120/30» (3600/7200 — dynamic AOR из pjsip-generated.conf, dynamic sync на хосте SKIP); rollback.sh STOP «infra-sip archive root is wrong» (ничего не откатил; состояние оставлено — рабочее). Затем restart ag-sip-native для активации barge-in: Asterisk 20.19 поднялся (5060/5061, endpoints=6), :4080 200, но контакт после рестарта не восстановился (0 в +152 с) — persistence регистраций не доказана; владелец перерегистрирует и тестирует звонок/перебивание. Круг 2 плана = 2322-sip-hostsync-fix (A1, sol xhigh). Бэкап: /var/backups/ag-sip-native/20260906T133135Z-3488516-l113f-sync.

[06.09 13:58Z координатор] [2026-09-06T13:58Z координатор] ПОСТ-QA l113g на проде (2320, A1, QA-учётка): PASS — pin/paid ready, витрина/redirect, legal/DMCA, Stripe-бета (PaymentElement, sandbox €10, без ввода карты), свой .md → done + C07 live propagation, периметр 27 методов (0×5xx), paid chat (6.05 credits ≈ /bin/zsh.06), me2-bridge (307/403/401 по контракту), нагрузка-lite 1200×200 (p95 1.9 с — выше, чем 197 мс на l113d; окно совпало с рестартами телефонии — перепроверить). FAIL: realtime session-start 200 → session-turn 404 session_not_found ×6 (сессии process-local за двумя бэкендами) → митигация на A1 13:56Z: nginx  → 3010 (бэкап в /etc/nginx/backups), фикс в коде — волна 2328 (redis-хранилище сессий); повтор пика — 2329 (A1). Apple/Google «error=Configuration» — снова GET-проба (POST с csrf работает, проверено 11:2xZ). Большой PDF для QA — 403 (другой владелец, ожидаемо). Revive --new-attempt: автор 2319 сдал 2f0fde7c (GO) → приёмка 2326 (A2, PG). C4-RU-3/C1-2 из батареи → разбор 2324 (A2). WEB-370: staged-артефакты для хостовой установки → 2327 (A2).

BOARD-WASH-20260910:WAVE-3339
По поручению владельца 18:43Z назначена исполнительская волна 3339 (infra), Codex gpt-5.6-luna xhigh, A1. Полная история карточки и база l115c 1ad52e16b доставлены, brief-guard и проверка Git-базы пройдены. Задача: проверить существующую сдачу, устранить остатки, передать бандл и доказательства. Финальная приёмка и посадка остаются за координатором. Запуск группы подтверждён в журнале диспетчера.
КАРТА ДОКУМЕНТОВ: ноут /Users/annakorin/nc-ops-scripts/board-wash-20260910/3339-wash-infra-brief.md; A1 /home/wave/waves/inputs/board-wash-20260910/infra-tickets.json; ожидаемый отчёт /home/wave/waves/3339WASHINFRA-REPORT.md. Правила обогащения: WEB-449.

[12.09 22:17Z координатор] МОЙКА 12.09 (3567-wash-g2-telephony-billing): веб и телефония уже на A1 (посадки 01.09), репо-пакет телефонии/мессенджеров принят и в l113d. Осталось: холодный cutover мессенджеров в окне владельца (TG/Signal релогин) и увод DNS-зоны с Малинки. Это эпик миграции — не закрывать; статус не менять, ждём окно владельца.
Остаток: Хостовой cold-cutover мессенджеров (TG StringSession + Signal регистрация) — требует окна владельца, не выполнен.; DNS-зона wool2.online (ns1/ns2) всё ещё на Малинке — не уведена.; certbot-renewal на A1 + полная батарея на A1-проде — не подтверждены.; Полный физический перенос стека (arm64-артефакты WEB-401, SIP UDP-порты в OCI) — отдельный шаг.
Отчёт: /Users/milamarty/waves/3567WASH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/collected/. Проверка по исходнику прода l115g (9c8a9762).

[13.09 10:37Z координатор] Мойка доски, волна 3654. RETURN. Веб и телефония уже на A1 (посадки 01.09, репо-пакет в l113d), но мессенджеры (TG/Signal) и DNS-зона wool2.online ещё на Малинке — холодный cutover ждёт окна владельца. Статус не меняю.

[13.09 10:51Z координатор] Волна 3663. 

[13.09 12:01Z координатор] Гигиена доски (волна 3676): эта карточка висела сиротой под преждевременно закрытым эпиком WEB-395. Эпик возвращён в работу, связь восстановлена.

[14.09 15:16Z координатор] # WEB-370 - блок для вставки

Источники, проверенные отсюда: тело тикета из live API; все 22 комментария из локального `web-board.sqlite`, последний комментарий `id=4744` от 2026-09-13T12:01:50.677Z. Статус на live API при финальной сверке: `in_progress`. A1/Pi/DNS живьём отсюда не проверялись.

## Что болит словами пользователя

Киллер-фича не должна умереть при выключении Pi: messenger/call stack должен переехать на Oracle/A1 с fencing, rollback и понятным owner window.

## Что уже сделано и чем доказано

По материалам карточки web prod и часть telephony уже на A1; telephony/messenger package принят и попал в l113d commit `5a750755`, acceptance 2178 GO. Есть план cold cutover из wave 3663 с фазами, fencing Pi и A1, owner gates, canary и rollback. Отдельно доказано, что SIP/voice часть работает на A1, но это не покрывает TG/Signal и DNS.

## Что осталось

Messenger bots TG/Signal не migrated: ждут cold cutover, owner window и relogin. `wool2.online` DNS ещё завязан на Pi bind. Нужны certbot-renewal на A1 и полная A1-prod battery. WEB-413 остаётся исполнительным cutover/observation-тикетом.

## Противоречия между комментариями

Раннее “телефония целиком на A1” отменяется/уточняется поздними комментариями `id=4369`, `id=4646`, `id=4744`: voice/SIP не равно весь messenger/call stack; TG/Signal и DNS всё ещё удерживают Pi-зависимость. Комментарий `id=4744` также фиксирует, что родственный WEB-395 был закрыт преждевременно и возвращён в работу.

## С ЧЕГО НАЧАТЬ НУЛЕВОМУ АГЕНТУ

Смотреть: план wave 3663, WEB-413, package/commit `5a750755`, Pi/A1 service maps for TG/Signal, DNS zone `wool2.online`, A1 certbot/nginx. Первый шаг: подготовить pre-cutover checklist и подтвердить blockers: owner relogin, WEB-409/412/401, Pi OFF readback rule.

Готово: Pi provider-facing processes выключены и fenced до старта A1; TG/Signal singleton registrations живут на A1; canary и observation зелёные; DNS/certbot подтверждены; rollback documented.

Нельзя: запускать A1 provider-facing process до readback Pi=OFF, делать dual-registration TG/Signal, менять DNS/production без owner window, считать SIP cutover закрытием messenger cutover.

Размер: несколько смен. Большим это делает холодный owner-window cutover, singleton-регистрации, fencing двух хостов, DNS/certbot и rollback.

## Закрытие и связи

Не закрыто. WEB-413 является executable child/overlap по production cutover, но не полный дубль.

ENRICH-4132-WEB-370
```markdown
## ДЕЛЬТА ОБОГАЩЕНИЯ — 2026-09-15T21:54Z, M1/4132 (DeepSeek Flash 4.1, read-only аудит), VERDICT=DRAFT_DELTA

### 1. Вердикт
Тело: «Прод сейчас = l115j (133fe00c, 13.09 08:50Z)». Живая линия —
**l115o `68e25d8df5ae8263c5ac5466353631f57a17cfcc`**. План холодного cutover готов, но не
выполнен; это по-прежнему ожидание окна владельца, а не техническая работа.

### 2. КАРТА ДОКАЗАТЕЛЬСТВ
- Тело: план холодного cutover, волна 3663 — `CUTOVER-PLAN.md` (фазы 0–6) + `OWNER-STEPS.md`.
- Тело: репо-пакет телефонии/мессенджеров принят и лежит в l113d (`5a750755`), приёмка 2178 = GO.
- HANDOFF-LIVE.md §1 строки 445–450 (l115o) и §6в строки 580–589 (обязательный шаг перед посадкой).
- HANDOFF-LIVE.md §7 строки 644–657 (долги смены, в т.ч. ротация двух секретов телефонии —
  действие владельца, запрошено).
- Доска WEB-370 id 4744 (2026-09-13T12:01:50.677Z): карточка висела сиротой под преждевременно
  закрытым эпиком WEB-395; эпик возвращён в работу, связь восстановлена.
- Доска WEB-370 id 5035 (2026-09-14T15:16:25.245Z): сводка для нулевого агента.

### 3. ЭВОЛЮЦИЯ / ПОПРАВКИ (append-only)
- Якорь: l115j `133fe00c` → **l115o `68e25d8df5ae8263c5ac5466353631f57a17cfcc`**.
- 13.09: карточка восстановлена под эпиком WEB-395 (была сиротой).
- Не изменилось и требует явной фиксации: мессенджер-боты (TG/Signal) ждут холодного cutover;
  DNS-зона wool2.online (ns1/ns2 = 86.45.55.126) по-прежнему на Малинке; certbot-renewal на A1
  и полная батарея на A1-проде не подтверждены.
- **НЕ ПРОВЕРЕНО ОТСЮДА:** живое состояние Pi, DNS, A1-прод, TG/Signal — доступа нет.

### 4. KNOWN ISSUES / ТРАБЛШУТИНГ
1. **Cutover ждёт окно владельца и молча стареет.**
   - Симптом: план готов и лежит, прогресса нет, карточка выглядит «в работе».
   - Проверка за 2 минуты: найти в карточке согласованное окно (UTC) и выбранный Telegram-аккаунт
     worker identity → если их нет, cutover не начат.
   - Причина: фаза 0 требует действий владельца (код/2FA Telethon, SMS/captcha, окно).
   - Лечение/статус: не начинать без окна; не считать «план готов» прогрессом cutover.
   - Ссылка: тело, `OWNER-STEPS.md`.
2. **Секреты телефонии напечатаны в лог и ждут ротации.**
   - Симптом: `TELEPHONY_GATEWAY_SECRET`, `TELEPHONY_LANE_CLAIM_SECRET` и пароль субаккаунта
     Hetzner засвечены в логе.
   - Проверка за 2 минуты: `grep -ril 'TELEPHONY_GATEWAY_SECRET' <каталоги логов>` →
     ожидание отсутствия значений (не имён) в открытом виде.
   - Причина: печать в лог при отладке.
   - Лечение/статус: ротация — действие владельца, запрошено. **Не закрывать карточку**
     миграции, пока ротация не проведена.
   - Ссылка: HANDOFF-LIVE.md §7 строка 646.

### 5. ТЕКУЩИЙ ОСТАТОК (ответственный)
1. Согласовать окно cutover (UTC) + worker identity — владелец.
2. Фазы 0–6 по `CUTOVER-PLAN.md`, включая fence Pi, singleton TG/Signal, 60-минутное наблюдение —
   координатор после окна.
3. Ротация двух секретов телефонии и пароля субаккаунта Hetzner — владелец.
4. Проверка версии по КАЖДОЙ службе после посадки (правило 14 канона).

### 6. ПЕРВЫЙ ШАГ НУЛЕВОГО АГЕНТА (без агентов)
Прочитать `CUTOVER-PLAN.md` и `OWNER-STEPS.md`; проверить, есть ли в карточке согласованное
окно. Нет окна — ничего не запускать, доложить координатору одной строкой, чего ждём.
Сверить якорь тела с живым `/api/ready`.
```

---

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=тело 13.09: приёмка 2178=GO и посадка l113d 5a750755; комментарий 5457 от 15.09 и аудит 4211 от 19.09: cold cutover не выполнен
ЧТО НУЖНО=координатору и владельцу провести cold cutover TG/Signal с Pi readback OFF, затем подтвердить DNS, certbot и A1 battery цифрами
triage-m1 4609

РЕШЕНИЕ=parked
ОСНОВАНИЕ=2026-09-15, волна 4132 DRAFT_DELTA: приёмка 2178=GO посадила пакет 5a750755 в l113d; текущая линия l115o 68e25d8d; cold cutover TG/Signal не выполнен
ЧТО НУЖНО=ЖДЁТ=владелец: согласовать окно cold cutover и relogin TG/Signal; triage-neo 4707