WEB board

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

ENTERPRISE2-DISPATCH:3359
2026-09-10T19:44:12.846367+00:00 — A1, wave 3359, session wq-cap-metrics, model gpt-5.6-luna xhigh. Бриф, исходная база и SHA256 входов проверены; запуск подтверждён процессами и журналом. Подготовка исходников; capacity и prod acceptance не выполнялись.
Бриф: Intel /Users/annakorin/nc-ops-scripts/enterprise2-20260910/3359-cap-metrics-brief.md
Входы A1: /home/wave/waves/inputs/enterprise2-20260910
Сдача A1: /home/wave/waves/3359CAPMETRICS-REPORT.md; 3359CAPMETRICS.bundle + SHA256.

ENTERPRISE2-DELIVERY:3359:4cd86784d
Получен и сохранён отчёт 3359CAPMETRICS-REPORT.md и source bundle. HEAD 4cd86784d16952af0994bc1b8af5666a68c97278; BASE 1ad52e16b784d3ae80a148fddae4d5a3ab4a89c4. SHA256 293086235c77b9f0d7af3670f90836d0613a9bf0a68e7085a6c23c5a8ef8e797 совпал, git bundle verify PASS.
Подготовлены collectors записанных метрик app/DB/Redis/host/generator, анализ счётчиков и stop-controller; по отчёту автора 10/10 тестов. Это авторская сдача исходников. Независимой приёмки, runtime integration, замеров ёмкости и посадки нет. CAP-01 должен подключить readers и callback генератора; CAP-02 подтвердить реальные метрики.
Сдача A1: /home/wave/waves/3359CAPMETRICS-REPORT.md и 3359CAPMETRICS.bundle. Копия Intel: /Users/annakorin/nc-ops-scripts/enterprise2-20260910/. Документ в commit: docs/capacity/r1/cap-metrics.md. Следующий этап — независимая проверка synthetic fixtures и отрицательных сценариев по критериям карточки.

FILL-SLOTS-2046:3377
2026-09-10 20:50Z. Независимая CAP-04 source приёмка 3377 запущена на M4, exact 4cd86784d16952af0994bc1b8af5666a68c97278. Bundle/report и SHA доставлены, ancestry/preflight PASS. Собственные проверки malformed/missing counters, resets, thresholds, callback ownership, redaction. Это проверка recorded metrics tooling; capacity не измерена.

FILL-2104:3389:active
Проверено 2026-09-10T21:10:06.758266+00:00. Волна 3389, A2, состояние active. Живая tmux pane и свежий журнал подтверждены. Exact BASE 9ba0cce99b2013d44b4eef330178eadc00f774b7. Входы SHA256 и bundle ref проверены перед dispatch. Бриф Intel nc-ops-scripts/fill-slots-20260910-2104/3389-cap-metrics-rework-brief.md. Сдача /home/ubuntu/waves/3389CAPMETRICSREWORK-REPORT.md. Посадки/окончательной приёмки этой работы нет. CAP-04 independent 3377 NO-GO: 18/22, missing counters false-PASS, null/empty->zero, non-monotonic/malformed timestamps; retention bound unresolved. Полный отчёт/raw evidence/QA bundle доставлены. Capacity UNKNOWN.

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

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

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

Волна 3432 a2nc gpt-5.6-terra: active (дочерний процесс подтверждён, журнал 25 с); exact BASE 77f0d64a46ad45ca84de44b77e0c2e3ec97dfb48; inputs /home/ubuntu/waves/inputs/3432-acc-ledger-partitions
Новой посадки этим тиком нет. Evidence: nc-ops-scripts/refill-20260910-2221/.

SLOTS12-BATCH3442-3461-WEB-631
2026-09-10T22:50:05.652264+00:00 Лимиты A1/A2 подняты до12; действовавшие worker panes сохранены. Волна 3443 a1nc active acc-metrics-reset-final; BASE bfe4d20980eb6fe5f1ad64ba00d7ba925859450c; model gpt-5.6-luna
Брифы прошли guard; входные report/history/raw/bundle переданы и SHA проверены до очереди. Source/QA scope, посадки и measured capacity не заявляются.

SHIFT-STOP-20260912:FINAL:WEB-631
Enterprise-2 / CAP-04: Сбор метрик, stop-controller и доказательства

Срез перед остановкой 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. Исторические отчёты/отказы сохранены.

ИНДИВИДУАЛЬНЫЙ ОСТАТОК
На T0 собрать реальные before/during/after метрики и stop-controller evidence; synthetic detector tests не являются нагрузочными измерениями.
Следующая смена начинает только после возобновления владельцем. Исторический status сохранён; STOPPED означает отсутствие выполняемой работы, не закрытие задачи.

[12.09 22:25Z координатор] ОБОГАЩЕНИЕ 12.09 (3571-enrich-web626):
Сделано: collectors + анализатор счётчиков + stop-controller (3359), после NO-GO 3377 — доработки 3389/3399/3418/3432/3443 (source scope).
На проде: НЕТ — метрик-инструмент source-only, в l115g не посажен.
Доказано: 3359CAPMETRICS-REPORT.md (HEAD 4cd86784d), NO-GO 3377, rework 3389.
Осталось: реальные before/during/after метрики и stop-controller evidence на T0.
Кто следующий: координатор при первом k6 T0 на R3.
Ссылки: /home/wave/waves/3359CAPMETRICS-REPORT.md + 3359CAPMETRICS.bundle; /home/ubuntu/waves/3389CAPMETRICSREWORK-REPORT.md; /home/ubuntu/waves/3399ACCCAPMETRICSR2-REPORT.md; docs/capacity/r1/cap-metrics.md (в commit автора, в прод не попало); commits 4cd86784d16952af0994bc1b8af5666a68c97278, 9ba0cce99b2013d44b4eef330178eadc00f774b7, ac887a196dacfb7eb9288d53e684ac4659d8072e
Отчёт волны: /Users/milamarty/waves/3571ENRICH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/enrich-collected/.

