WEB board

ENTERPRISE2-LINKS:CAP-05
Parent: WEB-626
Зависимости: WEB-628 (CAP-01)
Спецификация целиком в WEB-626. Порядок: подготовка → изолированный стенд/T0 → выделенные измерения → независимый итог. CAP-13 опциональный.

FILL-2104:3387:active
Проверено 2026-09-10T21:10:06.758266+00:00. Волна 3387, A2, состояние active. Живая tmux pane и свежий журнал подтверждены. Exact BASE 34a06c66222b8335d35d1bc7b86150f49d64d7e9. Входы SHA256 и bundle ref проверены перед dispatch. Бриф Intel nc-ops-scripts/fill-slots-20260910-2104/3387-cap-provider-stub-brief.md. Сдача /home/ubuntu/waves/3387CAPPROVIDERSTUB-REPORT.md. Посадки/окончательной приёмки этой работы нет. CAP-01 вернулся NO-GO 3376, доработка 3388. Эта работа только независимая подготовка; итоговая интеграция и измерения заблокированы до принятия контрактов. Нагрузки на реальные endpoints нет.

DISPATCH-20260910-3397
На 2026-09-10T21:38:23.260126+00:00: active; A2, волна 3397 acc-cap-stub. Exact BASE e0268d9c04c100b1b1fd877ab89f080e5e2a7780. Бриф прошёл brief-guard; входы SHA256 и наличие BASE проверены до постановки. Входы /home/ubuntu/waves/inputs/3397-acc-cap-stub. Отчёт ожидается /home/ubuntu/waves/3397ACCCAPSTUB-REPORT.md. Живой процесс модели подтверждён; возраст журнала 46 с. Source/подготовка и независимая проверка — в объёме брифа; это не посадка, не live/capacity GO и не окончательное закрытие security.

REFILL-20260910-2155-3417
Снимок 2026-09-10T21:54:52.066911+00:00. Волна 3417 / cap-stream-lifecycle-rework на A1: active. Оператор Codex, модель gpt-5.6-luna. Живой процесс подтверждён; возраст журнала 27 с. Входы /home/wave/waves/inputs/3417-cap-stream-lifecycle-rework; SHA256 и exact BASE 58e57f98366a426bce60a8b5a9daf953fd38a540 проверены при доставке. Новых посадок и измерений capacity нет; source QA не означает окончательное закрытие Security.

REFILL-2221-RESULTS-WEB-632
Снимок 2026-09-10T22:27:17.204978+00:00

Волна 3431 a2nc gpt-5.6-sol: active (дочерний процесс подтверждён, журнал 7 с); exact BASE d03a93f613a27974b28191b4ed766a67bd5a1849; inputs /home/ubuntu/waves/inputs/3431-acc-stream-terminal
Новой посадки этим тиком нет. Evidence: nc-ops-scripts/refill-20260910-2221/.

SLOTS12-BATCH3442-3461-WEB-632
2026-09-10T22:50:05.652264+00:00 Лимиты A1/A2 подняты до12; действовавшие worker panes сохранены. Волна 3452 a1nc active stream-ledger-e2e; BASE c97f424ee1919fe4ec86a6014980a0f1ac9bf492; model gpt-5.6-sol
Волна 3453 a1nc queued stream-ledger-recovery; BASE c97f424ee1919fe4ec86a6014980a0f1ac9bf492; model gpt-5.6-sol
Брифы прошли guard; входные report/history/raw/bundle переданы и SHA проверены до очереди. Source/QA scope, посадки и measured capacity не заявляются.

CHECKPOINT3483:WEB-632 2026-09-10T23:42:32.159576+00:00
3452 NO-GO: combined real-PG E2E 3/4, sourceReturnCalls=0 при consumer return; разрыв src/lib/billing/vendorEgressGuard.ts. 3453 отдельно доказала durable recovery 1/1, zero drift, без исправления этого разрыва. Ремонт 3481 доставлен, inputs SHA и exact BASE b7cec0f640a3251a1650c3907a7c7e34b6db8a37 проверены, запуск наблюдался. Не считать CAP05 принятым целиком.
Доказательства: /Users/annakorin/nc-ops-scripts/checkpoint-3483/snapshot.json и полные *-REPORT.md; доставка: capacity-integration-3480, refill-20260911-0040, refill-20260911-0046. Норматив: enterprise2-20260910/ENTERPRISE-2.md.

CHECKPOINT3488:WEB-632 2026-09-11T00:15:51.647210+00:00
3481 author repair GO, HEAD5d6de6f93b5a7fc0e4c3d7182cf04798135aff00: unchanged PG E2E3/4→4/4, inherited33/33, lifecycle6/6. Бандл/SHA проверены. Независимая component/PG regression3485 реально работает на A2; это не security certification или live acceptance. Evidence: checkpoint-3488/snapshot.json; capacity-integration-3487; refill-20260911-0110.

CHECKPOINT3490:WEB-632 2026-09-11T00:21:57.481659+00:00
3485 independent source/component + disposable PG GO, HEAD f59cb0f3c3776ed2e14d83049250c36dc404de46. Parent RED3/4 -> candidate GREEN4/4; inherited33/33, focused6/6, own5/5; terminal deltas16. Product unchanged by QA. Exact bundle/head/SHA verified. Final integration/runtime/capacity/security certification pending. Evidence: checkpoint-3490/snapshot.json and 3485ACCSTREAMRETURNFINAL-REPORT.md; raw A2 /home/ubuntu/waves/3485ACCSTREAMRETURNFINAL-evidence/.

CHECKPOINT3492:WEB-632 2026-09-11T00:32:55.179360+00:00
3487 source integration GO fa8c397686fd2b99be6033baeafd3fe897c9d3e6 проверена и сохранена; 269 focused checks прошли, legacy RED controls сохранены, runtime inputs отсутствуют. 3491 подтверждена RUNNING на M4: core3487 + independently checked stream3485 + oracle3486. Нет T0, измерений или новой посадки. Evidence: checkpoint-3491/snapshot.json, capacity-integration-3491/3491-receipt.json и inputs/manifest.json.

CHECKPOINT3493:WEB-632 2026-09-11T00:51:25.833863+00:00
3491 source integration GO, HEAD 85baad7f925cf3c9c161cbd911009051a404ac9d; SHA256 3c4bb303c890c85dd74355160bd2fb8ee6741a9477c3a47ced42d819491ecef4. Exact core3487/stream3485/oracle3486 ancestry and clean bundle verified and copied by coordinator. Report records 256/256 focused tests, no schema/migration changes, lint 0 errors/6 warnings. Runtime checklist correctly exits 2 BLOCKED_RUNTIME_INPUTS. Final Linux PG integration, isolated deployment, T0 and measurements pending. Evidence: checkpoint-3493/snapshot.json and full 3491CAPACITYINTEGRATIONFINAL-REPORT.md; M4 /Users/milamarty/waves/3491CAPACITYINTEGRATIONFINAL-evidence/. 3493 RUNNING: deliver bounded HTTP emulator attached at provider bytes, preserving actual auth/ACL/P11/Prisma/ledger; current stub alone cannot serve standalone runtime. No measured capacity yet.

CHECKPOINT3498:WEB-632 2026-09-11T01:11:50.464421+00:00
3493 functional source GO: local provider emulator, report12/12 + syntax7/7 and CLI lifecycle. Source attachment remains blocked for hardcoded realtime/speech; embeddings SDK baseURL needs proof. No authenticated standalone, T0 or capacity measurement. Raw evidence preserved in checkpoint-3498/3493CAPACITYRUNTIMEPROVIDER-evidence.tar.gz. HEAD 280fae10e079fd6d96b79dbda8ece5efa956d2c0; bundle SHA256 130ebb8123f96ad4568aad1f56f149e2c782163b68a549b7308b25244e4d8f56. Exact bundle/head/clean/SHA checked and copied by coordinator.

LANDING115D-PG3496:WEB-632 2026-09-11T01:15:45.387983+00:00
3496 independently verified and collected: HEAD1e189b107960a390cc312a6c84b7e781085b211b, bundle/head/clean/SHA checked. Report focused256/256 + own boundary1/1 + real disposable PostgreSQL8/8;32 terminal counter deltas, sourceReturnCalls1, cluster cleanup proven. Source/component/PG scope only. Runtime/T0/load/capacity/security remain UNKNOWN. Evidence: checkpoint-3498/snapshot-linux-pg.json and3496ACCCAPACITYLINUXPG-evidence.tar.gz, archive SHA256 dc6764bcaca91431200e9c6fcfdd1db4fcf743ee5ebb19a3b17be47882ad92af.

SHIFT3502:WEB-632 2026-09-11T01:31:25.453329+00:00
3500 RUNNING on Neo from exact provider3493 HEAD280fae10e079fd6d96b79dbda8ece5efa956d2c0. Guard/input hashes/BASE verified. Implements isolated application attachment to emulator through actual chat/embedding/speech transport paths. Unsupported WebRTC stays blocked; runtime/T0/capacity pending. shift-3500/3500-receipt.json.

CHECKPOINT3505:WEB-632 2026-09-11T01:50:34.398161+00:00
3500 application attachment delivered. Author reports SDK chat/embeddings/TTS/bootstrap checks; existing route-string test remains RED (15/16 combined). WebRTC/other providers not attached. Independent acceptance, isolated standalone, egress/T0/load pending. Coordinator verified and preserved bundle/head/clean/SHA: b71d88e62a2c921f8a169a94aa97c52899dff0b9 / 728439262438a650831750376350ea0206f8c6adedf9e7546df03f5190f4b843. Evidence archive members=20; SHA256=197fd3333035d67e52bc34c822ecd585221dc3fdc0eeed6675d3a70692363be3. Receipts: checkpoint-3505/snapshot.json and snapshot-3504.json.

SHIFT3506:WEB-632 2026-09-11T02:16:03.175385+00:00
3510 RUNNING from exact3500 BASEb71d88e62a2c921f8a169a94aa97c52899dff0b9: repair inherited openaiStream exact-string regression guard against actual handleChatGlobal delegation, with negative proof. Provider attachment and all production source unchanged by this test-only work. Authenticated standalone/provider-egress/T0 remain pending. Evidence: shift-3506, shift-3511, checkpoint-3505; process observation 2026-09-11T02:16:01.981638+00:00

CHECKPOINT3511:WEB-632 2026-09-11T02:22:40.994630+00:00
3510 collected and verified: HEAD5e3fe28e4fadaca35830180f9efa9c7f6ad85a58, bundle SHA d712098ef29f5d83b3038ab9e088bf229b466025af29cad8f21898411c76a809. Report records repaired streaming guard12/12, combined17/17, provider attachment3/3 and negative mutation proof. Test-only scope; product unchanged. Raw archive fully read. Integration with3506 and actual Auth.js/application T0 remain pending. Evidence checkpoint-3511/snapshot.json.

RESUME20260912:WEB-632 2026-09-12T08:51:16.229899+00:00
3510 test-only streaming guard collected earlier;3516 now integrates it with3506 provider/runtime source. Actual Auth.js/application/persistence T0 pending. Dispatch inputs verified; observed RUNNING. Evidence resume-20260912/3516-receipt.json; observation.json; collected.json.

