WEB board

[A1 16:52 Фабл] Корректировка после NO-GO 1261 сдана: волна 1266-lane8000v3, коммит b2da463601 (ветка lane8000v3-1266 = 20bf8f9c + b2da4636, база gwleaserecover2-1217 = живой шлюз A1). Закрыто: (1) третий флаг SIP_EXPERIMENTAL_LIVE_UPSTREAM_ENABLED в рендере и guard 8000 — live только при трёх ON, иначе AGI byte-identical baseline; (2) ReferenceError trustedRoute в liveTransport/upstreamLifecycleClient.js — синтетический startSession доходит до одного POST /api/telephony/v1/sessions/start; (3) 8010/5074 byte-identical; (4) единый deploy-контракт infra/sip/lane8000-land.sh (404 строки): backup|stage|env|verify|rollback, --candidate <worktree-root> --live-root --env-file (тот, что читает start-sip-native.sh) --ari-password-file; proof на временном дереве (rollback байт-в-байт), честный сухой старт: readiness ready, stasisSnoopSpike connected, mock_post_count=1. Отчёт: A1 /home/ubuntu/waves/LANE8000V3-REPORT.md (§5 команда посадки). Дальше: приёмка 1271-acclane8000v3 (A1, другой verifier: 8 комбинаций флагов, undeclared-линт, land.sh на дереве-двойнике с негативами, ARI 401) → при GO посадка на /home/pi/ag-voice этим скриптом → restart ag-sip-native → D2/D3 → звонок owner-а с barge-in (WEB-463) → откат из backup при провале. Бандл: A1 /home/ubuntu/mirrors/lines/lane8000v3-1266.bundle; A2 ref lane8000v3-1266/head.

[A1 17:25 Фабл] Приёмка 1271-acclane8000v3 = NO-GO (A1 /home/ubuntu/waves/ACCLANE8000V3-REPORT.md). Три исходных блокера 1261 закрыты и подтверждены (три флага/8 комбинаций, runtime → один POST, защита шлюза и монитор аренды, rollback на временном дереве байт-в-байт, честный сухой старт ready/connected). Три условия повторного GO — все в deploy-контракте: (1) lane8000-land.sh принимает только supervisor-loaded env path для выбранного live-root (<live-root>/.env(.local), $AG_REPO_ROOT/.env) и явно отказывает для внешнего файла; (2) валидирует существующие managed-флаги до перезаписи, мусор → отказ; (3) строгая грамматика флагов, единая для renderer и Asterisk (ровно 1/0), негативы в тестах. До этого backup/stage/env/verify на A1 и рестарт ag-sip-native не выполняются. → волна 1281-lane8000v4 (A1, в очереди — A1 в перегрузке 17:10–17:20, диспетчер на PAUSE). Эволюция: 1164 → 1246 → 1261 NO-GO(3) → 1266 → 1271 NO-GO(3 условия контракта) → 1281.

[A1 18:02 Фабл] Третий круг сдан: волна 1281-lane8000v4, коммит 4bfe58391e (ветка lane8000v4-1281 = 1266 + фикс контракта; база gwleaserecover2-1217). Закрыты три условия 1271: (1) lane8000-land.sh принимает только supervisor-loaded env path для --live-root (внешний файл → отказ с перечнем допустимых); (2) существующие managed-флаги валидируются до перезаписи (garbage → rc=1 «invalid existing managed value(s)», файл не тронут; --force-fix явно); (3) строгая грамматика 1/0 едина для render-asterisk-dialplan.py, start-sip-native.sh и диалплана, негативы в тестах; §1–§6 приёмки 1271 повторены автором (rollback diff -r пустой). Отчёт: A1 /home/ubuntu/waves/LANE8000V4-REPORT.md (§«Команда посадки для coordinator», §Rollback). Дальше: приёмка 1292-acclane8000v4 (A1, другой verifier) → при GO посадка на /home/pi/ag-voice скриптом кандидата (backup→stage→env→verify), restart ag-sip-native, D2/D3, звонок owner-а с barge-in (WEB-463), откат F1 при провале. Бандл: A1 /home/ubuntu/mirrors/lines/lane8000v4-1281.bundle; A2 ref lane8000v4-1281/head.

[A1 18:45 Фабл] Приёмка 1292-acclane8000v4 = NO-GO с ОДНИМ блокером (A1 /home/ubuntu/waves/ACCLANE8000V4-REPORT.md): env-path с лексическим `..` (`<live-root>/sub/../.env.local`) принимается после realpath -m (lane8000-land.sh:97–102) — по контракту должен отвергаться; всё остальное прошло: allow-list env-path (внешний файл/symlink/чужой live-root → отказ с перечнем), валидация managed-флагов до перезаписи, строгая грамматика 1/0 renderer=Asterisk, регресс 1271 (8 комбинаций, byte-identical 8010/5074, один POST, защита шлюза, rollback байт-в-байт, честный сухой старт), статика, runbook. → волна 1307-lane8000v5 (A1, точечно: лексическая проверка `..`/абсолютности до нормализации + тест) → приёмка 1308 (только этот негатив + повтор набора) → посадка → звонок owner-а. Эволюция: 1164→1246→1261(3)→1266→1271(3 условия)→1281→1292(1 негатив)→1307.

[A1 19:35 Фабл] Четвёртый круг сдан: волна 1307-lane8000v5, коммит e79b55f921 (ветка lane8000v5-1307 = 1281 + лексическая проверка `..`/абсолютности путей до нормализации; автор перегнал набор 1292). Дальше: приёмка 1321-acclane8000v5 (A1, другой verifier: негативы путей + регресс §1–§6) → при GO посадка скриптом кандидата на /home/pi/ag-voice (backup→stage→env→verify, ARI-пароль 600 от 16:51), restart ag-sip-native, D2/D3, звонок owner-а с barge-in (WEB-463), F1 откат. Бандл: A1 mirrors/lines/lane8000v5-1307.bundle; A2 ref lane8000v5-1307/head.

[A1 20:15 Фабл — сводка] Четвёртый круг на приёмке 1321. Команда посадки после GO: см. LANE8000V4-REPORT.md §«Команда посадки» (ARI-пароль /home/ubuntu/ops-backups/lane8000/ari-password-20260902T1651Z.txt), затем restart ag-sip-native, D2/D3, звонок owner-а 7016→8000 с перебиванием (WEB-463), откат rollback.

[A1 19:44 Фабл] Приёмка 1321-acclane8000v5 = GO (кандидат e79b55f9, 2 файла: lane8000-land.sh + start-sip-native.sh; синтетический dry-start честный; §1–§6 регресс PASS). ПОСАЖЕНО на живой шлюз /home/pi/ag-voice по рецепту приёмки: backup=/tmp/lane8000-land/25ef6b3f25cc8e5e0c06b54f/lane8000-pre-20260902T194345Z.tar.gz (sha 90a91748…), stage ok (gateway, extensions.conf, start-sip-native.sh, vendor present), env ok (11 ключей, ARI-пароль validated, 600), verify: 8000=Stasis flags MEDIA:audiosocket SNOOP:1 UPSTREAM:1, 8010 baseline byte-identical. restart ag-sip-native → D2: 4574/4084/8088/4080/4180 слушают, readiness 4080/4180=200, ARI /asterisk/info 200 новым паролем, Stasis app live-8014-snoop-ingress-spike зарегистрирован, dialplan 8000 → Stasis. D3: LEASE_LOST нет; единственная ошибка в журнале — start-скрипт делает git pull + pnpm install в /home/pi/web и pnpm падает на ERR_PNPM_IGNORED_BUILDS (наследие, на запуск шлюза не влияет; отдельная находка → в следующую волну телефонии: убрать pnpm install из старта). Ожидаю звонок owner-а 7016→8000 с перебиванием. Откат: land rollback + restart ag-sip-native.

