WEB board

Круг 1 сдан: коммит f9d43d97 «recover registrations across native restart» — persistent ledger sip-registration-state.json вне временного дерева, snapshot контактов перед остановкой, восстановление после подъёма. Приёмка = волна 1607-accsipreregister на A1: контакт восстанавливается за ≤10 с, ledger без секретов и не шире 0640, подталкивающий сигнал не создаёт шторм, в readiness 4080 появилось число зарегистрированных контактов. Живой шлюз приёмка НЕ трогает.

Приёмка 1607 = NO-GO, шесть находок. Главная (F1): парсер принимает любую строку Contact: и не отличает динамический REGISTER от статического contact-объекта (sipRegistrationRecovery.js:31), а сам модуль создаёт статические AOR вида sip-recovery-7016-aor (:122); readiness считает длину всего массива (:219). Шим приёмщика воспроизвёл пост-рестартовый вывод, где динамического 7016 НЕТ, но registeredContactCount=1 — то есть готовность врала бы, что телефон owner-а на связи. Остальные: F2 время возврата может остаться дорестартовым, F3 активный recovery не доказывает доставку в мёртвый TCP-сокет, F4 нет негативов на неизвестный AOR и шторм, F5 запрет секретов не обеспечен валидатором, F6 посадка не переносит recovery целиком. Круг 2 = волна 1614 на A1.

⚠️ Коммит круга 2 (c9606fdf) ПОТЕРЯН: волна работала в клоне ВНУТРИ своего worktree, уборщик снёс его вместе с коммитом; отчёт SIPREREGISTER2-REPORT.md сохранён. Круг 3 = волна 1626 на A1, восстанавливает по отчёту, с явным требованием держать клон вне wt-* и указать его путь. Дополнительно из приёмки круга 1: readiness НЕ должен засчитывать статический recovery-contact как живую регистрацию.

Круг 3 сдан: коммит eaab930c «prove registration recovery within deadline», база 70eb5014. Автор работал в клоне /home/wave/waves/nc-sipre3 ВНЕ wt-* (предписанный worktree вернул invalid reference) и восстановил содержимое утраченного круга 2 из уцелевшего checkout wt-1614-sipreregister2. Коммит вынут бандлом в /home/ubuntu/nc как sipre3-line. Приёмка = волна 1634 на A1, с отдельным требованием проверить негативом, что счётчик зарегистрированных в готовности не считает статический служебный recovery-контакт живой регистрацией (эту подмену нашла приёмка круга 1). Приёмке запрещено трогать живую телефонию — на ней идёт отладка звонков владельца.

04.09 координатор: в body добавлен блок «ЭВОЛЮЦИЯ 04.09.2026» — состояние, причина с доказательством, что село, что осталось, ловушки.

[06.09 09:49Z координатор] [2026-09-06T09:49Z координатор] WEB-509: волна 2241 (A2, luna) сдала 9ad8335c за 4 минуты (VERDICT=GO, отчёт 30 строк) — тонко; приёмка 2249-accweb509 с фейковым pnpm по 6 сценариям. WEB-508: волна 2240-web508-sipreload (A2, luna high) идёт — graceful reload + сохранение регистраций в репо-копии infra/sip; на хост — координатор в окне.

[06.09 10:38Z координатор] [2026-09-06T10:38Z координатор] WEB-508: автор 2240 сдал f3b3c1bb (GO) — graceful reload + persistent astdb + expiration/qualify в репо-копии infra/sip → приёмка 2269-accweb508 (A2). Хост-синк — координатор в окне после GO.

[06.09 10:48Z координатор] [2026-09-06T10:48Z координатор] WEB-508: приёмка 2269 = NO-GO f3b3c1bb только по scope (.gitignore и src/lib/telephony/asteriskSipSync.ts вне infra/sip; техника на моках прошла) → круг 2 = 2276-web508b (разделить на коммит A infra/sip + обоснованный коммит B).

[06.09 10:53Z координатор] [2026-09-06T10:53Z координатор] ИНЦИДЕНТ 10:48–10:51Z: кап Codex (OpenAI) исчерпан — «You've hit your usage limit… try again at Sep 9th, 2026 8:57 PM». Все codex-волны на A2/A1/M4 (в т. ч. 21 ревью Astra блока 18 и приёмки 2270/2272/2273/2275/2276/2277/2263) умерли без отчётов; Astra на M1 тоже ограничен. Владелец уведомлён (докупить кредиты / ждать 9.09). Критичные волны переведены на claude-opus в Anthropic-капе: 2275c приёмка фикса большого PDF, 2278c роли по живым ответам прода, 2272c revive-identity 5, 2270c C5-C круг 6, 2277 приёмка barge-in. Остальное стоит.

[06.09 11:07Z координатор] [2026-09-06T11:07Z координатор] WEB-508 круг 2: автор 2276b сдал серию b93d862f (коммит A 8c76aa7d = только infra/sip) — приёмка 2281-accweb508b (A2). Роли C5-C круг 6: автор 2270c (claude-opus) сдал 59d4f3ee (GO, 269 строк) — приёмка 2280-accrolesrefusal6 (A2, sol xhigh) с RED-наборами 2235/2265.

[06.09 11:33Z координатор] [2026-09-06T11:33Z координатор] ПРИНЯТО: роли C5-C круг 6 (2280 ACCROLESREFUSAL6, sol xhigh) = GO 59d4f3ee — детерминированный отказ на прямом отрицании предиката, judge для чужого предиката; RED-наборы 2235/2265 зелёные → кандидат l113f. WEB-508 круг 2 (2281 ACCWEB508B) = GO b93d862f (коммит A 8c76aa7d только infra/sip) → l113f; хост-синк в окне. Фикс большого PDF круг 2: автор 2285 сдал 76dcb114 (GO) → приёмка 2290 (sol, PG).

