WEB board

[02.09 06:05Z Фабл] Ключевая находка: живой SIP-шлюз A1 = /home/pi/ag-voice (не git, файлы 05.07), службы ag-sip-native (:5060) и ag-sip-native-opus-experimental (:5074), два Asterisk с раздельными astdb. Код шлюза не совпадает ни с одной версией в репо (audiosocketTransport.js live md5 1c3d02aa отсутствует в истории) и со снапшотом 30.08. Поэтому ВСЕ телефонные фиксы линий l6x–l88 (web15g, WEB393J наблюдаемость, greeting «Six by Y», bargein/bargein2) до живого 8000/8010 не доехали — owner слышит «this service» и не может перебить. Волна 1141-sipreconcile: классификация расхождений, перенос live-only правок в репо, кандидат живого дерева с фиксами, ранбук посадки/отката (рестарт только под GO). Затрагивает WEB-463, WEB-464, WEB-318.

[02.09 07:05Z Фабл] 1141-sipreconcile сдан (8dcedb1f37): live↔l88 gateway diff 254 hunks → 16 semantic live-only (сохранены), перенесены 5 repo-фиксов (bargein 91300bb2, bargein2 0f08d87a, greeting fbcff892, 393J f3d7ddfa, web15g 12704970) + lane-auth/ARI guards; кандидат /home/ubuntu/waves/sip-landing/ag-voice-gateway-l88; probe перебивания 8/8 на кандидате; структурный suite 66/68 (2 ожидаемых конфликта l88-контрактов с July-live). Топология: native :5060 → AGI 4573, opus-experimental :5074 → AGI 4673; оба грузят один путь /home/pi/ag-voice/infra/sip/gateway. Ранбук SIPRECONCILE-RUNBOOK.md: backup → copy → restart → проверка → откат; перевод 8000 на Stasis — отдельный GO. Приёмка 1145 (сухой старт кандидата на свободных портах, негативы по секретам, сохранение live-поведения) → посадка.

[02.09 06:50Z Фабл] Приёмка 1145-accsipreconcile: NO-GO до A1. PASS: сухой старт кандидата на свободных портах (health 200, readiness ready, SIP reachable как у живого), probe перебивания 8/8, 6 рискованных live-only областей PRESERVED (audiohook/lead-proxy, pseudo-agent 9090/9292, cached greeting+DTMF, room/PIN, playback graph, eager provider startup), greeting без старых имён, отказ без секретов. БЛОКЕРЫ: полный gateway suite 172/176 — 2 падения activePassiveLeasePreflight (контракт active-passive lease WEB-370/405 перенесён неполно) + 2 известных статических конфликта July-live↔l88; ранбук: dialplan-команды без context [internal] и без пути asterisk. Доработка 1146-sipreconcile2 → ре-приёмка → посадка шлюза.

[02.09 07:20Z Фабл] 1146-sipreconcile2 сдан (6f148c919e): в кандидат возвращён полный active/passive lease preflight l88 (fail-closed при LEASE_REQUIRED=1, дефолт 0 для одного стека), pseudo-agent через /me-bridge/enqueue вместо приватного Prisma, execution checkpoints; suite 174/176 + 2 skip с причинами (оба в stasisBargeInSafety.test.js — статические конфликты July-live↔l88); probe 8/8; ранбук исправлен (dialplan @internal, путь asterisk). Ре-приёмка 1148 (codex, сухой старт + негатив lease) → посадка шлюза.

[02.09 07:30Z Фабл] Ре-приёмка 1148-accsipreconcile2: NO-GO (сухой старт ok, lease/suite ok) — новый блокер: 9090 pseudo-agent по умолчанию шлёт originChannel=lead-live, а прод-роут me-bridge/enqueue (l89) принимает только web/web2 → 422 до enqueue; 9292 (web2) проходит. Доработка 1149-sipreconcile3 (дефолт web2 + override env, app-роут не трогаем) → ре-приёмка → посадка.

[02.09 08:00Z Фабл] 1149-sipreconcile3 сдан (b540c15d20): 9090 без env → originChannel=web2 (override SIP_9090_ORIGIN_CHANNEL сохранён, key=lead-live/originChatId для различения от 9292), app-роут не тронут; тест против скомпилированного прод-роута l89; кандидат обновлён (mirrors/lines/ag-voice-gateway-l88-candidate-b540c15d20.tar.gz). Финальная ре-приёмка 1151 (codex) → посадка шлюза по ранбуку с предупреждением owner-а.

[02.09 08:00Z Фабл] Посадка SIP-кандидата b540c15d20 (после GO приёмки 1151) ПРОВАЛИЛАСЬ: ag-sip-native не поднялся — `Cannot find module ../../../config/telephony-security-policy.json` (кандидат импортирует файл из корня репо, которого нет в /home/pi/ag-voice); супервизор перед стартом гоняет `pnpm install` (падает). Откат из backup gateway-20260902T075543Z.tar.gz за 2 мин, живое восстановлено (health/readiness ok, 0 звонков затронуто). Причина пропуска в приёмках 1145/1151: сухой старт шёл с временным require-hook для repo-relative импортов. Журнал: A1 /home/ubuntu/waves/SIPLANDING-FAIL-20260902T0756Z.log; упавшая копия /home/pi/ag-voice/infra/sip/gateway.landed-failed. Доработка 1154-sipreconcile4 (самодостаточный кандидат + честный сухой старт без подпорок) → ре-приёмка → повтор посадки. Owner предупреждён (звонить пока не нужно).

[02.09 08:45Z Фабл] 1154-sipreconcile4 сдан (a7d51b0367): 6 внешних импортов кандидата (config/telephony-security-policy.json, src/lib/temporal/futureDatedNews, src/lib/realtime/assistantSpeechEpoch ×3, roomAudioReadyPayload) перенесены в infra/sip/gateway/vendor/ с README и SHA источников; EXTERNAL_IMPORTS=0. Приёмка 1166 (codex) с ЧЕСТНЫМ сухим стартом: копия всего /home/pi/ag-voice + rsync кандидата как в ранбуке + запуск командной строкой супервизора с живым env, без require-hook; require.resolve по всем модулям. После GO — повтор посадки (owner предупредить). Бандл mirrors/lines/sipreconcile4-1154-a7d51b0367.bundle, архив кандидата ag-voice-gateway-l88-candidate-a7d51b0367.tar.gz.