[A1 19:58 Фабл] ИНЦИДЕНТ 19:49–19:57: при откате P11 (restart nc-a1) я перезапустил ОБА SIP-сервиса одновременно (ag-sip-native + ag-sip-native-opus-experimental). Они убивают друг у друга Asterisk: start-sip-native.sh останавливает experimental gateway, experimental стартует свой Asterisk с /tmp/ag-asterisk-native-opus-experimental/asterisk.conf → native «Asterisk PID is gone» → петля (14 рестартов). В окне petли dynamic sync (pnpm install в /home/pi/web падает ERR_PNPM_IGNORED_BUILDS) оставлял pjsip-generated.conf 0 байт → Linphone 7016 «неправильный пароль», звонок owner-а на 8000 оборвался после приветствия. Разрешение: stop experimental → restart native один → asterisk=1, endpoint 7016 200, Stasis app 1, readiness 4080=200, 0 рестартов за 75 с. Experimental (4180) ОСТАВЛЕН ВЫКЛЮЧЕННЫМ до фикса. Правило до фикса: после restart nc-a1 рестартовать ТОЛЬКО ag-sip-native. В волну телефонии: (1) experimental не должен поднимать второй Asterisk/убивать боевой (один Asterisk, lock-guard); (2) убрать git pull + pnpm install из старта; (3) sync не должен truncate-ить pjsip-generated.conf при провале (atomic write).

[A1 20:12 Фабл] ЖИВОЙ ЗВОНОК owner-а 7016→8000 (20:02, callId 6c0b6ecc): дозвон и ответ есть (регистрация 7016 после инцидента восстановлена), ПЕРЕБИВАНИЕ НЕ СРАБОТАЛО. Лог шлюза: provider_selected=openai fallbackUsed=false, но сессию вёл google-bridge (Gemini) — рассинхрон выбора/исполнения; ни одного snoop/upstream/barge события за звонок; initial_greeting_blocked ×3 (missing_live_bridge, external_channel_not_ready, already_requested). Owner: OpenAI realtime перебивается, Google — имитация realtime. Улика: A1 /home/ubuntu/waves/evidence/lane8000-call-20260902T2002.log (ключи вырезаны). Круг 6 = волна 1334-lane8000v6 (A1, Luna xhigh, от e79b55f9): единая точка выбора провайдера + provider_effective, перебивание на уровне шлюза независимо от провайдера, call_summary. Плечо 8000 остаётся посаженным (звонки работают), бэкап для отката сохранён.

[A1 21:35 Фабл] Волна 1351-lane8000v6 (перезапуск 1334 после капа) сдана: коммит 5ae7d42395 (единая точка выбора провайдера + provider_effective, перебивание на уровне шлюза для обоих провайдеров, call_summary). Отчёт: A1 /home/ubuntu/waves/LANE8000V6-REPORT.md. Дальше: приёмка 1369-acclane8000v6 (A1, Sol high, в очереди) → посадка на живой шлюз → звонок owner-а с перебиванием.

[A1 23:50 Фабл] Приёмка 1369-acclane8000v6 = NO-GO (отчёт A1 /home/ubuntu/waves/ACCLANE8000V6-REPORT.md). PASS: единая точка выбора провайдера + provider_effective, call_summary, регресс §1–§6, честный dry-start; сам barge-in action работает. Блокер: в штатной посадке он недостижим — runtime читает SIP_EXPERIMENTAL_LIVE_BARGE_IN_ENABLED fail-closed (ключа нет → false), обычный звонок 8000 не в исключениях, lane8000-land.sh env этим ключом не управляет (фикстура посадки: barge_in=<absent>, production_8000_action_reachable=false) — свежая установка повторит звонок owner-а с 0 событий; плюс граничный порог RMS 1199/1200. Круг 7 = волна 1393-lane8000v7 (A1, Luna xhigh): barge-in для 8000 штатный (SIP_LANE8000_BARGE_IN default 1, управляется land.sh), порог с гистерезисом.

[A1 03:55 Фабл] Волна 1393-lane8000v7 сдана: коммит 75d0b72c7d (barge-in для 8000 штатный: SIP_LANE8000_BARGE_IN default 1, управляется land.sh; порог с гистерезисом). Приёмка 1413-acclane8000v7 (A1, Sol high, в очереди) → посадка на шлюз → звонок owner-а.

[A1 08:15 Фабл] Приёмка 1413-acclane8000v7 = NO-GO формально (отчёт A1 /home/ubuntu/waves/ACCLANE8000V7-REPORT.md): функционально всё PASS — штатный barge-in для 8000 достижим по умолчанию и после свежего land env, порог/гистерезис, provider identity, call_summary, dry-start; блокер — обычный ShellCheck gate rc=1 (SC2016 ×4 в lane8000-land.sh, SC1091 в start-sip-native.sh). Круг 8 = волна 1433-lane8000v8 (A1, Luna medium): точечные disable/source-директивы → короткая повторная приёмка → посадка → звонок owner-а с перебиванием (обязательный live gate).

[A1 Фабл] Волна 1433-lane8000v8 сдана: коммит c1859c1c (только ShellCheck-директивы: SC2016 ×4 точечно, SC1091 через source=). Приёмка 1449 (A1, Sol medium) в очереди; при GO — посадка на A1 (/home/pi/ag-voice) и звонок owner-а на 8000 с перебиванием.

[A1 Фабл] Приёмка 1449-acclane8000v8 = NO-GO формально: функционал/scope/регресс §1–§6/dry-start PASS, но автор добавил две директивы disable=SC2015 сверх разрешённых. Круг 9 = волна 1465 (A1, Luna low): убрать SC2015-директивы, переписать A&&B||C в if/else, shellcheck rc=0.

[A1 Фабл] Волна 1465-lane8000v9 сдана: коммит 5209921c (SC2015-директивы убраны, if/else). Приёмка 1476 (A1, Sol medium) в очереди.

[A1 Фабл] Приёмка 1476-acclane8000v9 = NO-GO (5209921c): одна из переписанных конструкций не эквивалентна (if/else без `|| true` на ветке info → под set -e роняет launcher при info rc=1; truth-table в отчёте). Круг 10 = волна 1483 (A1, Luna low): строгая эквивалентность `if A; then B || true; fi` + truth-table.

[A1 Фабл] Волна 1483-lane8000v10 сдана: коммит 3950cf19 (строгая эквивалентность конструкций + truth-table). Приёмка 1489 (A1, Sol medium) в очереди.

[A1 Фабл] Приёмка 1489-acclane8000v10 = GO (Sol): truth-table эквивалентности, shellcheck rc=0, регресс §1–§6. Коммит 3950cf19 (круг 10). Далее: посадка на A1 (/home/pi/ag-voice) по команде отчёта, проверки readiness/stasis/7016, звонок owner-а на 8000 с перебиванием.