CHECKPOINT3516:WEB-632 2026-09-12T09:16:55.809642+00:00
Сдача 3516 получена и проверена координатором. Source/component GO; runtime/capacity UNKNOWN.
HEAD e1f6cb526d946af339c213ea77eb26c8d77594d2; bundle SHA66f9391565856ea7b7f53102b60927181d4396be75581400a55efcd64d059631. Проверены 12 предков и обе ветви merge; 327 файлов evidence сохранены. Прочитаны итоговые raw результаты: stream12/12+5/5, seed13/13+7/7, auth10/10, harness21/21, action10/10, stop23/23, boundary1/1. Исходные неудачные запуски сохранены.
Исправление seed разрешает системный macOS temp symlink, сохраняя запрет run-owned symlinks; финальные negative tests зелёные. Дальше: архитектурно совместимая сборка точного SHA, отдельный PG/провайдер-заглушка/настоящий Auth.js, apply+readback seed, document-session join и T0 приложения. Измерения нагрузки/soak и capacity пока не выполнены.
КАРТА ДОКУМЕНТОВ: Intel /Users/annakorin/nc-ops-scripts/checkpoint-3516/receipt.json, selected-raw-results.txt, полный REPORT, bundle и evidence archive; M4 /Users/milamarty/waves/3516CAPACITYRUNTIMEREADYSOURCE-evidence/.
ДЛЯ ТИКЕТА (из отчёта автора):
WEB-626 receives a source/component `GO` for final HEAD
`e1f6cb526d946af339c213ea77eb26c8d77594d2` on
`wave/3516-capacity-runtime-ready-source`, with exact 3506 first-parent and
3510 second-parent ancestry, the known stream RED fixed and verified, and the
seed-generator runnable defect repaired. The branch is ready for owner-approved
coordinator runtime setup. It does not close measured capacity, T0, release,
deployment, or live provider acceptance; those remain `UNKNOWN` until the
listed isolated Linux actions produce evidence.

COORD-TICK-20260912T1003:WEB-632
Исходники 3516 собраны и проверены; фактический путь провайдера в запущенном приложении ещё не проверен T0.

CAP3516-PROVIDER-ISOLATION-R1:WEB-632
Проверен запуск тестового provider emulator на A2 в отдельном systemd PrivateNetwork, exact source e1f6cb526d946af339c213ea77eb26c8d77594d2. В пространстве сети только loopback; исходящие IPv4 и IPv6 соединения отвергнуты ENETUNREACH. Provider readiness=true, activeRequests=0; процесс штатно остановлен exit0, порт закрыт, unit inactive/MainPID0. Шесть файлов доказательств скопированы, SHA256 совпали. Это проверка окружения и жизненного цикла provider, не вызов через приложение и не T0: applicationT0=NOT_RUN, capacity=UNKNOWN. При запуске приложения его собственная изоляция должна быть проверена заново. Evidence: nc-ops-scripts/capacity-3516-linux/provider-isolation-probe-r1/receipt.json; provider-isolation-collection.json.

SHIFT-STOP-20260912:FINAL:WEB-632
Enterprise-2 / CAP-05: Provider stub через настоящий платный путь

Срез перед остановкой 12.09.2026. По поручению владельца 18:13:55 UTC новая работа остановлена.
Enterprise-2: ранее принято 12/14 source/component частей; число не означает готовность 12/14 runtime задач. Ёмкость UNKNOWN. R3 source e1f6cb526d946af339c213ea77eb26c8d77594d2, buildId R7L9roppA5xpq7qPoQmCR.
r8c SAVE_READBACK_PASS: настоящий Auth.js owner, 2MiB документ, Socket.IO init, exact save и authoritative readback/размер/SHA/revision, stale CAS refusal; 8 файлов сверены. Собственная PG остановлена, unit inactive/MainPID0. Shared editor остаётся OPEN из-за effective TeamMember=commenter.
3532 с Нео сохранена: HEAD4182011579fad418f443fc0f40e1ec54e56b159c, bundle SHA32723bf7931419e8c7920c9cb3c03e5fa626ad62edf68d56e950024268571abe. Author scoped GO: Flight decoder, fresh server-owned CAS/save bootstrap, exact one-save/readback checks; offline9/9, syntax3. k6 execution/applicationT0/load/spike/soak NOT_RUN. Новая независимая приёмка3532 не присваивалась.
Следующий запуск требует двух locks: /home/ubuntu/.coordinator-release-build.lock и /home/ubuntu/capacity-3516/runtime-t0.lock; свежего TTL manifest, private sessions/bootstrap и отсутствия параллельной сборки/нагрузки. Реальные credentials не публиковать.
Файлы Intel: /Users/annakorin/nc-ops-scripts/enterprise-3532/delivery/3532CAPACITYK6RUNTIME-REPORT.md (полная инструкция bootstrap/generator/k6); bundle и evidence рядом. /Users/annakorin/nc-ops-scripts/tick-20260912-recovery/capacity-r8-coordinator/collected-r8c/collection-receipt.json. Исторические отчёты/отказы сохранены.

ИНДИВИДУАЛЬНЫЙ ОСТАТОК
Проверить provider stub через настоящий paid admission/reservation/ledger путь на T0, отсутствие внешнего egress, cancellation/replay и один terminal effect.
Следующая смена начинает только после возобновления владельцем. Исторический status сохранён; STOPPED означает отсутствие выполняемой работы, не закрытие задачи.

[12.09 22:25Z координатор] ОБОГАЩЕНИЕ 12.09 (3571-enrich-web626):
Сделано: provider stub доведён до source/component GO (3516) — stream lifecycle, emulator 3493, Linux PG 3496; проба emulator изолирована (egress отвергнут).
На проде: НЕТ — весь путь provider/ledger проверялся на A2/M4/Neo, не в l115g.
Доказано: 3516 HEAD e1f6cb526 (bundle SHA66f939156…), 3496ACC…, provider-isolation-probe-r1.
Осталось: настоящий paid admission/reservation/ledger путь на T0, один terminal effect, cancel/replay.
Кто следующий: координатор после подъёма R3 и свежего Auth.js bootstrap.
Ссылки: /home/ubuntu/waves/3387CAPPROVIDERSTUB-REPORT.md; /home/ubuntu/waves/3397ACCCAPSTUB-REPORT.md; M4 /Users/milamarty/waves/3485ACCSTREAMRETURNFINAL-evidence/; M4 /Users/milamarty/waves/3491CAPACITYINTEGRATIONFINAL-evidence/; /Users/annakorin/nc-ops-scripts/checkpoint-3516/receipt.json; /Users/annakorin/nc-ops-scripts/capacity-3516-linux/provider-isolation-probe-r1/receipt.json; commits 85baad7f925cf3c9c161cbd911009051a404ac9d, e1f6cb526d946af339c213ea77eb26c8d77594d2
Отчёт волны: /Users/milamarty/waves/3571ENRICH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/enrich-collected/.

[14.09 17:40Z координатор] # WEB-632 — Enterprise-2 / CAP-05: Provider stub через настоящий платный путь

**Блок подготовлен волной 3898 (2026-09-14) для публикации координатором.**
Статус не двигать. Волна 3898 комментарии не публиковала.

---

## 1. СНЯТО — НЕ ИСПОЛЬЗОВАТЬ КАК ФАКТ

**Из хронологии смены 14.09 в этот тикет не относится ни одно снятое утверждение.**
Ни один из восьми отозванных выводов эпика не касался provider stub.

Записываю это прямо, потому что пустой раздел «снято» читается двусмысленно.
**Здесь он означает: CAP-05 не был источником ошибок. Он также не был проверен.**

---

## 2. ДОКАЗАНО ЗАМЕРАМИ

**Собственных замеров по CAP-05 за смену 14.09 не появилось.**

Единственное, что смена добавила к этому тикету, — косвенно, через соседний компонент:
`room-audio-daemon.mjs` (отдельный node-процесс, который поднимается рядом с k6)
оказался источником двух отказов сразу — он **не входит** в `/proc/<родитель>/stat`
при наивном замере CPU и он занимает **фиксированный порт 18099**
(`room-audio-daemon.mjs:94`, `CAP06_ROOM_AUDIO_REOPEN_PORT || 18099` — жёсткий дефолт),
из-за чего две ноги двухпроцессного плеча молча дают нули `[3875-отчёт §2.2, §2.4]`.
Это напоминание для CAP-05: **любая заглушка — это ещё один процесс со своим портом,
своим CPU и своим режимом отказа**, и её надо описывать как участника замера, а не как
фон.

---

## 3. ОТКРЫТО

1. **Provider stub через настоящий платный путь за смену не проверялся.**
2. **Не зафиксировано, как заглушка попадает в манифест прогона** — её версия, порт,
   режим и потребление CPU должны быть полями, иначе повторяется история 18099.
3. **Платные провайдеры запрещены** действующими правилами волн, поэтому «настоящий
   платный путь» требует отдельного явного разрешения владельца; такого разрешения в
   материалах смены **нет**.

---

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

**Куда смотреть:** тело тикета WEB-632; `room-audio-daemon.mjs:94` — как выглядит
типичный отказ заглушки; §4 блока WEB-633 (CAP-06) — там же troubleshooter по нулевым
сводкам.

**Первый шаг:** выписать список **всех** процессов, которые поднимаются во время
прогона помимо приложения и k6, с их портами. Если хоть один порт жёстко зашит —
это блокер для любого многоногого плеча, и его надо закрыть до замеров.

**Что считается готовым:** заглушка, которая (а) проходит по тому же коду, что и
настоящий платный путь, (б) не требует денег, (в) объявлена в манифесте прогона со
своей версией, портом и режимом, (г) имеет параметризуемый порт без жёсткого дефолта,
(д) её CPU входит в замер прибора (дерево, а не один pid).

**Чего делать нельзя:** обращаться к платным провайдерам без явного разрешения
владельца; оставлять жёстко зашитые порты; считать заглушку «фоном», не попадающим в
замер; трогать production, прод-БД, sudo, secrets.

---

## 5. Граница этого блока

Волна 3898 CAP-05 не проверяла и кода заглушки не читала. Всё в §2 — побочное
наблюдение волны 3875, прочитанное волной 3898 из её отчёта на A1. Содержимое
комментариев WEB-632 **отсюда не проверено** (доска не отвечает).

[14.09 18:28Z координатор] VERDICT=GO

# 3903-cap05-provider-map — Enterprise-2 / CAP-05 (WEB-632): карта отличий заглушки провайдера от настоящего ИИ

Дерево: `/home/wave/waves/wt-3903-cap05`, ветка `wave/3903-cap05-provider-map`,
от `refs/waves/l115n` = `d85bb2dad1` («l115n: merge wave 3840»).
TypeScript в этой волне не правился — ни одного файла продукта я не менял (это документ).
Платных провайдеров не вызывал ни разу; наружу не ходил вообще.