[02.09 09:00Z Фабл] Приёмка 1166-accsipreconcile4: NO-GO по единственному пункту — в greeting pseudo-agent 9292 (infra/sip/gateway/index.js:241) осталось старое имя «me two»; всё остальное PASS, включая ЧЕСТНЫЙ сухой старт без хуков (DRY_START_NOHOOK=ok), самодостаточность (EXTERNAL_IMPORTS=0), suite, probe. Координатор поправил строку (коммит 145618713a, ветка sipreconcile5-1170, бандл mirrors/lines/sipreconcile5-1170-145618713a.bundle), кандидат синхронизирован. Быстрая ре-приёмка 1171 (codex) → посадка по ранбуку с предупреждением owner-а. Параллельно: инцидент WEB-472 (волна с sudo сломала пароль боевой БД) — guard поставлен, волны без sudo.

[02.09 09:12Z Фабл] ПОСАЖЕНО на A1: кандидат живого SIP-шлюза 145618713a (1171 GO, честный сухой старт без хуков) — backup /home/pi/ag-voice/infra/sip/backups/gateway-20260902T090941Z.tar.gz, rsync в /home/pi/ag-voice/infra/sip/gateway, node --check + require.resolve всех внешних модулей до рестарта, restart ag-sip-native (health ok, readiness ready, порты 5060/4080/4573), затем ag-sip-native-opus-experimental (5074/4180/4673). 8000 остаётся AGI (по ранбуку §7 перевод на live — отдельный шаг, кандидат dialplan готовит 1164-lane8000). Owner попрошен позвонить на 8000 (ожидание: приветствие «Six by Y»; голосовое перебивание — только после перевода 8000 на live-плечо). В шлюзе теперь: bargein 91300bb2 + bargein2 0f08d87a, greeting fbcff892, 393J f3d7ddfa, web15g 12704970, lease-preflight, vendored импорты, 9090→web2.

[02.09 09:35Z Фабл] boot-env-contract (3 замечания /api/ready=503): кандидат 1160-bootenv3 ec053c8fc4 (сужение dev-маркера, PREVIOUS-ключ none/unset, BLUEBUBBLES необязателен при закрытой зоне, warn≠unready; tests 62/62) → приёмка 1176; ENV_ACTIONS для координатора при посадке l90: убрать stale BLUEBUBBLES_SERVER_PASSWORD (зона messenger-bridges исключена на A1), SOCIAL_ENCRYPTION_KEY_PREVIOUS → unset/none, DATABASE_URL — без изменений (noteclone допустим после фикса).

[02.09 09:45Z Фабл] Приёмка 1176-accbootenv3: FAIL — два негатива дырявые: (1) SOCIAL_ENCRYPTION_KEY_PREVIOUS с dev-маркером в длинном значении принимается; (2) при открытой зоне messenger-bridges (PROD_EXCLUDED_ZONES=none) отсутствующий BLUEBUBBLES_SERVER_PASSWORD принимается. Остальное (DATABASE_URL-маркер, warn≠unready, 62/62) ок. Доработка 1177-bootenv4 → ре-приёмка → l90.

[02.09 09:45Z Фабл] 1177-bootenv4 сдан (de4becc2f5): длинный PREVIOUS-ключ с dev-маркером → bad_secret_format (unset/none ок); BLUEBUBBLES_SERVER_PASSWORD при открытой зоне messenger-bridges → missing_conditional (fatal в production enforce), при исключённой — не требуется. Ре-приёмка 1180 → l90. Бандл mirrors/lines/bootenv4-1177-de4becc2f5.bundle.

[02.09 10:45Z Фабл] (1) 1180-accbootenv4 PASS (de4becc2f5; матрица 20/20, boot-contract 70/70) → в l90: c172842ca + 1052d16cc. (2) ИНЦИДЕНТ 09:50Z: после посадки шлюза owner на 8000 получил «This line is protected by a PIN» — флаг pinRequired приходит из приложения при старте сессии; новый appSessionHttpClient шлёт другие поля идентичности (laneClaim/originChannel/userId). ОТКАТ к backups/gateway-20260902T090941Z.tar.gz выполнен 09:58Z (оба стека, health/readiness ok), упавшая копия сохранена как gateway.landed-pin. Диагностика+фикс: 1184-sippin (Luna). Повторная посадка после.

[02.09 11:10Z Фабл] КОРЕНЬ PIN на 8000: приложение с l87 (WEB393J f3d7ddfa88, sessionStart.ts resolveTrustedLaneClaim) требует lane-claim от шлюза и берёт секрет из TELEPHONY_LANE_CLAIM_SECRET — в env прода его НЕ БЫЛО → lane_claim_rejected (secret_not_configured) → сессия в PIN-режим → verify-pin: endpoint_pin_missing. Старый шлюз lane-claim не шлёт вовсе (0 упоминаний), т.е. 8000 был сломан для l87+ с 04:10Z независимо от посадки шлюза. Фикс 10:03Z: сгенерирован секрет (40 симв.), добавлен в /home/ubuntu/prod/shared/.env.local (бэкап .bak-laneclaim-20260902) и /home/pi/ag-voice/.env (бэкап), nc-a1 перезапущен (paid true), шлюз-кандидат 145618713a посажен повторно (backup gateway-20260902T100303Z), оба стека с секретом в environ. Ошибка того же класса, что landing-must-inventory-server-env-not-just-nextpublic. Owner попрошен позвонить. Волна 1184-sippin продолжает независимую проверку.