[14.09 17:40Z координатор] # WEB-631 — Enterprise-2 / CAP-04: Сбор метрик, stop-controller и доказательства

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

**Метки источника:** `[задание]` — дословно из задания 3898; `[3898]` — проверено самой
волной 3898 на `a1-payg-01`; `[3875-отчёт]`, `[3853-док]`, `[3863-файлы]`,
`[3882-README]`, `[3882-коммит]` — прочитано волной 3898 из файла на A1.

**Почти каждое снятое утверждение эпика — это ошибка ПРИБОРА, а не вывода.**
Поэтому CAP-04 — не вспомогательный тикет, а корень.

---

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

| снятое утверждение | чем опровергнуто |
|---|---|
| «при том же CPU» | приложения выросли с **0.85 до 1.40 ядра** `[задание]` — прибор показывал не то |
| «offered actions — это пропускная способность» (WEB-635 c.5011) | забаррикадировано: брать **completed** `[3879 WITHDRAWN-CLAIMS-BARRIER.md]` |
| «предупреждений пула на 50 пользователях ноль» (WEB-626 c.4897, WEB-637 c.4898) | число опубликовано из **провалившейся** проверки `[3879 WITHDRAWN-CLAIMS-BARRIER.md]` |
| «четыре строки near-capacity = вчетверо хуже» | строка **защёлкнута**: 20 с нагрузки с 7475 операциями выше порога → **1** строка; полное исчерпание со **150** `P2024` → тоже **1** строка `[3853-док §3]`. Выше порога число строк **анти**коррелирует с тяжестью |
| «`active=` — это соединения» | это операции Prisma **в полёте**; при `connection_limit=10` и 24 вызывающих строка печатает `active=24`, а `pg_stat_activity` показывает **10** бэкендов `[3853-док §1]`; подтверждено экспериментом E2 приёмки 3863 `[3863-файлы]` |

### Эволюция: пять способов, которыми прибор врал, и как это поймали

**(1) `ps -o %cpu` занижает в 4.6 раза.** На эталоне известного размера (спит 30 с,
затем ровно 10 с жжёт одно ядро, приколот к ядру 3): истина **0.875** ядра, честный
прибор дал **0.873** — ошибка **0.2 %**; `ps -o %cpu` показал **18.9 %**, то есть
занизил **в 4.6 раза** `[задание]`, `[3875-отчёт §2.1]`. Причина: `%cpu` — среднее за
**всю жизнь** процесса (10 с CPU на 37 с возраста), а не за окно замера. Лечение:
дельта `utime+stime` из `/proc/<pid>/stat` за окно.

**(2) Наивный замер дерева даёт НОЛЬ и «доказывает», что генератор бесплатен.**
Измерительная установка — не один процесс: `run-rung-r4.sh` поднимает k6 **и отдельный**
node `room-audio-daemon.mjs`. CPU живого ребёнка не входит в `/proc/<родитель>/stat`
(попадёт в `cutime/cstime` только после reap). На эталоне с истиной **2.000** ядра:
один pid родителя → **0.000**, дерево → **1.996** `[3875-отчёт §2.2]`.

**(3) Снимок-минус-снимок на умирающем дереве даёт ОТРИЦАТЕЛЬНЫЙ расход.** Первая
версия прибора брала снимок в t0, снимок в t1 и вычитала; двое жгущих детей успели
выйти до t1, и получилось **−2.290 ядра** `[3875-отчёт §2.2]`. Лечение: накопительный
сэмплер — опрос каждые 0.25 с, per-pid first/last, сумма per-pid дельт.

**(4) `pgrep -f` матчит собственную оболочку скрипта.** `pgrep -f 'room-audio-daemon'`
дал **3 фальшивых «pid генератора»** — их CPU записался бы генератору. Тот же класс
ошибки: `pkill -f 'drain/balancer.js'` убил вызывающую оболочку (rc=144). Лечение:
якорь `^node ` / `^bash ` `[3875-отчёт §2.3]`. В первой живой попытке прибор вдобавок
взял **не тот Postgres** (dev-кластер на :55450) и посторонний `next-server` на :3030,
оба простаивающие `[3875-отчёт §12]`.

**(5) Сэмплер крутился на измеряемых ядрах.** В `run-rung-r4.sh` k6 и демон получают
ядра 2,3, а ребёнок `sampler.sh` получает **0-3** `[3875-отчёт §2.4]`.

**И шестой, отдельного класса — проба, которая вообще не различает.** Попытка узнать,
ловит ли `next-server` SIGTERM, через `/proc/<pid>/status` SigCgt: node **без**
обработчика и node **с** обработчиком дают одинаковую маску `0000000100004602`; только
обычный `sleep` даёт нули. Проба выброшена, вопрос честно помечен «НЕ ИЗМЕРЕНО»
`[3875-отчёт §6.3]`. **Это правильный исход:** прибор, который не различает гипотезы,
должен быть выброшен, а не истолкован.

---

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

### 2.1 Класс «метрик» в коде — это КОНСТАНТЫ, включая `active=32` `[задание]` (волна 3882)

Самый тяжёлый результат смены для CAP-04: показания не измеряются, а возвращаются
жёстко зашитыми. **Любое число, снятое через этот класс, подлежит пересмотру.**