**Правило чисел в этом отчёте.** Числа, помеченные **[замерено мной]**, получены моими
командами в этой волне (лог — в evidence). Числа **[из кода]** — константы, которые я
прочитал сам, с указанием файла и строки. Числа **[заявлено]** — цитаты из чужих
отчётов/блоков; они НЕ являются моим доказательством и помечены источником.
Ни один из восьми снятых выводов эпика здесь не используется как факт; блок WEB-632
волны 3898 отдельно фиксирует, что ни одно из восьми снятых утверждений CAP-05 не
касалось (`3898EVOLUTION-WEB-632.md §1`).

---

## 0. Что я проверял, чем, и где граница моего доступа

| Что | Чем | Результат |
|---|---|---|
| Найти заглушку в коде | `grep` по дереву l115n и по всем локальным копиям capacity-харнесса | Найдены **три разные заглушки**, см. §1. Главная (CAP-05) — HTTP-эмулятор `scripts/capacity/runtime-provider/server.mjs` |
| Проверить, есть ли CAP-05 на линии продукта | `git cat-file -e refs/waves/l115n:<path>` | **Ни эмулятора, ни шва подключения, ни харнесса, ни существующего doc'а на `refs/waves/l115n` нет** (4/4 «absent») — §1.4 |
| Замерить, что заглушка реально отдаёт | поднял эмулятор на `127.0.0.1:43991`, 834 запроса, потом остановил | §2, evidence `34-`, `36-`, `37-` |
| Тело WEB-632 и комментарии | `grep -rIl` по `/home/wave/waves` и `/home/ubuntu/waves` | **Тела тикета и комментариев на этой машине нет.** Ближайший доступный материал — блок `3898EVOLUTION-WEB-632.md`, который сам пишет: «Содержимое комментариев WEB-632 отсюда не проверено (доска не отвечает)» |
| Конфигурация стенда `CAP_RUNTIME_PROVIDER_*` | `grep` по l115n; затем по capacity-дереву | В l115n этих имён **нет вообще**; они существуют только в capacity-ветке — §1.2 |

**Граница моего доступа, названная прямо:** я читал код и запускал заглушку локально.
Я НЕ видел ни одного лога прогона, где заглушка была подключена к приложению, и НЕ мог
позвонить настоящему провайдеру. Поэтому все строки таблицы §2 в колонке «заглушка» —
доказаны, а в колонке «настоящий провайдер» — это либо константы нашего же кода (что
продукт *ожидает* от провайдера), либо явно помеченное «не измерено».

---

## 1. Что именно подменяет заглушка

### 1.1 Их три, и это разные вещи

| # | Заглушка | Уровень подмены | Включается | Что продукт при этом «думает» |
|---|---|---|---|---|
| **A** | `scripts/capacity/runtime-provider/server.mjs` (500 строк) — **HTTP-эмулятор OpenAI**. Это и есть заглушка CAP-05 | **байты на проводе (HTTP)**. Реальный `openai` SDK, реальный metered-биллинг, реальный retry — всё работает | `CAP_RUNTIME_PROVIDER_MANIFEST/STATE/SOURCE_COMMIT/RUN_ID` + `OPENAI_BASE_URL`, шов `src/lib/ai/isolatedProviderEndpoint.ts` | Продукт думает, что говорит с `api.openai.com`. Он не знает ничего: ему подменили только `baseURL` у SDK-клиента |
| **B** | `scripts/capacity/stub/provider-transport-stub.mjs` (286 строк) — **in-process transport double** | **функция/модуль**: подменяются `MeteredAIProvider.performChat` и `meterProviderStream`. Ни `fetch`, ни сокета, ни SDK | `CAPACITY_PROVIDER_TRANSPORT_STUB=1` **и** `enabled:true` в конструкторе, `NODE_ENV!==production` | Продукт не делает сетевого вызова вообще. `networkRequests=0` — это заявленный инвариант тестов (`docs/capacity/r1/cap05-provider-stub.md`) |
| **C** | `MOCK_OPENAI=true` — **старый юнит-тестовый флаг**, НЕ заглушка CAP-05 | ветка `if` в 8 файлах продукта | `MOCK_OPENAI=true` | Продукт думает, что провайдера **нет**, и деградирует: лексический поиск вместо семантического, отрывок текста вместо ответа модели |

README эмулятора прямо запрещает смешивать A и C:
> «Do not set `MOCK_OPENAI=true` for this transport run. Semantic search uses `bypassMock: true`, and a mock flag would not prove provider bytes.»
> (`scripts/capacity/runtime-provider/README.md`)

Дальше «заглушка» без уточнения = **A**, потому что именно она подменяет вызов, а не
выключает функцию.

### 1.2 Какие вызовы подменяет A — ровно шесть маршрутов

`ROUTES` в `common.mjs`, поведение — `server.mjs:258-389`:

| Маршрут | Что это в продукте | Статус |
|---|---|---|
| `POST /v1/chat/completions` | весь текстовый LLM (JSON и SSE) | подменяется |
| `POST /v1/embeddings` | индексация и семантический поиск | подменяется |
| `POST /v1/audio/transcriptions` | Whisper | подменяется |
| `POST /v1/audio/speech` | TTS | подменяется |
| `POST /v1/realtime/client_secrets` | серверный bootstrap голоса | подменяется |
| `POST /v1/realtime/calls` | WebRTC SDP | **`501 realtime_sdp_blocked`** — принципиально не эмулируется |

Ничего больше: `server.mjs:441-446` — если путь не в `ROUTES`, это `404`, catch-all
проксирования в файле нет.

**Сколько это от платного контура продукта** [замерено мной по реестру
`src/lib/billing/paidEntrypointRegistry.json` на l115n]:
- всего зарегистрировано **117 платных callsite'ов** и **39 платных входных точек**;
- по провайдерам: openai **61**, openrouter **21**, google **14**, internal 11,
  anthropic 4, tavily 2, perplexity 2, xai 1, elevenlabs 1;
- эмулятор говорит на протоколе **одного** вендора из **17** в списке
  `src/lib/billing/paidVendorHosts.ts`. Anthropic и Google README честно помечает
  `BLOCKED`, generic-прокси не поставляется.

То есть даже при идеальной точности эмулятор накрывает **openai-подмножество**, а
`anthropic/google/openrouter/perplexity/tavily/elevenlabs`-пути в изолированном прогоне
не существуют. Плюс: под изоляцией продукт **сам отключает** OpenRouter-fallback
(`!isolatedBaseURL && ...` в патче `openai.ts`, коммит `b71d88e62a`) — то есть контур
отказоустойчивости, который в жизни удваивает задержку и стоимость, в изолированном
прогоне не работает по построению.

### 1.3 Что подменяет C (для полноты — это тот флаг, который реально стоит в наших тестах)

`MOCK_OPENAI` встречается в 8 файлах продукта l115n. Из **67** уникальных файлов, где
живут платные callsite'ы, ветку `MOCK_OPENAI` содержат **3**
(`src/app/actions.ts`, `src/lib/rag/embeddings.ts`, `src/lib/telephony/groundedAnswer.ts`),
и в них **13 из 117** callsite'ов [замерено мной]. Из 39 платных входных точек хоть
одну ветку `MOCK_OPENAI` на пути имеют **5**, не имеют — **34** [замерено мной].

И это не «подмена провайдера», а выключатель функции:
- `src/lib/ai/tools/semanticSearchSources.ts:89-91` → строка «Семантический поиск недоступен в offline/mock режиме»;
- `src/lib/ai/tools/tellMeTheStory.ts:90` → embedding-путь пропускается, остаётся keyword;
- `src/lib/council/retrievalRuntime.ts:148,161` → `searchChunks = null`, совет уходит на лексику;
- `src/lib/telephony/groundedAnswer.ts:1601,1689` → вместо ответа модели отдаётся **отрывок исходника** (`fallbackExcerpt`, 320 символов);
- `src/app/actions.ts:5380` → `Mock answer for "<query>"` + до 3 фальшивых цитат, **и только если ключей нет** (`mockAi && !hasAnyKey`);
- `src/lib/rag/embeddings.ts:17-22` → синтетический вектор, **независимо от наличия ключей**.

Два практических следствия, которые надо знать читателю наших чисел:
1. **`MOCK_OPENAI=true` не является защитой от денег.** Для чата он срабатывает только
   при отсутствии ключей (`actions.ts:5380`, `podcast/scriptGenerator.ts:160-170`), а
   маршруты `api/sources/semantic-search:98`, `api/search/local-semantic:49`,
   `api/selection/counterargument:91`, `actions.ts:9391` и индексирующий воркер
   (`processDocumentRuntime.ts:724`) передают `bypassMock: true` — они пойдут к
   **настоящему** OpenAI даже с поднятым флагом.
2. Единственный не-тестовый способ получить mock-эмбеддинги в индексации — per-source
   canary-метка `canary.ticket === 'ARCH-NER-BIG2-QA-CANARY-RUNNER' && mockEmbeddings === true && liveOpenAIEmbeddings === false`
   (`src/lib/ingest/sourceIndexingQueue.ts:227-240`), а не переменная окружения.

Поведение самого вектора C я замерил (evidence `10-`): размерность 1536,
но **всего 11 различных значений** в векторе и **ровно 11 различных векторов на все
тексты длиной 1..5000** — потому что весь вектор определяется `text.length % 11`
(`embeddings.ts:19-22`). Косинус между двумя РАЗНЫМИ текстами одинаковой длины =
**1.000000**, L2-норма 23.18 (не единичная). Поиск идёт по `cosine_distance`/`<=>`
(`src/lib/rag/vectorStore.ts:217-234`) — то есть в режиме C векторный поиск работает на
вырожденном корпусе. Любой замер качества ИЛИ стоимости ANN-поиска в режиме C
недействителен. Эмулятор A здесь заметно честнее (см. §2).

### 1.4 Главная структурная граница: CAP-05 нет на линии продукта

```
git cat-file -e refs/waves/l115n:docs/capacity/r1/cap05-provider-stub.md        → absent
git cat-file -e refs/waves/l115n:scripts/capacity/stub/provider-transport-stub.mjs → absent
git cat-file -e refs/waves/l115n:scripts/capacity/harness/k6-script.js          → absent
git cat-file -e refs/waves/l115n:src/lib/ai/isolatedProviderEndpoint.ts         → absent
git merge-base --is-ancestor b71d88e62a refs/waves/l115n                        → exit 1
```
[замерено мной]. Шов подключения эмулятора добавлен коммитом `b71d88e62a`
(«feat(capacity): attach isolated provider endpoints», 7 файлов) и живёт только на
capacity-ветках: `refs/waves/m4/3506/...`, `m4/3516/...`, `m4/3520/...`, `m4/3764/...`,
`refs/waves/3764/...`.

Значит: **дерево, в котором заглушку можно подключить, — не то дерево, которое мы
называем продуктом.** В l115n нет ни одного env-управляемого `baseURL` для OpenAI
(`grep 'process.env.*BASE_URL'` по `src` даёт только DATABASE_URL/SIGNAL/SIP/PSTN и
т.п. — ни одного OPENAI_BASE_URL), то есть на линии продукта указать провайдеру
подставной адрес нечем. Это надо читать не как «заглушка плохая», а как: **число
ёмкости, снятое на capacity-ветке, и код, который мы отдаём, — это две разные сборки**,
и разница между ними лежит ровно в том месте, которое делает провайдера ненастоящим.