[A1 Фабл] ПОСАЖЕНО на живой шлюз /home/pi/ag-voice (круг 10, 3950cf19): backup lane8000-pre-20260903T055244Z (sha b5a5805c…), stage ok, env ok (barge_in=1, ARI password validated), verify ok, ag-sip-native restart → readiness ready, stasisSnoopSpike connected, app live-8014-snoop-ingress-spike, ep7016=200, 4574/4084/8088 слушают. Ждём звонок owner-а 7016→8000 с перебиванием (barge_in → playback_stopped → response_cancelled).

[A1 Фабл] ЖИВОЙ ЗВОНОК owner-а 7016→8000 после посадки круга 10 (3950cf19): callId a9aac956… provider_selected=openai provider_effective=openai; [gateway-barge-in] barge_in detected turnIndex=1 reason=caller_barge_in_during_playback → playback_stopped ok=true → response_cancelled ok=true; call_summary barge_events=1. Перебивание РАБОТАЕТ. Замечено: initial_greeting_blocked (missing_live_bridge, external_channel_not_ready, already_requested) — уточняю у owner-а, звучало ли приветствие (WEB-464).

[A1 Фабл] Живой звонок owner-а: на слух НЕ перебивается. Трасса (evidence/lane8000-call-20260903T0620-a9aac956.log): ход 0 сгенерирован целиком (turn_complete, 1.3 МБ аудио в очереди) ДО barge-in; затем barge_in → playback_stopped ok → response_cancelled ok, но провайдер: response_cancel_not_active; уже отправленное аудио продолжило звучать; turnIndex расходится (1 vs 0). Круг 11 = волна 1504 (Luna high): сброс очереди аудио к абоненту ≤300 мс независимо от провайдера, единый turnIndex, barge_latency_ms/dropped_audio_bytes в call_summary.

WEB-479/463 — lane 8000 круг 11 (волна 1504) сдан: коммит 6c5f0b1e (база 3950cf19). Причина неудачного перебивания в живом звонке a9aac956: ответ уже полностью сгенерирован и стоял в ARI playback (~1.3 MB), response_cancel_not_active; расхождение turnIndex gateway/bridge. Фикс: синхронный barge-flush очереди, параллельные ARI DELETE всех caller-facing playback (полный/streaming/wait-cue) + повторный DELETE после гонки, отбрасывание поздних событий по responseId/turnIndex, единый turnIndex в обоих bridge, метрики barge_latency_ms/dropped_audio_bytes. Приёмка = волна 1540 (ACCLANE8000V11, A1, после окна установки user wave WEB-472). После GO — посадка на /home/pi/ag-voice и повторный звонок owner-а.

ПРИЁМКА круга 11 (волна 1540) = NO-GO. Что ХОРОШО (owner-сценарий OpenAI закрыт): полностью сгенерированный ответ 1 327 200 байт обнуляется синхронно, ARI DELETE уходит для полного playback, streaming и wait-cue, старый ход подавляется по responseId/turnIndex, response_cancel_not_active трактуется как local_playback_flush_only, barge_latency_ms ≤300, новый ход не режется. Три блокера: (1) утечка playback ID после гонки POST/DELETE — bargeInPlayback.js:57 сохраняет массив, очищающего присваивания нет, старый ID участвует в будущих остановках; (2) Google bridge не передаёт индекс хода (googleRealtimeWsBridge.js:763-769 перезаписывает mutable lastResponseTurnIndex) → позднее аудио старого хода приходит как ход 2 и звучит после перебивания; (3) у Google output transcript responseId = постоянный тег transcript_source:google_output_audio_transcription → после barge-in suppressor режет ЛЮБОЙ будущий текст этого тега, новый ход возвращает пустую строку. Регресс: 214 тестов candidate vs 212 база, три падения serviceIdentity воспроизводятся и на базе (не причина NO-GO). Круг 12 = волна 1544 (A1). ВАЖНО для owner-а: в его учётке провайдер мог быть Google — на Google-пути перебивание не работает по (2)+(3), это объясняет, почему ответ не замолчал.

Круг 12 сдан (волна 1544): коммит c2918def «fix lane8000v12 playback and Google turn causality», база 6c5f0b1e. Закрыты все три блокера приёмки 1540: (1) lifecycle-очистка call.bargeInPlaybackIds после stop/retry и на завершении playback-хода, при этом ID держится до конца возможной гонки POST/DELETE (первый DELETE 404 → POST 200 → повторный DELETE → bargeInPlaybackIds=[], activePlaybackId=null); (2) каждый requestAssistantResponse в Google-bridge получает собственные responseId и turnIndex, шлёт response.metadata, identity переносится на audio/text/done/tool — поздний выход старого хода остаётся turnIndex=1, новый = 2; (3) Google output transcript получает identity текущего ответа, для legacy source-tag добавлено подавление по паре tag+turnIndex — старый ход режется, новый не теряет текст. Тесты: новый lane8000v12BargeInCausality.test.js 3/3; независимая фикстура приёмщика круга 11 на v12 = 4/4; обязательный glob v12 217 тестов (212 pass, 3 fail) против базы 212 (207 pass, 3 fail) — падают те же три serviceIdentity, что и на базе. Приёмка = волна 1553 на A1 (свои тесты, не повтор фикстуры автора). После GO — посадка на /home/pi/ag-voice и звонок owner-а с перебиванием на ОБОИХ провайдерах.

Приёмка круга 12 (волна 1553) = NO-GO, но по существу: 5 PASS / 2 FAIL. ЗАСЧИТАНО: очистка call.bargeInPlaybackIds после stop/retry и на завершении хода с сохранением ID до конца гонки POST/DELETE; owner-сценарий OpenAI (1.3 МБ, три ARI DELETE, response_cancel_not_active = local flush, latency ≤300 мс); подавление legacy transcript по паре source-tag+turnIndex; три падения serviceIdentity подтверждены как base-residual (падают и на 3950cf19). БЛОКЕРЫ (оба про Google): (1) googleRealtimeWsBridge.js:795-802 шлёт в живой сокет generativelanguage.googleapis.com сообщение {"response":{"metadata":…}}, а Live API требует ровно одно из setup/clientContent/realtimeInput/toolResponse — неизвестное top-level поле грозит закрытием 1007; (2) resolveResponseContext (:973-1014) ищет в server-сообщениях response/responseId/metadata/turnIndex, которых в схеме BidiGenerateContentServerContent НЕТ, и падает назад на activeResponse.turnIndex — поздние реальные сообщения старого хода (serverContent.modelTurn, outputTranscription, turnComplete, toolCall) получают turnIndex нового хода и звучат после перебивания. Работало только потому, что тестовый двойник эхировал отправленные metadata. Круг 13 = волна 1554: индекс хода определяется ЛОКАЛЬНО по моменту приёма (счётчик поколений растёт при barge-in и при запросе хода), отправка response.metadata убирается, добавляется тест-страж на форму client-сообщений.

ПОСАДКА круга 13 на живой шлюз 03.09 12:47–12:55Z. Приёмка 1571 (M4) = GO. Коммит ee241c23 (lane8000v13). Стадии: backup → /tmp/lane8000-land/25ef6b3f25cc8e5e0c06b54f/lane8000-pre-20260903T124740Z.tar.gz (sha 9734a10c…), stage=ok (infra/sip/gateway, extensions.conf, start-sip-native.sh, vendor present), env=ok (.env.local, 12 ключей, barge_in=1, пароль ARI валидирован, mode 600), verify=ok (8000=Stasis MEDIA:audiosocket SNOOP:1 UPSTREAM:1; 8010 baseline byte-identical; barge_in=1). После рестарта ag-sip-native: status=ready, stasis connected=true, sip reachable 127.0.0.1:5060, LEASE_LOST=0, greeting pre-warmed.