**ГРАНИЦА:** место в коде **с A1 не найдено**. Волна 3898 проверила на линии
`refs/waves/l115n` = `d85bb2dad` точные литералы `active: 32` / `active=32` /
`activeConnections: 32`, каталоги `src/lib/monitoring` и `src/lib/metrics`, все файлы
со словом `metric` в имени, шаблоны `idle:/active:/waiting:` с числом и символы
`getConnectionPoolMetrics` / `poolMetrics` / `PoolMetrics` — **ни одного совпадения**
`[3898: evidence/05-cap11-metrics-constants-search.txt]`. Это **не опровержение**,
а «не проверено отсюда»: `file:line` надо взять из доказательств 3882 (лежат на A2).

### 2.2 Честный прибор CPU существует и откалиброван — волна 3875

`proc-cpu-delta.py`: дельта `utime+stime` по дереву, накопительный сэмплер.
Калибровка на эталонах: **0.873** против истины **0.875** (0.2 %) и **1.996** против
**2.000** (0.2 %) `[3875-отчёт §2.1, §2.2]`. Собственный след волны, снятый тем же
прибором: **0.208 ядра, 5.2 % машины** `[3875-отчёт §2.5]`.

### 2.3 Аффинность снимается по живым pid — и в одном окне она была нарушена

В окне 15:24:40–15:26:41Z 14.09 реальные маски: k6 → 2,3; room-audio → 2,3;
приложение :3610 (pid 261374) → 0,1; приложение :3611 → 0,1; postmaster (134 pid) → 0,1
`[3875-отчёт §2.4]`. А в окне **14:56Z–15:21:38Z** Postgres **не был прижат** к ядрам
0,1 вопреки `taskset` — числа того окна **недействительны** `[задание]`.

### 2.4 Правила чтения гейта пула — проверены (3853 + E2 приёмки 3863)

- `active=` — операции Prisma в полёте, **не** соединения, **не** глубина очереди,
  **не** время ожидания `[3853-док §1]`;
- строка защёлкнута: **N строк = N пересечений порога вверх**, и минимум N−1 возврат
  вниз `[3853-док §3]`;