Ещё одна проверка: во всём `/home/wave/waves` (на 2026-09-14) строка
`capacity-runtime-provider` встречается **только в двух файлах — в исходниках самого
эмулятора**. Ни одного state-файла, ни одного `/metrics`-снимка, ни одного evidence-пака
прогона, где эмулятор был поднят рядом с приложением, на машине нет [замерено мной].
Это совпадает с тем, что пишет сам README эмулятора: «The following is a source map, not
a claim that a Next standalone run has been attached», и с блоком WEB-632: «Provider stub
через настоящий платный путь за смену не проверялся».

---

## 2. Карта отличий — по осям, со ссылками и с колонкой «что портит в замере»

Все «заглушка»-числа получены мной 2026-09-14 на `127.0.0.1:43991`
(`34-emulator-probe.out`, `36-emulator-probe2.out`, `37-metrics-final.json`).
Направление: **↑ёмкость** = замер завышает ёмкость продукта (нагрузка занижена),
**↓ёмкость** = замер занижает ёмкость, **0** = не влияет.

### Ось 1 — задержка ответа

| | Заглушка A | Настоящий провайдер |
|---|---|---|
| Форма | **постоянная, не случайная**: словарь `{fast:5, normal:25, slow:100, stream:15, timeout:750, cancel:1000}` мс — `runtime-provider/common.mjs:157-159` | распределение с тяжёлым хвостом; **не измерено мной** |
| Замерено | `normal`: min 28.1 / med 30.3 / max 34.1 мс; `fast` 8.9/10.9/85.9; `slow` 103.5/103.9/104.0; `timeout` → `504` через 753-757 мс | — |
| Дисперсия | нет вовсе: ни джиттера, ни распределения. Разброс, который я видел, — это оверхед loopback+Node, не модель провайдера | — |
| Потолок | `--max-delay-ms` ограничен 5000 мс (`common.mjs:8`) | таймаут продукта: 120 000 мс на прямой OpenAI-чат (`src/lib/ai/providers/openai.ts:26`), 30 000 мс на шаг fallback-цепочки (`providerFallbackChain.ts:62`) |
| Свой вклад заглушки в задержку под нагрузкой | p50 растёт 27.9 → 33.8 → 42.6 → 51.7 → 64.3 мс при 1/8/32/64/128 одновременных [замерено мной] — заглушка сама однопроцессная и добавляет очередь | — |

**Что портит:** **↑ёмкость, и это главный риск (см. §4).** В замкнутом контуре (k6 задаёт
число VU и ждёт ответа) пропускная способность одного VU = 1 / длительность итерации.
Заменив секунды на 25 мс, мы не «немного ускорили» действие — мы убрали из итерации её
доминирующую статью. Собственная арифметика над двумя константами нашего же кода: модель
задержки эмбеддингов в дереве считает **1500 мс** фиксированным полом одного запроса к
провайдеру (`src/lib/rag/embeddings.ts:41`, `MOCK_EMBEDDING_BASE_MS ?? 1500`), а эмулятор
в дефолтном сценарии отдаёт **25 мс** — отношение **60×** на один запрос.

### Ось 2 — размер и форма ответа

| | Заглушка A | Настоящий провайдер |
|---|---|---|
| Чат: тело | **301 байт**, ответ — фиксированная строка `CAPACITY_RUNTIME_PROVIDER_OK` (**28 символов**), `finish_reason:'stop'` — `server.mjs:184-193` | сотни-тысячи токенов |
| Чат: `tool_calls` | **никогда** (поле отсутствует) [замерено мной] | инструментальные вызовы — 11 callsite'ов модальности `tool` в реестре |
| Чат: `usage` | **константа `{prompt_tokens:7, completion_tokens:4, total_tokens:11}`**; не меняется ни при промпте 4 000 символов, ни при 40 000 [замерено мной] | пропорционально промпту/ответу |
| Эмбеддинги | 1536 float, `((byte + i*17) % 1000)/1000` — `server.mjs:195-201`. Замерено: 831-1000 различных значений в векторе, L2 ≈ 22.5, `cos` между разными текстами 0.906-0.947 (не 1.0) | 1536 float, нормированный |
| Эмбеддинги: объём | батч на 96 элементов (= `MAX_BATCH_ITEMS`, `embeddings.ts:~297`) → **873 010 байт, 9 094 байта/вектор, 101.2 мс** [замерено мной] | тот же порядок байт |
| Эмбеддинги: `usage` | **`prompt_tokens` = число символов входа** (замерено: 59 для входа 59 символов) — `server.mjs:209` | токены, ≈ в 4 раза меньше символов |
| Транскрипция/речь | пиннутая строка `CAPACITY_RUNTIME_TRANSCRIPT` и 60-байтный WAV-кадр — `server.mjs:345-368` | реальный текст/аудио |

**Что портит:** **↑ёмкость.** Вся работа продукта ПОСЛЕ ответа модели пропорциональна
длине ответа и числу цитат: привязка маркеров, `enforceCitationMarkerIntegrity`,
claim-judge, citation-entailment judge (`src/app/actions.ts:4016-4056, 8248-8262`). На
28 символах без маркеров этот контур делает ~ничего. Отдельно: постоянный `usage` = 11
токенов означает, что оценщики и потолки расходов никогда не срабатывают — ни один из
**38** предвендорных отказов из `reason`-объединения (`src/lib/ai/providers/base.ts:96`,
включая `spend_cap_*`, `insufficient_funds`, `estimator_missing`, `request_too_large`)
в таком прогоне не наблюдается. По эмбеддингам направление обратное (**↓ёмкость** по
деньгам): символы вместо токенов завышают учтённый расход примерно вчетверо.
Форма самого вектора у A честная — это единственная ось, где заглушку можно считать
пригодной.

### Ось 3 — потоковая выдача

| | Заглушка A | Настоящий провайдер |
|---|---|---|
| Кадры | **4 `data:`-кадра + `[DONE]` = 5**, всего **931 байт**, весь стрим **87.3 мс** [замерено мной] | десятки-сотни кадров, секунды |
| Содержимое | жёстко `CAPACITY_` + `RUNTIME_` + `PROVIDER_OK` + кадр с `usage` — `server.mjs:231-236` | по токену/группе токенов |
| Каденция | фиксированные 15 мс между кадрами (`common.mjs:157`) | неравномерная |
| Content-Type | `text/event-stream; charset=utf-8` — форма кадрирования настоящая | то же |
| Заглушка B | всего **2 delta** (ответ делится пополам) + `done` — `provider-transport-stub.mjs:261-265`; это async-итератор, **не HTTP-кадры** | — |

**Что портит:** **↑ёмкость.** Стриминговый ответ в реальности держит открытым HTTP-соединение
секундами и заставляет `streamChatResponse` (`src/app/api/chat-global/route.ts:586-766`)
делать много мелких записей в `ReadableStream`. 5 кадров за 87 мс не создают ни этого
давления на запись, ни длинного удержания соединения — а именно длина удержания и есть
то, что ограничивает число одновременных пользователей.

### Ось 4 — ошибки и их частота

| | Заглушка A | Настоящий провайдер |
|---|---|---|
| Как возникают | **выбираются**, а не случаются: `?scenario=` в URL, заголовок `x-capacity-runtime-scenario`, либо процессный дефолт `CAP_RUNTIME_PROVIDER_SCENARIO` — `common.mjs:161-164`, `server.mjs:40` | случайны и коррелированы во времени |
| Частота по умолчанию | **0 %**: 200 последовательных вызовов дефолтного сценария → `{"200":200}` [замерено мной] | > 0 |
| Кто их включает в наших прогонах | **никто**: `grep x-capacity-runtime-scenario` по всему capacity-дереву даёт 2 попадания — README и сам `common.mjs`. k6-харнесс этот заголовок не ставит [замерено мной] | — |
| Значит | в прогоне либо 0 % ошибок, либо 100 % ошибок одного вида. Смешанной, реалистичной доли отказов получить нельзя | — |
| Формы | `429` (+`Retry-After: 1`), `500`, `504` после 750 мс — `server.mjs:271-285`, замерено: 107/109/105 байт тела | 4xx/5xx/сетевые, с телами и заголовками вендора |
| Что остаётся непроверенным | `withRetry`: 3 повтора, база 600 мс, ×2, потолок 8000 мс + случайные 0-200 мс, повтор по `[408,429,500,502,503,504]` и `[ETIMEDOUT,ECONNRESET,ENOTFOUND,EAI_AGAIN]` (`src/lib/rag/embeddings.ts:85-125`); `maxRetries:0` у SDK (`providers/openai.ts:71`); fallback-цепочка по 30 с на шаг | — |

**Что портит:** **↑ёмкость.** Настоящий провайдер умножает работу: один 429 превращает
один запрос в до 4 попыток с ожиданиями до 8 с, а fallback-цепочка добавляет шаги по 30 с
на другого вендора. Этот множитель — не поправка в процентах, он меняет и задержку, и
число одновременно висящих запросов. При 0 % ошибок он равен 1.

### Ось 5 — ограничение скорости

| | Заглушка A | Настоящий провайдер |
|---|---|---|
| Природа лимита | **потолок одновременных запросов = 128** (`MAX_ACTIVE_REQUESTS`, `server.mjs:47,453-458`). Замерено: 160 одновременных → ровно `{"200":128, "429":32}` | лимиты вендора по RPM/TPM за окно, а не по числу in-flight |
| `Retry-After` у этого 429 | **отсутствует** — 72 отказа, все с `retry-after: null` [замерено мной]; тело `runtime_provider_concurrency_limit` | вендор присылает `Retry-After` |
| Следствие для продукта | `getRetryAfterMs` вернёт `null` (`embeddings.ts:71-84`) → продукт уйдёт на свой экспоненциальный backoff, а не на подсказку вендора | — |
| Свои ограничители продукта | `MAX_CONCURRENT_EMBEDDING_BATCHES = 4` (`embeddings.ts:~270`) — работает и в mock-ветке, это честно; `MAX_CONCURRENT_LLM_PER_USER/GLOBAL` — **по умолчанию без лимита** (`src/lib/ai/concurrencyGate.ts:16-28`) | — |

**Что портит:** **смешанное.** Ниже 128 in-flight — **↑ёмкость** (лимита нет вообще,
хотя в жизни вендор бы уже тормозил). Выше 128 — **↓ёмкость и, хуже, подмена смысла**:
прогон упрётся в потолок **прибора**, а 429 от прибора в сводке k6 выглядит так же, как
429 от продукта. Потолок 128 в манифесте прогона не объявляется — ровно та болезнь, о
которой предупреждает блок WEB-632 («любая заглушка — это ещё один процесс со своим
портом, своим CPU и своим режимом отказа»).

### Ось 6 — стоимость и учёт