[02.09 11:40Z Фабл] Вторая половина PIN: даже с секретом приложение отвечало lane_claim_rejected (missing) — legacy-путь 8000 в шлюзе вызывал appClient.startSession(body, key) без trustedRoute, т.е. без lane-claim; приложение открывает caller_id-авторизацию только с подписанным claim → PIN. Фикс координатора: index.js передаёт {targetExtension, dialedExtension, callerNumber} третьим аргументом → claim прикладывается (коммит b6b0069407, ветка sipreconcile6-1189, бандл mirrors/lines/sipreconcile6-1189-b6b0069407.bundle, кандидат синхронизирован), посажено 10:14Z (backup gateway-20260902T101341Z), оба стека ok. Owner попрошен позвонить. 1184-sippin продолжает независимую проверку и должна подтвердить/уточнить.

[02.09 12:40Z Фабл] 1184-sippin (Luna): корень PIN — app-side: WEB393F (l87) добавил fail-closed resolver, который для любой Asterisk-сессии вне проверенной lane 8011 возвращает authMethod=pin, игнорируя TelephonyEndpoint.authMethod (до этого authMethodUsed = endpoint.authMethod || none). Т.е. и старый шлюз (без claim), и новый (с валидным claim 8000) получали pin=true. Фикс f2345e4ce8: laneAuth.ts + sessionStart.ts (endpoint authMethod уважается для non-8011; 8010/pin-эндпоинты — по-прежнему PIN) + тест telephony-8000-pin-regression + gateway index.js. App-часть включена в l90-candidate = 26da36faba (сборка перезапущена), приёмка 1193 (codex). Owner предупреждён: до посадки l90 (~1 ч) 8000 просит PIN.

[по A1 ~11:00Z Фабл] Приёмка 1193-accsippin: PASS — 8000 с authMethod=none без PIN (legacy-тело и валидный canonical HMAC claim), негативы (endpoint pin, 8010, битый/просроченный claim) fail-closed, verify-pin 422 без изменений, gateway третий аргумент идентичен посаженному b6b0069407; telephony-падения идентичны родителю. App-часть в l90-candidate 26da36faba (сборка идёт) → посадка → контрольный звонок owner-а.

[A1 11:05Z Фабл] ПОСАЖЕН l90 на A1: commit 26da36faba, артефакт me2-standalone-linux-arm64-26da36fa-20260902T105621Z (sha dffb8a17…), run /home/ubuntu/prod/shared/run/l90-26da36fa, /api/ready TRUE (boot-env: 1 warning), paid true, воркер индексации на l90. Env: убраны BLUEBUBBLES_SERVER_PASSWORD и SOCIAL_ENCRYPTION_KEY_PREVIOUS, добавлен SYNC_PAGINATION_ENABLED=1 (P15 SAFE_NOW). Откат: nc-a1.service.bak-l89 + l89 целы.

[A1 12:35 Фабл] Четвёртый слой PIN на 8000 (звонок owner-а 12:27 на l90 после живых фиксов шлюза): lane_claim принят (в журнале больше нет lane_claim_rejected), но сессия стартует с pinRequired → verify-pin 422 endpoint_pin_missing. Корень: laneAuth.ts resolveVerifiedLaneAuthContract (f2345e4ce8) даёт исключение «канонический 8000» только при `endpointExtension === 8000`; боевой endpoint owner-а = pi_sip_7016 (extension 7016, sip_digest, без PIN), 8000 — набираемая линия, а не extension аккаунта → strictPinLaneAuthContract → PIN. Приёмка 1193 прошла на фикстуре с endpoint.extension=8000 (fixture-green ≠ польза). Фикс — волна 1206-sippin2 (A1, база l90): исключение по requestedExtension 8000 + канонический claim для любого активного sip-endpoint-а с sip_digest/caller_id/none; authMethod pin у endpoint-а сохраняется; тесты на реальной форме данных (7016→8000). Попутно живьём на шлюзе: секрет линии никогда не использовался для подписи (resolveLaneClaimSecretDetails возвращал gateway secret) → bad_signature — исправлено в /home/pi/ag-voice (backup gateway-20260902T122619Z), коммит 9165532f87 (ветка gwlanesecret-1205). До посадки l91 8000 просит PIN — owner предупреждён (ETA 1.5–2 ч).

[A1 13:05 Фабл] Волна 1206-sippin2 сдана: 3a70ebcc0bd0d2510f7eaa3f3724c427d60d9241 (laneAuth.ts: канонический 8000 определяется только по requestedExtension 8000 + canonical claim/его отсутствию, endpoint.extension не участвует; alias claim и 8011 без lane — по-прежнему strict PIN; тест на продовой форме endpoint 7016/sip/sip_digest/без PIN, 16/16; scoped tsc, eslint, client-boundary PASS). Приёмка 1211-accsippin2 (A1) — с собственными тестами на форме данных прода и негативами (pin/caller_id_pin/alias/8011/inactive/expired claim) + сквозной sessionStart. Cherry-pick в l91-candidate = bff7842f. После посадки l91: звонок owner-а 7016→8000, ожидание — приветствие без PIN; journal без endpoint_pin_missing/lane_claim_rejected.

