WEB board

[WEB370-I] Telegram user-session и bot singleton qualification

Источник: WEB370PLAN2. Зависимости: WEB370-A,B,C,F,G. Оценка: 1.5 дня. Offline mocks/fixtures; production session/tokens не подключать.

--- 30.08 ~16:00Z (Фабл): ПРИЁМКА PASS_OFFLINE (ACCWEB370I): session round-trip через B-формат, singleton (второй паркуется), битая сессия → отказ, production tokens отсутствуют (греп). Ступень I ЗАКРЫТА (ship-dark; live-квалификация с боевой сессией — на этапе cutover-подготовки). Отчёты: A1 ACCWEB370I-REPORT.md, WEB370I-REPORT.md (ветка wave/web370i 5b8b21da).

Mocked Telethon/NTgCalls suite green; один worker/session; fixture replay без дублей; один active webhook/polling consumer на bot; prod connect невозможен в dark mode.

[2026-08-27 10:50Z] web407i в очереди A1: offline mock Telethon lifecycle, bot singleton negативе, session-миграция дизайн (структурная верификация без прод).
[2026-08-27 11:20Z] WEB407I DONE: offline mock-квалификация зелёная (lifecycle, bot singleton negативе через lease), session-миграция дизайн со структурной верификацией. Честный список остаточных NO-GO гейтов до live-приёмки (hash-qualified sources, sealed credentials, cold snapshot после fence, lease ACTIVE). -> review.
[2026-08-27 20:29:19Z tickacc5] ВЕРДИКТ: частично доказано
Что проверил: открыл WEB407I-REPORT.md и offline qualification artifacts; проверил mock/fixture results и поиск actual bot source/mode/state paths.
Что увидел: offline mock qualification зелёная, включая single-worker/fixture replay и duplicate-worker rejection; production credentials/session/provider не использовались. Actual bookbot/gptbot sources, webhook|polling modes и state/offset/dedupe paths не предъявлены; report оставляет production NO-GO.
Отрицательный тест: второй mock worker/duplicate path получил отказ; offline fixture не заменяет production positive trace.
Чего не хватает: hash-qualified sources/locks, per-bot mode/state inventory, current lease/fence evidence и paired authenticated acceptance/restore proof.

[2026-08-27 21:58Z EVID407408] Read-only current-state supplement. WEB-407: A1 snapshot has 0 matching Telegram/bot processes; telegram-call-native, bookbot and gptbot are loaded but inactive/dead, disabled, ConditionResult=no, ExecMainPID=0; /etc/web370/ACTIVE and lease are absent, and A1 web370-a1 release entrypoints are absent. Native source uses Telethon StringSession from TELEGRAM_STRING_SESSION (main.py:62; config.py:104-112), mounted through sealed EnvironmentFile /etc/web370/secrets/telegram-call-native.env (mode 0640; value not read); no persistent native SQLite session path is configured. bookbot/gptbot mode/state paths and Pi process count remain unproven because Pi and M1 SSH were unavailable; production credentials were not touched. Fixed-name units/lease gate and offline mock second-route rejection (409 webhook_conflict) are proven, but not a production duplicate proof. Owner decision required: approve one fenced authenticated health/start window after hash-qualified source/mode/state inventory, with one process/listener per actual consumer and a repeated identical update in disposable/non-production account proving one side effect/zero duplicates; no credential values, live calls or second production account.

[2026-08-27 21:58Z EVID407408] WEB-408: current A1 web408j-asterisk and all discovered A1 SIP/call units are inactive/dead, disabled, ConditionResult=no; relevant processes/listeners are 0; /etc/web370/ACTIVE absent; lease precheck rc=1; current systemd-analyze verify rc=0/0B. Source and installed asterisk.conf/extensions.conf/pjsip.conf/rtp.conf/unit compare cleanly (artifact manifest 10/10 OK). Current config enforces maxcalls=5 plus WEB408J_HARD_CAP=5 with GROUP_COUNT cap branch; transport is 127.0.0.1:15060, RTP 18000-18099, endpoint match 127.0.0.1/32, and baresip regint=0 with no registrar. Thus current ship-dark boundary and zero active REGISTER-capable lane are proven read-only. Existing dynamic summary remains stale/inconsistent: summary/TSV RTP=3982/3982 while WEB408J-REPORT claims 3985/3985; no runtime qualification was rerun because it starts processes and rewrites evidence. Dynamic 1→3→5 acceptance remains open. Owner GO is only needed for a future isolated synthetic rerun; provider credentials/live calls remain forbidden.

[BOARDTRIAGE] Последнее read-only evidence 27.08 21:58Z: все Telegram units на A1 inactive, offline duplicate rejection доказан, production state/режимы Pi не подтверждены. Нужен fenced authenticated health/start window и zero-duplicate proof.