| | Заглушка A | Настоящий провайдер |
|---|---|---|
| Деньги наружу | **ноль**. Манифест обязателен, принимает только `mode=provider-emulator`, требует `externalEgressBlocked=true`, отвергает публичные и LAN-адреса, TTL ≤ 24 ч (`isolatedProviderEndpoint.ts:19-22`, README) | деньги владельца |
| Учёт в продукте | **работает по-настоящему**: под A в дело идёт реальный `meterOpenAIClient` → `meterVendorCall` → резервирование → ledger; из-за только подменённого `baseURL` ни одна строка денежного контура не пропускается | то же |
| Но суммы | считаются из **константного** `usage` (11 токенов на любой чат) и из **символов** для эмбеддингов | из настоящего расхода |
| Что не наблюдается | ни один из **38** предвендорных отказов `reason` (`providers/base.ts:96`), в т.ч. `spend_cap_global_usd`, `spend_cap_user_usd`, `insufficient_funds`, `overdraft_limit`, `estimator_missing`, `price_missing`; ни advisory-блокировка кошелька `pg_advisory_xact_lock(billing-wallet:…)` под реальным давлением (`src/lib/billing/walletService.ts:538-556`) — она берётся, но за микроскопические суммы | — |
| Заглушка B | не делает вызова вообще, `usage.outputTokens = content.length` (`provider-transport-stub.mjs:164-172`) | — |
| Заглушка C | полностью минует metered-обёртку (клиент создаётся только в не-mock ветке, `embeddings.ts:136-186`) — денежный контур не исполняется совсем | — |

**Что портит:** **↑ёмкость по деньгам и по БД-контенции одновременно.** Механика учёта
исполняется, а её нагрузка — нет: строки ledger'а крошечные, кошельки не исчерпываются,
потолки не срабатывают, конфликтов за блокировку кошелька почти не возникает. Вывод
«столько-то пользователей» из такого прогона молча предполагает, что деньги бесконечны и
что ни один отказ по расходу не случается.

### Ось 7 — разрывы соединения

| | Заглушка A | Настоящий провайдер |
|---|---|---|
| Сценарий `disconnect` | детерминированный: отдаёт `{"id":"capacity-runtime-provider","partial":true` и рвёт сокет (`server.mjs:251-256`); для стрима — часть SSE и `res.destroy()` (`:241-246`). Замерено: клиент получил `TypeError: fetch failed`, `cause=UND_ERR_SOCKET` | случайные обрывы, полуоткрытые соединения, перезапуски у вендора |
| Отмена | `cancel`: ждёт 1000 мс и отдаёт `499`; отмена клиента отслеживается и чистится (`server.mjs:391-411`) | — |
| Транспорт | **plain HTTP по loopback**: ни TLS-рукопожатия, ни DNS, ни внешнего RTT, ни пула keep-alive к удалённому хосту (манифест обязывает `http://127.0.0.1:<port>/v1`) | TLS + DNS + внешняя сеть к одному из 17 хостов `paidVendorHosts.ts` |
| Остановка | при `SIGTERM` рвёт все сокеты разом (`server.mjs:476-489`) | — |

**Что портит:** **↑ёмкость.** Отсутствие TLS снимает с приборного прогона заметную долю
CPU и всю работу по установлению соединений — а это как раз та статья, из-за которой в
модели задержки нашего же дерева появился «фиксированный пол» 1500 мс на запрос
(`embeddings.ts:33-37`: «TLS/connection setup plus provider queueing»). Обрывы при этом
не случайны, а включаются вручную, поэтому «устойчивость к обрывам» в прогоне либо не
проверяется, либо проверяется в режиме 100 % обрывов.

### Ось 8 — что заглушка НЕ подменяет (чтобы карта не читалась как «всё врёт»)

| Оставлено настоящим | Ссылка |
|---|---|
| Auth/ACL/admission/P11, резервирование, dispatch, settlement, финализация | README: «The emulator does not decide application identity, ACL, billing, admission, reservation, persistence, or finalization» |
| `openai` SDK, обёртка учёта, retry-контур, AbortSignal — под A всё работает | патч `b71d88e62a` трогает только `baseURL` |
| Форма и объём эмбеддинг-ответа | §2 ось 2 |
| Форма SSE-кадрирования | `Content-Type` и `data:`-кадры настоящие |
| Семафор на 4 батча внутри портии | `embeddings.ts`, исполняется и в mock-ветке |
| Проверка `Authorization` | есть, но **только на синтаксис**: `/^Bearer\s+\S+$/` (`server.mjs:171-174`). Замерено: `Bearer qqq…q` (51 символ) → `200`; без заголовка → `401`. Ключ не валидируется, задержки авторизации нет |

---

## 3. Самое опасное отличие

**Задержка (ось 1): постоянные 25 мс вместо распределения с секундным масштабом.**

Почему именно она может сделать число ёмкости неверным **в разы, а не на проценты**:

1. **Она умножает, а не сдвигает.** В замкнутом контуре пропускная способность одного
   VU обратно пропорциональна длительности итерации, а число одновременно живущих
   запросов в системе пропорционально задержке. Это множитель на всём замере, а не
   поправка к одной статье.
2. **Масштаб множителя виден из наших же констант, без звонка провайдеру.** Модель
   задержки эмбеддингов в дереве считает полом одного запроса **1500 мс**
   (`embeddings.ts:41`), эмулятор по умолчанию отдаёт **25 мс** (`common.mjs:157`) —
   **60×** на запрос. Продукт, со своей стороны, рассчитан на секунды: таймаут прямого
   чата **120 000 мс** (`providers/openai.ts:26`), шаг fallback **30 000 мс**
   (`providerFallbackChain.ts:62`). Ни одна другая ось такого разрыва не даёт.
3. **Она меняет, какой ресурс упирается первым.** При 25 мс провайдер практически не
   держит ресурсы: соединение, строку резервирования, слот пула БД, память запроса. При
   секундах именно длительность удержания становится ограничителем, и первый предел
   продукта оказывается в другом месте. Замер с 25 мс не «немного оптимистичен» — он
   измеряет другую систему.
4. **Её нельзя починить параметром.** `--max-delay-ms` ограничен 5000 мс
   (`common.mjs:8`), значений всего три (5/25/100), джиттера нет, распределения нет. Даже
   выставив `slow`, получаем 100 мс — постоянные, без хвоста. Тяжёлый хвост p99, который
   и определяет ёмкость, воспроизвести этой заглушкой нечем.

Ближайший второй — **ось 4 (ошибки выбираются, а не случаются)**, потому что она
выключает retry-усилитель (до 4 попыток + fallback-шаги по 30 с). Но она даёт множитель
только при ненулевой доле отказов, а ось 1 действует на каждом запросе.

**Отдельно и честно: есть вещь опаснее любого отличия заглушки.** В тех прогонах CAP-06,
которые названы сравнимыми, платного провайдера нет вообще — ни настоящего, ни
поддельного:
- обязательное условие прогона включает **`CAP06_EXCLUDE_GROUPS=upload_index`**
  (`3898EVOLUTION-WEB-633.md §2.3`, со ссылкой на README волны 3882) — единственная
  группа, которая доходит до эмбеддингов, из расписания исключена **[заявлено, источник
  указан]**;
- группа `retrieval` (вес 20/100) бьёт в `POST /api/sources/text-search` — **лексический**
  поиск, без эмбеддингов (`harness/k6-script.js:733-738`) **[замерено мной по коду]**;
- группа `realtime` (вес 5/100) отправляет `requestedModel:'local-simulated'` и
  `assistantText:'local simulated response'` — текст ответа даёт сам харнесс
  (`k6-script.js:780-810`); `grep` по `src/app/api/realtime/session-start/route.ts` на
  `client_secret|openaiRealtimeSession` — пусто, провайдерская квитанция не выпускается
  **[замерено мной]**.

То есть из 8 бизнес-групп харнесса провайдера касается ровно одна, весом 5/100, и она
выключена. Это значит: **точность заглушки сегодня не влияет на наши числа ёмкости,
потому что заглушка в них не участвует.** Любой вывод «продукт держит столько-то» описывает
продукт с выключенным платным ИИ. Подключение заглушки с 25 мс эту дыру не закроет — оно
лишь заменит «ИИ отсутствует» на «ИИ отвечает в 60 раз быстрее пола нашей же модели».

---

## 4. Какие наши выводы уже опираются на заглушку и наследуют её границу

| Вывод | Чья заглушка | Что именно наследуется |
|---|---|---|
| **WEB-626 / волна 3808: «распараллеливание батчей внутри портии даёт ×1.50 (100.1 с → 66.7 с), семафор = 4»** (`/home/wave/waves/3808PARALLEL-REPORT.md §3-4`) | **C** (`forceMock` через `embeddingMode:'mock'`) + искусственная задержка `MOCK_EMBEDDING_LATENCY_MODE=realistic` | Числа получены на **реконструированной** форме задержки (`base=1500`, `perItem=7.8`), выведенной из чужого числа, а не измеренной у провайдера. Сам отчёт 3808 это признаёт (KNOWN ISSUES №1, №5). Коэффициент ×1.50 держится на предположении, что у настоящего запроса фиксированный пол — при другой форме хвоста выигрыш от параллелизма другой |
| **Выбор `MAX_CONCURRENT_EMBEDDING_BATCHES = 4`** (в коде l115n, `embeddings.ts`) | C | Комментарий в коде прямо пишет: потолок «не откалиброван к реальному RPM-лимиту OpenAI». Это защита от своей архитектуры, а не измеренный лимит |
| **Компонентная приёмка CAP-05: 3485 GO → 3491 (256/256) → 3496 (8/8)** (`3496ACCCAPACITYLINUXPG-REPORT.md`) | **B** | Доказан жизненный цикл вокруг провайдерского шва (auth/ACL/резервирование/terminal settlement/replay/lease), при инварианте `networkRequests=0`. Отчёт сам шапкой пишет `CAPACITY=UNKNOWN` и «not a live runtime/provider approval … or measured capacity». Наследуемая граница: доказано поведение продукта при **детерминированном** провайдере, не при настоящем |
| **Матрица подключения в README эмулятора («SUPPORTED with the complete coordinator binding»)** | A | Это карта исходников, а не прогон. Строки `SUPPORTED` опираются на файл `src/lib/ai/isolatedProviderEndpoint.ts`, которого **нет на линии продукта** (§1.4). WebRTC-строка честно `BLOCKED` (501) |
| **Любое число ёмкости из прогонов CAP-06 с `CAP06_EXCLUDE_GROUPS=upload_index`** | ничья | Наследует не границу заглушки, а более широкую: платного пути в замере нет. Сюда попадают все выводы вида «предел / envelope / сколько пользователей» из этих ступеней |
| **ENTLOADTEST2 / 2B / 3 (WEB-093)**, которые я читал на A1 | ничья | Там прямо сказано: «Платные операции (чат/LLM/embedding/NER/голос/видео/Stripe) … намеренно не выполнялись». Это не заглушка — это честно объявленное исключение. Envelope «до 30 RPS» относится к read-only смеси |

Чего в этом списке нет и почему: **ни одного вывода, снятого коллегами**, я сюда не
включил и ни на один не опирался.

---

## 5. Что нужно, чтобы снять ограничение, и во что это обойдётся владельцу

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