[A1 13:20 Фабл] ЭВОЛЮЦИЯ «PIN на 8000» для нулевого агента (02.09). Симптом: owner (SIP-аккаунт 7016 на A1-Asterisk) набирает 8000 и слышит «This line is protected by a PIN»; PIN у него не настроен → verify-pin 422 → отбой. Цепочка данных: Asterisk (/tmp/ag-asterisk-logs/messages, диалплан 8000@internal → AGI 4573) → шлюз /home/pi/ag-voice/infra/sip/gateway (логи ТОЛЬКО в /tmp/ag-asterisk-logs/gateway.out, journalctl пуст) → приложение nc-a1 (journal `[telephony-auth] reason`) → src/lib/telephony/runtime/{sessionStart,laneAuth}.ts. Слои и лечение: (1) 10:03 — в env прода не было TELEPHONY_LANE_CLAIM_SECRET (приложение с l87 требует подписанный lane-claim) → reason secret_not_configured; добавлен в /home/ubuntu/prod/shared/.env.local и /home/pi/ag-voice/.env. (2) 10:14 — legacy-путь 8000 в шлюзе не передавал trustedRoute → claim не отправлялся (lane_claim_rejected: missing); коммит b6b0069407 (sipreconcile6-1189) посажен живьём. (3) 12:26 — laneClaim.js resolveLaneClaimSecretDetails проверял lane-секрет, но подписывал TELEPHONY_GATEWAY_SECRET → bad_signature; живой патч + коммит 9165532f87 (gwlanesecret-1205). Попутно WEB-476: односторонний lease-фенс шлюза после рестарта nc-a1 → все звонки reject (12:15), рестарт стека 12:23; фикс 0506c4cf (1204) на приёмке 1214. (4) 12:27 — app-side: f2345e4ce8 (в l90) давало исключение для 8000 только при endpoint.extension=8000, а у owner-а endpoint 7016 → strict PIN; фикс 3a70ebcc (1206) на приёмке 1211 → l91 (bff7842f). Почему не поймали раньше: приёмки 1184/1193 — на фикстуре с endpoint.extension=8000 (память telephony-acceptance-must-use-prod-endpoint-shape). Состояние: до посадки l91 8000 = PIN; после посадки — звонок owner-а 7016→8000, ожидание: приветствие; проверка journal без endpoint_pin_missing/lane_claim_rejected, gateway.out: Session → greeting. Следом: 8000→live lane (LANE8000-CHECKLIST, отдельный GO).

[A1 13:40 Фабл] Приёмка 1211-accsippin2 (A1, свой тест через production handleSessionStart): **NO-GO, критично** — для canonical 8000/8000 с ИСТЁКШИМ или с БИТОЙ подписью claim ответ laneClaim.status=rejected, но authMethodUsed=sip_digest, pinRequired=false (fail-open): sessionStart.ts:1039 отбрасывает невалидный claim в null, а canonical-предикат laneAuth принимает `!claim` как «старый шлюз без claim». Положительные кейсы на продовой форме (7016→8000) прошли. Корректировка — волна 1216-sippin3 (A1, поверх 3a70ebcc): три состояния claim absent/valid/rejected, rejected → fail-closed (strict PIN/отказ), регрессионный тест приёмщика (tests/unit/telephony-8000-pin-acceptance.test.ts) забирается в ветку. Коммит bff7842f снят с l91-candidate (rebase) до GO новой версии. ETA посадки l91 сдвигается на ~40 мин.

[A1 13:30 Фабл] Корректировка 1216-sippin3 сдана: 10bb40b8d8fbe798c31f34a16b718542b6116b6c (laneAuth: verification со статусом absent|valid|rejected, absent ≠ malformed; sessionStart: rejected claim → сессия с authMethodUsed=pin/pinRequired=true (для owner-а без PIN = отбой, что правильно при подделке), лог lane_claim_rejected + laneClaimReason; тест приёмщика telephony-8000-pin-acceptance.test.ts взят в ветку + replay-негатив; 6/6, targeted 23/23, scoped tsc/eslint/client-boundary PASS; полный telephony-набор 952/30/4 — 30 провалов заявлены как baseline, приёмка сверит с чистым l90). Матрица claim→контракт — в SIPPIN3-REPORT.md. Повторная приёмка 1220-accsippin3 (A1). В l91-candidate: fa43a493 + 68fbcb59 (11 коммитов поверх l90).

[A1 13:50 Фабл] Повторная приёмка 1220-accsippin3 (A1, дерево от 10bb40b8, свой harness через production handleSessionStart на форме данных прода 7016→8000): **GO** — матрица absent/valid/rejected подтверждена (rejected: expired/bad_signature/malformed/mismatch/replay → pin/pinRequired=true, fail-closed; absent → sip_digest без PIN; alias → strict PIN; 8011 без lane → PIN; inactive → 403), baseline-провалы полного telephony-набора совпадают с чистым l90 (новых нет). Сборка l91 запущена на A2 (l91-candidate 38ab6c18, 16 коммитов, hashes 14, P19-гейт в цепочке). Далее: sign → land-l91 (unpack|env|bootcontract|dryrun|migrate|flip(+SIP restart)|verify) → живой звонок owner-а 7016→8000.

[A1 14:12 Фабл] ПОСАЖЕНО l91 на прод A1: release arm64-l91-20260902T140416Z, run l91-9ad68bc2, sourceCommit 9ad68bc261c833e792bc17523245975e15f48612, артефакт sha 96b3466b…dc3f; ready TRUE (boot/database/release/drain ok), paid TRUE enforce_ready, public 200, live-sha 9ad68bc2; SIP-стек перезапущен (readiness 200/200, монитор аренды пережил рестарт: 2 poll-failed, LOST=0). Откат: land-l90 run/l90-26da36fa (nc-a1.service.bak-l90). Фикс 8000 (sippin2+sippin3: fa43a493/68fbcb59 в l91) в serving. Owner попрошен позвонить 7016→8000; вахта gateway.out + journal [telephony-auth]. Чек-лист живого звонка — ACCSIPPIN3-REPORT §Live.

[A1 14:30 Фабл] 🏁 ЖИВОЙ ЗВОНОК ПРОШЁЛ на l91: owner 7016→8000 дважды (14:23:37 и 14:24:xx A1): gateway.out — Call from 7016 → Session cmtk6rhgf009u88rcfttitm8r → greeting (cached) → Done (1 turn, status=completed, 94 s); второй — Session cmtk6s9pr00d588rchh0zhb8w → completed, 62 s. journal nc-a1 `[telephony-auth]` отказов с 14:20 — 0 (нет endpoint_pin_missing / lane_claim_rejected). Owner: «Звонок прошёл. Было приветствие» (TTS читает «Six by Y» как «сикс бай вей» — косметика, отдельная мелкая правка текста приветствия). Все четыре слоя PIN закрыты (env-секрет, legacy-путь шлюза, подпись lane-секретом, контракт endpoint 7016→8000 fail-closed). Остаток эпика: 8000→live lane (LANE8000-CHECKLIST) — только с отдельным GO owner-а. Тикет → done.