[06.09 12:42Z координатор] [2026-09-06T12:42Z координатор] ПОСАЖЕНО: ПРОД = l113f 221e8f39 (flip 12:39:47Z, без простоя; оба бэкенда ready, paid enforce_ready, edge 200×8; миграций новых нет (187/192); hetzbk l113f-221e8f39 + env-pack, Pi standby → l113f). Состав (15 коммитов над l113e): роли C5-C детерминированный отказ на прямом отрицании предиката (9fdfd6fe, 86afe601, 3ad54814, 59d4f3ee), WEB-541 SEC-024 retention contract (ebecd7f2, 3fd18f21), WEB-545 SEC-028 lighthouse headers (c4373797), WEB-509 gateway install (9ad8335c, репо-копия), WEB-463 barge-in + VAD env (0d7b50ee, 44ea7cea), WEB-542 rate-limit на client-account-generation (4891645b), WEB-508 SIP reload (8c76aa7d, b93d862f, репо-копия), WEB-506 куки-баннер (fc462e1d), периметр 500/embed (5837dd0f). Откат = l113e 65ff9060 (RUN l113e-65ff9060, REL arm64-l113e-20260906T101257Z). Снято с линии: WEB-560 merge (Prisma при импорте валил сборку → фикс 2309 → l113g). l113g: WEB-550 ed246cae, WEB-531 merge e8c97f1f, WEB-568 faf26ab9, revive5+499 42b61743, WEB-552 ecca7846 + ждущие: big-PDF r3, roles r3, backfill, 560 fix. Хост-синк SIP (508/509/463) — отдельное окно.

[06.09 13:20Z координатор] [2026-09-06T13:20Z координатор] ПРИНЯТО: WEB-560 build-fix — 2317 ACCWEB560BUILDFIX (sol xhigh, PG, импорт-тест phase-production-build) = GO 742066c1 → кандидат l113h (вместе с merge-цепочкой). На проде l113g после посадки: большой PDF cmtkm80jo… revive → pending (checkpoint 9801/9801 сохранён; ждём финализацию воркером); big-test 1782161239510l4gl4zzur revive → pending (revive-identity v5). SIP host-sync план (2315, A1) = GO: sync-plan.sh/rollback.sh, COPY allowlist 12, PATCH allowlist 6 — выполняю окном по плану.