**Шаг 1 (денег не стоит): объявить заглушку участником замера, а не фоном.**
Сегодня ни версия (`capacity-runtime-provider/v1`), ни порт, ни сценарий, ни потолок 128
in-flight, ни CPU процесса эмулятора не являются полями сводки прогона. Это ровно та
болезнь, которая уже дала молчащие ноги на фиксированном порту 18099. Нужны поля:
`stubVersion`, `stubPort`, `stubScenario`, `stubMaxInFlight`, `stubCpu`, и запрет
жёстких дефолтов портов. **Стоимость: 0 $.**

**Шаг 2 (денег почти не стоит): калибровка задержки эмбеддингов одним настоящим вызовом.**
Самая опасная ось (§3) — задержка, и для эмбеддингов её можно откалибровать
предельно дёшево. Арифметика по нашему же прайсу:
- ставка `text-embedding-3-small`: **$0.02 за 1 M входных токенов**
  (`src/data/models.ts:1041`) [из кода];
- фикстура харнесса: **2 MiB = 2 097 152 байта** на итерацию `upload_index`
  (`harness/per-vu-fixtures.ts:76`) [из кода];
- чанкинг по умолчанию: размер 1000, перекрытие 200 → шаг 800
  (`processDocumentRuntime.ts:514-522`) [из кода] → ≈ **2 622 чанка** на документ, то есть
  ≈ **2.62 M символов** уходит в эмбеддинги (с учётом перекрытия — больше, чем размер файла);
- при 4 символах на токен это ≈ **655 k токенов → ≈ $0.013 за документ**;
  при пессимистичной оценке «символ = токен» — ≈ **$0.052 за документ**.

Итого: **калибровка на одном документе — порядка полутора-пяти центов.** Даже сто
документов — **$1.3-5.2**. Это цена, которая убирает KNOWN ISSUE №1 и №5 волны 3808 и
даёт реальные `MOCK_EMBEDDING_BASE_MS`/`PER_ITEM_MS` вместо реконструкции.
*Ограничение аккуратности:* «4 символа на токен» — моё явное допущение, не замер; сам
эмулятор считает символы токенами (`server.mjs:209`), что даёт верхнюю границу выше.

**Шаг 3 (главные деньги): capped-прогон с настоящим провайдером на группе `upload_index`
и на одной чат-группе.**
Формула, чтобы владелец считал сам, а не верил моей цифре:

```
стоимость_прогона ≈ N_upload_index × $0.013…$0.052                       (эмбеддинги)
                  + N_чат × (in_tokens × $0.20 + out_tokens × $1.25)/1e6  (gpt-5.4-nano)
```
ставки `gpt-5.4-nano`: **$0.20 / 1 M входных, $1.25 / 1 M выходных**
(`src/data/models.ts:81-99`) [из кода]. Например, 500 чат-действий по 4 000 входных и
600 выходных токенов ≈ 2 M in + 0.3 M out ≈ **$0.78**; 250 `upload_index` ≈ **$3.3-13**.
Порядок всего такого прогона — **единицы-десятки долларов**, и он ограничивается сверху
существующими механизмами: `SPEND_CAP_*` (`src/lib/billing/spendGuard.ts:26,391`) и
kill-switch'ами — то есть потолок расхода можно выставить жёстко до старта.

Чего этот шаг НЕ покроет за те же деньги: anthropic/google/openrouter-пути и WebRTC
(`BLOCKED` в README), плюс realtime-минуты, которые тарифицируются иначе.

**Шаг 4 (условие, не деньги): решение владельца.**
Блок WEB-632 §3.3 фиксирует: платные провайдеры запрещены действующими правилами волн,
«настоящий платный путь» требует отдельного явного разрешения владельца, и такого
разрешения в материалах нет. Отчёт 3901 добавляет: реальные платные вызовы — optional
(отдельный capped run), **не блокер** для закрытия WEB-632. То есть закрытие тикета от
шага 3 не зависит; от него зависит снятие границы «наши числа ёмкости не знают
настоящего ИИ».

---

## ДЛЯ ТИКЕТА — WEB-632 (детским языком)

**Что проверял.** В наших замерах ёмкости вместо настоящего платного ИИ работает
подделка. Я нашёл её в коде, прочитал целиком, **поднял у себя на машине и погонял** —
834 запроса — и выписал, чем она отличается от настоящего провайдера.

**Чем проверял.** Читал исходники (заглушка, шов подключения, платный реестр, нагрузочный
харнесс), запускал заглушку на локальном адресе и мерил секундомером и байтами. Наружу не
ходил, денег не тратил, TypeScript не правил.

**Что устояло (заглушка честная).** Она действительно говорит на языке OpenAI по-настоящему:
настоящий HTTP, настоящее SSE-кадрирование, эмбеддинг-вектор правильного размера и формы
(1536 чисел, разные тексты дают разные векторы). И главное — она подменяет **только байты
на проводе**. Всё остальное в продукте работает как в жизни: вход по паролю, права,
резервирование денег, запись в журнал, повторы при ошибке. Это правильная конструкция
заглушки.

**Что не устояло (и где именно граница).**
1. **Она отвечает слишком быстро.** Всегда ровно 25 миллисекунд, одинаково, без «иногда
   подвисло». Наша же модель в коде считает, что один запрос к провайдеру не может быть
   быстрее полутора секунд — это в **60 раз** больше. Ёмкость продукта считается по
   тому, как долго каждый запрос занимает место; если сделать провайдера в 60 раз
   быстрее, ёмкость получится завышенной **в разы**, а не на проценты. Это самое опасное
   отличие.
2. **Она всегда говорит одно и то же.** Ответ — фиксированные 28 символов
   `CAPACITY_RUNTIME_PROVIDER_OK`, и «расход» всегда 11 токенов, хоть пришли ей просьбу
   на 4 000 символов, хоть на 40 000. Значит вся наша работа после ответа (расстановка
   ссылок на источники, проверка утверждений судьями) на таком ответе почти ничего не
   делает — а в жизни делает много.
3. **Ошибки у неё не случаются, а выбираются рукой.** Хочешь 429 — попроси 429. В нашем
   нагрузочном скрипте эту просьбу никто не ставит, поэтому в прогоне ошибок ровно 0 %.
   А в жизни один отказ провайдера превращает один запрос в четыре попытки с ожиданиями —
   и этого множителя в замере нет.
4. **У неё свой потолок — 128 запросов одновременно.** Я это проверил: пустил 160 сразу,
   получил ровно 128 ответов и 32 отказа, причём в отказе она даже не говорит «приходи
   через столько-то». В сводке такой отказ выглядит как отказ нашего продукта. Потолок
   прибора нигде не объявлен.
5. **Соединение у неё простое, без шифрования, внутри одной машины.** Нет ни рукопожатия
   TLS, ни обращения по имени в интернет — а это как раз та работа, из-за которой в жизни
   у запроса есть «плата за вход».

**ГДЕ ГРАНИЦА — две границы, и вторая важнее первой.**
- *Первая:* заглушка годится, чтобы проверять **правильность** поведения (кто платит, что
  записалось, что будет при обрыве), и не годится, чтобы получать **числа ёмкости** —
  из-за задержки.
- *Вторая, более неприятная:* в тех нагрузочных прогонах, которые мы называем
  сравнимыми, платного ИИ нет вообще — ни настоящего, ни поддельного. Единственная группа
  действий, доходящая до платного пути (загрузка и индексация документа), из расписания
  **исключена**, поиск в прогоне лексический, а «голосовой» ответ подставляет сам скрипт.
  Значит любое наше «продукт держит столько-то» описывает продукт **с выключенным
  платным ИИ**. Подключить заглушку — не лечение: она ответит в 60 раз быстрее нижней
  границы нашей же модели.
- *Третья, структурная:* кода, которым заглушку подключают к приложению, **нет на линии
  продукта**. Я проверил: четыре ключевых файла CAP-05 отсутствуют в `refs/waves/l115n`, и
  коммит подключения не является её предком. Замеряется одна сборка — отдаётся другая, и
  различаются они ровно тем местом, которое делает провайдера ненастоящим.

**Что осталось открытым.**
1. Тела тикета WEB-632 и его комментариев на этой машине нет — я строил карту по коду и
   по блоку 3898, который сам пишет, что доска не отвечает. Если в комментариях есть
   утверждения о заглушке, они этой картой не проверены.
2. Ни одного лога прогона, где заглушка была подключена к приложению, на машине нет.
   Насколько она ведёт себя так же под настоящим приложением — не проверено никем.
3. Настоящую задержку провайдера никто не мерил. Дешёвый способ есть: калибровка на
   эмбеддингах стоит **порядка полутора-пяти центов за документ** по нашему же прайсу.
4. Потолок 128 и версия/порт/сценарий заглушки не являются полями сводки прогона — это
   надо закрыть до следующих замеров, иначе повторится история с жёстким портом 18099.
5. Закрытие тикета от платного прогона не зависит: карта отличий — это второй и последний
   пункт из двух, оставленных волной 3901; первый (сверка цепочки 3485/3491/3496 со снятыми
   восемью выводами) — за координатором, и я его не делал и делать не мог.

---

## KNOWN ISSUES

1. **Тело WEB-632 и комментарии недоступны.** `grep` по `/home/wave/waves` и
   `/home/ubuntu/waves` на `WEB-632`/`CAP-05`/`CAP05` (полный проход, RC записан) не дал
   ни одного файла с телом тикета. Использован ближайший материал —
   `.3898-work/repo/waves/3898-evolution/blocks/3898EVOLUTION-WEB-632.md`, который сам
   отмечает: «Содержимое комментариев WEB-632 отсюда не проверено (доска не отвечает)».
   Если координатор откроет доску, карту надо сверить с комментариями — в первую очередь
   на предмет чисел, которые я мог не увидеть.
2. **Задание называло конфигурацию стенда `CAP_RUNTIME_PROVIDER_*`; на линии продукта её
   нет.** Эти имена существуют только в capacity-ветках (`m4/3506`, `m4/3516`, `m4/3520`,
   `m4/3764`, `3764`), в `refs/waves/l115n` отсутствуют вместе с эмулятором, харнессом и
   швом. Я не считаю это ошибкой задания — но карта отличий без этого факта была бы
   неполной.
3. **Настоящий провайдер не измерен ни по одной оси** — это запрещено мандатом. Все
   сравнения «против настоящего» опираются либо на константы нашего кода (что продукт
   ожидает), либо помечены «не измерено». Коэффициент 60× — это отношение двух наших
   собственных констант (1500 мс пола модели vs 25 мс эмулятора), а не измеренная
   разница с OpenAI.
4. **`CAP06_EXCLUDE_GROUPS=upload_index` — цитата, а не мой замер.** Источник:
   `3898EVOLUTION-WEB-633.md §2.3` со ссылкой на README волны 3882 (`[3882-README]`),
   которого у меня нет. Проверяемая мной часть — что `upload_index` вообще исключаема
   (`group-schedule.mjs:25-32`) и что остальные группы провайдера не касаются
   (`k6-script.js:733-738, 780-810`) — сделана по коду.