[A1 14:58 Фабл] Косметика после звонка (TTS «Six by Y» → «сикс бай вей»): волна 1236-brandspoken сдана — 9e6695e9a7: BRAND_TTS_NAME="Six by Why" только для голосового контура (telephony greeting.ts, inboundConsent, composeOpener, realtime prompts); BRAND_SPOKEN_NAME/BRAND_NAME/UI не тронуты. Приёмка 1241-accbrandspoken (A1) → l92; кэш greeting шлюза обновится сам (новый хэш текста).

[A1 15:12 Фабл] Приёмка 1241-accbrandspoken: NO-GO — Google Signal realtime bootstrap (src/app/api/signal-call/v1/sessions/[sessionId]/google-bootstrap/route.ts:213) всё ещё строит system instruction с BRAND_NAME («SIXBYY»); SIP AudioSocket, OpenAI Signal realtime, greeting/consent/opener — уже BRAND_TTS_NAME (таблица в ACCBRANDSPOKEN-REPORT.md). Корректировка 1248-brandspoken2 (A1) + тест production-пути.

[A1 15:26 Фабл] 1248-brandspoken2 сдана: 156bda8f (Google Signal bootstrap → BRAND_TTS_NAME в system instruction). Повторная приёмка 1253-accbrandspoken2 (A1, полный аудит голосовых контуров). Линия на A2 → l92 после GO.

[A1 15:40 Фабл] Повторная приёмка 1253-accbrandspoken2 (A1): **GO** — все голосовые контуры (SIP greeting/consent/opener, AudioSocket, Signal OpenAI и Google realtime) используют BRAND_TTS_NAME «Six by Why», UI/письма/визуал — BRAND_NAME; production-path тест Google bootstrap зелёный. Cherry-pick 9e6695e9 + 156bda8f в l92-candidate. После посадки l92 owner услышит «сикс бай уай».

[05.09 21:03Z координатор] [05.09 21:35Z координатор | ИНЦИДЕНТ ТЕЛЕФОНИИ ПОСЛЕ OCI RESET A1 15:11Z — разбор и лечение] Владелец 20:17Z: «отпали звонки по SIP, выбило Telegram и Signal». Три РАЗНЫЕ причины:
1) SIP (A1): после ребута стартовали ОБА enabled юнита `ag-sip-native` и `ag-sip-native-opus-experimental` (экспериментальный был enabled, хотя остановлен с 02.09 19:56Z) и 5 ч дрались за :5060/:4080 — каждый старт убивал Asterisk соседа («Killed stale process on port 5060» → «Asterisk PID is gone; exiting so systemd can restart»), 686 рестартов. Лечение 20:30Z: `systemctl disable --now ag-sip-native-opus-experimental`, `restart ag-sip-native` → Asterisk 20.19.0 на :5060 udp/tcp, шлюз :4080, AGI :4573, AudioSocket :4574, ARI app live-8014-snoop-ingress-spike подключён. Побочно: fail2ban (jail asterisk-sip-auth) не стартовал с ребута (не было лога Asterisk) → restart 20:31Z, 4 сканера забанены. 7016 владельца зарегистрировался 20:35:11Z (86.45.x.x, RTT 117 ms), отрегистрировался 20:35:59Z; INVITE на 8000 за это время НЕ поступал — звонок не покинул клиент; ждём повторный набор под живой вахтой журнала.
2) Telegram-звонки (Pi, `telegram-call-native`): с 01.09 11:27Z `AuthKeyDuplicatedError` — StringSession использована с двух IP одновременно (кто-то подключился к живой сессии → Telegram отозвал ключ). Нужен новый логин с кодом владельца: на Pi `/home/pi/telegram-call-native/relogin-telegram.sh` (пишет `TELEGRAM_STRING_SESSION` в `current/worker.env`, перезапускает юнит). Юнит остановлен 20:37Z, enabled оставлен.
3) Signal (Pi, `signal-cli-daemon`): с 30.08 07:02Z «User +353857367035 is not registered» — 58 000 рестартов. Нужна перерегистрация номера владельцем (`signal-cli-forked --config /home/pi/signal-cli-data -u +353… register` / `verify`). Юнит остановлен 20:37Z.
KNOWN ISSUES / ТРАБЛШУТИНГ: «SIP не логинится» → `systemctl status ag-sip-native ag-sip-native-opus-experimental; ss -lunp | grep 5060` → два юнита enabled → disable экспериментальный; «fail2ban failed» после ребута → он должен стартовать ПОСЛЕ Asterisk (добавить `After=ag-sip-native.service` — backlog); «TG AuthKeyDuplicatedError» → сессию открыли извне → перелогин, и НИКОГДА не подключать живую сессию с другой машины; «Signal not registered» → перерегистрация владельцем. Правило на будущее: юниты экспериментальных стеков держать disabled, не только stopped.

[05.09 21:07Z координатор] [05.09 21:10Z координатор | ДИАГНОЗ «8000 → тишина 30 с»: UDP-фрагментация INVITE, хвосты фрагментов не доходят до A1] tcpdump на A1 (`/tmp/sipcap.pcap`, фильтр host 86.45.55.126) на звонке владельца 21:06:16Z: REGISTER (598 B) → 401 → REGISTER+auth (874 B) → 200 OK; PUBLISH → 489 Bad Event (норма); INVITE sip:8000 cseq=20 (1319 B, без auth) → 401; затем клиент ШЕСТЬ раз (21:06:17 → 21:06:32, экспоненциально) шлёт INVITE cseq=21 с Authorization — датаграмма >1500 B, идёт двумя IP-фрагментами; на A1 приходят ТОЛЬКО первые фрагменты (flags [+], length 1500, offset 0), ни одного хвоста → ядро не собирает датаграмму, Asterisk INVITE cseq=21 не видит (в `full` только «Could not find matching transaction… INVITE/cseq=20» и CHALLENGE). Через ~35 с клиент отрегистрируется. Не-первые фрагменты теряются на пути (Oracle VCN/NAT — типичное поведение), REGISTER мелкий и потому живёт. Раньше «работало», потому что INVITE был короче (другой клиент/кодеки/без opaque) — не проверялось.
Лечение: (1) немедленно — софтфон на TCP (sip.wool2.online:5060;transport=tcp; Asterisk слушает tcp, ufw открыт) — владельцу отправлено; (2) постоянно — SRV `_sip._tcp.wool2.online` → sip.wool2.online:5060 (Cloudflare DNS — владелец; агент в DNS-поля печатать не может) и приоритет TCP над `_sip._udp`; (3) backlog: TLS 5061 (сертификат nb/sixbyy есть), урезать SDP (меньше кодеков) в шаблоне pjsip endpoint, чтобы UDP-INVITE с auth влезал в ~1400 B; (4) в ранбук: «регистрация есть, звонок молчит» → `tcpdump -ni any host <ip> and (udp port 5060 or ip[6:2]&0x3fff!=0)` → фрагменты без хвостов.
KNOWN ISSUES / ТРАБЛШУТИНГ (дельта): симптом «REGISTER ок, INVITE после 401 не доходит» → проверка: `grep "INVITE/cseq=21" /tmp/ag-asterisk-logs/full` пусто при видимых 1500-байтных фрагментах в tcpdump → причина: UDP-фрагментация, non-initial фрагменты дропаются до хоста → лечение: TCP/TLS транспорт клиента, SRV _sip._tcp, компактный SDP.