- порог = `max(1, ceil(limit·0.8))`: web 10→8 (две свободные), worker 4→**4** (ноль
  свободных, то есть для worker'а это не раннее предупреждение) `[3853-док §2]`;
- **слепое пятно:** `src/lib/prisma-readonly.ts` строит голый `new PrismaClient()` без
  `$extends`, его соединения не попадают ни в `db_pool_near_budget_total`, ни в
  `db_pool_exhausted_total`; и приобретение соединения в `$transaction` — вне хука
  `[3853-док §4]`;
- для тяжести читать `prisma.pool.busy_high_water` и `db_pool_exhausted_total`
  (`/api/cron/metrics-alerts`), а не число строк `[3853-док §3]`.

### 2.5 Процессное правило, добытое дорого

Волна 3867 свои инструменты **не закоммитила**, её worktree вычистили, и
`proc-sampler` / `pg-sampler` / `analyze-rung` пропали — волне 3882 пришлось писать их
заново. Формулировка автора: **«инструмент, который не закоммичен, не существует»**
`[3882-коммит]`. Готовые и закоммиченные инструменты сегодня: `sampler-3882.py`
(1 Гц: CPU приложения и самого загруженного потока, CPU Postgres, CPU k6, полосы по
ядрам, активные бэкенды PG и аффинность **каждого** измеряемого процесса на **каждой**
выборке), `thread-sampler-3882.py` (per-thread CPU по tid), `analyze-rungs.py`
`[3882-README]`.

---

## 3. ОТКРЫТО

1. **Реальная телеметрия на финальном T0/нагрузке не получена** `[3879 LIMITATIONS.md]`.
   Требуемая форма: таймлайн + вердикт анализатора + сырые счётчики; **недействительный
   прогон не должен получать PASS** `[3879 REQUIREMENT-SOURCE-MAP.md]`.
2. **`file:line` для «класса метрик — констант» в тикете не назван** `[3898]`.
3. **Доля CPU прибора на здоровой ступени не измерена** — окно волны 3875 попало на
   ступень, уже сломанную конфликтом двух других волн; она держала взведённый сэмплер
   с 15:44:58Z до 15:56Z, но **ступень не появилась** (`pgrep -x k6` пуст всё окно).
   Замер не провалился — **мерить было нечего** `[3875-отчёт §2.4]`.
4. **Stop-controller за смену не проявился ни в одном отчёте** — ни как сработавший,
   ни как проверенный.
5. **`sampler.sh` по-прежнему без `taskset`** (ядра 0-3) `[3875-отчёт §2.4]`.

---

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

**Куда смотреть:** §1 этого блока — шесть способов, которыми прибор врал;
`tools-3882/sampler-3882.py` и `thread-sampler-3882.py` (закоммичены, ветка
`wave/3882-who-is-serial-r2` = `d78307f625`); `proc-cpu-delta.py` из доказательств 3875;
`3853-DB-POOL-CEILING.md` §1–§4 — как читать гейт пула.

**Первый шаг (2 минуты, ничего не запускает):** взять любой живой pid приложения и
снять его CPU **двумя** способами — `ps -o %cpu` и дельтой `utime+stime` за окно.
Если они разошлись в разы, ты только что воспроизвёл дефект (1) и можешь спокойно
выбрасывать любое число смены, снятое через `%cpu`.

**Что считается готовым:**
- каждый прибор **откалиброван на эталоне известного размера**, и калибровка лежит в
  доказательствах (как 0.873 против 0.875);
- каждый прибор **закоммичен** (правило 3882);
- каждое измерение CPU — по **дереву**, накопительно, с якорями в `pgrep`;
- аффинность снята с **живых pid** и попала в манифест прогона;
- для каждого числа есть сырой файл и **SHA256**; число без сырья остаётся
  «ЧИСЛО НЕ ПОЛУЧЕНО» `[3879 LIMITATIONS.md]`;
- недействительный прогон **fail-closed**, а не PASS с оговоркой.

**Чего делать нельзя:**
- мерить CPU через `ps -o %cpu`;
- мерить дерево процессов снимком-минус-снимком;
- использовать `pgrep -f` / `pkill -f` без якоря;
- читать число строк «near capacity» как тяжесть, а `active=` как соединения;
- публиковать число, снятое классом метрик, пока не назван его `file:line` и не
  доказано, что это не константа;
- брать числа из окна 14:56Z–15:21:38Z 14.09;
- считать, что «прибор ничего не показал» = «нагрузки не было»: различать «измерено
  ноль» и «мерить было нечего»;
- трогать production, прод-БД, sudo, secrets.

---

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

Волна 3898 приборов не запускала и CPU не мерила. Сама проверила только отсутствие
места в коде для `active=32` на линии — и это «не найдено отсюда», а не опровержение.
Числа 0.85→1.40 ядра, 4.6 раза, `active=32` взяты из задания **дословно**. Числа
0.873/0.875, 1.996/2.000, −2.290, 0.208 ядра, 7475/1 строка, 150 `P2024`/1 строка,
`active=24` при 10 бэкендах — прочитаны волной 3898 из отчётов 3875 и 3853 на этой
машине. Содержимое комментариев WEB-631 **отсюда не проверено** (доска не отвечает).

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

# 3904-acc-cap04-analyzer — свежая независимая приёмка

## Для тикета, детскими словами

Я взял чистый пример прогона и сам сделал плохие примеры. Проверял только
записанные числа, без production, базы, SSH и сборок. Штатные тесты анализатора
прошли: 10 из 10. Мой отдельный тест нашёл одну плохую дырку: если в середине
прогона нет ни одного снимка телеметрии, анализатор говорит `PASS`.

Это нельзя принять. Плохой прогон не должен становиться хорошим.

## Где был анализатор

Заявлено в задании: анализатор находится в линии `refs/waves/l115n`.

Доказано проверкой: путь
`refs/waves/l115n:scripts/capacity/r1/observability/index.mjs` отсутствует
(проверка закончилась с кодом 128). Реальный кандидат найден в переданном
`metrics.bundle`, коммит `bfe4d20980eb6fe5f1ad64ba00d7ba925859450c`, ref
`refs/heads/cap3480-export-metrics`. Его исходники проверялись read-only из
`/Users/limamarty/waves/wt-3487-capacity-integration-addons`.

Это важная граница: ниже доказано поведение кандидата из bundle, но не наличие
этого кода в `l115n`.

## По каким признакам анализатор решает

Код анализатора (`scripts/capacity/r1/observability/analyzer.mjs`) делает так:

- сравнивает `before` и `after` для app, database, redis, host и generator;
- отвергает нечисловые, отрицательные, пропавшие и уменьшившиеся счётчики;
- проверяет обязательные классы итераций и бизнес-деление, если оно заявлено;
- проверяет время снимков и движение времени назад;
- на каждом `during`-снимке проверяет отсутствующую телеметрию, correctness,
  насыщение генератора, ошибки, p95, рост очереди и рост пула;
- ставит `PASS` только когда список причин отказа пуст.

Точные места и отпечатки файлов лежат в
`3904ACCCAP04-evidence/04-source-decision-map.txt` и
`3904ACCCAP04-evidence/00-provenance.txt`.

## Что я подал анализатору

| Проверка | Самостоятельный ввод | Фактический итог |
|---|---|---|
| Сброс счётчика | `before.app.counters.requests=100`, `after.app.counters.requests=99` | `NO-GO`, причина `counter-integrity` |
| Пропущенная телеметрия | во время прогона `generator=undefined` | `NO-GO`, причина `missing-telemetry` |
| Насыщение | `cpuUtilization=0.95`, `activeVus=100`, `maxVus=100`, `droppedIterations=1` | `NO-GO`, причина `generator-saturation` |
| Пороговое окно | `unexpectedErrorRate=0.02` в `T0` и через 30 секунд | `NO-GO`, причина `unexpected-error-rate` |
| Короткий всплеск | `unexpectedErrorRate=0.02` в `T0`, затем `0` через 29 секунд | `PASS` — это годный прогон, ложного отказа нет |
| Полностью пустое окно | `before` и `after` полные, `during=[]` | **`PASS` — дефект** |

Последняя строка — конкретный false-PASS. Ввод сохранён в
`3904-acc-cap04-analyzer-independent.test.mjs`, тест называется
`an entirely missing during-window telemetry sample is rejected`. Получено:
`actual 'PASS'`, ожидалось `NO-GO`; весь независимый файл завершился с кодом 1:
6 успешных тестов и 1 обнаруживший дефект.

## Тавтологии

Проверил независимый файл и штатный `observability.test.mjs` поиском форм
`assert.equal(X, X)`, `assert.strictEqual(X, X)` и `assert.deepEqual(X, X)`.
Совпадений нет. Assertions сравнивают результат с явными ожидаемыми строками,
числами и массивами.

## Что доказано и что не доказано

Доказано offline-подачей записанных объектов: сброс счётчика, явная пропажа
источника телеметрии, насыщение и устойчивое нарушение окна не проходят; чистый
прогон проходит; короткое нарушение до конца окна не даёт ложного отказа.

Не доказано: live-коллекторы, реальный генератор, PostgreSQL/Redis, нагрузка,
production, deployment, release, full `tsc` и наличие анализатора в `l115n`.
TypeScript не запускался: по правилам этой приёмки разрешён только `node --test`.

## Граница

Это приёмка source-side recorded-metrics кандидата из входного bundle. Она не
является live capacity или production приёмкой. Для `GO` нужны исправление
пустого `during`, повторная независимая проверка и появление точно проверенного
анализатора в целевой линии `l115n`.

## KNOWN ISSUES

1. **False-PASS при `during=[]`.** `analyzeRecordedRun` создаёт пустой список
   решений и не добавляет отдельную причину за отсутствие окна телеметрии.
   Минимальное исправление должно fail-closed отвергать пустое окно; затем нужен
   повтор этого негативного теста.
2. Кандидат `bfe4d2098…` есть во входном `metrics.bundle`, но не входит в
   `refs/waves/l115n`. Нельзя считать это доказательством кода целевой линии.
3. Живой контур и реальные источники данных не запускались и не должны
   трактоваться как проверенные.
4. `timeout` отсутствует на этом macOS. Для `node --test` применён локальный
   Perl alarm; сам тестовый runner оставался `node --test`.

## Артефакты

- Evidence: `/Users/limamarty/waves/3904ACCCAP04-evidence/`
- Checksums: `/Users/limamarty/waves/3904ACCCAP04-evidence/SHA256SUMS`
- Bundle: `/Users/limamarty/waves/3904ACCCAP04.bundle`
- Bundle SHA-256 sidecar: `/Users/limamarty/waves/3904ACCCAP04.bundle.sha256`
- Bundle ref: `71a72bf3a559d9888d7bb34218c141cbbdc3373e refs/heads/acceptance/3904-acc-cap04`
- Bundle SHA-256: `f88d9c0a4787c0a7634b24f169bb7615820fea1612cd77110491708d6b482c22`
- `git bundle verify` завершился с кодом 0; evidence `SHA256SUMS` проверен с
  кодом 0.

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

# 3906-cap04-telemetry-hole — итог

## Для тикета, детским языком

Болело так: если в середине прогона не было ни одного снимка, анализатор видел пустоту и говорил `PASS`. Плохой прогон мог выглядеть хорошим.

Сделали так:

- В [analyzer.mjs](/Users/limamarty/waves/wt-3906-cap04/scripts/capacity/r1/observability/analyzer.mjs:574) пустое окно `during` теперь получает причину `missing-during-telemetry`, запись в timeline и итог `NO-GO`; verdict считается на [строке 600](/Users/limamarty/waves/wt-3906-cap04/scripts/capacity/r1/observability/analyzer.mjs:600).
- В [collectors.mjs](/Users/limamarty/waves/wt-3906-cap04/scripts/capacity/r1/observability/collectors.mjs:270) отмечаем, был ли `pgss` действительно подан. В [stop-controller.mjs](/Users/limamarty/waves/wt-3906-cap04/scripts/capacity/r1/observability/stop-controller.mjs:73) пустая база больше не маскируется под честное ограничение `pg_stat_statements unavailable`.
- Добавили прямой регрессионный тест в [observability.test.mjs](/Users/limamarty/waves/wt-3906-cap04/scripts/capacity/r1/observability/observability.test.mjs:174) и матрицу в [telemetry-coverage.test.mjs](/Users/limamarty/waves/wt-3906-cap04/scripts/capacity/r1/observability/telemetry-coverage.test.mjs:94).

## Воспроизведение дыры

Заявлено: acceptance проверяет пустое окно телеметрии.

Доказано старым кодом: ввод — полный `before`, полный `after`, `during=[]`; старый анализатор вернул `actual 'PASS'`, хотя тест ожидал `NO-GO`. Acceptance-файл завершился с кодом 1. Полный вывод: [01-old-independent-node-test.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/01-old-independent-node-test.txt).

Доказано новым кодом: тот же acceptance-ввод завершился с кодом 0: 7 тестов прошли, 0 упали; пустое окно получило `NO-GO` и `missing-during-telemetry`. Вывод: [02-new-independent-node-test.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/02-new-independent-node-test.txt).

## Где ещё анализатор мог молчать

Проверены все виды recorded input в середине прогона. `absent` — ключ источника отсутствует; `empty` — источник `{}`; `truncated` — остался только `observedAt`.

| Вид данных | absent | empty | truncated |
|---|---|---|---|
| app | `NO-GO`, `missing-telemetry` | `NO-GO`, `invalid-timestamp` + `missing-telemetry` | `NO-GO`, `missing-telemetry` |
| database | `NO-GO`, `missing-telemetry` | `NO-GO`, `invalid-timestamp` + `missing-telemetry` | `NO-GO`, `missing-telemetry` |
| redis | `NO-GO`, `missing-telemetry` | `NO-GO`, `invalid-timestamp` + `missing-telemetry` | `NO-GO`, `missing-telemetry` |
| host | `NO-GO`, `missing-telemetry` | `NO-GO`, `invalid-timestamp` + `missing-telemetry` | `NO-GO`, `missing-telemetry` |
| generator | `NO-GO`, `missing-telemetry` | `NO-GO`, `invalid-timestamp` + `missing-telemetry` | `NO-GO`, `missing-telemetry` |

Это не заявленная таблица: она получена запуском [05-telemetry-matrix-node-test.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/05-telemetry-matrix-node-test.txt). Все варианты завершились отказом; для каждого в решении есть названная причина отсутствия данных. Для `{}` дополнительно показана проблема отсутствующего времени, а не спрятан тихий `FAIL`.

## Что проверяли штатные тесты

Старый штатный набор был зелёным: код 0, 10 тестов прошли. Он проверял чистый прогон и дельты счётчиков, сброс счётчика, исчезновение строки `pgss`, явное ограничение недоступного `pgss`, пропажу `generator` внутри существующего снимка, насыщение генератора, устойчивую ошибку, correctness, redaction evidence и безопасную поверхность abort. Он не проверял `during=[]`, поэтому живая дыра оставалась. Вывод старого набора: [03-old-official-node-test.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/03-old-official-node-test.txt).

После добавления регрессии штатный набор зелёный: код 0, 11 тестов прошли. Новый прямой тест краснеет на старом коде и зелёный на новом: [04-new-official-node-test.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/04-new-official-node-test.txt).

## Обратная проверка

Чистый recorded run не отвергнут: штатный тест `clean recorded run keeps iteration classes separate and receives PASS` прошёл, а независимый acceptance-тест `clean recorded run is accepted with exact expected deltas` тоже прошёл. Короткий, очищенный до конца окна всплеск ошибки также остался разрешённым в независимом тесте.

## Граница доказанного

Доказан source-side анализ уже записанных объектов. Доказано, что отсутствие окна и отсутствие/пустота/обрыв каждого из пяти источников не превращаются в `PASS`, а чистый recorded run остаётся `PASS`.

Не доказаны и намеренно не запускались live-коллекторы, реальный генератор, PostgreSQL, Redis, production, prod-БД, SSH, sudo, secrets, deployment, release build, `next build` и полный `tsc`. TypeScript не запускался: по правилам задания разрешён только `node --test`.

## Troubleshooter

Если получен `NO-GO` с `missing-during-telemetry`, сначала проверь, что адаптер записал хотя бы один snapshot в окно `during`. Если snapshot есть, но отсутствует источник, смотри `stopController.decisions[].reasons[]`: там будет `missing-telemetry` с именем источника. Если объект пустой, дополнительно исправь `observedAt`; это будет явно отмечено как `invalid-timestamp`.

## KNOWN ISSUES

1. Точный входной ref `refs/waves/3904/acceptance/3904-acc-cap04` на машине не разрешился через `git rev-parse --verify`. Использован найденный локальный `refs/heads/acceptance/3904-acc-cap04` с commit `71a72bf3a559d9888d7bb34218c141cbbdc3373e`; это зафиксировано в [00-provenance.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/00-provenance.txt).
2. На исходной линии `refs/waves/l115n` CAP-04 analyzer отсутствовал. В ветку от этой линии добавлен пакет recorded-metrics из проверенного кандидата `bfe4d20980eb6fe5f1ad64ba00d7ba925859450c`, затем внесён этот fix. Это граница source-side bundle, не утверждение о live-контуре.
3. `timeout` отсутствует; для тестов использована локальная Perl alarm-обёртка.

## Артефакты

- Ветка: `wave/3906-cap04-telemetry-hole`
- Commit: `397f04e2856d5900d6c302039440fd4aba15adf8`
- Родитель линии: `d85bb2dad15a3ba52c773b0a2362748009a2c3b9`
- Bundle: [3906CAP04FIX.bundle](/Users/limamarty/waves/3906CAP04FIX.bundle)
- Bundle SHA-256: [3906CAP04FIX.bundle.sha256](/Users/limamarty/waves/3906CAP04FIX.bundle.sha256)
- Evidence: [3906CAP04FIX-evidence/](/Users/limamarty/waves/3906CAP04FIX-evidence/)
- Evidence checksums: [SHA256SUMS](/Users/limamarty/waves/3906CAP04FIX-evidence/SHA256SUMS)
- Проверка bundle и checksum: [08-bundle-verify.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/08-bundle-verify.txt), [09-checksums.txt](/Users/limamarty/waves/3906CAP04FIX-evidence/09-checksums.txt)

[14.09 21:30Z координатор] **ЗАКРЫВАЮ. Остаток этого тикета выполнен.**

Остаток требовал: «на T0 собрать реальные before/during/after метрики и stop-controller evidence; synthetic detector tests не являются нагрузочными измерениями».

**Выполнено, и не синтетикой:**
- пре-регистрированный анализатор `analyze-rung-3910.py` применяет гейты H1–H7 и V1–V3 **буквально** и печатает каждое число, которым пользовался, — вердикт можно перевыводить руками;
- по каждой ступени лестницы (N = 1, 5, 10, 15, 20) и по часовому прогону получен `verdict-*.json` с `healthy`, `health_fails`, `valid`, `validity_fails`;
- before/during/after сняты по-настоящему: CPU считается дельтой `utime+stime` из `/proc/<pid>/stat` по каждому процессу **и каждой нити**, с классификацией MEASURED / INSTRUMENT / FOREIGN и проверкой привязки к ядрам через `Cpus_allowed_list`;
- вторжение прибора **измерено, а не объявлено**: `intrusion_cores 0.144` при пороге `0.40` на часовом прогоне; на ступенях 0.088–0.235;
- **stop-controller работает и применялся**: раннер проверяет здоровье прода до и после каждой ступени и прерывает лестницу на любом не-200; все проверки в `runs/prod-health.log`;
- лестница действительно **остановилась** на первой нездоровой ступени (N=20, `H4 p95 3035 мс > 2500`) и ступень 25 не запускалась — контроллер сделал ровно то, ради чего написан.

**Найдено и починено по ходу** (волна 3910, §7a и §7c): ssh-сэмплер не отцеплялся; счётчик пула писал две строки и гейт H7 оценивался по `None`. Оба дефекта дожили до волны потому, что **раннер до неё ни разу не гонял ступень** — это само по себе закрытая теперь дыра в оснастке.

Доказательства: `3910CAP10TWO-evidence/runs/` (verdict-*.json, analysis-*.txt, cpu-delta-*.log, prod-health.log), ветка `refs/waves/3910/...` в зеркале A2.

Статус → `done`.

[15.09 01:25Z координатор] ## 15.09 01:40Z — ВОШЁЛ В ПОСАДКУ l115o. Требуется пост-QA на проде.

Прод работает на `l115o-68e25d8d` (коммит `68e25d8df5ae8263c5ac5466353631f57a17cfcc`, артефакт `cd2773f65d66b09ec03d39b553041d2814ce09413e72d72b07bc9de89df536c8`) с 00:56Z 15.09. Посадка проверена: `ready=true`, коммит совпал, браузерная проба открыла документ, 0 новых ошибок.

**Работу по этому тикету принесли волны:** 3418.

**Что это значит для этого тикета.** Работа по нему пролежала принятой, но НЕ посаженной — в некоторых случаях неделями. Теперь она на проде. Приёмка волной доказывала, что код правильный в дереве волны; она НЕ доказывала, что фича работает на живом проде. Это разные вещи, и мы на этом уже обжигались.

**Поэтому статус — `review`, а не `done`.** Закрыть тикет имеет право только пост-QA, который проверит поведение на работающем проде и приложит доказательство. До тех пор «сделано» — это заявка.

### Для нулевого агента (тот, кто будет делать пост-QA)

Ты приходишь на этот тикет без нашей истории. Что надо знать:

1. **Проверяй на проде, не на стенде.** Стенд сейчас вообще не поднят — у него не было своего артефакта, он запускался из каталога боевого релиза и заблокировал проверку посадки; пересобирается волной 3948 (WEB-662).
2. **`/api/health` ничего не доказывает** — он проходит и на пустом приложении. Нужно деловое действие: аутентифицированная сессия делает то, про что этот тикет.
3. **Отсутствие ошибок в логе — не доказательство жизни.** Нужен положительный результат, а не тишина.
4. **Числа в обосновании закрытия получай командой в момент закрытия.** Я однажды закрыла тикет числом `4255`, взятым из `pg_stat_user_tables.n_live_tup` — это ОЦЕНКА. Настоящее `count(*)` дало `107 817`. Разница в 25 раз.
5. **Не верь имени волны в теме коммита** — проверяй наличие содержимого (`git cherry`), а не упоминание номера.
6. Запускатель тестов в проекте — `node --test`. Vitest нет.

[15.09 10:46Z координатор] Post-QA 3973: FAIL на l115o. Analyzer проверяет missing before/after, но during=[] не делает результат invalid; прежний false-PASS воспроизведён, а fix 3906 не входит в l115o. Следующий шаг: перенести fail-closed empty-during fix и повторить recorded-fixture + T0 telemetry gate. Карточку оставить review.

[15.09 11:25Z координатор] [15.09 11:25Z координатор] Авторская починка 3980: VERDICT=GO, но ещё не независимая приёмка. Candidate 7b0538d643f70851516bf8d361bcba339fe9664f, parent ровно l115o 68e25d8df; bundle/sidecar/evidence 6/6 SHA256 проверены. Изменены только analyzer.mjs и его focused test: during=[] теперь даёт NO-GO, valid=false, missing-during-telemetry; на чистой l115o тот же fixture давал ложный PASS. Focused observability 11/11 и node --check зелёные; общий capacity suite имеет baseline/dependency failures и не выдан за PASS. Ref закреплён в A1 mirror: refs/waves/3980/fix/3980-web631-current-line. Независимая приёмка 3986 поставлена в очередь A2 после WEB-653. Статус оставить review.

[15.09 12:01Z координатор] Независимая приёмка 3997 на A2: VERDICT=GO. Evidence и входной пакет проверены.

На чистой l115o корректный recorded fixture с `during=[]` ложно давал PASS/valid=true/sampleCount=0. Candidate `7b0538d643f70851516bf8d361bcba339fe9664f` на том же fixture даёт NO-GO/valid=false, причину `missing-during-telemetry` и 0 samples. Непустой during проходит; missing before/after сохраняет отдельную причину. Focused observability: baseline 10/10, candidate 11/11; красный перевёрнутый expected упал. Parent ровно l115o, diff два заявленных файла.

Candidate принят в следующую линию. WEB-631 оставить review до посадки и post-QA на исполняемом harness.

[15.09 16:04Z координатор] M1/DeepSeek 4075 read-only reconciliation: `REOPEN`, evidence SHA 7/7. На l115o `during=[]` всё ещё может дать ложный PASS; принятая fail-closed починка `7b0538d6…` и объединённый вход `c5d6375a…` отсутствуют в текущей линии. Это landing gap, не повод снова гонять старый QA. `c5d6375a…` уже включён в M4/4063; после посадки нужен один recorded-fixture прогон: пустой during → NO-GO/invalid/missing-during-telemetry, непустой → PASS, причины missing before/after сохранены.

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

УЖЕ ПОКРЫТО историей тикета (не дублируется):
- вход в посадку l115o — 2026-09-15T01:25:17.203Z;
- post-QA FAIL с механизмом — 2026-09-15T10:46:43.383Z (analyzer проверяет missing
  before/after, но `during=[]` не делает результат invalid);
- авторская починка 3980 — 11:25:43.013Z (candidate `7b0538d64…`);
- независимая приёмка 3997 `VERDICT=GO` на A2 — 12:01:26.036Z (focused baseline 10/10,
  candidate 11/11, красный перевёрнутый expected упал, diff два заявленных файла);
- текущий вердикт `REOPEN` — 2026-09-15T16:04:10.713Z (M1/DeepSeek 4075, evidence 7/7).

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

1) НЕТ блока KNOWN ISSUES в формате канона. Фактический known issue —
   ЛОЖНЫЙ PASS ПРИ ПУСТОЙ ТЕЛЕМЕТРИИ, у него нет «как проверить за 2 минуты»
   и нет «причина файл:строка»:
   на чистой l115o корректный recorded fixture с `during=[]` давал
   PASS / `valid=true` / `sampleCount=0`; candidate `7b0538d643f70851516bf8d361bcba339fe9664f`
   на том же fixture даёт NO-GO / `valid=false` / причину `missing-during-telemetry` /
   0 samples (2026-09-15T12:01:26.036Z). Проверка за 2 минуты: прогнать recorded
   fixture с пустым `during` и посмотреть поля `valid` и `sampleCount` в выводе —
   `valid=true` при `sampleCount=0` означает, что fail-closed починка НЕ посажена.
   Имя analyzer-файла и строка в комментариях 15.09 НЕ названы — это надо назвать.