5. **Заглушка B (in-process double) не подключена ни к одному месту продукта.** `grep` по
   всему capacity-дереву на `CAPACITY_PROVIDER_TRANSPORT_STUB`/`provider-transport-stub`
   даёт одно попадание — сам файл. Её швы существуют только внутри тестов
   (`tests/capacity/stub-provider-transport.test.mjs`, `tests/capacity/qa-3397-acc-cap-stub.test.mjs`),
   которых в l115n тоже нет. Я эти тесты **не запускал** (их нет в моём дереве).
6. **Частичная карта отличий уже существовала** —
   `docs/capacity/r1/cap05-provider-stub.md`, раздел «Difference from a real AI provider»,
   5 качественных пунктов. Она описывает только заглушку B, без ссылок на строки, без
   колонки «что портит в замере» и без HTTP-эмулятора A. Этот документ её не отменяет, а
   расширяет; координатору стоит решить, оставлять ли оба или сослаться из того в этот.
7. **Мой локальный прогон эмулятора — не прогон продукта.** Я мерил заглушку в вакууме
   (`node` → loopback → `node`), без Next, без БД, без нагрузки от приложения. Числа
   §2 описывают прибор, а не систему с прибором. Потолок «1345 запросов/с от заглушки при
   128 in-flight» — это про заглушку, и ни в каком смысле не про ёмкость продукта.
8. **Порт 43991 я выбрал сам** (свободный, нестандартный), эмулятор поднял и остановил в
   рамках этой волны (`38-stop.out`: `{"stopped":true,...}`), state-файл
   `/tmp/cap3903-state.json` удалён процессом при остановке — проверено `ls` (нет файла) и
   `ps -p` (процесса нет). Ничего чужого не трогал.
9. **Моя копия `mockEmbedding` в `10-mock-vector-probe.mjs` — копия, а не импорт.** Файл
   продукта не менялся и не импортировался (это TS внутри Next-графа). Строки 19-22
   `embeddings.ts` скопированы дословно; если кто-то изменит оригинал, замер надо повторить.

---

## Evidence

`/home/wave/waves/3903CAP05-evidence/` (`SHA256SUMS` внутри):

| Файл | Что это |
|---|---|
| `00-capacity-lane-ref.txt` | ref capacity-ветки, из которой взяты канонические исходники заглушки |
| `10-mock-vector-probe.mjs` / `.out` | замер вектора заглушки C: 11 различных векторов на все длины, `cos=1.000000` для разных текстов равной длины |
| `20-server.mjs` | канонический HTTP-эмулятор (md5 совпал с копией на диске) |
| `21-isolatedProviderEndpoint.ts` | шов подключения, отсутствующий на линии продукта |
| `22-cap05-provider-stub-doc.md` | существовавшая частичная карта отличий (заглушка B) |
| `30-manifest-create.out` | манифест run-owned цели |
| `31-emulator-stdout.log`, `32-readiness.out` | подъём и готовность эмулятора |
| `33-emulator-probe.mjs` / `34-emulator-probe.out` | основной замер: задержки по сценариям, тела, usage, SSE, эмбеддинги, 160 одновременных, 200 подряд, auth |
| `35-emulator-probe2.mjs` / `36-emulator-probe2.out` | 429 без `Retry-After` (72 отказа) и задержка заглушки против числа одновременных |
| `37-metrics-final.json`, `38-stop.out` | итоговые счётчики прибора и чистая остановка |
| `40-line-checks.txt` | проверки `git cat-file -e` / `merge-base` по `refs/waves/l115n` и подсчёты по платному реестру |

[15.09 01:17Z координатор] ## 15.09 01:30Z — волна 3950 умерла на первой секунде, перевыпущена как 3955.

Причина смерти: **на машине A2 протух вход в модель Клода** (`Failed to authenticate: OAuth session expired and could not be refreshed`, `WAVE_EXIT=1`). Работа не начиналась: каталог доказательств пуст, отчёт остался заготовкой. Это не результат — это потерянный слот.

Перевыпуск **3955** идёт на той же A2 через Codex (`gpt-5.6-luna`), вход туда живой — проверено командой. Ограничение владельца «приёмка Security не на моделях OpenAI» здесь не нарушается: это работа, а не приёмка безопасности.

**Заодно исправлено в брифе:** база была указана устаревшая (`l115n` = `d85bb2da…`), теперь `l115o` = `68e25d8df5ae8263c5ac5466353631f57a17cfcc` — то, что сейчас стоит на проде.

**Остаток тикета без изменений:** заглушка провайдера должна проходить весь денежный контур — допуск, резервирование, запись в книгу — **без единого реального вызова наружу**; отсутствие исходящего соединения должно быть ИЗМЕРЕНО, а не заявлено ссылкой на код; отмена и повтор не должны давать двойного списания; на одну операцию — ровно один конечный эффект.

Известное состояние прода: `ENABLE_REAL_SPEND_LEDGER=1`, `PAID_OP_RECORD_ENABLED=1`, `ENABLE_SPEND_RESERVATIONS=1`, `SPEND_CONTAINMENT_MODE=enforce` (переведён волной 3916).

**Побочная находка для журнала парка:** на A2 освобождено место (86 ГБ занято из 96, было 9.9 ГБ свободно — ниже порога диспетчера 10 ГБ, машина не брала работу молча). Убраны отработанные деревья волн; базовые деревья линий не тронуты.

[15.09 01:48Z координатор] ## 15.09 03:00Z — волна 3955 отказалась честно: нет живого PostgreSQL. Перевыпуск 3957 на машину с базой.

`VERDICT=INCOMPLETE`, причина названа прямо: **живой путь PostgreSQL на A2 недоступен**, а денежный контур без базы не проверить. Отказ с названной причиной законен — волна не стала имитировать. Отчёт: `/home/ubuntu/waves/3955PAID-REPORT.md` на A2.

(Отдельно: сдача 3955 не легла в зеркало волн A1 — у зеркала не было прод-коммита `68e25d8df…`, его `origin /home/ubuntu/nc` вообще не существует. Прод-коммит в зеркало положен, причина записана.)

**Волна 3957 поставлена на M4** — там уже прогонялась фикстура на настоящем Postgres (волна 3949). База `68e25d8df…` — то, что на проде.

### Что добавлено в бриф по сравнению с 3955

1. **Образец правильного поведения с живого прода.** Платная проба 01:28Z: резервирование `resv_047ece9deae94ec38f512eedc23590d5` → `SETTLED_ACTUAL`, зарезервировано 40 724 микро, списано по факту 1017; конечное событие `tse_afa117295d1bb2ac79d9d904461c` → `APPLIED`, ровно одно на резервирование; зависших 0. Заглушка обязана давать ту же форму.
2. **Прямая привязка к дефекту WEB-666.** Расшифровка речи уходит в `SETTLED_MAX` с `releaseReason=usage_missing`, потому что провайдер не возвращает usage. Волна обязана проверить, **не ведёт ли себя её заглушка так же**: если заглушка не возвращает usage, она будет списывать потолок, и все замеры ёмкости посчитают деньги неправильно. Это прямо в скоупе CAP-05 — иначе стенд будет измерять не то.

[15.09 02:22Z координатор] ## 15.09 04:45Z — волна 3957 сдала `VERDICT=GO`. Остаток CAP-05 закрыт по существу. Статус → review.

Ветка в зеркале: `refs/waves/3957/wave/3957-paid-path` = `7b378b157a172ea8a91fab7916d64b0dbd7755a1`.

### Что доказано

**Заглушка проходит весь денежный контур целиком** — не «рядом» с ним, а сквозь: допуск, проверка кошелька, защита от повторов, резервирование, отметка о выдаче наружу, запись в книгу и её разноска. Настоящий боевой код, настоящий PostgreSQL, настоящие боевые переключатели в режиме `enforce`. Подменены **только байты, изображающие ответ провайдера**.

**Наружу не уходит ничего — и это ИЗМЕРЕНО, а не выведено из чтения кода.** Три независимых слоя:
1. счётчик на каждом способе Node выйти в сеть — **ноль вызовов**;
2. перепись сокетов процесса средствами операционной системы — **три соединения, все к локальной базе**, наружу ни одного;
3. собственный «забор» продукта поднят и сам подтвердил, что заглушил бы обращение к платному провайдеру.

Плюс адрес прокси для платного трафика в тесте намеренно указывает на **закрытый порт**: попытка выйти наружу упала бы громко, а не ушла тихо. Это правильная постановка — отсутствие ошибок само по себе не доказательство.

### Заодно закрыт вопрос про WEB-666

Дефекта «списываем потолок» у заглушки **нет**: она возвращает данные о потреблении, и путь честно списывает факт — **13 микро из 46 зарезервированных**. Для контраста через тот же боевой путь прогнали «провайдера без данных о потреблении»: он списал **ровно потолок, 45 из 45**. Разница видна в цифрах, а не в рассуждении.

Это важно для всего Enterprise-2: если бы заглушка вела себя как расшифровка речи, все замеры ёмкости считали бы деньги по потолку и были бы неверны.

### Статус

Ставлю **review**: работа сделана и доказана, но вердикт автора на свою же работу приёмкой не считается. Нужна независимая приёмка, и она обязана перепроверить именно измерение отсутствия egress — это главное утверждение волны.

История: волна 3950 умерла на протухшем входе в модель на A2; перевыпуск 3955 честно отказался (`INCOMPLETE`) — на A2 нет живого PostgreSQL; 3957 на машине с базой довела до конца.

[15.09 02:59Z координатор] ## 15.09 07:15Z — независимая приёмка 3962: `VERDICT=NO-GO`. Работа подтверждена целиком, но найден дефект боевого кода → **WEB-671**.

### Все четыре утверждения автора перепроверены и сошлись

**Отсутствие egress — проверено четвёртым способом, которого у автора не было и который сильнее.** Автор мерила тремя слоями; приёмка запретила машине выходить в сеть **на уровне ядра операционной системы** — так, что не помог бы ни отдельно запущенный процесс, ни код на другом языке, ни попытка разрешить имя. Проверки прошли полностью. Плюс «ловушка»: вместо закрытого порта автора приёмка посадила **слушателя ровно по тому адресу**, куда пошёл бы настоящий платный вызов. **Никто не постучался ни разу.**

**Заглушка идёт сквозь весь денежный контур.** 12 проверок автора зелёные, у приёмщика — зелёные девять прогонов подряд.

**Списывается факт.** Прямыми запросами к базе: из 12 случаев **7 списали по факту, все строго меньше зарезервированного**; 5 по потолку, все ровно потолок. Дефекта WEB-666 у заглушки нет.

**Двойного списания нет** — искали жёстче автора, в трёх местах, куда она не заглядывала: четыре переигрывания самой разноски (шаг, который списывает с кошелька), гонка из **восьми** одновременных списаний вместо трёх, и уборщик просроченных резервов по уже списанному резерву. Итог: 336 микро записано, 336 списано, ни на одном кошельке расхождения с выпиской нет.

### Почему всё-таки NO-GO

Задание требовало построить случай «отмена после списания». Он не даёт двойного списания — он даёт другое: **позднее списание по факту после списания по потолку закрывает ГЛОБАЛЬНЫЕ ворота расходов**, и платные вызовы отклоняются у всех. Деньги целы, функции выключены.