[05.09 21:10Z координатор] [05.09 21:15Z координатор | ПОДТВЕРЖДЕНИЕ: по TCP звонок на 8000 работает] После переключения софтфона владельца на transport=tcp: вызов C-00000001 21:08:06–21:08:47Z (41 с), путь Stasis `live-8014-snoop-ingress-spike` → provider openai (`provider_selected=openai`, `upstream_session_started`), snoop/bridge/external media joined, ассистент отвечал (playback turnIndex 2 и 3), оба раза сработал barge-in (`caller_barge_in_during_playback` → playback_stopped ok, response_cancelled ok). Замечание для backlog: `initial_greeting_blocked reason=missing_live_bridge / external_channel_not_ready / already_requested` — приветствие на 8000 блокируется до готовности external channel; проверить, слышит ли абонент приветствие или тишину первые секунды. tcpdump-доказательство UDP-фрагментации — комментарий выше.

[05.09 21:13Z координатор] [05.09 21:35Z координатор | ПОБОЧКА TCP-звонка 21:08Z: ESTIMATOR_BREACH закрыл платный шлюз на 3 мин] Резервация `resv_e99d8f57…` (feature `telephony.voice_tool_prepass`, callsite `telephony.voice-tool-prepass.openai.gpt54-nano`, gpt-5.4-nano): reserved 162 micros / 283 tokens, settled 1524 micros / 7093 tokens (×9.4 по деньгам, ×25 по токенам), state SETTLED_ACTUAL, ownerCharged=t → outbox `sob_22b292b8…` kind=ESTIMATOR_BREACH OPEN 21:08:52Z → nc-a1 `billing_guard_accounting_unhealthy` 21:08:48–21:11:39Z (8 отказов), в т.ч. ДВА голосовых владельца 21:10/21:11Z не транскрибированы (`gpt-4o-mini-transcribe` 503 «accounting is being repaired», `whisper-1 not in MODEL_ALLOWLIST; not retrying`). Шлюз сам вернулся в ok (posture enforce_ready), OPEN-строка закрыта координатором через `resolveBacklogEntry` (по ранбуку, без raw UPDATE) + spend-reconcile. Деньги не потеряны, владелец списан по факту. ДЕФЕКТ: эстиматор w32-estimator-2 для voice_tool_prepass занижает в ~10× (в промпт уходит контекст тетради/инструментов, а оценка считает только реплику) → каждый SIP-звонок будет ронять платный шлюз всем пользователям на минуты. → фикс-волна: калибровка оценки для `telephony.voice_tool_prepass` (учитывать системный промпт + инструменты) и/или reaction=payer без деградации шлюза при terminal SETTLED_ACTUAL. Третий класс «одна транзиентная запись закрывает весь платный продукт» — см. ранбук WEB-511 / память paid-gate-closed-by-settlement-failed-outbox-row.

[05.09 21:21Z координатор] [05.09 21:55Z координатор | ОБРАТНАЯ СВЯЗЬ ВЛАДЕЛЬЦА ПО TCP-ЗВОНКУ 21:08Z + сводка шлюза] Владелец (voice 21:16Z): приветствие было; «как называется тетрадь, которую видишь» → «не понял»; перечисление файлов по просьбе — работает; перебивал дважды; после третьей реплики ассистент «начал булькать, захлёбываться и замолчал», разговор потерян (владелец повесил трубку 21:08:56Z, Asterisk «Hangup (no more frames)»). Владелец напоминает: OpenAI realtime = настоящее перебивание, Google = псевдо; «раньше лечили, потом вернулось» (WEB-318). Шлюз: provider openai, barge_events=2, barge_latency_ms=3, playback_stopped/response_cancelled ok на ходах 2 и 3, `deferred_rejected responseDeferred call_finalized:caller_hangup`, **dropped_audio_bytes=1072800** (~67 с при 8 кГц/16 бит — больше длины звонка: после cancel сбрасывается и последующий ассистентский поток), noise_floor_rms 4.6 / threshold 450 / peak 3941, frames_above_threshold 165, greeting_blocked=[missing_live_bridge, external_channel_not_ready, already_requested]. → фикс-волна 2094 (A1, luna): причина дропа file:line, RED/GREEN на фикстуре, отдельно — привязка контекста тетради на 8000 («не понял»). Патч на хост — только координатором в окне после приёмки.