🔴 ДЕФЕКТ СКРИПТА ПОСАДКИ (в следующий круг): стадия env под sudo записывает /home/pi/ag-voice/.env.local как root:root 0600, а служба ag-sip-native работает от ubuntu → при рестарте бесконечный цикл «start-sip-native.sh: line 122: /home/pi/ag-voice/.env.local: Permission denied», 59 попыток авторестарта, телефония лежала ~6 минут. Лечение: chown ubuntu:ubuntu при сохранении 0600. Требование: стадия env обязана ставить владельца, совпадающего с User= юнита, и стадия verify обязана это проверять (сейчас verify прошёл на файле, который служба не может прочитать).

Круг 14 сдан: коммит 70eb5014 «fix(sip): harden lane8000 barge-in detection». Приёмка = волна 1585-accbargein на A1: гистерезис вместо обнуления счётчика слабым кадром, адаптивный порог от шумового пола, отсечение эха, новые замеры в call_summary (noise_floor_rms, threshold_rms, peak_rms, frames_above_threshold) и проверка находки про [google-bridge] в OpenAI-звонке. Приёмщику также поручено проверить, починен ли в самом land-скрипте дефект, из-за которого .env.local пишется от root при юните от ubuntu (при посадке круга 13 телефония лежала 6 минут).

ПОСАДКА круга 14 на живой шлюз 03.09 20:43Z. Коммит 70eb5014 (приёмка 1585 = GO). Приёмка 1600 замерила устройство на синтетике телефонного профиля: старый строгий гейт (RMS 1200, 12 подряд кадров, сброс на каждом слабом кадре) детектирует 1 попытку из 8 — теряется 87.5%; при RMS 450 тот же результат 1/8. Кандидат с 3-frame hangover: 8/8. То есть корень был не в пороге громкости, а в отсутствии удержания. Посадка: backup /tmp/lane8000-land/25ef6b3f25cc8e5e0c06b54f/lane8000-pre-20260903T204312Z.tar.gz (sha e4d109e5), stage ok, env ok (12 ключей, barge_in=1, mode 600), СРАЗУ после env выполнен chown ubuntu:ubuntu (03.09 утром на этом шлюз ушёл в 59 авторестартов), verify ok, рестарт ag-sip-native: ready, stasis connected, LEASE_LOST=0, greeting pre-warmed. Owner приглашён звонить.

Tuning-коммит 55d7ec4e = NO-GO: сделан на другой, сильно разошедшейся линии (относительно ee241c23 расхождение 24/140, относительно 70eb5014 — 25/140), патч не накладывается, и он терял принятый контракт круга 14. Круг настройки №2 = волна 1609-bargetuning2 на A1, ПОВЕРХ уже посаженного 70eb5014: env-параметры проходят end-to-end до детектора и до stasis policy, отрицательный RMS откатывается к 1200 с записью в лог (сейчас превращался в 1), контракт круга 14 сохраняется целиком.

Круг 2 настройки перебивания сдан: коммит 0f2ac6d1 (родитель 70eb5014, «preserve lane8000 barge-in env tuning»). Отчёт автора оказался НУЛЕВОГО размера — вынул коммит из рабочего дерева бандлом до уборки, ветка bargetuning2-line в /home/ubuntu/nc. Приёмка = волна 1618 на A1, с обязательным пунктом про стабильность старта: сегодня посадка этой линии привела к выходу супервизора с кодом 1 (Gateway PID is gone / Asterisk PID is gone) и авторестартам, каждый из которых снимал SIP-регистрацию владельца; обе сегодняшние посадки на живой шлюз откачены.

🔴 КОРНЕВАЯ ПРИЧИНА «тишины в трубке» 03–04.09 НАЙДЕНА и устранена ночью: в принятом круге 14 (70eb5014, посажен 20:43Z) опечатка — параметр называется pcm16k, а в теле используется pcm16 → ReferenceError: pcm16 is not defined на КАЖДОМ входящем аудиокадре. Каждое падение рвало ARI-сокет и перезапускало весь SIP-стек примерно за 24 с: отсюда гудок→тишина→reject и слетающие регистрации 7016 (в логе это выглядело как «Removed contact due to system boot»). Приёмка 1585 этого не поймала, потому что проверяла фикстуры, а не живой аудиопоток. Исправление: волна 1648, коммит 1928dd4e, приёмка 1654 в очереди. Контроль после правки: контрольный звонок прошёл (приветствие + полная сессия), 26 минут без падений; на 04.09 ~05:00Z NRestarts=0, readiness ready, stasis connected, вхождений «pcm16 is not defined» в gateway.out = 0. Требование к приёмке 1654: доказать на РЕАЛЬНОМ аудиопотоке (синтетический кадр PCM16 8 кГц через AudioSocket), а не только на фикстурах.

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

[07.09 12:08Z координатор] **Контрольный звонок владельца на 8000 (12:05:24Z 07.09, callId 3a9bfc7d…): трубка после приветствия — причина найдена по логу с метками (кит 2613 применён 11:59Z).** Цепочка: initial_greeting → disclosure delivered 12:05:35.812Z → listen_ready → 12:05:40.804Z `empty_input_audio_commit_nonfatal code=input_audio_buffer_commit_too_small action=recover` → `listen_ready reason=empty_commit_recovered` → **12:05:41.131Z `final status=gateway_error reason="Cannot read properties of null (reading 'promise')" stage=listen`** → hangup. Это 4-й сбой одного класса на живом звонке (v5 consent 07:54Z, v6 пустой коммит 08:34Z, v7 LISTEN 09:37Z, теперь null-объект хода после recover) → по правилу «третья находка одного класса = дефект устройства» волна **2627** (A2, sol xhigh) переделывает машину состояний хода (turn-контроллер, ошибки обработчиков не завершают звонок) на снимке живого кода 1210Z + RED/GREEN по трейсу; кит → окно рестарта. Трейс: A2 `waves/inputs/sip-live/call-8000-20260907T1206Z.log`. Также в окне 12:00Z: кит 2613 (метки времени + lease-poll по времени) применён; 2614 (509) откачен — маркер зависимостей не там (круг 2 = 2624); ротация ARI не подействовала (источник учётки не env → волна 2626).

[09.09 06:57Z координатор] 🔴 ДВА БОЕВЫХ ЗВОНКА ВЛАДЕЛЬЦА НА 8000 — ОБА ВОСПРОИЗВЕЛИ ОДНО И ТО ЖЕ. Теперь есть и журнал шлюза, и захват пакетов.

Звонок 1: 09.09 06:44:08–06:44:53, callId `856c2eb1-99b3-4cee-9e73-04c7e510c667`.
Звонок 2: 09.09 06:53:49–06:54:33, callId `7795ef02-a327-4faf-a0d5-42983be5915e`.

Слова владельца: «оборвал приветствие и потом тишина и какой то короткий артефакт звуковой периодически», второй раз — «привецтвие перебил своим запросом (шепотом) потом тишина и короткие артефакты».

## Сетевой уровень: звук ДОХОДИТ, обратно почти ничего

Захват `/home/ubuntu/ops-backups/lane8000-capture-20260909T064746Z/call.pcap00`, второй звонок:

| Направление | Пакетов RTP |
|---|---:|
| звонящий → A1 (:10014) | **2200** |
| A1 → звонящий (:10014) | **138** |
| A1 → звонящий (:10015) | 32 |
| звонящий → A1 (:10015) | 23 |

2200 пакетов за 44 секунды — это полноценный поток голоса. Обратно ушло 138 пакетов, при 20 мс на пакет это около 2,8 секунды звука: ровно обрезанное приветствие, дальше тишина.

**По четырём случаям из `capture-8000-call.sh` это СЛУЧАЙ 2: RTP есть на сетевой карте, но не доходит до Stasis и провайдера.** Ни сеть, ни оператор, ни периметр OCI ни при чём. Звук умирает внутри машины.

## Что говорит шлюз

Итоги обоих звонков:
```
звонок 1: providerAppendCount=0 providerAppendBytes=0 candidateFrames=0
          dropped_audio_bytes=434400 frames_above_threshold=81  peak_rms=28694  threshold_rms=126
          barge_events=1 barge_latency_ms=7
звонок 2: providerAppendCount=0 providerAppendBytes=0 candidateFrames=0
          dropped_audio_bytes=403200 frames_above_threshold=172 peak_rms=3106   threshold_rms=120
          barge_events=1 barge_latency_ms=3
оба:      greeting_blocked=[missing_live_bridge,external_channel_not_ready,already_requested]
```

Во втором звонке владелец говорил ШЁПОТОМ (пик 3106 против 28694 в первом) — и всё равно 172 кадра выше порога. То есть порог ни при чём: голос распознан как речь, но провайдеру не ушло НИ ОДНОГО БАЙТА в обоих звонках.

## Два дефекта, оба подтверждены дважды

1. **Приветствие теряется навсегда.** Запрос выдаётся до постройки медиа-моста, блокируется и помечается `already_requested`. Через 240 мс мост готов, но заново приветствие никто не выдаёт — все ретраи по таймауту упираются в `already_requested`. Это тишина после обрыва.
2. **Голос звонящего не доезжает до модели.** 403–434 килобайта выброшено в `dropped_audio_bytes`, `providerAppendCount=0`.

Плюс подозрение: перебивание срабатывает через 3–7 мс на нулевом ходу — похоже на срабатывание по эху приветствия.

Волна **3181** работает с этим следом. Сетевые доказательства выложены отдельно: `/home/ubuntu/waves/CALL-8000-RTP-EVIDENCE.md`.

[09.09 07:15Z координатор] 🔬 УТОЧНЕНИЕ ДИАГНОЗА: ДЕФЕКТ ОДИН, А НЕ ДВА. Мой предыдущий комментарий назвал две независимые поломки — это неверно, и вот доказательство.

Владелец сам поставил A/B-опыт: позвонил дважды, в первый раз НЕ перебивал приветствие, во второй перебил. Оба раза говорил шёпотом. Журнал подтверждает его слова дословно.

| | Звонок A, 07:09:50 — приветствие НЕ перебито | Звонок B, 07:11:09 — приветствие перебито |
|---|---|---|
| callId | `9f780a59-13f8-4a9d-aa70-1d0f581d5ddf` | `96c7070d-7942-4510-bf64-cc502d6ea830` |
| providerAppendCount | **645** | **0** |
| providerAppendBytes | **412 800** | **0** |
| barge_events | 3 — перебивал ОТВЕТЫ, и это работало | 1 — перебил приветствие |
| stage при отбое | **listen** | **playback** |
| dropped_audio_bytes | 2 404 800 | 420 000 |
| frames_above_threshold | 343 | 154 |

## Что отменяется

Я утверждала: «голос звонящего не доезжает до модели» — как самостоятельный дефект №2. **Это неверно.** Голос доезжает: 645 добавлений, 412 килобайт, и перебивание ответов работает три раза подряд в том же звонке. Нулевой `providerAppendCount` в предыдущих трёх звонках был СЛЕДСТВИЕМ, а не отдельной причиной.

## Что остаётся

**Один дефект: перебивание ПРИВЕТСТВИЯ (нулевого хода) убивает сессию навсегда.** Приветствие помечается `already_requested` и заново не выдаётся; сессия остаётся в `stage=playback` и никогда не переходит в `listen`; звук звонящего некому забирать, и он весь уходит в `dropped_audio_bytes`.

Перебивание последующих ответов исправно — доказано тремя срабатываниями в звонке A.

## Что это меняет для волны 3181

Приоритет смещается: чинить надо **переход хода после отменённого приветствия**, а не путь звука. Путь звука исправен. Требование «найти, где 434 килобайта уходят в dropped вместо providerAppend» в брифе поставлено неточно — ответ на него теперь известен: они уходят туда потому, что ход не начался.

Уточнение дописано в `/home/ubuntu/waves/CALL-8000-RTP-EVIDENCE.md` (58 строк, оба сравнения).

## Отдельно, не закрыто

`candidateFrames=0` в ОБОИХ звонках, включая полностью рабочий — счётчик ни о чём не говорит, опираться на него нельзя.

Владелец слышит короткий артефакт в тишине примерно раз в секунду. По журналу повторные попытки выдать приветствие идут раз в двенадцать секунд — значит щёлкает что-то другое. Не закрыто, ловушка пакетов слушает до ~09:47Z.

## Обходной путь для владельца, пока не починено
Не перебивать первое приветствие; дождаться его конца. Дальше перебивать можно свободно.

[09.09 07:18Z координатор] 📋 ПОЛНОЕ ОБОГАЩЕНИЕ ТИКЕТА ПО ЗАПРОСУ ВЛАДЕЛЬЦА: вся эволюция контура SIP за ночь 08→09.09, все находки, все нерешённые проблемы. Заменяет и дополняет два предыдущих комментария этого часа.

## 1. ЧЕТЫРЕ БОЕВЫХ ЗВОНКА ВЛАДЕЛЬЦА — сводная таблица

Все четыре на 8000, 09.09, журнал `/tmp/ag-asterisk-logs/gateway.out` на A1, метка `[stasis-snoop-spike]`.

| Время | callId | Приветствие | append (порций/байт) | barge | задержка barge | dropped | кадров > порога | stage при отбое |
|---|---|---|---:|---:|---:|---:|---:|---|
| 06:44:53 | `856c2eb1` | перебито | 0 / 0 | 1 | 7 мс | 434 400 | 81 | playback |
| 06:54:36 | `7795ef02` | перебито (шёпот) | 0 / 0 | 1 | 3 мс | 403 200 | 172 | playback |
| 07:09:50 | `9f780a59` | **НЕ перебито** | **645 / 412 800** | **3** | 4 мс | 2 404 800 | 343 | **listen** |
| 07:11:09 | `96c7070d` | перебито | 0 / 0 | 1 | 3 мс | 420 000 | 154 | playback |

Во всех четырёх: `greeting_blocked=[missing_live_bridge, external_channel_not_ready, already_requested]`.

## 2. ЭВОЛЮЦИЯ ДИАГНОЗА — три версии, две отменены

**Версия 1 (06:45, по первому звонку).** Назвала два независимых дефекта: приветствие теряется навсегда; голос звонящего не доезжает до модели.