2) НЕ ЗАФИКСИРОВАНО, что REOPEN — это landing gap, а не провал приёмки: fail-closed
   починка `7b0538d6…` и объединённый вход `c5d6375a…` ОТСУТСТВУЮТ в текущей линии
   (2026-09-15T16:04:10.713Z). Проверка за 2 минуты:
   `git merge-base --is-ancestor 7b0538d643f70851516bf8d361bcba339fe9664f 68e25d8df5ae8263c5ac5466353631f57a17cfcc`
   → ненулевой код возврата означает «не в линии».
3) Нет МАШИННЫХ ПУТЕЙ к report/evidence 3997 и 4075 (12:01:26.036Z — «Evidence и входной
   пакет проверены»; 16:04:10.713Z — «evidence SHA 7/7»). Правило 15 требует ссылку на факт.
4) Тело заканчивается блоком 12.09 (`SHIFT-STOP-20260912:FINAL`, STOPPED,
   `ИНДИВИДУАЛЬНЫЙ ОСТАТОК`) — противоречит `review` на 15.09.

ОСТАТОК на 15.09 16:04Z: `c5d6375a…` уже включён в M4/4063; после посадки нужен один
recorded-fixture прогон: пустой `during` → NO-GO/invalid/`missing-during-telemetry`,
непустой → PASS, причины missing before/after сохранены.