[05.09 21:24Z координатор] [05.09 22:05Z координатор | DNS-факты для SIP] Авторитетный DNS зоны wool2.online — НЕ Cloudflare (в аккаунте Cloudflare только sixbyy.com): `ns1/ns2.wool2.online` → 86.45.55.126 (домашний IP владельца, bind9 `named` на Pi, зона `/etc/bind/db.wool2.online` динамическая — правки только через nsupdate/rndc, не файлом). Публично: `sip.wool2.online A 129.213.25.105` (A1), `_sip._tcp.sip.wool2.online SRV 10 100 5060`, `_sip._udp.sip.wool2.online SRV 20 100 5060` — TCP уже в приоритете; софтфон владельца SRV не использует → в клиенте transport=TCP явно. РИСК (правило «прод не зависит от Pi/ноутов»): весь домен wool2.online (в т.ч. nb.wool2.online) резолвится через bind на Малинке за домашним интернетом — падение Pi/провайдера = домен не резолвится (TTL спасает недолго). → backlog: перенос зоны wool2.online на Cloudflare (как sixbyy.com) или вторичный NS на A1/A2; решение владельца.

[05.09 22:51Z координатор] [06.09 03:05Z координатор | 2109 SIPNOTEBOOKSCOPE = GREEN автора → приёмка 2114] Кандидат `6838d50ec680345f2e6de968048fd0100fe207c2` (luna, A1; бандл `/home/ubuntu/waves/SIPNOTEBOOKSCOPE.bundle`, отчёт `SIPNOTEBOOKSCOPE-REPORT.md`): ассистент на 8000 получает имя текущей тетради и краткую опись в scoped knowledge instructions и отвечает на вопросы класса «какая тетрадь / что видишь» без похода к провайдеру; join code — по отчёту. Приёмка 2114 (luna, A1) с проверкой совместимости с af94f766/cfbb68861 (в l113). После GO — l113b + хост-sync шлюза одним окном (cleanup + barge-in audio + notebook scope), проверка одним звонком владельца.

[05.09 23:00Z координатор] [06.09 04:05Z координатор | ПРИЁМКА 2114 = GO] Luna на A1 (`/home/ubuntu/waves/ACCSIPNOTEBOOKSCOPE-REPORT.md`) кандидата `6838d50ec680345f2e6de968048fd0100fe207c2` (база af94f766 sipbargeaudio): имя тетради и опись в scoped instructions, ответ на «какая тетрадь» без провайдера, без тетради — честное «не выбрана», совместим с af94f766/cfbb68861 — GO. → l113b (вместе с bigdoc-merge 11b73949, DMCA-page 08ed8596, TG-retry после 2115, SIP-templates после 2113). Хост-sync шлюза `/home/pi/ag-voice/infra/sip/gateway/**` одним окном после посадки l113b: cleanup (cfbb68861) + barge-in audio (af94f766) + notebook scope (6838d50e) → проверка одним звонком владельца («как называется тетрадь», перебивание ×3).

[05.09 23:21Z координатор] [06.09 05:35Z координатор | ПРИЁМКА 2113 = NO-GO (ранбук) → 2121] Luna на A1 (`/home/ubuntu/waves/ACCSIPTRANSPORT-REPORT.md`) кандидата a0e30818 (компактный SDP, TLS 5061, realm sip.sixbyy.com + alias sip.wool2.online): статика принята; NO-GO по полноте `SIPTRANSPORT-RUNBOOK.md` — нет проверки звонком по TCP/TLS с ожидаемыми строками журнала, нет безопасного выбора webroot/nginx для certbot sip.sixbyy.com, tcpdump-фильтр ловит не все фрагменты. → волна 2121 (luna, A2) дополняет ранбук; затем l113b + хост-sync одним окном (WEB-565).

[05.09 23:26Z координатор] [06.09 06:10Z координатор | 2121 SIPRUNBOOKFIX = GO (документ)] Кандидат `f16ded4d0e3897e52740aaf65e548610f3b8b6b0` (luna, A2, база a0e30818; бандл `/home/ubuntu/waves/SIPRUNBOOKFIX.bundle`): изменён только `infra/sip/SIPTRANSPORT-RUNBOOK.md` — certbot через существующий nginx webroot (основной путь, :10-17) или временный vhost `--nginx` (:19-37) с откатом; отдельные тесты звонком TCP/5060 и TLS/5061 с ожидаемыми строками журнала (:104-142); проверка authenticated UDP INVITE ≤ 1300 B по tcpdump (:144-165); полный фильтр фрагментов (0x1fff/0x2000/0x3fff, :167-201); rollback-чеклист по шагам. Все три блокера приёмки 2113 закрыты документально, код/шаблоны не менялись → принято координатором (документ) → в l113b; хост-sync (WEB-565) по этому ранбуку одним окном с cleanup/audio/notebook-scope.

[06.09 10:39Z координатор] [2026-09-06T10:39Z координатор] WEB-463: приёмка 2261 (A1) = NO-GO 0d7b50ee — функциональный barge-in/full-duplex проходит, но env-валидация VAD clamp-ит вместо «дефолт + предупреждение» (phoneAudioConfig.js:11-17,35-52,60-71; ожидались 300/500, получены 0/3000, warning не вызван) → круг 2 = 2271-web463b (A1). Пост-QA l113d (2239) = NO-GO по ожидаемой причине (прод уже l113e) + SIP readiness на 4080 отвечает 404 на «/» (сервис жив, 5060/5061 слушают) — пост-QA l113e будет с верным пином.

[06.09 11:07Z координатор] [2026-09-06T11:07Z координатор] WEB-463: приёмка круга 2 (2277, A1) = GO 44ea7cea (VAD env-валидация: дефолт+предупреждение; barge-in full-duplex, cancel ≤200 мс) → кандидат l113f. На хост телефонии — вместе с WEB-508 в окне.

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

[13.09 12:13Z координатор] Волна 3689.  Эпик возвращён в работу: два ребёнка открыты, закрывать его рано.

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

Источники, проверенные отсюда: тело тикета из live API; все 45 комментариев из локального `web-board.sqlite`, последний комментарий `id=4761` от 2026-09-13T12:13:40.088Z. Статус на live API при финальной сверке: `in_progress`.

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

Телефония и мультирум должны быть доведены как линия, а не закрыты набором частичных удачных проверок. Пользовательский смысл: звонки, SIP, TG/Signal и multiroom должны переживать реальный контур, а не только отдельные тесты.

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