**Версия 2 (06:58, добавлен захват пакетов).** Сетевой уровень снял подозрения с сети и оператора: от звонящего 2200 пакетов RTP за 44 секунды, обратно 138 (≈2,8 с — обрезанное приветствие). По разметке `capture-8000-call.sh` это СЛУЧАЙ 2: RTP есть на сетевой карте, но не доходит до Stasis и провайдера.

**Версия 3 (07:13, A/B владельца) — ДЕЙСТВУЮЩАЯ.** Владелец сам поставил опыт: один звонок без перебивания приветствия, другой с перебиванием. Результат в таблице выше однозначен. **Дефект ОДИН, а не два.** Утверждение «голос не доезжает до модели» ОТМЕНЯЮ: в звонке 9f780a59 модель получила 645 порций и 412 килобайт, и перебивание ОТВЕТОВ отработало три раза подряд.

## 3. ДЕЙСТВУЮЩИЙ ДИАГНОЗ

**Перебивание ПРИВЕТСТВИЯ (нулевого хода) убивает сессию навсегда.** Механика по журналу:
1. запрос приветствия выдаётся ДО постройки медиа-моста → `initial_greeting_blocked reason=missing_live_bridge`, `externalReady=false`;
2. следом `reason=external_channel_not_ready`;
3. через ~240 мс мост готов (`snoop_created` → `udp_bound` → `snoop_joined` → `upstream_media_joined`, `externalReady=true`) — **но запрос уже помечен `already_requested` и заново не выдаётся**;
4. срабатывает barge-in на нулевом ходу (3–7 мс), `playback_stopped ok=true`, `response_cancelled ok=true`;
5. три ретрая `source=caller_audio_timeout_retry` каждые 12 с упираются в `already_requested`;
6. сессия навсегда остаётся в `stage=playback`, перехода в `listen` не происходит → звук звонящего некому забирать → всё в `dropped_audio_bytes`.

Нулевой `providerAppendCount` — СЛЕДСТВИЕ пункта 6, а не самостоятельная поломка.

## 4. ЧТО РАБОТАЕТ (доказано, не предполагается)

- Приём звука до машины: 2200 пакетов RTP за звонок.
- Путь звука до модели: 645 добавлений, 412 КБ в звонке без перебивания приветствия.
- Перебивание ОТВЕТОВ: 3 срабатывания в одном звонке, все успешные.
- Сам стек: `ag-sip-native` активен, Asterisk держит 5060 и 8088, шлюз на 4080 отвечает `reachable`, `telephonySecurity.gatewaySecretConfigured=true`, `laneClaimSecretConfigured=true`.
- После каждой из восьми ночных посадок: `sip readiness 4080 = 200`, `LEASE_LOST = 0`.

## 5. НЕЗАКРЫТЫЕ ВОПРОСЫ — честно, без замалчивания

1. **`candidateFrames=0` во ВСЕХ четырёх звонках**, включая полностью рабочий 9f780a59 с 645 добавлениями. Счётчик ни о чём не говорит; опираться на него при диагностике нельзя. Причина не выяснена.
2. **Артефакт раз в секунду в тишине.** Владелец слышит короткий звук примерно каждую секунду в обоих «мёртвых» звонках. По журналу повторные попытки приветствия идут раз в 12 секунд — значит щёлкает что-то другое. Не найдено. Ловушка пакетов слушает до ~09:47Z, материал накапливается.
3. **`dropped_audio_bytes=2 404 800` в РАБОЧЕМ звонке.** Даже когда всё шло правильно, 2,4 мегабайта звука выброшено против 412 килобайт принятых. Отношение примерно шесть к одному. Возможно так и задумано (снуп слышит обе стороны и режет своё), но это не проверено.
4. **Ротация ключа ARI заблокирована устройством запуска.** Строка 73 в `start-sip-native.sh` перебивает `EnvironmentFile` из `/etc/ag-sip/ari.env`. Ротацию 08.09 откатили, телефония цела. Пока ротация невозможна, единственная защита — вычёркивание адреса в журнале (закрыто в WEB-531, посажено в l114i).

## 6. БЕЗОПАСНОСТЬ КОНТУРА — проверено за ночь

- **Постоянное сканирование из интернета.** За 20 минут захвата: 12+ уникальных источников, **284 попытки INVITE**, включая `INVITE sip:+14063890227@129.213.25.105:5060` — попытка платного звонка через нас.
- **Защита держит:** Asterisk отвечает `SIP/2.0 401 Unauthorized`, RTP от сканеров ноль.
- **fail2ban живой:** джейл `asterisk-sip-auth`, всего банов 534, сейчас забанено 8, список совпадает со сканерами из захвата.
- SEC-003 (очистка аудио по владению вызовом, WEB-519) — закрыт, приёмка на живой вершине.
- SEC-014 (ключ ARI в журнале, WEB-531) — ключ **действительно утекал тремя способами**, все закрыты, тестов 62 вместо 32, посажено в l114i.
- Набор тестов шлюза на Linux: **301 из 301**. На macOS падает `sec014dAriAddressRedaction.test.js:405` (читает `/proc`) — платформенная ловушка, не регресс.

## 7. ИНСТРУМЕНТЫ, СОЗДАННЫЕ ЗА НОЧЬ

- `/home/ubuntu/capture-8000-call.sh <минут>` — синхронный снимок звонка, tcpdump с ротацией 20×20 МБ на `enp0s6`, фильтр `udp portrange 10000-10020 or port 5060`. Разделяет четыре случая: нет RTP на карте / есть на карте но не в Stasis / ingress есть egress нет / оба есть.
- `/home/ubuntu/waves/CALL-8000-RTP-EVIDENCE.md` — 58 строк сетевых доказательств с A/B-сравнением.
- `/home/ubuntu/dryrun-chat-probe.sh <порт>` — живая проба чата, вшита в сухой прогон посадки (не про SIP, но родилась из того же урока: проверять поведением, а не кодом ответа).

## 8. РАБОТА В ХОДУ

Волна **3181** — чинит переход хода после отменённого приветствия. Приоритет ей уточнён после A/B: путь звука исправен, чинить надо `playback → listen`.

## KNOWN ISSUES / ТРАБЛШУТИНГ

| Симптом | Проверка | Причина (файл:строка) | Лечение | Ссылки |
|---|---|---|---|---|
| Перебил приветствие — дальше тишина навсегда | `sudo grep call_summary /tmp/ag-asterisk-logs/gateway.out \| tail -1`: `stage=playback`, `providerAppendCount=0` | Запрос приветствия помечается `already_requested` при блокировке по неготовности моста и заново не выдаётся; сессия не переходит `playback → listen` | Обходной путь: не перебивать первое приветствие. Постоянный — волна 3181 | `CALL-8000-RTP-EVIDENCE.md` |
| «Голос не доходит до модели» | Сравнить `providerAppendCount` в звонке с перебитым и неперебитым приветствием | Это НЕ отдельный дефект — следствие застревания в `playback` | Чинить пункт выше | звонок `9f780a59`: append=645 |
| Захват пакетов не поймал звонок | `pgrep -f tcpdump` | Окно захвата истекло — скрипт принимает минуты первым аргументом | Ставить окно с запасом; 09.09 звонок пришёл через 5 минут после закрытия 120-минутного окна | `capture-8000-call.sh` |
| Тест шлюза падает на macOS (`path 5c`) | Прогнать тот же набор на Linux | `infra/sip/gateway/__tests__/sec014dAriAddressRedaction.test.js:405` читает `/proc/<pid>/cmdline` | Гонять набор шлюза на Linux; на macOS это ложный NO-GO | на A1: 301/301 |
| Ротация ключа ARI не применяется | `systemctl show ag-sip-native -p Environment` | Строка 73 `start-sip-native.sh` перебивает `EnvironmentFile` из `/etc/ag-sip/ari.env` | Чинить строку 73 ДО попытки ротации | откат 08.09, телефония цела |
| Сканеры долбят 5060 | `sudo fail2ban-client status asterisk-sip-auth` | Обычное фоновое сканирование интернета | Ничего не делать: 401 + fail2ban (534 бана всего, 8 активных) | 284 попытки INVITE за 20 мин |