ПЕРВЫЙ ШАГ НУЛЕВОГО АГЕНТА (2 минуты, ничего не запускает): прочитать
2026-09-15T16:04:10.713Z и проверить ancestry `7b0538d6…` (команда выше).
Если не предок — не гонять старый QA, ждать посадки.

L115Q-LANDING-20260915-WEB-631
[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-631
Аудит-источник: `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-631 — CAP-04: сбор метрик, stop-controller и доказательства
## Самое сильное принятое доказательство

- Исправление `missing-during-telemetry` принято; A2/4122 на будущем carrier прогнала
  collector suite **121/121** и реальный repaired analyzer: GREEN PASS,
  пять invalid families NO-GO, `fault=false`.
- Portable package: `worker-results/4108WEB631COLLECTOR-REPORT.md`.
- `l115q` несёт %s.
- Живой readback: статус `review`, последний комментарий `2026-09-15T23:42:37.969Z`.

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

`4108` прямо помечает live passive collection `NOT_RUN`. Общая расписка `l115q`
не является пассивным сбором. Точный формат receipt на карточке не выписан.

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

Один пассивный source/artifact-bound запуск на реальном изолированном run:
`before.json`, непустой `during.jsonl`, `after.json`,
app/DB/Redis/host/generator counters, analyzer/stop-controller result.
Отдельный inverted control `during=[]` обязан дать `missing-during-telemetry`.

## Первый шаг нулевого агента
За 2 минуты, ничего не запуская: открыть
`worker-results/4108WEB631COLLECTOR-REPORT.md` и найти пометку live passive collection
`NOT_RUN`; затем прочитать `2026-09-15T23:42:37.969Z` и убедиться, что пассивный
receipt там не заявлен. Только после этого ставить пассивный прогон на `l115q`.

## Явные незамены
- `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
ОСНОВАНИЕ=Приёмка 3997: VERDICT=GO; последняя сверка 4075: REOPEN из-за landing gap; l115q посадка записана, но 4108 помечает live passive collection NOT_RUN.
ЧТО НУЖНО=Source/artifact-bound passive receipt с before.json, непустым during.jsonl, after.json, counters, analyzer/stop-controller и отдельным during=[] -> missing-during-telemetry.
triage-m1 4607

РЕШЕНИЕ=parked
ОСНОВАНИЕ=Волна 4140, аудит 2026-09-16: collector suite 121/121 и repaired analyzer подтверждены, но live passive receipt NOT_RUN; движения ≥7 дней, остаток не у владельца.
ЧТО НУЖНО=ПРЕДЛОЖЕНИЕ=split; вынести passive receipt в отдельный тикет и зафиксировать before/during/after; 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. Недостающие расписки собираются там.