По истории карточки были приняты и посажены большие части: ACCMULTIROOM2 GO, 8000/PIN фикс, brand work, voice/SIP на A1, live calls частично проходили. Тело сейчас честно говорит, что parent epic возвращён в работу, а хвосты вынесены в детей: WEB-370 messenger/address-book migration и WEB-413 production cutover/observation.

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

Закрыть детей WEB-370 и WEB-413. В самом parent не надо начинать новый код до закрытия детей: он должен агрегировать доказательства, связать owner calls/observations и только потом перейти в done.

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

Старые комментарии и старый статусный блок создавали впечатление “done”. Комментарии `id=4739` и `id=4761` отменяют это: epic был закрыт преждевременно, возвращён в работу, два ребёнка открыты, закрывать рано.

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

Смотреть: WEB-370, WEB-413, комментарии `id=4739`, `id=4761`, план wave 3663 и plan 3689. Первый шаг: не писать код в parent, а составить dependency checklist по детям и сверить, что у каждого есть доказательство закрытия.

Готово: WEB-370 и WEB-413 закрыты по своим критериям; parent body обновлён ссылками на доказательства; нет открытого owner-window/cutover хвоста.

Нельзя: закрывать WEB-395 по старому “телефония на A1”, обходить детей, объединять TG/Signal cutover и SIP health в один зелёный чек.

Размер: несколько смен. Большим является не parent-правка, а два живых ребёнка с production cutover и observation.

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

Не закрыто. Связано с WEB-370/WEB-413 как parent, не дубль.

ENRICH-4132-WEB-395
```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`**. Эпик остаётся открытым на двух детях;
закрывать его нельзя до боевого перехода (WEB-413).

### 2. КАРТА ДОКАЗАТЕЛЬСТВ
- Тело: эпик возвращён в работу волной 3676 (был закрыт рано).
- Дети: WEB-370 (перенос мессенджеров/адресной книги; план — волна 3663 `CUTOVER-PLAN.md`
  + `OWNER-STEPS.md`) и WEB-413 (боевой переход с наблюдением; план — волна 3689
  `CUTOVER-PLAN.md` + `WATCH-HOUR.md`).
- HANDOFF-LIVE.md §4 строки 504–515: пять дыр телефонии, найденные аудитом 3947
  (`list_my_notebooks` без ACL; каталожный запрет не применяется; именованный фокус без
  проверки права; пустой scope = поиск без фильтра при `dev_single_user`; мёртвый `failClosed`).
  Комната-встреча защищена правильно; realtime-путь считает `sharedGuest`.
- Решение по режиму доверия: `TELEPHONY_TRUST_MODE=shared` ставить ПОСЛЕ починки 3951 и её
  приёмки — строгий режим закрывает только дыру №4 из пяти (HANDOFF-LIVE.md строка 515).
- HANDOFF-LIVE.md §3 строка 494: 3951 = GO (`refs/waves/3951/fix/3951-telephony-scope`
  = `e5c59ff1c034fd6d40af4970f51ae00e5c18d381`), но ветка от ДО-откатного `c0bcab849` —
  при сборке переносить на `68e25d8df`, и `next build` в логе был оборван.
- Доска WEB-395 id 4761 (2026-09-13T12:13:40.088Z): эпик возвращён в работу, два ребёнка открыты.
- Доска WEB-395 id 5036 (2026-09-14T15:16:26.574Z): сводка для нулевого агента.

### 3. ЭВОЛЮЦИЯ / ПОПРАВКИ (append-only)
- Якорь: l115j `133fe00c` → **l115o `68e25d8df5ae8263c5ac5466353631f57a17cfcc`**.
- Новое с 13.09: аудит 3947 нашёл пять дыр телефонии (см. карту доказательств); починка 3951
  сдана с GO, но её ветка отрезана от текущей линии — при сборке обязателен перенос на
  прод-коммит. Это прямое следствие правила 14 и правила 9 канона.
- Эпик не закрывать: закрытие эпика телефонии без боевого перехода = ровно та ошибка,
  из-за которой он уже был закрыт рано и возвращён волной 3676.

### 4. KNOWN ISSUES / ТРАБЛШУТИНГ
1. **Эпик закрывают по частичным удачным проверкам.**
   - Симптом: набор зелёных проверок читается как «телефония доведена».
   - Проверка за 2 минуты: найти в карточке ссылку на боевой переход (WEB-413) с 60-минутным
     наблюдением → если запись о переходе отсутствует, эпик закрывать нельзя.
   - Причина: эпик уже закрывался рано и был возвращён волной 3676.
   - Лечение/статус: критерий закрытия эпика — завершённый боевой переход, а не набор PASS.
   - Ссылки: доска WEB-395 id 4761; тело.
2. **Правка, принятая против старой базы, не переносится сама.**
   - Симптом: GO на ветке от до-откатного коммита; в текущей линии правки нет.
   - Проверка за 2 минуты: `git merge-base --is-ancestor <прод-коммит> <ветка>` → ожидание RC=0
     до того, как считать правку посадочной.
   - Причина: ветка собрана от `c0bcab849` (до отката).
   - Лечение/статус: при сборке переносить на `68e25d8df`; приёмка обязана довести `next build`
     до конца (в логе он был оборван).
   - Ссылка: HANDOFF-LIVE.md §3 строка 494.

### 5. ТЕКУЩИЙ ОСТАТОК (ответственный)
1. Довести боевой переход (WEB-413) — координатор после снятия трёх предусловий.
2. Перенести мессенджеры/адресную книгу (WEB-370) — координатор после окна владельца.
3. Принять/перенести починку 3951 на текущую линию с полной сборкой — координатор.
4. Решить режим доверия телефонии ПОСЛЕ починки и приёмки — координатор.

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

---

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=2026-09-15, волна 4132 DRAFT_DELTA: текущая линия l115o 68e25d8d; живые дети WEB-370 и WEB-413 не закрыты, эпик остаётся зонтом
ЧТО НУЖНО=первый шаг: свести доказательства детей WEB-370/WEB-413 и затем принять 3951 на текущей линии; triage-neo 4707