ЭВОЛЮЦИЯ 10.09 — владелец звонил на 8000 дважды за день, оба раза с моей подачи.

12:43Z — РЕДЖЕКТ. Причина не в живом плече: диалплан отработал правильно (Answer, вход в Stasis
live-8014-snoop-ingress-spike, кодек ulaw согласован на входящей ноге). Сломалось на открытии
сессии в приложении — 403 origin_boundary_rejected. Виновата моя посадка шлюза, разбор в WEB-578.
Call ID для истории: 8f1c7709-564f-48de-b9cf-e03e9ac855be и a77f73b6-a83f-4e76-b1e2-db6ecb7d8118.
В обоих call_summary: providerAppendCount=0, candidateFrames=0, barge_events=0, provider_effective=unknown —
до провайдера не дошло ни байта.

12:56Z — после отката ТЕЛЕФОНИЯ ОТВЕЧАЕТ, владелец подтвердил.
Остаточный дефект, который он назвал сам: ассистент НЕ ЗНАЕТ НАЗВАНИЕ ТЕТРАДИ.
Это не телефония — это распознаватель вопроса про тетрадь, тикет WEB-580, волна 3287 в работе.

Состояние живого плеча на сейчас: transport=audiosocket, snoop-spike connected,
порты 4574 (AudioSocket) / 8088 (ARI) / 4084 (health, ok), дialплан 8000 ведёт в Stasis + AGI.
Перебивание (barge-in) починено 09.09 волной 3195 на живом шлюзе: providerAppendCount 0 -> 2704.

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): живое плечо 8000 работает, barge-in починен (3195, владелец подтвердил). Остались краевые дефекты: перебивание приветствия убивает сессию (диагноз 09.09) и артефакт в тишине. Шлюз живёт вне репо (~6700 строк дрейфа) — чинить на живом шлюзе диффом, а не посадкой релиза. Статус не менять.
Остаток: Перебивание приветствия (нулевого хода) — закрыто ли после 3195, не доказано.; Артефакт ~раз в секунду в тишине после перебитого приветствия — не найден.; candidateFrames=0 и dropped_audio_bytes (2.4МБ в рабочем звонке) — счётчики не объяснены.; Ротация ARI-ключа заблокирована (start-sip-native.sh:73) — известный остаток.
Отчёт: /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): Телефон на 8000 умеет перебивать ассистента, и это работает — владелец проверял. Но есть одна дырка: если человек перебьёт самое первое приветствие, разговор умирает и дальше тишина. Мы нашли в коде, почему: приветствие просится раньше, чем готов мост, и потом помечается «уже просили», поэтому его больше не повторяют. Ещё мы объяснили два загадочных счётчика: candidateFrames всегда ноль, потому что это временный буфер, который чистят на каждом ходе; а dropped_audio_bytes — это выброшенная речь самого ассистента после перебивания, а не голос человека. Осталось доказать на живом звонке, что приветствие переживает перебивание, и поймать тихий щелчок раз в секунду захватом пакетов.
Остаток: Перебивание ПРИВЕТСТВИЯ (нулевого хода) по-прежнему не доказано починённым: по коду запрос приветствия блокируется как already_requested до готовности моста (stasisSnoopIngressSpike.js:5664-5695) и не перевыдаётся; нужен живой A/B-звонок.; Артефакт «короткий звук ~раз в секунду» в тишине: кандидат — idle-keepalive 400 мс/20 мс (audiosocketTransport.js:87-89, 835-839, 2022-2050), НЕ подтверждён захватом RTP.; Ротация ARI-ключа заблокирована: на живом шлюзе start-sip-native.sh:73 перебивает EnvironmentFile /etc/ag-sip/ari.env (в репо ARI-пароль читается из SIP_SIDECAR_ARI_PASSWORD, start-sip-native.sh:76-78 — дрейф).
Предложение: Провести стандартизованный A/B-звонок (перебить/не перебить приветствие) с чтением call_summary и greeting_blocked; подтвердить переход stage=playback→listen после перебивания приветствия. Параллельно снять tcpdump мёртвого эфира для артефакта. Счётчики candidateFrames=0 и dropped_audio_bytes считать объяснёнными и закрыть их как остатки.
Материалы: shift-20260912-resume/colM2|colP2/ (RESULT.md — ранбуки и спецификации). Статус не меняю.

[13.09 10:37Z координатор] Мойка доски, волна 3654. RETURN. Живое плечо и barge-in работают (волна 3195, владелец подтвердил, providerAppendCount 0→2704); остался дефект перебивания приветствия (нулевой ход) + артефакт ~раз/сек в тишине + ротация ARI. Статус не меняю.

[13.09 12:53Z координатор] Волна 3704. [13.09 волна 3704 — план доказательства, остаток] Разобрал остаток на три части и подготовил сценарий живого звонка для владельца и процедуру ротации. Доказательств по трём частям ПОКА НЕТ — карточка не закрывается (RETURN). План: waves/3704-telephony-live-leg-out/PROOF-PLAN.md; сценарий владельца: waves/3704-telephony-live-leg-out/OWNER-CALL-SCRIPT.md. Три части и чем каждая закрывается: (1) Перебивание ПРИВЕТСТВИЯ — нужен живой A/B-звонок (перебить/не перебить приветствие) с чтением call_summary и greeting_blocked: успех = stage=listen и providerAppendCount>0 у перебитого звонка, приветствие не застревает в already_requested (stasisSnoopIngressSpike.js:5664-5695). (2) Артефакт ~раз/сек в тишине — нужен tcpdump мёртвого эфира и замер реального периода; кандидат idle-keepalive 400мс/20мс (audiosocketTransport.js:87-89,835-839,2022-2050) НЕ подтверждён и не стыкуется по периоду (ретраи приветствия 12с). (3) Ротация ARI-ключа — заблокирована start-sip-native.sh:73 (перебивает EnvironmentFile /etc/ag-sip/ari.env). Счётчики candidateFrames=0 и dropped_audio_bytes считаю объяснёнными (разбор волны 3632) и закрываю как остатки. Статус не меняю.

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

Источники, проверенные отсюда: тело тикета из live API; все 43 комментария из локального `web-board.sqlite`, последний комментарий `id=4781` от 2026-09-13T12:53:05.684Z. Статус на live API при финальной сверке: `in_progress`. Live calls/RTP отсюда не проверялись.

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

Номер 8000 должен быть живым плечом: приветствие, disclosure, слушание, barge-in и штатный отбой. Сейчас есть зависимые дефекты: если перебить первое приветствие, сессия может умереть, а в тишине слышен периодический артефакт.

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