[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:45Z координатор] [2026-09-06T13:44Z координатор] ОТКАТ ОКНА ТЕЛЕФОНИИ 13:47Z: после restart с синком 508 res_pjsip не загрузил ни одного объекта (transports/aors/endpoints=0; REGISTER 7016 → «No matching endpoint found») — и с sorcery.conf «contact = astdb,registrator» (опечатка), и с исправленным «registrar», и с пустым sorcery.conf. rollback.sh упал на своей проверке корня архива → откат вручную: infra-sip.tar + runtime-config.tar из бэкапа, удалены созданные файлы (список created-host-files.list) и drop-in 50-web508; restart → aors=3, endpoints=7, :4080 200 — состояние до окна. Barge-in (463) не активен. Evidence для 2322 в /home/ubuntu/waves/inputs/sip-hostsync-evidence/ (санитизировано). KNOWN ISSUES: (1) на A1 присутствие sorcery.conf ломает загрузку pjsip-конфига — причину искать (порядок #include/pjsip.conf vs sorcery, или res_sorcery_astdb отсутствует в сборке /home/pi/.local/asterisk); (2) rollback.sh v1 непригоден; (3) моки CLI не заменяют реальный Asterisk — приёмка 508 обязана поднимать asterisk на стенде.

[06.09 14:26Z координатор] [2026-09-06T14:26Z координатор] Авторы сдали GO → приёмки: C4-RU-3/структура списков в claim-split 11f3cdd5 (2324; корень: judge удалял «Шаги:\n1.», оставляя сиротский «2.»; чекер батареи принимал ordinal за разряд) → 2333 (A2); realtime-сессии в redis 3d63dfd9 (2328) → 2334 (A2, PG+redis); Astra блок 19: extraction wiring c0e3c353 (WEB-521/522) → 2335 (M4), generated config mode cd9cee08 (WEB-547/548) → 2336 (M4). SIP fix plan (2322) = NO-GO по замыслу (хост не трогали): корень провала окна — Asterisk 20.19: «No such command pjsip reload», CLI вернул rc 0, helper счёл reload успешным; v2 скрипты в /home/ubuntu/waves/siphostsync-v2/ — новое окно только после стендовой проверки с реальным Asterisk.

[06.09 14:56Z координатор] [2026-09-06T14:56Z координатор] На проде l113h: big-test 1782161239510l4gl4zzur после revive --new-attempt индексируется (status=running, checkpoint 3328/3932, attempts=2) — новый parent бюджета работает. SIP: независимое ревью v2 (2338) = процедура v3 готова (: reload = module reload res_pjsip.so с проверкой endpoints>0; фаза 0 backup/validate+check; фаза 1 reload-only apply; фаза 2 proof без владельца — UDP Digest REGISTER 401→200 и contact через module reload; фаза 3 restart только при необходимости) — выполняю фазу 0 (read-only) сейчас, окно фаз 1–2 следом.

[06.09 14:59Z координатор] [2026-09-06T14:59Z координатор] ОКНО ТЕЛЕФОНИИ v3 (14:57Z, A1): фаза 0 validate/check OK; фаза 1  = APPLY OK — v3 render path, module reload res_pjsip.so, endpoints=7, transports=3, PID Asterisk не изменился, AOR 7016 = 90/120/30 (цель WEB-508), :4080 200; бэкап /var/backups/ag-sip-native/20260906T145730Z-3911089-l113f-sync-v3. Фаза 2  = STOP «proof endpoint reload failed» (синтетический UDP-endpoint не появился после reload; runtime-файл восстановлен) — деплой оставлен (здоров по независимым проверкам), причина proof — в разбор. Фаза 3 (restart для активации barge-in WEB-463) — после подтверждения владельца.

[06.09 15:17Z координатор] [2026-09-06T15:17Z координатор] WEB-547 (Astra 2114 generated config mode): приёмка 2336 = NO-GO cd9cee08 — контракт http.conf/ari.conf верен, регрессия x64 explicit-root (status/stop считают conf root иначе, чем start) → круг 2 = 2356 (M4). SIP proof-диагноз (2347) = NO-GO: внутренняя причина STOP proof-reload.sh:130-132 не восстановима без защищённого reload-add.raw; статические гипотезы отвергнуты (append верный, include-порядок верный); расхождение 6 vs 7 endpoints — мой grep считал заголовок. Круг 2 = 2347b с добавленным evidence. Фаза 3 (restart для barge-in) ждёт «го» владельца с зарегистрированным Linphone. SEC-007 config assurance → 2355 (A1) с receipts-паком.

block22-relay9-adjudication-web-508 — 2026-09-06T23:52:21.455386+00:00 / IST=2026-09-07T05:22:21.455396+05:30

BLOCK22 RELAY-9: вердикты по доставленному пакету. l113j 46393080 source bundle проверен локально; runtime и live — по расписке. Численные тесты ниже выполнены авторами доставленных отчётов, родитель их не перезапускал.

SIPV33PREVALIDATE-REPORT.md — новый отчёт.
Вердикт: OFFLINE GO / LIVE NO-GO upheld. The v3.3 SIP restart-proof kit passes offline integrity and validation, but live window admission is blocked by missing exact backup validation, stale RUNBOOK backup path, and missing renderer-aware BARGEINRENDERFIX bundle/sync-plan.
Commit/base: Checked repo line 18f130938b8d2a8f4376811651ad21beb4e28838. Required renderer fix commit 28467587 was unavailable in that local line; l113j later contains replay 8e04c6432 for WEB-463. / /home/ubuntu/waves/wt-l113i-migrate at l113i 18f130938b8d2a8f4376811651ad21beb4e28838; kit directory /home/ubuntu/waves/siphostsync-v3.3.
Доказательства: sha256sum -c SHA256SUMS exit 0; ./proof-reload.sh --check --snapshot exit 0; ./restart-proof.sh --validate-only --snapshot exit 0; ./tests/offline-check.sh exit 0. Exact backup validate-only against /var/backups/... exit 1 due inaccessible root-only path.
Anchors: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:7; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:33; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:130; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:165; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md:436; /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/L113J-RELEASE-RECEIPT.md:18
KNOWN ISSUES / ТРАБЛШУТИНГ: No live backup VALIDATION OK, no updated RUNBOOK, no renderer-aware sync-plan, no 0 active calls/endpoints=6/7016 Avail/unit enablement proof, and no dialplan show 8000 post-check.
Действие: Proceed only through the existing SIPHOSTSYNCV4 coordinator lane after exact backup validation and renderer-aware bundle admission.
Report: /Users/poolpooly/audit/evidence/block22-relay9/intake-originals/a1/SIPV33PREVALIDATE-REPORT.md
SHA256: a97a0c060fbfb8591d22e912266783caf4e92de95bb0f4f62fb1c83b5663f59c

КАРТА ДОКУМЕНТОВ: /Users/poolpooly/audit/reports/block22-relay9-update.md; /Users/poolpooly/audit/evidence/block22/ledger46.json; /Users/poolpooly/audit/evidence/block22-relay9/adjudications.json. Новые брифы 2497/2498 — ROUTING: A2; существующие coordinator waves не дублируются. Правила обогащения: WEB-449.

Волна 2964, VERDICT=GO: перезагрузка PJSIP без рестарта нативного Asterisk; тест доказывает, что процесс переживает мягкую перезагрузку и существующие регистрации не сбрасываются, при этом полный рестарт остаётся возможным и явно отличается от мягкого. Фиксы f9cd0e7d2 + a92af2a51. Ждёт посадки в l113x.

Волна 2964, VERDICT=GO: перезагрузка PJSIP без рестарта нативного Asterisk; тест доказывает, что процесс переживает мягкую перезагрузку и существующие регистрации не сбрасываются, при этом полный рестарт остаётся возможным и явно отличается от мягкого. Фиксы f9cd0e7d2 + a92af2a51. Ждёт посадки в l113x.

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

[12.09 22:17Z координатор] МОЙКА 12.09 (3567-wash-g2-telephony-billing): код в репо есть (reload-sip-native.sh — мягкая перезагрузка без рестарта, принят в l113f и 2964), но на живом Asterisk persistence регистраций не доказана — хостовой sync откачен. Осталось: посадить 2964 и провести proof на реальном стенде. Статус не менять.
Остаток: Persistence регистраций после рестарта НЕ доказана (окно 13:31Z: контакт 0 в +152 с).; Host-sync (sync-plan.sh --apply) не доведён; rollback.sh v1 непригоден (неверный archive root).; Принятый 2964 (reload без рестарта) не посажен (ждёт l113x).; sorcery.conf на A1 ломает загрузку pjsip-конфига — причина не найдена.
Отчёт: /Users/milamarty/waves/3567WASH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/collected/. Проверка по исходнику прода l115g (9c8a9762).

[13.09 08:06Z координатор] РАЗБОР 13.09 (волна 3632, DeepSeek): Когда сервис телефонии перезапускают, все телефоны теряют регистрацию, и людям приходится самим переподключаться. Мы нашли, что фикс, который перезагружает настройки без полного перезапуска, уже лежит в коде, но его не включили на живом сервере. Главное, чего не хватает — доказать на настоящем Asterisk, а не в докер-игрушке, что регистрации действительно переживают перезагрузку. Мы расписали по шагам, как это проверить: снять состояние до, мягко перезагрузить, сравнить, и только в самом конце — с разрешения — полный перезапуск. И разобрали, почему файл sorcery.conf ломает загрузку настроек, с четырьмя гипотезами по порядку.
Остаток: Persistence регистраций после рестарта НЕ доказана на реальном Asterisk: существующий proof гоняется в Docker andrius/asterisk:latest (run-asterisk-registration-proof.sh:13), а не на сборке A1 20.19 (/home/pi/.local/asterisk).; Host-sync не доведён: sync-plan.sh/rollback.sh — хостовые инструменты, в репо отсутствуют; rollback.sh v1 непригоден (неверный archive root).; Принятый фикс 2964 (f9cd0e7d2+a92af2a51) в репо ЕСТЬ как cherry-pick 152194ee (предок HEAD), но НЕ синхронизирован на живой шлюз /home/pi/ag-voice.; sorcery.conf ломает загрузку pjsip-конфига — причина не найдена; зафиксированы 4 гипотезы по порядку (res_sorcery_astdb отсутствует / опечатка registrator / смена режима резолва об
Предложение: Применить мягкий reload (module reload res_pjsip.so) на реальном A1 Asterisk и провести proof-фазы 0-3: снимок до, reload без рестарта с проверкой PID/AOR 7016=90/120/30, UDP Digest REGISTER 401→200, полный рестарт только с GO владельца и фиксацией АВТОМАТИЧЕСКОЙ перерегистрации. Параллельно прогнать гипотезы sorcery.conf по порядку на сборке A1.
Материалы: shift-20260912-resume/colM2|colP2/ (RESULT.md — ранбуки и спецификации). Статус не меняю.

[13.09 10:37Z координатор] Мойка доски, волна 3654. RETURN. Фикс мягкого reload без рестарта в репо есть (2964 f9cd0e7d2+a92af2a51, cherry-pick 152194ee), но на живой шлюз не посажен и persistence регистраций на реальном Asterisk не доказана; sorcery.conf не разобран. Статус не меняю.

[13.09 12:02Z координатор] Волна 3681. RETURN. Фикс мягкого reload в репо есть (2964 f9cd0e7d2+a92af2a51, cherry-pick 152194ee), но на живой шлюз не посажен и persistence регистраций на реальном Asterisk не доказана (окно 13:31Z: контакт 0 в +152 с); sorcery.conf не разобран. Статус не меняю.

[13.09 13:22Z координатор] Взял карточку на себя после слова владельца «всё, что можешь сам — делай сам». Первый шаг сделан, и он дал честный промежуточный результат.
Снял состояние живой телефонной станции на A1 (Asterisk 20, служба ag-sip-native работает): исходящих регистраций ноль, контактов у абонентских точек ноль, точек настроено семь (7015 и 7016 в трёх доменах каждая).
Это значит, что доказать «регистрации переживают мягкий перезапуск» прямо сейчас НЕЛЬЗЯ: переживать нечему, ни один телефон сейчас не зарегистрирован. Прежний вывод карточки «после полного перезапуска контакт не восстановился» на этом фоне читается иначе: возможно, контакта не было и до перезапуска.
Что делаю дальше сам: на машине есть клиент baresip. Поднимаю им тестовую регистрацию на точку 7016, снимаю состояние, делаю мягкий перезагруз модуля без остановки службы, снимаю состояние снова. Если регистрация пережила — это и есть доказательство, и оно не требует ни твоего телефона, ни окна. Если не пережила — у нас впервые будет воспроизводимый случай, а не наблюдение задним числом.
Отдельно зафиксирую номер процесса станции до и после: при мягком перезагрузе он обязан не меняться.

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

Источники, проверенные отсюда: тело тикета из live API; все 28 комментариев из локального `web-board.sqlite`, последний комментарий `id=4788` от 2026-09-13T13:22:43.651Z. Статус на live API при финальной сверке: `in_progress`. A1/Asterisk live отсюда не проверялись.

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

После restart/reload телефонной службы SIP-регистрации исчезают, и владелец вручную передёргивает Linphone после посадок. Нужно доказать, что регистрации сохраняются или автоматически возвращаются.

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

В repo есть accepted soft reload fix: l113f `8c76aa7d/b93d862f`, wave 2964, cherry-pick `152194ee`. Host-window v3 доказал phase 1 soft module reload без смены PID и с healthy AOR по материалам карточки. Но comments `id=4371`, `id=4558`, `id=4648`, `id=4746` повторяют: live gateway sync откачен, real persistence not proven, sorcery.conf не разобран.

Поздний `id=4788` добавляет важный факт: на живой станции в момент проверки было zero outbound registrations and zero contacts, поэтому старый вывод “после restart contact 0” не доказывает, что restart его сбросил. Переживать было нечему.

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

Нужно получить воспроизводимую регистрацию, например через `baresip`, снять before/after, выполнить `module reload res_pjsip.so` без restart, доказать PID unchanged and AOR/contact stable. Полный restart - только с owner GO and observation of automatic re-registration. Отдельно решить sorcery.conf and rollback archive root.

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

Старый текст тела трактует `contact 0 in +152s` как доказательство failure после restart. Комментарий `id=4788` отменяет уверенность: возможно, контакта не было уже до restart. Также accepted repo fix не равен live sync: это явно повторено поздними мойками.

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

Смотреть: live A1 `/home/pi/ag-voice`, Asterisk `/home/pi/.local/asterisk`, `infra/sip/reload-sip-native.sh`, `proof-reload.sh`, `run-asterisk-registration-proof.sh`, procedure `3681-sip-registrations-persistence-out/PROOF-PROCEDURE.md`, hypothesis tree for sorcery.

Первый шаг: create controlled test registration with `baresip` for 7016, record PID/AOR/contact before, perform soft reload, record after. Only then discuss full restart.

Готово: real Asterisk proof exists for soft reload and full restart auto re-registration, with logs and RC; sorcery.conf root cause fixed; rollback path validated.

Нельзя: rely on Docker proof, do full restart without owner GO, blind-sync host files, expose ARI/SIP secrets, infer failure from an absent contact without before snapshot.

Размер: смена. Большим это делает live host proof, owner restart window and sorcery/rollback cleanup.

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

Не закрыто. Blocks/feeds WEB-565 and WEB-479; not a duplicate.

[14.09 16:35Z координатор] VERDICT=NO-GO

# WEB-508 — есть ли дефект «перезапуск ag-sip-native выбивает все SIP-регистрации»

Волна 3889. MODEL=deepseek-v4-pro EFFORT=high. BASE=refs/waves/l115n (d85bb2dad).
Ветка: wave/3889-web508-sip-persistence. Worktree: ~/waves/wt-3889-web508.

> Правила отчёта соблюдены: каждое число либо получено мной на одноразовом стенде,
> либо помечено «заявлено»; заявленное в тикете отличимо от доказанного.

---

## ДЛЯ ТИКЕТА (детским языком, полный след)

**Что говорит тикет (заявлено, не доказано).** Владелец говорит: «после перезапуска
ag-sip-native телефон перестаёт звонить, пока я вручную не передёрну Linphone».
Из этого делается вывод «рестарт выбивает ВСЕ SIP-регистрации».

**Почему это не доказательство.** В тикете приведён только замер числа контактов
**ПОСЛЕ** рестарта («0 в +152 с»). Замера **ДО** рестарта нет. Если контактов не было
и до рестарта, то «0 после» ничего не доказывает — это ровно то, что сказано в
комментарии `id=4788` и процитировано в брифе. Чтобы доказать симптом, нужно
«ДО = N>0, ПОСЛЕ = 0 и не возвращается» — такого замера в тикете нет.

**Что я сделал.** Я не трогал живой шлюз A1 (запрещено, он в проде и разошёлся с
репозиторием). Я собрал одноразовый Docker-Asterisk на этой машине, в точности с
маппингом из репозитория и с продакшен-настройками истечения регистрации, и проверил
главный вопрос: **переживает ли зарегистрированный контакт настоящий рестарт процесса?**

**Что получилось (числа получены мной).** На Asterisk 20.20.1 (ближайший стенд к A1,
там 20.19) и на 22.10.1, во всех трёх вариантах конфигурации (без sorcery.conf, с
репозиторным `registrator`, с исправленным `registrar`) результат одинаковый:

- REGISTER → `SIP/2.0 200 OK`, контактов до рестарта = **1**;
- реальный рестарт (docker `StartedAt` сменился, это доказано) → контактов после = **1**.

То есть **из кода репозитория дефект не воспроизводится: контакт переживает рестарт.**

**Про «registrator».** В репозитории `sorcery.conf:5` пишет `contact = astdb,registrator`.
Это НЕ опечатка, ломающая персистентность: эксперимент доказал, что с `registrator`
контакт так же переживает рестарт, как и с `registrar`. Разница только в имени
семейства ключей в AstDB (`/registrator/contact/…` вместо `/registrar/contact/…`).
Это косметика: в репозитории ничто не читает эти ключи по имени семейства (проверено
grep-ом), так что имя ни на что не влияет.

**Где граница.** Доказано: персистентность регистраций из репо работает на чистом
Asterisk 20.x/22.x. НЕ доказано и не воспроизводится: сам симптом тикета. Если на A1
он всё же есть — причина не в репозитории, а в расхождении живого шлюза с репо (там
разъехались ~2500 строк, Asterisk 20.19) либо в замере только ПОСЛЕ.

**Вывод для тикета.** Прежде чем «чинить», нужен один замер на живом A1: снять
`pjsip show contacts` ДО рестарта (должно быть N>0 живых динамических контактов),
потом перезапустить, потом снять ПОСЛЕ каждые 10 с до +180 с. Только если «ДО>0,
ПОСЛЕ=0 и не возвращается» — дефект доказан, и тогда копать надо в расхождении A1 с
репо, а не в репозитории.

---

## 0. Заявленное vs доказанное

**Заявлено (тикет, комментарий `id=2303`, окно 13:31–13:38Z 06.09):** после рестарта
контакт не восстановился («0 в +152 с»). Тот же комментарий упоминает, что «контакт
7016 пережил reload» — это про мягкую перезагрузку (reload), а не про рестарт.

**Доказано (мной, на одноразовом стенде):** смотри раздел «ЭКСПЕРИМЕНТ» ниже. Кратко —
контакт 1→1 переживает полный рестарт процесса на Asterisk 20.20.1 и 22.10.1 во всех
вариантах конфигурации.

**Не доказано:** что на живом A1 рестарт реально выбивает контакты (нет замера ДО).

---

## 1. Где живут регистрации (проверено чтением кода)

Регистрации (динамические контакты PJSIP) — состояние процесса Asterisk (память).
Поверх памяти в репозитории ЗАДУМАНА и РЕАЛИЗОВАНА запись в AstDB (файл на диске)
через sorcery-маппинг, чтобы контакты переживали рестарт. Realtime/БД не задействован.

Конкретные места:

- `infra/sip/asterisk-conf/sorcery.conf:1-5` — намерение и маппинг:
  ```
  ; Keep registrar-created PJSIP contacts across an Asterisk process restart.
  [res_pjsip]
  contact = astdb,registrator
  ```
- `infra/sip/start-sip-native.sh:51-53` — «Registrations are state, not generated
  config. Keep AstDB out of /tmp so an ordinary launcher restart cannot erase
  PJSIP contacts.»
- `infra/sip/start-sip-native.sh:320-321` — `cp sorcery.conf` в генерируемый каталог конфигурации.
- `infra/sip/start-sip-native.sh:445-461` — выбор `SIP_NATIVE_STATE_DIR` (постоянный, не /tmp).
- `infra/sip/start-sip-native.sh:466-472` — `asterisk.conf` получает
  `astdbdir => $SIP_NATIVE_STATE_DIR` и `astkeydir => $SIP_NATIVE_STATE_DIR`.
- `infra/sip/README.md:43-75` — раздел «Reload vs restart»; «Registrations are
  persisted by Sorcery's `contact=astdb,registrator` mapping».

**Что из этого следует.** По умолчанию (без sorcery-маппинга) Asterisk держит
динамические контакты в памяти, и при рестарте они пропадают. Репозиторий это обходит
через AstDB. Эксперимент (раздел «ЭКСПЕРИМЕНТ») подтверждает, что этот обход **работает**:
контакт, записанный в `astdb.sqlite3`, после полного рестарта снова появляется в
`pjsip show contacts`.

**Про `registrator` (не опечатка).** `registrator` в `sorcery.conf:5` и `README.md:66`
— это имя семейства ключей AstDB, а не имя визарда. Эксперимент доказал: с `registrator`
контакт переживает рестарт так же, как с `registrar` (ключ в `/registrator/contact/…`
вместо `/registrar/contact/…`). В репозитории ни один файл не читает эти ключи по имени
семейства (grep по `registrar`/`registrator`/`astdb` — только конфиг каталогов и текст
документации), поэтому на поведение персистентности имя не влияет. Это косметическое
расхождение, а не дефект.

---

## 2. Доказательство перезапуска в дереве — что оно реально проверяет

`infra/sip/tests/asterisk-registration-reload.test.mjs` → запускает
`infra/sip/tests/run-asterisk-registration-proof.sh` (одноразовый Docker-Asterisk).

Что проверяется и что НЕ проверяется:

- `run-asterisk-registration-proof.sh:246-250` — контакт регистрируется (REGISTER 7001),
  `pjsip show contacts` читается ДО.
- `:271-281` — мягкая перезагрузка (`reload-sip-native.sh`): PID не меняется, контакты те же.
- `:284-296` — негатив: сломанный конфиг блокируется до CLI, контакты не меняются.
- `:324-330` — полный рестарт: проверяется ТОЛЬКО `RESTART_START != BEFORE_START`
  (что рестарт отличим от мягкой перезагрузки). **Число контактов после рестарта
  не измеряется вообще.**
- В конфиге этого proof **нет `sorcery.conf`** — контакты там живут только в памяти.

**Итог п.2:** существующий автотест доказывает «мягкая перезагрузка сохраняет контакты»
и «рестарт — это отдельный путь». Он НЕ доказывает «регистрации переживают рестарт».
Это ровно та дыра, на которую указывает тикет. **Дыра закрыта в этой волне** — добавлен
`infra/sip/tests/run-asterisk-restart-persistence-proof.sh` (и обёртка
`asterisk-restart-persistence.test.mjs`): он кладёт репозиторный `sorcery.conf`,
регистрирует контакт, меряет его ДО, делает настоящий рестарт, меряет ПОСЛЕ и требует
выживания. Тест проходит (`node --test`, без сборки).

---

## 3. Два устройства хранения (диск / база) и чем плохо каждое

Если решено, что регистрации ДОЛЖНЫ переживать рестарт, есть два устройства:

**А. AstDB на диске (то, что уже сделано в репо).**
- Чем плохо: AstDB — плоский key-value файл (`astdb.sqlite3`). При SIGKILL возможна
  рассинхронизация; контакт хранит IP:port абонента, которые за окно простоя устаревают
  (NAT сменил адрес) — Asterisk может вернуть «живой» контакт с мёртвым адресом, пока
  qualify/перерегистрация не обновит. Плюс: локально, без внешней зависимости, дёшево.

**Б. Realtime в базе (res_sorcery_realtime, таблица ps_contacts).**
- Чем плохо: добавляет внешнюю зависимость (БД) в критический путь регистрации;
  если БД недоступна — регистрации падают вместе с ней; нужны схема, миграции,
  доступы, репликация. Тяжелее и дороже, чем сам гейтвей.

**Граница решения.** Хранить регистрации на диске/в базе нужно только если требование
«рестарт не должен выбивать регистрации» — продуктовое. Репозиторий его уже реализует
через AstDB, и эксперимент это подтверждает. Если допустимо, что после рестарта абоненты
сами перерегистрируются в пределах окна expiry (см. п.4) — хранение не нужно вовсе.

---

## 4. Как ведут себя абоненты (перерегистрация) и настраивается ли это

Параметры перерегистрации — в двух местах, оба в дереве:

- `infra/sip/asterisk-conf/pjsip-compact-defaults.conf:27-29` (шаблон ручных AOR):
  `default_expiration = 90`, `maximum_expiration = 120`, `qualify_frequency = 30`.
- `src/lib/telephony/asteriskSipSync.ts:340-342` (рендер динамических AOR, которыми
  владеет приложение): те же `90 / 120 / 30`.
- Тест фиксирует контракт: `src/lib/telephony/__tests__/asteriskSipSync.reload.test.ts:24-26`.

**Что это значит.** `default_expiration=90` — если клиент шлёт REGISTER без `Expires`,
Asterisk выдаёт ему 90 с; `maximum_expiration=120` — потолок, дольше 120 с контакт не
живёт. Здоровый клиент обычно перерегистрируется на ~половине expiry. То есть при этих
настройках здоровый абонент должен сам вернуться **в пределах ~45–120 с** после рестарта,
БЕЗ всякого «подталкивания». Это настраивается (числа правятся в двух файлах выше).

**Ключевой вопрос.** Если после рестарта абонент НЕ вернулся через 152 с (как заявлено),
то при `maximum_expiration=120` это значит одно из двух: (а) его не было ДО рестарта
(симптом не доказан), либо (б) клиент не перерегистрировался, хотя должен был — и тогда
это дефект НЕ «потеря при рестарте», а «окно слепоты/неререгистрация» (клиентский
таймер, либо Asterisk не принял REGISTER — в тикете был случай «No matching endpoint
found», комментарий `id=2308`). Это разные дефекты и разная починка.

---

## 5. Воспроизведение на одноразовом стенде (без живого шлюза) — ВЫПОЛНЕНО

Docker на этой машине доступен. Живой шлюз A1 не затрагивался. Ниже — фактические
результаты, все числа получены лично. Логи и скрипты лежат в
`~/waves/3889WEB508-evidence/` (с SHA256SUMS). Отдельно в дерево добавлен автотест
`infra/sip/tests/asterisk-restart-persistence.test.mjs` (см. п.2).

---

## ЭКСПЕРИМЕНТ (одноразовый стенд) — фактический результат

Методика: одноразовый контейнер Asterisk, конфиг с продакшен-AOR (90/120/30),
REGISTER 7001 по Digest (401→200), снять `pjsip show contacts` ДО, `docker restart`
(настоящий рестарт процесса), снять ПОСЛЕ. Рестарт подтверждается сменой
`docker inspect .State.StartedAt`.

| Стенд | Вариант sorcery | REGISTER | контактов ДО | контактов ПОСЛЕ | рестарт подтверждён |
|---|---|---|---|---|---|
| Asterisk 22.10.1 | без sorcery.conf (default) | 200 OK | 1 | 1 | StartedAt сменился |
| Asterisk 22.10.1 | `registrator` (репо) | 200 OK | 1 | 1 | StartedAt сменился |
| Asterisk 22.10.1 | `registrar` | 200 OK | 1 | 1 | StartedAt сменился |
| Asterisk 20.20.1 (≈A1 20.19) | без sorcery.conf (default) | 200 OK | 1 | 1 | StartedAt сменился |
| Asterisk 20.20.1 (≈A1 20.19) | `registrator` (репо) | 200 OK | 1 | 1 | StartedAt сменился |
| Asterisk 20.20.1 (≈A1 20.19) | `registrar` | 200 OK | 1 | 1 | StartedAt сменился |

Дополнительно (Asterisk 22.10.1) доказано по факту:

- контакт физически пишется на диск в `/var/lib/asterisk/astdb.sqlite3` (12288 байт +
  journal) — файл есть ДО рестарта;
- семейство ключа зависит от имени в маппинге: default → `/registrar/contact/…`,
  `registrator` → `/registrator/contact/…`, `registrar` → `/registrar/contact/…`;
  во всех случаях контакт переживает рестарт;
- airtight-проверка рестарта: `StartedAt` сменился (например, 16:25:57 → 16:26:00),
  т.е. это реальный перезапуск процесса, а не мягкая перезагрузка.

**Вывод эксперимента:** из кода репозитория дефект не воспроизводится. Контакт
переживает полный рестарт процесса на чистом Asterisk 20.x/22.x во всех вариантах
конфигурации. «registrator» — не ломающая опечатка, а имя семейства AstDB (косметика).

---

## ГДЕ ГРАНИЦА (для нулевого агента)

- Доказано чтением: регистрации — состояние процесса; в репо реализована и
  подтверждена персистентность в AstDB (`sorcery.conf` → `astdbdir` в state-dir).
- Доказано экспериментом (мной): контакт 1→1 переживает полный рестарт на Asterisk
  20.20.1 и 22.10.1 во всех вариантах конфигурации; `registrator` не ломает.
- НЕ доказано: что на живом A1 рестарт реально выбивает контакты (нет замера ДО);
  причина симптома на A1, если он есть, лежит в расхождении живого шлюза с репо
  (~2500 строк разъехались, Asterisk 20.19), а не в репозитории.
- Не трогалось (по запрету): живой шлюз A1, прод, БД, любые чужие деревья.

## ЧТО ОСТАЛОСЬ ОТКРЫТЫМ

1. Замер ДО/ПОСЛЕ рестарта на живом A1 (сценарий в разделе «ДЛЯ ТИКЕТА»). Только он
   решает, есть ли дефект на живом шлюзе.
2. Если на A1 симптом подтвердится — разобрать расхождение A1 с репо (что именно
   разъехалось в ~2500 строках, какая версия конфига там реально работает).
3. Возвращается ли клиент сам в пределах 120 с; если нет — почему (клиентский таймер
   vs «No matching endpoint found», комментарий `id=2308`).

## TROUBLESHOOTER (для оператора)

- Хочешь показать «выбило регистрации»: сначала `asterisk -rx "pjsip show contacts"`
  ДО рестарта и сохрани список URI; иначе «0 после» ничего не значит.
- Не путай `systemctl reload ag-sip-native.service` (мягко, контакты живы) и
  `systemctl restart` (убивает Asterisk; контакты возвращаются из AstDB, если
  `astdbdir` в постоянном state-dir и есть `contact=astdb,…` в sorcery.conf).
- Смотри на `maximum_expiration=120`: если клиент здоров, он вернётся сам ≤120 с.

## KNOWN ISSUES

- `infra/sip/asterisk-conf/sorcery.conf:5` и `infra/sip/README.md:66`: `registrator` —
  косметическое имя семейства AstDB, не ломает персистентность (доказано), но имя
  `registrar` было бы единообразнее; в дереве нет валидатора имени визарда/семейства.
- `infra/sip/tests/run-asterisk-registration-proof.sh`: proof рестарта не меряет
  контакты после рестарта и не кладёт `sorcery.conf` — дыра покрытия. Закрыта новым
  `run-asterisk-restart-persistence-proof.sh`.
- В тикете нет замера числа контактов ДО рестарта (симптом не доказан).

ENRICH-4132-WEB-508
```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`**. Существеннее другое: 14.09 волна 3889
дала **NO-GO по самому симптому тикета** — в репозитории дефект не воспроизводится, а замер
в теле неполный. В теле этого нет.

### 2. КАРТА ДОКАЗАТЕЛЬСТВ
- Тело: фикс мягкого reload (`module reload res_pjsip.so`) в репо ЕСТЬ — принят в l113f
  (`8c76aa7d`/`b93d862f`, приёмка 2281 GO) и волной 2964 (`f9cd0e7d2`+`a92af2a51` = GO);
  в текущей линии присутствует как cherry-pick `152194ee` (предок HEAD). НО на живой шлюз
  `/home/pi/ag-voice` НЕ синхронизирован (`host-sync sync-plan.sh --apply` откачен 13:47Z 06.09).
- Тело: persistence регистраций на РЕАЛЬНОМ Asterisk 20.19 (`/home/pi/.local/asterisk`) не
  доказана; окно 13:31Z 06.09 — после полного рестарта контакт 7016 = 0 в +152 с.
- Тело: существующий proof гоняется в Docker `andrius/asterisk:latest`
  (`run-asterisk-registration-proof.sh:13`), а не на сборке A1. `sync-plan.sh`/`rollback.sh` —
  хостовые инструменты, в репо отсутствуют.
- Доска WEB-508 id 5076 (2026-09-14T16:35:39.549Z), волна 3889, VERDICT=NO-GO,
  BASE=refs/waves/l115n (`d85bb2dad`), ветка `wave/3889-web508-sip-persistence`, worktree
  `~/waves/wt-3889-web508`. Дословно: «В тикете приведён только замер числа контактов ПОСЛЕ
  рестарта („0 в +152 с“). Замера ДО рестарта нет… Чтобы доказать симптом, нужно „ДО = N>0,
  ПОСЛЕ = 0 и не возвращается“ — такого замера в тикете нет.»
- На одноразовом Docker-Asterisk (20.20.1 и 22.10.1, три варианта конфигурации): REGISTER →
  `SIP/2.0 200 OK`, контактов до рестарта = **1**, реальный рестарт (смена docker `StartedAt`)
  → контактов после = **1**. То есть «контакт переживает рестарт».
- `sorcery.conf:5` пишет `contact = astdb,registrator` — это НЕ опечатка: с `registrator`
  контакт так же переживает рестарт; разница только в имени семейства ключей в AstDB
  (`/registrator/contact/…`), и в репозитории ничто не читает их по имени семейства (проверено grep).
- HANDOFF-LIVE.md §6д строки 597–610: фикс, исполняемый вне артефакта, нельзя закрывать по
  «коммит попал в линию»; живой шлюз `/home/pi/ag-voice` фикса не получил (WEB-607 ПЕРЕОТКРЫТ).

### 3. ЭВОЛЮЦИЯ / ПОПРАВКИ (append-only)
- Якорь: l115j `133fe00c` → **l115o `68e25d8df5ae8263c5ac5466353631f57a17cfcc`**.
- 14.09 волна 3889: NO-GO. Репозиторный дефект не воспроизводится на чистом Asterisk 20.x/22.x.
  Граница: доказано, что персистентность из репо работает; НЕ доказан и не воспроизведён сам
  симптом тикета. Если на A1 он есть — причина не в репозитории, а в расхождении живого шлюза
  с репо (там разъехались ~2500 строк, Asterisk 20.19) либо в замере только ПОСЛЕ.
- Формулировка тела «после полного рестарта контакт 7016 = 0 в +152 с» недостаточна как
  доказательство и не должна читаться как доказанная причина.

### 4. KNOWN ISSUES / ТРАБЛШУТИНГ
1. **Замер «только ПОСЛЕ» выдаётся за доказательство дефекта.**
   - Симптом: «0 контактов после рестарта» читается как «рестарт выбивает все регистрации».
   - Проверка за 2 минуты: на живом A1 снять `pjsip show contacts` **ДО** рестарта (ожидание
     N>0 живых динамических контактов), затем рестарт, затем снимать **ПОСЛЕ** каждые 10 с
     до +180 с. Дефект доказан только при «ДО>0, ПОСЛЕ=0 и не возвращается».
   - Причина: в карточке нет замера ДО; без него «0 после» не значит ничего.
   - Лечение/статус: сначала замер, потом починка. Копать в расхождении A1 с репо, не в репозитории.
   - Ссылки: доска WEB-508 id 5076.
2. **`registrator` в `sorcery.conf` читается как опечатка.**
   - Симптом: «нашли опечатку, ломающую персистентность».
   - Проверка за 2 минуты: `grep -rn 'registrator' infra/...` и проверка, читает ли кто-то ключи
     по имени семейства → ожидание: никто не читает.
   - Причина: имя семейства ключей в AstDB отличается, поведение — нет (доказано экспериментом).
   - Лечение/статус: косметика, не чинить «на всякий случай».
3. **Хостовые инструменты вне репозитория.** `sync-plan.sh`/`rollback.sh` — хостовые, в репо их
   нет; синхронизация живого шлюза — зона координатора (правило 11 канона).

### 5. ТЕКУЩИЙ ОСТАТОК (ответственный)
1. Один замер на живом A1 по схеме «ДО → рестарт → ПОСЛЕ до +180 с» — координатор
   (нужно окно владельца ~5 минут, чтобы телефон не трогали).
2. Синхронизация живого шлюза `/home/pi/ag-voice` с фиксом — координатор (после замера).
3. Только после доказанного симптома — починка в расхождении A1↔репо, не в репозитории.

### 6. ПЕРВЫЙ ШАГ НУЛЕВОГО АГЕНТА (без агентов)
Не трогая живой шлюз, открыть `run-asterisk-registration-proof.sh` и прочитать, что именно он
доказывает (Docker, не A1). Затем записать в карточку: доказательства симптома нет, нужен один
замер ДО/ПОСЛЕ на живом A1. Сверить якорь тела с живым `/api/ready`.
```

---

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=комментарий 5462 от 15.09: волна 3889 дала NO-GO; Docker доказал 1→1, но симптом A1 без замера ДО не доказан
ЧТО НУЖНО=координатору снять на живом A1 замер ДО→рестарт→ПОСЛЕ до +180 с, затем при подтверждении синхронизировать шлюз и разобрать расхождение
triage-m1 4609

РЕШЕНИЕ=parked
ОСНОВАНИЕ=2026-09-15, волна 4132 DRAFT_DELTA после NO-GO 3889 от 14.09: текущая линия l115o 68e25d8d; persistence на A1 не доказана, движения волны нет ≥7 дней
ЧТО НУЖНО=ЖДЁТ=владелец: дать 5-минутное окно и не трогать телефон для замера ДО→рестарт→ПОСЛЕ; triage-neo 4707