Сценарий не экзотический: это ровно отмена во время передачи и брошенный поток — оба описаны самой волной 3957. Плюс WEB-666 делает предусловие «списано по потолку» постоянным на пути расшифровки.

Тест автора на гонку проходит сквозь эту ситуацию и говорит «всё хорошо», **потому что смотрит только на деньги и не смотрит на состояние ворот**.

**Дефект в старом боевом коде, автор его не создавала.** Но закрывать тикет отчётом, который называет эту гонку чистой, нельзя — вердикт приёмщика правильный.

Выписано отдельным тикетом **WEB-671** с проверкой состояния ворот на проде (все 37 открыты; глобальные закрывались и были открыты **автоматически** сверщиком 10.09 в 16:40 — то есть ручное вмешательство не обязательно, но окно отказов существует).

### Остаток CAP-05

Работа заглушки принята по существу. Тикет остаётся в `review` до починки теста на гонку: он обязан смотреть на ворота, а не только на деньги. Сам дефект ворот чинится отдельно по WEB-671 и CAP-05 не блокирует.

[15.09 10:46Z координатор] Post-QA 3973: FAIL. Приёмка 3962 подтвердила исходный paid-path, но нашла WEB-671: delayed actual usage после max settlement закрывает глобальные spend gates. Следующий шаг: исправить race cancel-after-settlement + delayed usage, сохранив открытые ворота и один terminal effect. Карточку оставить review.

[15.09 16:09Z координатор] M1/DeepSeek 4076 read-only reconciliation: WEB-632 остаётся review до посадки. На l115o нет application seam `isolatedProviderEndpoint.ts`, post-QA 3973 красный; принятый WEB-671/CAP-05 head `2109514591…` включён в текущую M4/4063 cumulative integration. Повторять QA на l115o не нужно: следующий допустимый шаг — закончить source integration, build, посадку и только затем повторить настоящий paid-path post-QA. Evidence 4076 SHA 8/8.

DRAFT-DELTA-20260915-WEB-632 (append-only; правила обогащения: WEB-449).
ЧЕРНОВИК волны 4129 (M1/DeepSeek Flash). Опубликовано координатором после проверки SHA пакета.

УЖЕ ПОКРЫТО историей тикета (не дублируется):
- хронология волн — 3950 умерла на первой секунде, перевыпуск 3955 (2026-09-15T01:17:11.961Z);
  3955 отказалась честно: нет живого PostgreSQL, перевыпуск 3957 (01:48:23.095Z);
  3957 `VERDICT=GO` (02:22:37.182Z);
- независимая приёмка 3962 `VERDICT=NO-GO` — 02:59:17.401Z: исходный paid-path подтверждён,
  но найден дефект боевого поведения WEB-671 (delayed actual usage после max settlement
  закрывает глобальные spend gates);
- post-QA FAIL — 10:46:44.684Z;
- текущий вердикт — 2026-09-15T16:09:52.848Z (M1/DeepSeek 4076, evidence 8/8).

ЧЕГО НЕ ХВАТАЕТ ПО КАНОНУ WEB-449:

1) НЕТ блока KNOWN ISSUES в формате канона. Известные проблемы без «как проверить
   за 2 минуты» и без «причина файл:строка»:
   а) WEB-671 — гонка cancel-after-settlement + delayed actual usage: отложенное
      фактическое потребление после расчёта по максимуму закрывает глобальные spend gates
      (2026-09-15T02:59:17.401Z, 10:46:44.684Z). Проверка за 2 минуты: отправить запрос,
      дождаться терминального расчёта по max, затем дождаться прихода отложенного usage
      и посмотреть, открылись ли глобальные spend gates — закрытые gates = дефект открыт;
   б) отсутствие application seam `isolatedProviderEndpoint.ts` на l115o
      (2026-09-15T16:09:52.848Z) — это landing gap, а не дефект кода.
      Проверка за 2 минуты: `git ls-files | grep isolatedProviderEndpoint` на текущей линии.
2) Принятый head WEB-671 назван без машинного пути: `2109514591…` включён в текущую
   M4/4063 cumulative integration (2026-09-15T16:09:52.848Z) — полный 40-символьный SHA
   и путь отчёта 4063 в комментарии отсутствуют. По правилу 15 это заявка без ссылки.
   То же для 4076: «Evidence 4076 SHA 8/8» без пути.
3) НЕ ЗАФИКСИРОВАНО прямо, что повторять QA на l115o НЕ НУЖНО: следующий допустимый
   шаг — закончить source integration, build, посадку и только затем настоящий
   paid-path post-QA (2026-09-15T16:09:52.848Z). Без этой пометки нулевой агент
   потратит смену на заведомо красный прогон.
4) Оговорка приёмки 3962 не вынесена в тело: приёмка подтвердила ИСХОДНЫЙ paid-path
   целиком и нашла дефект отдельно (2026-09-15T02:59:17.401Z). «NO-GO» без этой
   развязки читается как провал всей работы 3957.
5) Тело заканчивается блоком 12.09 (`SHIFT-STOP-20260912:FINAL`, STOPPED,
   `ИНДИВИДУАЛЬНЫЙ ОСТАТОК`) — противоречит `review` на 15.09.

ОСТАТОК на 15.09 16:09Z: WEB-632 остаётся `review` до посадки; `2109514591…` уже в
M4/4063; следующий шаг — source integration → build → посадка → paid-path post-QA
(2026-09-15T16:09:52.848Z).

ПЕРВЫЙ ШАГ НУЛЕВОГО АГЕНТА (2 минуты, ничего не запускает): прочитать
2026-09-15T16:09:52.848Z и проверить, посажен ли seam:
`git ls-files | grep isolatedProviderEndpoint` на текущей линии. Пусто — посадки не было,
QA не гонять.

L115Q-LANDING-20260915-WEB-632
[15.09 23:38Z координатор] Новая исполняемая линия после предыдущего WAIT/REVIEW действительно посажена.

- Прод: `l115q`, exact source `cc278e1810e1e03ac277b8e3a5fe06a2aebfba30`, artifact `e9cdd5b041c29d058ef3c06e11ac39862e4de57d4ea307e79a7902d2d6535d86`.
- Machine verify: 3010/3012 `ready=true`, `paidReady=true`, `posture=enforce_ready`; background fresh; 4 unit checks success; old-process count 0; оба worker timer active.
- Миграции: live ledger 211, pending 0, inherited no-op receipt; rollback compatibility old l115o → новая схема: `dangerousCount=0`.
- Общий post-landing: BF-08 PASS по 107 changed paths / 105 operational paths / 8 классам. Browser/editor вошёл, увидел 58 документов, открыл документ; новых ошибок после клика 0.
- Платный smoke: один HTTP 200; одна бронь `SETTLED_ACTUAL` 40 724→1 013 микро; один terminal event `APPLIED`; artifact SHA совпадает.
- Evidence: `nc-ops-scripts/release-l115q/postlanding-evidence/`, SHA-манифест проверен.

Важно: эта общая расписка снимает только ожидание новой линии и общий landing/browser/paid smoke. Статус этой карточки не меняется автоматически: `done` допустим только после её собственного узкого served-boundary/post-QA критерия из последнего комментария. Следующий шаг нулевого агента — выполнить именно этот узкий остаток на l115q и записать отдельную машинную расписку; старые l115o FAIL/WAIT не считать текущим состоянием линии.

ENRICH-4140-WEB-632
Аудит-источник: `WEB-626-ENTERPRISE2-REMAINDER-20260916.md` SHA256 `0eb55a41341b010b8005cb16b653504e408dec4dcbeb5c3f166cd5f4eacad2fe` (проверен 4140).
Живая доска: http://127.0.0.1:8787/api/web (localhost, read-only GET), read-only readback.
append-only; статус доски этой записью не двигается.

# WEB-632 — CAP-05: provider stub через настоящий платный путь
## Самое сильное принятое доказательство

- `3957 GO` + независимая `3962`: paid-path, kernel egress fence и listener подтвердили
  заявленную механику.
- `l115q` paid probe дала одну `SETTLED_ACTUAL` бронь и один `APPLIED` terminal event.
- Portable runner готов: `worker-results/4113WEB632EMULATORRUNNER-REPORT.md`, 63 tests.
- Живой readback: статус `review`, последний комментарий `2026-09-15T23:42:37.975Z`.

## Чего НЕ ХВАТАЕТ на карточке

`4113` помечает fixture `NOT_RUN_LIVE`, а post-landing mode — `served-readback-missing`.
Общая расписка `l115q` не запускает application→loopback emulator и потому
`served-readback-missing` не снимает.

## Точная недостающая расписка

Post-landing запуск application→run-owned loopback emulator на `l115q` с exact
source/artifact/target binding и **явным supersession обеих source identities**.
Receipt обязан одновременно показать:
external network attempts = 0; auth/ACL/admission/P11/reserve/dispatch/ledger/finalization;
ровно один terminal effect; cancel releases lease; replay не дублирует;
forged/foreign identity и dispatch-without-lease отвергнуты.

## Первый шаг нулевого агента
За 2 минуты, ничего не запуская: открыть
`worker-results/4113WEB632EMULATORRUNNER-REPORT.md` и найти `NOT_RUN_LIVE` /
`served-readback-missing`; затем прочитать `2026-09-15T23:42:37.975Z` и убедиться,
что emulator-прогон там не заявлен.

## Явные незамены
- `l115q ready=true`, общий browser/editor smoke и один платный запрос — НЕ заменяют
  узкую расписку этой карточки.
- Fixture/package `GO` не равен post-landing PASS.
- Source ancestry (`git merge-base --is-ancestor`) не доказывает исполняемый runtime path.
- Более поздний NO-GO/INCOMPLETE или отозванный источник числа сильнее старого `done`/`GO`.
- `23.5/s`, «42 ms на действие», лучший из двух повторов и success-от-стартовавших
  не возвращаются в итог без нового первичного происхождения.

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=Приёмка 3962: VERDICT=NO-GO по WEB-671; l115q landing записан, но 4113 помечает fixture NOT_RUN_LIVE и served-readback-missing.
ЧТО НУЖНО=Post-landing loopback-emulator receipt на l115q с exact binding, zero external attempts, одним terminal effect, cancel/replay и forged/foreign/без lease отказами.
triage-m1 4607

РЕШЕНИЕ=parked
ОСНОВАНИЕ=Волна 4140, аудит 2026-09-16: 3957 GO и 3962 NO-GO по WEB-671, l115q paid probe есть, но fixture NOT_RUN_LIVE и served-readback отсутствуют; движения ≥7 дней, остаток не у владельца.
ЧТО НУЖНО=ПРЕДЛОЖЕНИЕ=split; вынести post-landing emulator receipt в отдельный тикет; triage-neo 4710

[27.09 15:30Z координатор] Закрыт по слову владельца 27.09 15:28Z (разбор парковки). Подзадача ёмкости от 16.09 устарела: её остаток (метрики, stub платного пути, A/B процессов, горячие запросы PG, evidence pack) покрывается текущей лестницей WEB-626 / WEB-637 на стенде 4400-r2. Недостающие расписки собираются там.