Заявлено и доказано комментариями: response barge-in работает после wave 3195; комментарий `id=3422` даёт owner A/B и отменяет ранний вывод, что голос “не доходит до модели”. `id=3453` уточняет, что один из отказов был вызван WEB-578 origin boundary, а не live leg. `id=4781` говорит, что wave 3704 подготовила proof plan и owner-call script, но live evidence ещё нет.

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

Доказать и исправить first greeting interrupt: кодовая зона `stasisSnoopIngressSpike.js:5664-5695`, где greeting requested before bridge ready and marked already requested. Отдельно проверить periodic silence artifact, вероятно вокруг `audiosocketTransport.js:87-89,835-839,2022-2050`, через RTP/log capture. ARI rotation blocked by `start-sip-native.sh:73`.

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

Комментарий `id=3421` утверждал два дефекта: greeting lost и voice not reaching model. Поздние `id=3422`/`id=3423` отменили это: voice reaches model if greeting not interrupted; response barge-in works. Следовательно, не надо чинить “весь live leg” заново.

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

Смотреть: `infra/sip/gateway/stasisSnoopIngressSpike.js`, `infra/sip/gateway/audiosocketTransport.js`, wave 3704 proof plan, WEB-578 for gateway drift, WEB-508 for restart persistence. Первый шаг: воспроизвести owner-call script на живом/стендовом gateway после сверки с WEB-578 и доказать one-turn interrupt trace.

Готово: owner/live or controlled call shows first greeting can be interrupted without killing session; silence artifact either fixed with capture or explicitly ruled out; ARI source identified for rotation path.

Нельзя: делать blind deploy/restart gateway, менять `/home/pi/ag-voice` из repo без WEB-578 reconcile, считать `candidateFrames`/`dropped_audio_bytes` самостоятельным blocker после разбора 3632, путать origin-boundary 403 с live-leg defect.

Размер: смена. Большим это делает live call/RTP evidence and dependency on WEB-578/508, а не широкий code rewrite.

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

Не закрыто. Связано с WEB-578, WEB-508 и WEB-565, но не является дублем: здесь именно поведение разговора на 8000.

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

### 1. Вердикт
Якорь в теле — l103 `d91ebefe` (04.09) — отстал примерно на семь линий. Живая линия —
**l115o `68e25d8df5ae8263c5ac5466353631f57a17cfcc`**. По трём частям остатка доказательств
ПО-ПРЕЖНЕМУ НЕТ; карточка не закрывается.

### 2. КАРТА ДОКАЗАТЕЛЬСТВ
- Тело: живое плечо работает; перебивание ОТВЕТОВ подтверждено владельцем — волна 3195 (09.09)
  на живом шлюзе, `providerAppendCount 0→2704`.
- Тело: остаётся боевой дефект перебивания ПЕРВОГО приветствия (нулевой ход) — по коду
  `stasisSnoopIngressSpike.js:5664-5695` запрос приветствия блокируется как `already_requested`
  до готовности моста и не перевыдаётся, сессия застревает в `stage=playback`; починка живым
  A/B-звонком НЕ доказана.
- Тело: артефакт «короткий звук ~раз в секунду» в тишине (кандидат idle-keepalive 400 мс/20 мс,
  `audiosocketTransport.js:87-89,835-839,2022-2050`) не подтверждён захватом RTP.
- Тело: ротация ARI-ключа заблокирована (на живом шлюзе `start-sip-native.sh:73` перебивает
  EnvironmentFile).
- Доска WEB-479 id 4781 (2026-09-13T12:53:05.684Z), волна 3704: план доказательства —
  `waves/3704-telephony-live-leg-out/PROOF-PLAN.md`; сценарий владельца —
  `waves/3704-telephony-live-leg-out/OWNER-CALL-SCRIPT.md`. Критерий успеха первой части:
  `stage=listen` и `providerAppendCount>0` у перебитого приветствия.
- Доска WEB-479 id 5043 (2026-09-14T15:16:34.454Z): live calls/RTP отсюда не проверялись.
- HANDOFF-LIVE.md §4 строки 504–515 (пять дыр телефонии; комната-встреча защищена правильно).

### 3. ЭВОЛЮЦИЯ / ПОПРАВКИ (append-only)
- Якорь: l103 `d91ebefe` → **l115o `68e25d8df5ae8263c5ac5466353631f57a17cfcc`**.
- 13.09 волна 3704 разложила остаток на три части и подготовила сценарий живого звонка для
  владельца. **Доказательств по трём частям нет** — это честный RETURN, а не прогресс.
- Смежное: аудит 3947 нашёл пять дыр доступа телефонии (handoff §4); они не в этой карточке,
  но затрагивают тот же живой контур — не дублировать сюда.

### 4. KNOWN ISSUES / ТРАБЛШУТИНГ
1. **Перебивание первого приветствия убивает сессию.**
   - Симптом: после перебивания приветствия сессия застревает в `stage=playback` навсегда.
   - Проверка за 2 минуты: живой A/B-звонок по `OWNER-CALL-SCRIPT.md` с чтением `call_summary` →
     ожидание `stage=listen` и `providerAppendCount>0` на перебитом ходе.
   - Причина (по коду): запрос приветствия блокируется как `already_requested` до готовности
     моста и не перевыдаётся — `stasisSnoopIngressSpike.js:5664-5695`.
   - Лечение/статус: НЕ доказано живым звонком. Без A/B-звонка не закрывать.
   - Ссылки: тело; `PROOF-PLAN.md`; `OWNER-CALL-SCRIPT.md`.
2. **Периодический звук в тишине.**
   - Симптом: короткий звук примерно раз в секунду при молчании.
   - Проверка за 2 минуты: захват RTP в тишине → ожидание отсутствия периодического пакета.
   - Причина (кандидат): idle-keepalive 400 мс/20 мс, `audiosocketTransport.js:87-89,835-839,2022-2050`.
   - Лечение/статус: кандидат не подтверждён захватом RTP; не «чинить» до подтверждения.
3. **Ротация ARI-ключа заблокирована живым скриптом.**
   - Симптом: значение секрета перебивается `EnvironmentFile` на живом шлюзе.
   - Проверка за 2 минуты: `grep -n` по строкам вокруг `start-sip-native.sh:73` на живом
     шлюзе → ожидание, что строка не перебивает окружение.
   - Лечение/статус: требует изменения на живом хосте (зона координатора, правило 11 канона).

### 5. ТЕКУЩИЙ ОСТАТОК (ответственный)
1. Часть 1 — живой A/B-звонок по приветствию — владелец + координатор.
2. Часть 2 — захват RTP в тишине — координатор.
3. Часть 3 — ротация ARI-ключа без поломки живого скрипта — координатор.
4. Статус карточки не менять до появления доказательств.

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

---

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=2026-09-15, ENRICH-4132: по трём частям остатка доказательств по-прежнему нет; раздел «ТЕКУЩИЙ ОСТАТОК (ответственный)» назначает владельца и координатора
ЧТО НУЖНО=Владелецу и координатору выполнить живую A/B-проверку перебитого приветствия; координатору снять RTP-захват тишины и закрыть ротацию идентификатора
triage-neo 4608

РЕШЕНИЕ=parked
ОСНОВАНИЕ=2026-09-15, волна 4132 DRAFT_DELTA: текущая линия l115o 68e25d8d; по трём частям остатка нет доказательств, включая live A/B перебитого приветствия
ЧТО НУЖНО=ЖДЁТ=владелец: выполнить live A/B-звонок перебитого приветствия с координатором; triage-neo 4707