WEB board

[14.09 21:41Z координатор] **Правка №2 ПРИНЯТА. Четвёртый круг завершён: волна 3929 (Neo, независимая приёмка) — `VERDICT=GO`.**

Счёт по этой одной правке: **четыре круга, два `NO-GO`, обе дыры найдены не автором**. Так это и должно работать.

**Что приёмка сделала — она не поверила доказательству, а повторила его.** Собственный перебор `acceptance/3927-completeness.probe.mjs` прошёл **21 708 800** написаний ключей `error`/`message` и трёх auth-слов: `missedByPreFilter = 0`. Лемма о коротких escape-последовательностях подтверждена независимо.

**Чем пыталась протащить отказ как успех** (все сравнивались с эталоном полного разбора): буквы через `\u`; изменённые пробелы и переносы вокруг двоеточия; отказ глубоко во вложенных массивах массивов; дублирующиеся ключи; BOM и zero-width символ в ключе; битая конкатенация; регистр; `\u` **далеко после** auth-строки в длинном теле; `ok:true` с вложенным auth. **Входа «полный разбор = 401/403, а 3927 = 200» не найдено.**

**`ok === true` проверен аудитом исходников, а не согласием.** Приёмка прошла `src/app/api` и `src/lib` по вызовам `privateContentJson`, `NextResponse.json`, `Response.json` и искала места, где рядом стоят `ok: true` и auth-литерал. **Список пуст.** Представительные ветки ставят auth-статус до success-ветки (`src/app/api/analytics/game/route.ts:23-47`, `src/app/api/sources/[sourceId]/entity-coverage/route.ts:19-64`).

**Цена названа честно, и она реальна.** Приёмка специально построила законный пользовательский текст с **битым одиночным суррогатом**: `\u` в нём есть, отказа нет. Защита не превратила его в 401 — но **отправила тело на полный разбор**. Это и есть цена: любой `\u` теперь означает «разобрать целиком». Обычный юникод, кириллица, CJK, эмодзи, кавычки, слеши и переносы строк `\u` в выводе `JSON.stringify` не дают — проверено её же прогоном.

**Тесты:** красный набор 3927 — 9/9; набор поведения 3926 — 24/24; собственный дополнительный — 2/2; совместный базовый прогон shipped/privateContent/3922/3927 — **80/80**.

**Счёт по разбору Астры: принято 2 из 11** (№1 копирование истории, №2 повторный разбор JSON). Ветки: `refs/waves/3927/wave/3927-parse-guard-r3`, `refs/waves/3929/acceptance/3929-acc-guard-r3`.

[14.09 21:51Z координатор] **Последнее условие пункта 0 снято — и снято без запуска посадки на проде.**

Астра вынесла `VERDICT=NO-GO; STEADY-3-WEB=GO@15/5/3; SINGLE-UNIT-RESTART=MEASURED; FLIP-PEAK=UNKNOWN` и назвала единственное оставшееся условие: подтвердить пик соединений при настоящем `flip`. Запускать посадку ради замера нельзя — это изменение прода без продуктовой цели. **Ответ нашёлся в развёрнутом коде.**

**`flip` не поднимает новый юнит до остановки старого.** Он выполняет **два последовательных `systemctl restart`**:

```
land-l115n.sh:140   systemctl restart nc-a1   ; sleep 7 ; await nc-a1 в upstream   (иначе exit 33)
land-l115n.sh:143   systemctl restart nc-a1-b ; sleep 7 ; await nc-a1-b в upstream (иначе exit 34) ; затем health=200 на 3012
```

`transition-l115n.py:118-120` на стадии flip вызывает именно этот скрипт. А стадия verify (`:141-145`) перебирает `/proc` и **требует** `assert not oldpids, 'compat processes remain'` — инвариант «процессов старого релиза не осталось» встроен в сам инструмент посадки.

**Следствие:** пик при `flip` **равен** пику при `systemctl restart` одного юнита, который я уже измерила на живом проде: `web 28 до = 28 пик`, провал до 11, возврат к 16 за ~30 с. Юниты перезапускаются **по одному**, каждый ждёт возврата в upstream до следующего. Удвоения спроса не возникает ни на каком шаге.

**Значит по бюджету соединений третий процесс допустим**: расчёт Астры `15/5/3` даёт спрос **72 из 77** при запасе 5, и посадка этого спроса не увеличивает.

**Две оговорки, которые идут вместе с выводом и не должны потеряться:**
1. Это вывод **из кода** развёрнутого скрипта, а не из инструментированного прогона настоящей посадки. Если скрипт следующей линии напишут по схеме blue/green, вывод перестаёт действовать.
2. Стадия verify, которая и проверяет отсутствие старых процессов, **не выполнялась на посадках l115m и l115n** — отдельный дефект **WEB-661**. Инвариант встроен, но на двух последних посадках его никто не подтверждал.

Астре отдано на окончательный вердикт пункта 0 с прямым требованием: если условий больше нет — назвать `GO`, число процессов, лимиты primary и readonly, остающийся запас и поведение на посадке; если оговорка №2 блокирует — сказать это прямо и назвать, что должно случиться.

[14.09 22:10Z координатор] **Правка №4 Астры сделана — волна 3934 (Neo), `VERDICT=GO`. Выигрыш крупный, и охват честно уточнён.**

**Что сделано:** когда sidecar содержит обычный текст без escape-символа, декодер больше не собирает текст посимвольно — он возвращает payload после проверки, что внутри нет запрещённого сырого `--`. Тексты с escape идут прежним общим путём.

**Замер волны** (`process.cpuUsage()`, 7 серий, медиана; тело строится **настоящим producer-путём** `wrapWysiwygContent(largeDocumentTextToWysiwygHtml(...))`, то есть проверяется и visible-copy ветка):

| исходный размер | было | стало | заявлено Астрой |
|---:|---:|---:|---:|
| 262 144 | 4.232 мс | **2.139 мс** | 5.341 |
| 1 048 576 | 35.900 мс | **3.142 мс** | 43.474 |

На мегабайте — **в 11 раз дешевле**. Столбец Астры помечен как заявленный и за свой замер не выдаётся.

**⚠️ Охват уточнён волной, и уточнение важнее числа.** Астра предупреждала, что обычный `GET` декодер не вызывает — **это подтвердилось**: `src/app/api/sources/[sourceId]/text/route.ts:57-121` только проверяет доступ и отдаёт поток. **Но правка всё же попадает в путь пользователя**: отложенный decode при открытии большого WYSIWYG-документа (`EditorModal.tsx:3611-3615`) и ещё один после GET-гидратации (`:3848-3853`, `:3994-4001`), плюс Markdown/plain export и editor collaboration.

**`Δ42 UNKNOWN` сохранён** — на стенде не мерилось, влияние на 42 мс не доказано.

**Выдана независимая приёмка — волна 3936 (M4).** Главное к проверке: найти вход, где быстрый путь и общий дают **разный** результат (сырой `--` на границе буфера, escape в самом конце, не-UTF8, суррогаты), и перепроверить утверждение об охвате своими глазами — если волна преувеличила, это находка.

**Счёт по разбору Астры: принято 2 из 11, в приёмке 1, пункт 0 на финальном вердикте.**

[14.09 22:52Z координатор] **Правка №5 Астры сделана — волна 3939 (Neo), `VERDICT=GO`. И она честно измерила ту оговорку, из-за которой правка могла оказаться бессмысленной.**

**Что сделано:** resolver превращал большой HTML в `plainText` **для всех**, хотя нужен он только realtime-поиску и визуализации. Теперь остальные получают только исходный `content`. Старое поведение сохранено по умолчанию (`includePlainText`, `undefined` = как раньше; при `false` ключ `plainText` не создаётся), `content` не преобразуется и не подменяется. Resolver: `src/lib/sources/resolveSourceContent.ts:77-110,206-235,251-366`.

**⚠️ Оговорка про кэш измерена, а не отброшена.** Астра предупреждала, что попадание в кэш может обнулить эффект. Волна проверила **до** правки:
- повторное чтение **одного** источника — кэш забрал **6 из 7** обращений;
- чередование **трёх** источников — кэш забрал **0 из 21**.

То есть на повторном одном источнике кэш действительно съедает большую часть выигрыша, **но на multi-source пути — нет**. Волна помечает это как локальную оценку, а не production-телеметрию.

**Замер (свой прогон, 7 серий, медиана, `process.cpuUsage()`), на материале 1 048 576 символов:** CPU resolver **4.497 мс → 0.101 мс**, разница **−4.396 мс**, снижение **97.75 %** на локальном холодном стенде.

**⚠️ Двойной счёт исключён явно.** Волна взяла базой ветку правки №4 (`2a337b07`, `src/lib/editor/largeDocumentTextCodec.ts:85-92`) и измеряла **поверх неё** — выигрыш №4 к №5 повторно не приписан. Это было прямым требованием брифа, и оно выполнено.

⚠️ **Дефект выдачи, мой:** точный ref `refs/waves/3934/wave/3934-opt4-sidecar-decoder` в зеркале Neo отсутствовал (`Needed a single revision`) — волна нашла локальную ветку с тем же именем и **сказала об этом**, вместо того чтобы молча взять что попало. Причина в том, что волна 3934 собрала бандл из detached HEAD, и именованная ветка в него не попала.

**Счёт по разбору Астры: принято 3 из 11** (№1, №2, №4); **№5 сделана и ждёт приёмки**; **пункт 0 отправлен на первую независимую приёмку** — волна 3942 (M4). ⚠️ Это важно: `GO` по пункту 0 Астра вынесла **сама себе**, независимой проверки не было ни разу, а именно он открывает второй процесс, который на стенде дал **+38 % пропускной**.

[15.09 00:05Z координатор] **Астра сдала первый проход по остатку и работает параллельно, как требовал владелец. Осталось СЕМЬ пунктов, а не шесть.**

Она пересчитала **по своему же файлу**, а не по памяти: в таблице подготовительный пункт 0 плюс пункты 1–11. Принято пять (0, 1, 2, 4, 5) → остаток: **3, 6, 7, 8, 9, 10, 11**.

**Что принесла этим проходом:**

| № | результат |
|---|---|
| **8** | ⛔ **отклонён ею самой, с причиной**: простое переиспользование раннего ACL-разрешения меняет наблюдаемый DTO при смене прав **во время запроса** — воспроизведено тестом. Ветка содержит только тесты и эксперимент |
| **10** | ⛔ **отложен**: полезное переиспользование неизменного inventory на найденном пути **не установлено**; тест показал, что индекс всё равно надо обновлять после commit. Отрицательная CPU-дельта **не заявлена** |
| **11** | кандидат реализован, красный тест до правки получен, функциональные тесты проходят; **`NEEDS_MEASUREMENT`** — CPU-эффект поверх принятого не измерен |
| 3, 6, 7, 9 | не начаты |

**Отказ с доказательством по пункту 8 — это ровно то поведение, которого я добиваюсь.** Он ценнее сделанной впустую правки: теперь мы знаем, почему так нельзя, и не вернёмся к этому через месяц.

**🔴 Её общий блокер оказался моим проколом.** Она написала: «локальная линия с финальными принятыми OPT-0/1/2/4/5 не найдена; у владельца запрошены путь/ref/SHA. Замер от l115n не подменяет требуемое сравнение». **Она права**: я собрала кандидата `l115o` и **не отдала его ей**, поэтому измерять было не от чего — замер от старой базы посчитал бы выигрыш дважды.

**Исправлено:** линия привезена в её клон как `refs/lines/l115o` (`c0bcab8490408e68…`), и она перезапущена с требованием измерять **от неё**.

**Следующим назначен пункт 7** — самый дешёвый из оставшихся: удалить `UserSession_lastActiveAt_idx`. По моему замеру на проде он стоит **+4 записи в индексы и +306 байт WAL на каждый запрос** при `idx_scan = 0`. ⚠️ Требование: проверить `idx_scan` **самой**, найти в коде **всех** возможных потребителей до предложения удалить, и помнить, что удаление индекса — изменение схемы, то есть миграция обязана быть rollback-safe или под флагом.

Далее по её же порядку — 3, 6, 9. `Δ42 UNKNOWN` не снимается, новая ёмкость не заявляется.

[15.09 00:08Z координатор] **🔴 Сборка линии-кандидата упала на правке №0, и приёмка не могла это поймать — потому что я сама запретила сборку в брифе.**

**Что случилось.** `next build` встал с webpack-ошибкой. Цепочка импортов напечатана целиком:

```
node:process
  ./src/lib/nodeProcessState.ts                     <- код правки №0
  ./src/lib/monitoring/persistent/aggregator.ts
  ./src/lib/monitoring/persistent/providerMetrics.ts
  ./src/lib/research/reliability.ts
  ./src/lib/podcast/speechAdapter.ts
  ./src/components/podcast/CreatePodcastModal.tsx    <- КЛИЕНТСКИЙ компонент
  ./src/app/(full)/dev/create-podcast/page.tsx
> Build failed because of webpack errors
```

Реестр правки №0 живёт на **встроенном модуле `node:process`** (это и была её сильная сторона — независимость от `globalThis` отдельных VM). Но через шесть звеньев импорта он дотягивается до **клиентского компонента**, а браузерная сборка встроенный модуль Node упаковать не может.

**🔴 Почему приёмка 3942 вынесла `GO` и была при этом не виновата.** Она проверяла ровно то, что я разрешила: `node --test`, единственность клиента, red→green, поведение fence и пробы. **Сборку я запретила — в каждом приёмочном брифе стоит `⛔ next build`, `⛔ полный tsc`.** А эта поломка **не видна тестами**: на сервере модуль импортируется нормально, ломается только при упаковке для браузера.

**Это моя дыра в процессе, и она системная:** все приёмки этой ночи шли с запретом сборки, значит **ни одна из них не могла поймать поломку упаковки**. В памяти у меня даже записано «UI-приёмка требует сборки, не запрещай её» — и я всё равно запретила везде.

**Что сделано сейчас:**
1. правка №0 **вынута из линии** откатом слияния (`git revert -m 1 10cb5c8c5`); проверено, что `src/lib/nodeProcessState.ts` исчез из дерева;
2. сборка перезапущена **без неё** — остальные 35 веток не должны ждать из-за одной;
3. попутно: перезапуск сначала отказался с `STOP: below 18GiB build floor` — упавшая сборка оставила `.next` на 6.5 ГБ; удалила, стало 19 ГБ.

**Что дальше с правкой №0.** Возвращается отдельной волной: починить цепочку импортов так, чтобы серверный реестр не утекал в клиентский бандл (обычный способ — разделить модуль на серверную и изоморфную части либо не тянуть `aggregator` в клиентский путь). ⚠️ **Её приёмка на этот раз ОБЯЗАНА собрать проект.**

**Правило, которое я записываю себе явно:** если правка трогает код, который может попасть в браузерный бандл, **приёмка без сборки приёмкой не считается**. Запрет сборки в брифе допустим только для правок, заведомо не достигающих клиента, и это надо обосновывать, а не ставить по привычке.

[15.09 00:18Z координатор] **Вопрос владельца: почему у нас однопоточность? Не защита ли это от чего-то? Не связано ли с индексацией?**

**Ответ: однопоточность мы не выбирали и ею ни от чего не защищаемся. Это устройство среды, на которой написан продукт.**

## 1. Почему один поток

Продукт на **Node**. В Node JavaScript исполняется **в одном потоке на процесс** — так устроен движок. Это не наша настройка, не архитектурное решение команды и не защитный механизм. Ядер можно выдать сколько угодно: **второе ядро некому занять**, потому что вся обработка запроса идёт в одной очереди.

Это ровно то, что показал замер: главная нить стоит на **0.888 ядра** и не сдвигается, а `cpu0/cpu1` заняты на три четверти при простаивающих `cpu2/cpu3`.

## 2. С индексацией НЕ связано — проверено

Индексация давно вынесена в **отдельный процесс**: на боевой машине это служба `nc-a1-indexing.service` со своим таймером, запускающая `workers/process-source-indexing-queue.js`. Она работает рядом и главный поток веба не занимает.

Проверено и по коду: `worker_threads` встречается в исходнике **дважды** — в тесте и в `src/lib/ingest/extractionBudget.ts`. Настоящей многопоточности в обработке запросов нет вообще.

## 3. Почему не многопоточность, а больше процессов

Для этой нагрузки потоки — **не тот инструмент**. Работа состоит из ожидания базы и сети, а не из счёта. Каждому потоку всё равно нужен свой клиент базы и своя память, а ни Next, ни Prisma не рассчитаны на то, чтобы их делили между потоками (сама Астра в разборе пункта 0 отдельно оговорила: Prisma-объект в worker-поток не переносится, и её правка **запрещает** создание клиента в worker-потоке).

Правильный ответ в мире Node — **больше процессов, по одному на ядро**. И это **уже измерено**: вторая копия дала **+38 % пропускной** (20.1 → 27.8 действия/с) при **меньшей** задержке (p95 1150 → 838 мс) и поднялась за 6 секунд.

## 4. Что мешает включить это сейчас — две вещи, обе с числами

1. **Живые сессии ломаются.** Голосовые сессии держат провод к **одной конкретной** копии; при второй копии из **273** попыток сорвалось **208**, само не восстановилось. Sticky-маршрутизация лечит частично — на двух копиях проценты всё равно теряются, на одной ноль. Значит внутри приложения есть **неразделяемое состояние** (волна 3932).
2. **Бюджет соединений к базе.** Без одного DB-клиента на процесс три копии съедают слоты — это и есть правка №0, которая только что уронила сборку на упаковке для браузера.

## 5. Главный вывод для планирования

**«Потолок 15» — это потолок ОДНОЙ копии**, а не железа и не продукта в целом. Снимается он **не** оптимизацией внутри потока, а починкой этих двух вещей — и тогда копии складываются.

Оптимизации Астры при этом не бесполезны: они удешевляют **каждую** копию, то есть поднимают и потолок одной, и суммарный. Но порядок величин разный: правки дают проценты, вторая копия дала **+38 %** сразу.

[15.09 01:17Z координатор] ## 15.09 01:30Z — полная картина по всем 11 пунктам + пункт 0 (append, старый текст сохранён)

Владелец просил не заблудиться: здесь состояние КАЖДОГО пункта, включая отклонённые, с причиной отказа. Отдельных тикетов у пунктов нет, поэтому таблица живёт тут.

Исполнитель — Астра (машина M1, отдельная линия `astra/*`), приёмки — независимые волны на других машинах. Правило: **вердикт автора на свою же работу приёмкой не считается.**

### Сводная таблица

| № | Что предлагалось | Вердикт автора | Независимая приёмка | Состояние |
|---|---|---|---|---|
| 0 | Единый клиент/состояние процесса вместо пересоздания | принят | 3942 GO | ⚠️ **ВЫНУТ ИЗ ЛИНИИ** — уронил сборку; чинится волной 3954 |
| 1 | — | принят | 3928 GO | **на проде** в линии l115o |
| 2 | — | принят | 3929 GO | **на проде** в линии l115o |
| 3 | Ранняя проекция полей | `REJECT_NAIVE_EARLY_PROJECTION` | не требуется | **отклонён**: ранняя проекция теряет поля, нужные ниже по пути |
| 4 | — | принят | 3936 GO | **на проде** в линии l115o |
| 5 | — | принят | 3944 GO | **на проде** в линии l115o |
| 6 | — | `REJECT_SESSION_SEMANTICS_CHANGE` | не требуется | **отклонён**: меняет наблюдаемое поведение сессий |
| 7 | Снять индекс `UserSession.lastActiveAt` | `CANDIDATE_ROLLBACK_SAFE_LOCAL_PROOF` | **волна 3953 (M4), идёт** | кандидат, НЕ принят |
| 8 | — | `REJECT_SEMANTICS` | не требуется | **отклонён**: меняет ответ при смене прав во время запроса |
| 9 | — | `REJECT_INCOMPLETE_DERIVATION_VERSION` | не требуется | **отклонён**: производные не версионируются, старое смешается с новым |
| 10 | — | `REJECT_NO_REUSE_PROOF` | не требуется | **отклонён**: заявленное переиспользование не доказано |
| 11 | Запоминание разбора `ADMIN_EMAILS` | `CANDIDATE_MEASURED` | **волна 3952 (M4), идёт** | кандидат, НЕ принят |

Итог по счёту: **принято и посажено — 4** (1, 2, 4, 5); **принято, но вынуто — 1** (0); **отклонено с причиной — 5** (3, 6, 8, 9, 10); **на приёмке — 2** (7, 11).

### Отклонения — это результат, а не простой

Пять отказов пришли с разбором и доказательствами. Переоткрывать их в прежнем виде не нужно. Если какой-то из них окажется важен по существу — задачу надо **переформулировать иначе**, а не повторять ту же попытку.

### Пункт 0 — чем он нас обжёг (важно для всех будущих приёмок)

Правка прошла приёмку 3942 с GO, была влита в линию и **уронила сборку прода**. Цепочка утечки: `node:process` → `src/lib/nodeProcessState.ts` → агрегатор → `providerMetrics` → `reliability` → `speechAdapter` → `CreatePodcastModal.tsx` → страница. Серверный модуль через семь звеньев оказался в клиентском компоненте.

Причина пропуска — **моя ошибка как координатора**: в брифе приёмки было сказано не запускать сборку (экономия времени). Правку пришлось выдернуть откатом слияния `git revert -m 1 10cb5c8c5`.

**Правило, купленное этим:** запрет на сборку в брифе приёмки допустим ТОЛЬКО для правок, про которые доказано, что они не доходят до браузерного бандла. Во всех остальных случаях приёмка без сборки приёмкой не считается.

Волна 3954 чинит границу (разделение серверной и общей части либо пометка `server-only`) и обязана поставить автоматическую ловушку, чтобы это ловилось сборкой, а не памятью приёмщика.

### Пункт 11 — почему не принят автоматически, хотя цифры красивые

Измерение автора (`process.cpuUsage`, 7 серий AB/BA, ≥250 мс на выборку):

| адресов | до, мкс/вызов | после, мкс/вызов |
|---|---:|---:|
| 0 | 0.009141 | **0.037802 — ХУЖЕ вчетверо** |
| 1 | 0.104120 | 0.017832 |
| 8 | 0.531066 | 0.019460 |
| 64 | 4.252627 | 0.036005 |
| меняющаяся конфигурация | 0.071667 | **0.096412 — ХУЖЕ** |

На проде в `ADMIN_EMAILS` **5 элементов** (замерено координатором на боевом процессе 15.09; значение не печатаем). Медиана запроса на проде — **24 000 мкс**. То есть даже лучший случай — доли процента запроса.

Приёмка 3952 обязана ответить числом: **сколько раз за запрос вызывается разбор** и какую долю от 24 мс это даёт. Без этого числа приёмка недействительна. Плюс проверить, что запоминание не отдаёт общую ссылку на массив (чужая мутация = право доступа) и что смена/удаление переменной действуют немедленно.

### Пункт 7 — что проверяет приёмка 3953

Автор честно указала слабость своего доказательства: `idx_scan=0` снят на локальной базе, но **время сброса статистики NULL — окно наблюдения неизвестно**. Ноль сканов за неизвестный срок — это отсутствие данных, а не доказательство.

Приёмка обязана: сбросить статистику явно, прогнать реальные пути, показать окно ЧИСЛОМ; собрать `EXPLAIN (ANALYZE, BUFFERS)` на правдоподобном распределении (у одного пользователя десятки сессий, у большинства одна-две), отдельно проверить случай «очень много сессий у одного»; прогнать миграцию и откат на настоящем Postgres; проверить, что `prisma migrate deploy` не оборачивает `CONCURRENTLY` в транзакцию (если оборачивает — миграция упадёт на проде, это NO-GO до исправления).

### Связанное

Вопрос владельца «почему у нас однопоточность» — ответ в WEB-638 (CAP-11): упирается главный поток JS (86.5% ядра). Ответ на масштабирование — больше процессов, а не потоки: Prisma и Next не разделяются между worker_threads.

[15.09 01:48Z координатор] ## 15.09 03:00Z — приёмки пунктов 7 и 11 пришли. Один GO с оговоркой, один NO-GO по релизному гейту.

### Пункт 11 (запоминание разбора ADMIN_EMAILS) — **GO**, волна 3952 (M4), ветка `refs/waves/3952/acc/3952-opt11` = `bc024d010cee441637c3fbf24d598457bd8111d3`

Дословный вердикт приёмщика:

> «Правка в `adminApiGate.ts` корректна и доказана моими тестами (мой негативный тест падает на базе, проходит на ветке), но её выигрыш — **0.00105% типового запроса**, поэтому сажать её стоит как попутную уборку, а не как оптимизацию; перед merge выбросить из `tests/` бенчмарк `astra-opt-11.measure.mjs`, который падает по умолчанию.»

Это ровно то число, которого я требовала в брифе: **одна тысячная процента запроса**. Правка правильная и пусть едет, но называть её оптимизацией нельзя — на цель эпика (42 мс → 10 мс) она не влияет никак.

**Условие к сборке:** перед слиянием выбросить `tests/astra-opt-11.measure.mjs` — бенчмарк падает по умолчанию и сделает красной чужую сюиту.

### Пункт 7 (снятие индекса `UserSession.lastActiveAt`) — **NO-GO**, волна 3953 (M4), ветка `refs/waves/3953/acc/3953-opt7` = `6c9c283b0e0e069f500c0f3e05615f659d3f4d78`

Дословный вердикт:

> «Снятие индекса безопасно и выигрыш подтверждён с запасом, но кандидат валит собственный релизный гейт репозитория `check:migration-compatibility` (зелёный на базе, красный на ветке), потому что манифест миграций не обновлён — а обновить его классификацией из отчёта автора **нельзя**: политика репозитория считает `DROP INDEX` contract-шагом.»

Важно, что это **не отказ правке**: сама правка безопасна и полезна, выигрыш подтверждён независимо. Уперлись в устройство нашей же политики миграций.

Разбор упирается в правило инструмента посадки: contract-миграция принимается ТОЛЬКО если её запись объявляет флаг возможности со значением по умолчанию `off` и этот флаг фактически выключен в окружении. У снятия индекса флага возможности нет и быть не может — индекс либо есть, либо нет.

**Поставлена волна 3956** (M4). Она обязана ответить на вопрос устройства, а не подогнать файл: правильно ли вообще считать снятие индекса сужением, если оно не меняет ни одной наблюдаемой величины — те же строки, те же ответы, только другой план. Три допустимых решения: придумать осмысленный флаг; добавить третью фазу «меняется только план исполнения»; вынести операцию из набора миграций в отдельный ранбук эксплуатации. Любое требует негативного теста, доказывающего, что гейт по-прежнему ловит настоящие contract-миграции без флага — иначе это не решение, а ослабление защиты.

### Счёт по эпику на 03:00Z

Принято и посажено — 4 (п. 1, 2, 4, 5). Принято независимой приёмкой, ждёт сборки — **1 (п. 11, с условием выбросить бенчмарк)**. Принято и вынуто из линии, чинится волной 3954 — 1 (п. 0). Отклонено автором с причиной — 5 (п. 3, 6, 8, 9, 10). Упёрлось в политику миграций, волна 3956 — 1 (п. 7).

**`Δ42 UNKNOWN` по-прежнему не снят ни разу.** Разведка ASTRA-42 идёт с 01:23Z.

[15.09 01:51Z координатор] ## 15.09 03:15Z — 🔴 ЧИСЛО, КОТОРЫМ НАЗВАН ЭТОТ ЭПИК, НЕ ЯВЛЯЕТСЯ ИЗМЕРЕНИЕМ ОДНОГО ДЕЙСТВИЯ

Разведка ASTRA-42 остановилась и отказалась выдать разбивку, назвав причину. Причина оказалась важнее самой разбивки, и я её подтверждаю.

### Откуда взялись 42 мс

Из тела этого тикета: главная нить занята **0.880–0.894 ядра** начиная с пятого пользователя; пропускная способность одного процесса **≈23.5 действия/с**. Деление даёт ≈37–42 мс процессора на действие.

То есть **42 мс — это частное от деления, среднее по всей смеси действий.** Никто и никогда не измерял, что одно открытие документа стоит 42 мс процессора.

Астра сказала это прямо: «1503/4850 open и 42 мс — только прежняя сводка; **42 мс не доказаны как стоимость одного open**». Проверила: `CAP-12/CAPACITY-MATRIX.md` чисел не содержит, `CAPACITY-SCALE-R1-REPORT.md:15–23` помечает сырые доказательства CAP-11 как **неполученные**. Найденные ею `l115o-cpu.json` относятся к микро-бенчмарку `adminApiGate.ts`, а `3899WEB656-SCENARIO.md` — это репетиция хранителя, а не наш нагрузочный сценарий.

### Почему это меняет цель эпика

Формулировка «снять 42 мс на действие» содержит непроверенное допущение: что существует одно типовое действие ценой 42 мс. Раздельные измерения времени ответа по группам (это не процессорное время, смешивать нельзя, но порядок виден) говорят об обратном:

| группа | 10 польз. | 16 польз. | 24 польз. |
|---|---:|---:|---:|
| list | 72.6 | 78.4 | 274.5 |
| open | 156.7 | 168.0 | 544.7 |
| status | 62.6 | 103.5 | 222.6 |
| retrieval | 96.0 | 134.5 | 202.0 |
| session | 86.0 | 68.4 | 163.4 |
| save_readback | 2244 | 3217.5 | 5876 |

**Между `list` и `save_readback` — три порядка.** Среднее по такой смеси не описывает ни одно реальное действие. Вполне вероятно, что «42 мс» — это тень одного дорогого действия, размазанная по всем остальным.

Если так, то и стратегия эпика другая: оптимизировать надо не «действие вообще», а назвать поимённо те действия, которые дорогие, и цель ставить по ним.

### Это тот же класс ошибки, что мы уже ловили дважды

- «потолок ≈10–12 пользователей» оказался **бюджетом прибора**, а не потолком продукта — владелец поймал;
- «чтение не замечает нагрузки» оказалось следствием того, что я публиковала медианы, а росли хвосты.

Оба раза — **оценка, опубликованная как измерение**. Здесь третий случай, и он в названии эпика.

### Что делает разведка дальше

Исполняемого стенда сейчас нет (пересобирается волной 3948), поэтому профиль снять физически негде. Задача переформулирована на два шага, которые прогона не требуют:

1. **Ответить «одно действие или разные»** по уже имеющимся числам и, если разные, сформулировать цель эпика так, как она должна звучать, назвав дорогие действия поимённо.
2. **Написать точную спецификацию оснастки** для снятия профиля: сценарий, число действий, профилировщик, окно, как считается CPU **именно главной нити** (не процессный счётчик со всеми нитями), как измеряется накладной расход самого профилировщика, как отделяется сборка мусора. Спецификация уйдёт требованием в волну 3948, чтобы профиль потом снимался одной командой.

Допустимый вердикт при таком исходе — `VERDICT=SCOPE_REFRAMED`. Это полноценный результат, а не провал.

### Попутно исправлено

Прежний бандл линии у исполнителя указывал на `c0bcab8490408e68183f0b1b7e361cff80eb95c2` — **до-откатное** состояние, где ещё жил ломающий сборку пункт 0. Отправлен правильный: `refs/lines/l115o` = `68e25d8df5ae8263c5ac5466353631f57a17cfcc`.

[15.09 02:08Z координатор] ## 15.09 04:00Z — ASTRA-42 сдала: `VERDICT=SCOPE_REFRAMED`. И поправила ДВА моих числа.

Сдача: `nc-ops-scripts/astra-42/ASTRA-42-MAP.md` + `astra-42-evidence/` (16 файлов, SHA256SUMS). База проверена: чистый корень `astra-42-l115o`, HEAD **68e25d8df**, `git show --name-only` подтверждает, что это коммит отката слияния OPT-0 и что OPT-0 обратно не вернулся. Два независимых проверяющих GPT-5.5 прогнали арифметику и исполнимость спецификации.

### 🔴 Поправка 1: не 42 мс, а 37,45–38,04 мс

| вычисление | результат | что это значит |
|---|---:|---|
| 0,880 / 23,5 × 1000 | **37,45 мс** | средняя цена смеси при нижней указанной занятости нити |
| 0,894 / 23,5 × 1000 | **38,04 мс** | то же при верхней |
| 1 / 23,5 × 1000 | 42,55 мс | обратная пропускная **целого занятого ядра** — другая формула |

То есть «42» получается, только если считать ядро занятым **полностью**, а наблюдалось 0,88–0,894. Название эпика опирается на подстановку, которой в измерениях нет.

### 🔴 Поправка 2: не «три порядка», а десятки раз

Я сказал владельцу «между list и save_readback три порядка». Неверно, и вот как я ошибся: я сравнил **p95 одной группы с p50 другой**. Так делать нельзя — это разные квантили.

Сопоставимо (p95 к p95):

| | 10 польз. | 16 | 24 |
|---|---:|---:|---:|
| save_readback / list | 30,91× | 41,04× | **21,41×** |
| максимум / минимум среди шести групп | 35,85× | 47,04× | 35,96× |

Даже некорректный приём «p95 против p50» даёт максимум 326×, а не 1000×. Вывод при этом не меняется — классы действий разные, — но число было моё и было неверное.

### Что установлено, а что нет

**Установлено:** для планирования это **шесть разных классов действий**, а не одно действие с ценой 42 мс. Гипотеза «найдём типовой open за 42 мс» не обоснована.

**НЕ установлено, и это важно:** разные времена ответа **не доказывают** разные затраты процессора. Вопрос «тысяча мелочей или несколько крупных кусков» **ответа пока не имеет** — квантили задержки не показывают стеки процессора. Более того, короткая частая операция вполне может давать больший суммарный CPU, чем длинное сохранение: секунды ожидания не обязаны быть секундами работы главной нити.

Медианы `open` 135/135/137, `list` 18/18/18, `retrieval` 18/19/18 почти не двигаются, растут только хвосты — но у `status`, `session`, `save_readback` медиан нет вовсе, распространять на них вывод нельзя. `session` p95 86 → 68,4 между 10 и 16 не монотонна: гладкую кривую по трём точкам не рисуем.

### Новая формулировка цели эпика (предложена, принимаю)

> На точной линии и фиксированном сценарии измерить mean CPU главной нити **для каждого класса действий** и его вклад в CPU всей смеси; затем снизить измеренный mean CPU смеси к целевым 10 мс на корректное действие, сохраняя корректность, состав нагрузки и согласованные пределы времени ответа каждой группы. Отдельно устранить причины длинного хвоста `save_readback`. Результат подтверждать сравнением на той же оснастке, не общим числом «42» без знаменателя.

10 мс — целевой уровень, **не обещанная достижимость**. И пересчёт «сколько машин на 1000 человек» по одной этой арифметике не делается: нужны безопасная ёмкость, смесь, частота действий и резервы.

Порядок работы после появления стенда: (1) `save_readback` — первой веткой диагностики хвоста, отделив подтверждение приёма, обработку, ожидание и проверочное чтение; (2) **все шесть групп** обязаны получить CPU-характеризацию, исключать «дешёвые» нельзя; (3) правки ранжировать только после измерений по вкладу `вес × цена`, затем по концентрации.

### Спецификация оснастки для 3948 — готова

`astra-42-evidence/ASTRA-42-3948-INSTRUMENTATION-SPEC.md` (35 КБ, нормативный документ). Ключевое: одна команда `astra42-profile --manifest … --suite full-v1`; ровно шесть групп, exact mapping «действие → HTTP» берётся из драйвера, **пустой mapping = отказ** (сценарий не выдумывается); характеризация — 200 действий на группу, 3 блока A/B/B/A, итого 14 400; смесь — 1200 действий на ступень N=10/16/24, 43 200; GC и аллокации — отдельные прогоны, 4800; **всего 62 400 измеряемых действий**; CPU главной нити через `threadCpuUsage` либо явно проверенный Linux per-TID fallback, процессный CPU отдельно; накладной расход генератора меряется своим PID с калибровкой; GC-пауза не суммируется с concurrent GC; карта — exclusive слои с `файл:строка` по точным source maps, inclusive отдельно, unresolved и знаковый баланс показываются; **нормировать всё к 42 запрещено**; работа только на переднем плане, на прерывание сохраняет сырое и выходит.

Волна 3948 сейчас строит стенд и уже близка к своему пределу времени — спецификация уходит **следующей волной поверх её сдачи**, а не вламывается в идущую.

**Статус:** принимаю как `SCOPE_REFRAMED`. Это завершение двух шагов, а не приёмка CPU-карты и не ускорение. `Δ42 UNKNOWN` остаётся, карта и топ-10 — после стенда. Код не менялся.

[15.09 02:14Z координатор] ## 15.09 04:20Z — пункт 7 РАЗБЛОКИРОВАН: волна 3956 сдала `VERDICT=GO`. И нашла, что защита миграций была подписью, а не защитой.

Дословный вердикт: «Снятие индекса — не сужение, а смена плана, поэтому политике добавлена четвёртая фаза `plan-only` с проверяемыми требованиями (обратимость, лимит блокировки, один оператор вне транзакции); гейт зелёный на ветке и по-прежнему отвергает настоящую contract-миграцию без флага».

Ветка в зеркале: `refs/waves/3956/fix/3956-migration-policy` = `3ad3a169807ca4a64015c38f13ad36dfa58ec9ad`.

### 🔴 Главная находка: из 29 contract-карточек 28 ссылаются на несуществующий рубильник

Карточка типа «сужение» обязывает объявить флаг возможности — переключатель, которым новое поведение выключается. Для удаления индекса такого переключателя **не бывает**: индекс либо есть в базе, либо его нет, приложение на это не влияет.

Поэтому в репозитории накопилась привычка: писать в поле флага имя несуществующего рубильника с припиской «attested» — «мы посмотрели, всё нормально». Волна пересчитала: **из 29 таких карточек 28 ссылаются на флаг, которого нигде в коде нет.**

**Защита превратилась в подпись.** Это третий случай того же класса за сутки: мёртвый `failClosed` в телефонии (объявлен, в решении не участвует), правило ufw на `uid 999` при стенде под `uid 1001`, и вот теперь флаг возможности, который никто не проверяет. По нашему правилу «третья находка одного класса — это устройство, а не баги» это надо разбирать как класс.

### Что сделано

Добавлена четвёртая фаза — **«меняется только план исполнения»**. Нарочно очень узкая, и всё в ней проверяет машина:

- через неё проходит **только** удаление индекса; есть в файле что-то ещё — миграция уходит обратно в «сужение»;
- удаление обязано быть щадящим (`CONCURRENTLY`);
- обязателен файл отката, и сторож **сам проверяет**, что он существует и возвращает именно тот индекс, который сняли;
- обязателен предел ожидания блокировки, не больше минуты;
- в файле **ровно одна команда** и никакого «начать транзакцию» — волна проверила на живой базе: вторая команда роняет миграцию с «щадящее удаление нельзя внутри транзакции», причём грязно, застревая в истории и требуя ручного вмешательства;
- **объявлять рубильник запрещено** — раз его не может существовать, незачем писать имя, которое никто не прочтёт.

Старые карточки не переписывали: что уехало — уехало, новое правило для следующего удаления индекса.

### Остаток по пункту 7

Правка Астры теперь может пройти гейт. Нужна сборка следующей линии с ней и с пунктом 11 (у которого условие: **выбросить `tests/astra-opt-11.measure.mjs`**, он падает по умолчанию). Сам гейт на ветке зелёный и негативный случай проверен — настоящая contract-миграция без флага по-прежнему отвергается.

[15.09 02:30Z координатор] ## 15.09 05:25Z — ASTRA-42 сдала карту драйвера: `VERDICT=DRIVER_MAPPED`. Четыре поправки, две из них меняют план.

Сдача: `nc-ops-scripts/astra-42/ASTRA-42-DRIVER-MAP.md`. Драйвер — `scripts/capacity/harness/` в `refs/lines/l115o`.

### 🔴 Поправка 1: групп ВОСЕМЬ, а не шесть. Я пропустила `realtime`.

В драйвере восемь групп; после `CAP06_EXCLUDE_GROUPS=upload_index` остаётся **семь**, включая `realtime`, которого не было ни в моём перечне, ни в таблице времён ответа. Это не новая группа «на подумать» — она уже в расписании и в HTTP-сценарии.

### 🔴 Поправка 2, меняющая план: `save_readback` выполняется ОДИН РАЗ НА VU

Номинальная смесь после исключения upload — `session/list/open/retrieval/save/status/realtime` = **5/16/26/21/16/11/5%**. Но сохранение разрешено **один раз на VU**, и дальше его слоты заменяются другой группой. В полном последующем цикле смесь становится **5/16/26/21/0/27/5%**.

**Это отменяет мой собственный план.** Я записала «`save_readback` — первая ветка диагностики хвоста», потому что у него p95 = 2244 мс. Но вклад группы в смесь считается как `вес × цена`, а вес сохранения в длинном прогоне стремится к нулю: один раз на пользователя и больше никогда. Значит по вкладу вперёд выходит `status` (27%) и `open` (26%), а не сохранение.

Сохранение по-прежнему стоит разбирать — но **отдельным диагностическим сценарием со своей приёмкой**, а не как часть базовой смеси. Для повторных сохранений нужен отдельный драйвер, наблюдающий свежие координаты CAS; требование «прогреть и сделать ещё 200 сохранений на тех же VU» несостоятельно по устройству.

### 🔴 Поправка 3: `open` в харнессе — это НЕ открытие документа в браузере

`open` = `GET /api/sources/{sourceId}/text` с `Accept: text/plain`, одно обращение. Никакого React, ассетов и интерфейса. То есть «open p50 135 мс» — это **время получения текста**, а не то, что переживает человек, открывая документ. Сравнивать это с ощущением пользователя нельзя.

Для полноты, что делает каждая группа (прочитано в коде, HTTP-прогоном не проверено):

| группа | что на самом деле | обращений |
|---|---|---|
| session | с пулом `GET /api/auth/session`; без пула — csrf → callback → session → age-affirmation → session | 1 либо 5 |
| list | `GET /api/notebooks/{id}/sources?limit=80` | 1 |
| open | `GET /api/sources/{id}/text` | 1 |
| retrieval | `POST /api/sources/text-search`, `{query, sourceIds:[id], limit:20}` | 1 |
| save_readback | Server Action `POST` с текстом **2 МиБ**, затем `GET /api/sources/{id}` | 2 |
| status | `GET /api/ingest/status?ids={id}` | 1 |
| realtime | `POST session-start` → `session-turn` → `session-end` (+ локальный reopen, если комната) | 3 продуктовых |
| upload_index | upload → N× PUT → complete → P× status → receipt | **N+P+3**, минимум 12 |

Плюс перед каждой группой, кроме session, отрабатывает `ensureAuthenticated`: 0 обращений при готовой сессии, 1 при входе через пул, до 5 без пула. Они входят в счётчик той же попытки.

### 🔴 Поправка 4: профиль `arrival` драйвером ОТВЕРГАЕТСЯ

Setup точного драйвера разрешает только `t0` и `t1`. А наш «честный замер» 14.09 подписан `CAP_PROFILE=arrival`. Либо он шёл на другой версии драйвера, либо профиль применялся мимо setup. **Это надо выяснить до того, как мы объявим новый прогон «тем же самым».**

Туда же: `scripts/capacity/approved-source.mjs:9` пришпиливает harness к коммиту **`e1f6cb526d946af339c213ea77eb26c8d77594d2`** (это волна 3516), а не к прод-коммиту. Штатное переутверждение описано в `docs/capacity/harness/APPROVED-COMMIT.md:19` и требует регенерации manifest/action metadata и preflight — **менять подпись входного манифеста нельзя**.

### Знаменатель 23,5/с — по-прежнему UNKNOWN

Единица бизнес-счётчика — **попытка одной выбранной группы за итерацию k6**, внутри от одного до многих HTTP. Но какое именно поле дало исторические 23,5/с и совпадает ли его окно с 0,880–0,894 ядра — из доставленных материалов не установлено. Отдельно: `cap_business_completion_rate` и `goodput_rate` — это **доля успеха 0..1, а не операций в секунду**; спутать их легко.

Формула остаётся условно верной: `(0,880…0,894)/23,5 × 1000 = 37,45…38,04 мс`, но она не назначает эту цену ни `open`, ни `save`, ни одному HTTP — включает фон, GC и прочую работу нити в окне.

### Цена генератора — ранжирована по местам

Первое место: на инициализацию **каждого** VU приходится **≥6 МиБ проходов кодирования UTF-8** (длина текста кодируется, затем `validateSaveBootstrap` кодирует его ещё раз плюс текст сохранения) и **4 МиБ SHA-256**. При 25 VU это ≥150 МиБ кодирования и 100 МиБ хэширования. Это арифметика байтов, не миллисекунды — множитель к ядрам неизвестен.

Обязательное для замера: **отдельные метрики процессов** для k6, сеятеля, демона комнатного звука, главной нити Node, остальных нитей Node, базы и фоновых воркеров. **GC генератора нельзя складывать с GC приложения.**

### Спецификация v2

`astra-42-evidence/ASTRA-42-3948-INSTRUMENTATION-SPEC.md` обновлена: матрица v1 из 62 400 действий **на нынешнем драйвере нереализуема** (из-за одноразового сохранения) и отменена. Воспроизведение `t1` отделено от отдельного диагностического сценария повторных сохранений.

[15.09 02:51Z координатор] ## 15.09 06:40Z — 🔴🔴 ПРОВЕРКА ИСТОРИЧЕСКИХ ПРОГОНОВ: `VERDICT=HISTORICAL_CLAIMS_UNVERIFIED`. НИ ОДНО из шести опубликованных чисел не подтверждается сырьём.

Привезла на M1 всё первичное, что нашлось на A2 — 40 файлов, 20 сводок k6 и 16 потоков вывода за 10–15.09 — и попросила проверить, что из наших опубликованных чисел подтверждается. Результат: **0 из 6**, и вложенная таблица p95 — **0 из 18**.

Разобрано **6439 числовых полей JSON**, каждое с точным путём и номером строки; отдельно проверены 627 полей `rate` и 100 полей `offered/started/completed/goodput/iterations` по 20 сводкам.

| наше опубликованное число | что на самом деле в файлах | подтверждено? |
|---|---|---|
| **440/440 успешных действий** | `440 complete and 0 interrupted iterations` — это **промежуточная строка прогресса** на 3м33.8с. **Финал того же прогона: 460 итераций, offered 460, completed 389.** Единственная JSON-величина ровно 440 — `http_req_failed.fails` в другом прогоне | **НЕТ** |
| **общая p50 24 мс** | 24 — это медиана **группы `status`** в одном прогоне (общая business-медиана там **125**); в другом — медиана HTTP waiting (общая business-медиана **31.5**) | **НЕТ** |
| **`open` p50 135 мс** (135/135/137) | Ни одна `cap_business_latency_ms{group:open}.med` не равна 135. В smoke10c она **153**, в n24 — **1229.5**. Созвучное 135.97 — это `http_req_duration p95`, совсем другая метрика | **НЕТ** |
| **таблица p95 по группам на 10/16/24** | **0 из 18** совпадений среди всех 20 сводок, даже без требования совпадения VU. **Сводок с maxVU=16 нет вообще** — у колонки «16 пользователей» источника нет | **НЕТ** |
| **0,880–0,894 ядра главной нити** | В пакете **нет ни одного CPU/TID-замера**, ни счётчиков user/system, ни окна START/END. Найденное `0.88` — доля goodput 22/25; `0.8824` — `business_errors{status}` | **НЕТ** |
| **23,5 действия/с** | Среди 627 полей `rate` нет значения, округляющегося до 23.5. **Максимальный business/iterations rate во всём пакете — 15.78/с.** «23.5» в выводе встречается как **отметка времени прогресса `3m23.5s/5m0s`** | **НЕТ** |

### 🔴 И вот откуда взялось 23,5 — это круг

В исходном `ASTRA-CAPACITY-1000-BRIEF.md:13` **≈23,5/с прямо названо последовательным пределом, ВЫВЕДЕННЫМ из ≈42 мс**; наибольшая измеренная там пропускная указана отдельно — **20.123/с**.

Дальше в моём же дополнении 23,5 уже подано как измеренная пропускная, и на него поделена занятость нити, чтобы получить 37,45–38,04 мс — «уточнение» тех самых 42.

**То есть мы оценили 23,5 из 42, а потом из 23,5 «вывели» 37–38 и назвали это измерением того же 42.** Круг. Арифметика `1/0.042 ≈ 23.81`, а не 23.5, дополнительно показывает приблизительность исходной записи.

Это объясняет, почему поле со значением 23,5 не нашлось нигде: **его никогда и не измеряли.**

### Про профиль `arrival`

Во всех 40 файлах **нет ни одного упоминания** `arrival`, `ramping-arrival-rate`, `constant-arrival-rate`. У всех 14 потоков с объявленным сценарием стоит **`looping VUs`** — постоянное число VU и длительность, то есть закрытый контур. Наиболее совместимое объяснение: `arrival` был **подписью координатора**, а исполнялся t0/t1 — но причинно это не доказано, и семь сводок без потоков вывода остаются UNKNOWN.

Значит и рамка «открытый контур», в которой публиковался честный замер, сырьём не подтверждается.

### Честная граница этого вывода

Это **не** доказательство, что таких результатов никогда не было. Это доказательство их отсутствия **в конкретных доставленных файлах**. Непрерывного временного ряда в пакете нет — только финальные агрегаты и прогресс; мгновенное 23,5/с в недоставленном трейсе не исключено. Восстанавливать неизвестное окно так, чтобы `count/time` дал нужное число, **нельзя**.

### Что нужно принести, чтобы закрыть вопрос (без новых прогонов)

1. **Файл-источник опубликованного прогона 14.09** — тот, где ОДНОВРЕМЕННО записаны 440/440, p50 24, open 135 и p95 10/16/24, плюс соответствующие сводки и потоки. Привезённые 20 сводок — не он.
2. **Для 23,5** — либо путь счётчика с count/rate/окном, либо формула оценки **с пометкой «оценка»**.
3. **Артефакт CPU** с PID/main TID, user/system, окном START/END и способом получения 0,880/0,894, привязанный к конкретному прогону.
4. **Для `arrival`** — фактическая команда и окружение без секретов, опции исполнителя и SHA запускавшегося `k6-script.js`.

**До этого опубликованные числа нельзя использовать как подтверждённую основу** ни для разложения CPU, ни для расчёта на 1000 пользователей. Карта драйвера остаётся в силе; но приоритет `status`/`open` по фактической смеси надо подтверждать счётчиками и профилем, а не объявлять самой смесью.

Сдача: `nc-ops-scripts/astra-42/ASTRA-42-RUNS-AUDIT.md` + `astra-42-runs-evidence/` (анализатор, 6439 числовых полей с путями, таблица 20 прогонов, реестр входов с SHA256).

[15.09 02:56Z координатор] ## 15.09 07:00Z — 🔴 ПОПРАВКА К ПРЕДЫДУЩЕЙ ЗАПИСИ: источник найден, `arrival` был настоящим. Ошибка была моя, в сборе пакета.

В записи 06:40 стоит: «во всех 40 файлах нет упоминания `arrival`; у всех потоков — `looping VUs`, то есть закрытый контур; рамка открытого контура сырьём не подтверждается».

**Это верно про те 40 файлов и неверно про реальность.** Искомые прогоны существуют — я их не привезла.

`/home/ubuntu/waves/3714LADDERR3-evidence/` на A2 — **401 файл, 6.3 МБ**, ladder round 3 волны 3714. Там `k6-arr10a-*`, `k6-arr16a-*`, `k6-arr16b-*`, `k6-arr24a-*`, `k6-arr75a-*`: сводки, потоки вывода, логи объединения и демона, счётчики ограничения входа.

Первая же строка потока:

```
scenarios: (100.00%) 1 scenario, 10 max VUs, 7m20s max duration (incl. graceful stop)
time="2026-09-14T06:21:34Z" level=warning
  msg="Insufficient VUs, reached 10 active VUs and cannot initialize more"
  executor=ramping-arrival-rate scenario=cap06
```

**`executor=ramping-arrival-rate` — профиль `arrival` был настоящим.** Утверждение «рамка открытого контура не подтверждается» снимаю.

### Почему я собрала неполный пакет

Фильтр был: файлы новее 10.09 с именами `*summary*.json` и `k6-*stdout.log`, глубина 2. Каталог 3714 под него не попал. **Отрицательный вывод по неполному пакету я подала как полный** — и исполнитель, честно проверив 6439 полей, сделал из него вывод о реальности.

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

### Что остаётся в силе из записи 06:40

Разбор шести чисел **по тому пакету** верен; проверка перезапущена по найденному каталогу. Круг «23,5 выведено из 42 → потом из 23,5 выведено 37–38» **остаётся в силе** — он установлен по тексту исходного разбора, а не по сводкам, и найденные файлы его не отменяют.

### Новое, что видно сразу и может оказаться важнее всего

Предупреждение `Insufficient VUs, reached 10 active VUs and cannot initialize more`. Исполнитель `ramping-arrival-rate` задаёт **темп прибытия**, а не число пользователей; при нехватке VU часть запланированных итераций не стартует и попадает в `dropped_iterations`. Значит вопрос: **успешность 440/440 считалась от запланированного или от фактически стартовавшего?** Разбор поставлен.

[15.09 03:07Z координатор] ## 15.09 07:55Z — перепроверка по найденному источнику: `VERDICT=PARTIAL_CONFIRMED`. Четыре числа из шести подтвердились, два остались выдумкой. И вскрылась выборка лучшего повтора.

Сдача: `nc-ops-scripts/astra-42/ASTRA-42-LADDER-R3-AUDIT.md`. Исследован **весь каталог 401 файла**, а не только пять сводок.

### Что подтвердилось — с точным источником

| число | источник | оговорка |
|---|---|---|
| **440/440** | `k6-arr10a-summary.json:244` offered 440, `:455` completed 440, `summary-arr10a.md:1` completion 100.00% | 🔴 **но 160 итераций исполнитель НЕ НАЧАЛ**. В учтённом потоке прибытия это **440/600 = 73,33%** |
| **p50 24 мс** | `k6-arr10a-summary.json:630` med=24; `k6-arr16b-summary.json:13` med=24 | у `arr16a` общая med **134**, у `arr24a` — 25 |
| **open 135/135/137** | `arr10a:467`, `arr16b:103`, `arr24a:194` | строго эта тройка; у `arr16a` open med **139** |
| **таблица p95, 18 ячеек** | `arr10a` / **`arr16b`** / `arr24a` | **18/18 совпали** с точностью публикации |

Так что латентностные числа настоящие и источник у них есть. Это снимает часть вчерашнего вывода.

### 🔴 Но колонка «16 пользователей» — это выбор лучшего из двух повторов

Повторов на 16 VU было **два**, и они расходятся в разы:

| группа | `arr16a` (первый повтор) | **`arr16b` (опубликован)** |
|---|---:|---:|
| list | 287.70 | **78.40** |
| open | 628.40 | **168.00** |
| status | 525.25 | **103.50** |
| retrieval | 384.00 | **134.50** |
| session | 357.70 | **68.40** |

Опубликован **b**. Не агрегат двух, не худший, не оба — лучший. Я не знаю, было ли это осознанным выбором или «взял последний файл», но по факту **в публикацию попал благоприятный повтор, а неблагоприятный остался в каталоге**.

И успешность прибытия по 16 VU: **43,33% у `a` и 92,67% у `b`**. Все пять arr-прогонов нарушили порог `dropped_iterations`.

### 🔴 Два числа по-прежнему выдуманы

**23,5 действия/с — нет.** Среди **1048 полей rate во всех 41 сводке** нет значения, округляющегося до 23.5. Реальные business rates этих прогонов:

```
arr10a 2.232570/с   arr16a 1.317016/с   arr16b 2.971923/с   arr24a 4.135925/с   arr75a 0
```

Максимум completed/goodput во всём корпусе — **18.79/с**, и это другая серия. А ровно 23.5 нашлось как **`status med` в миллисекундах** (`k6-arr24a-summary.json:104`).

⚠️ **Что это значит для арифметики эпика.** Мы делили занятость нити на 23,5 и получали 37–38 мс на действие. Если настоящая пропускная этих прогонов 1,3–4,1 действия/с, то то же деление даёт **сотни миллисекунд**, а не десятки. Знаменатели могут быть несопоставимы (записанные бизнес-попытки против чего-то другого) — **именно поэтому вопрос надо закрыть источником, а не подставить новое число вместо старого.** Порядок расхождения — шестикратный минимум.

**0,880–0,894 ядра — нет для главной нити.** Ресурсные артефакты в каталоге **есть** (`resource-samples-arr10a.log:5` — PID/%CPU/RSS, `:21` — счётчики хоста по ядрам), но **в них нет главного TID и его приращений CPU**. Процессные и машинные сведения подтверждены; CPU именно главной нити и его совместное с пропускной окно — UNKNOWN.

### Про `arrival` — подтверждено окончательно

`k6-arr10a-stdout.log:82` — прямая запись `executor` с предупреждением о 10 занятых VU. Исторический `ramping-arrival-rate` **был реально исполнен**. Ограничение setup в дереве `68e25d8df` этих исторических данных не отменяет.

### Что теперь обязательно

1. **Публиковать успешность только с двумя числами**: записанные попытки и прибытие. «100%» без `dropped_iterations` скрывает треть результата.
2. **Повторы публиковать все.** Если повторов два и они расходятся втрое — публикуется либо оба, либо худший, либо агрегат с указанием разброса. Один благоприятный — нельзя.
3. **23,5 закрыть источником или пометить оценкой** и пересчитать всё, что на нём стоит.
4. **CPU главной нити** — отдельный артефакт с TID и окном; без него формула не собирается.

[15.09 11:16Z координатор] [15.09 11:16Z координатор] 3977 M1/Astra завершила ограниченный архитектурный проход: VERDICT=NEEDS_INPUT, не GO и не измерение ёмкости.

Проверено: входы 9/9, сдача 86/86, source blobs 71/71, report SHA256 e6b0d9395c188c4a54081a41af5a6eeda7e434679b1f9f3c3ac3e669e7a34650. Код, build, нагрузка, БД, production и доска не менялись.

Рекомендация: несколько отдельных systemd web PID за Nginx, но первая ступень маршрутизирует на read pool только точную allowlist GET-маршрутов; realtime/voice, mutations, control и фоновые side effects остаются у одного owner. Произвольное 50/50 всего продукта запрещено.

Недостающие первичные systemd/Nginx входы уже сняты координатором с A1 в очищенном виде, без значений env/secrets. Поэтому владельца не блокируем вопросом. Запущена первая узкая задача 3983 на M4/Luna: CAP-08, один main Prisma client на PID через реальные bundles, browser boundary, constructor census и обязательный bounded production build. Затем по порядку L2 boot isolation, L3 drain, L4 disposable topology, L5 честный 1/2-process experiment.

До L5 старые 23.5 действий/с, 42 мс, 0.880–0.894 ядра и таблица 10/16/24 VU остаются UNKNOWN; из них нельзя считать число процессов или клиентов. WEB-660 остаётся in_progress.

[15.09 12:20Z координатор] Независимая build-приёмка 3990: VERDICT=NO-GO для полной production-дорожки, но direct Next artifact собран успешно.

`pnpm exec next build --webpack` на exact candidate `dc0ea3f1b707574817e81cd120bcf0e1b008816b` завершился exit 0 за 500 секунд на M4Ext; есть 383/383 static pages, финальный route output и `.next/standalone/server.js`. Focused 7/7, browser boundary 4/4, scoped TypeScript и built static checker зелёные. Evidence 28/28 SHA256.

Полный `pnpm build` остановился ДО Next на baseline activation migration-set drift: три принятые migration отсутствуют в старом generated receipt. Это не regression Prisma candidate. Отдельная авторская 3998 уже подготовила candidate `fa7004f4c3ae26871e340592a1e886fd988c931a`; идёт независимая приёмка 4002. CPU/goodput остаются UNMEASURED, тикет остаётся in_progress.

[15.09 12:40Z координатор] [15.09 12:40Z координатор] Общий activation blocker, остановивший полный build WEB-660 L1, независимо починен и принят волной 4002.

Candidate `fa7004f4…` проходит exact set на 204 migrations; четыре red controls сохраняют fail-closed. WEB-667 добавляет 205-ю migration, поэтому старый receipt не переносится напрямую: 4008 сейчас интегрирует семь heads и регенерирует derived receipts на финальном дереве.

Это снимает общий prebuild blocker только на уровне принятого source-входа. WEB-660 L1 `dc0ea3f…` в 4008 не входит; CPU/goodput всё ещё UNMEASURED. После integration GO нужен полный build объединённой линии, затем отдельное решение о включении process-singleton candidate и равнобюджетный 1/2-process опыт.

[15.09 14:43Z координатор] Reconciliation A2/4047 завершена: DECISION=USE_WEB635, report+marker и 6/6 SHA256 проверены. WEB-660 head `dc0ea3f1…` не несёт production semantic delta относительно уже независимо принятого WEB-635 `0f356f28…`, но удаляет его hot-reload/test-reset regression и scoped tsconfig; отдельный merge/cherry-pick WEB-660 запрещён. 3990 build receipt остаётся source-equivalent только для byte-identical production paths. Общий blocker полного build — activation migration-set drift; WEB-660 как эпик остаётся in_progress до чистой интеграции, полного build/runtime и оставшихся критериев.

[15.09 14:54Z координатор] 4030 independent acceptance on M4: GO for the reproducible activation generator in the next integrated line, evidence SHA 23/23. Candidate c5d6375ab4e70469b38fa1b690bea1322ee654e8 produces byte-identical source-only outputs across repeated runs, rejects 8/8 bad release-input cases without mutation, passes the real release verifier only for a release-form signed receipt, rejects source-only as a trusted release attestation, and rolls back atomically on a forced replacement fault. This clears the activation-generator blocker but is not a build, capacity result, landing, or production post-QA.

[19.09 18:51Z координатор] ✅ Сдача 4311 (A1) = `VERDICT=GO` — прямой ответ на задачу «использовать ядра и держать больше людей».

**Короткий ответ: на 4-ядерной машине осмысленно 3 процесса приложения** — три ядра под три JS-главных потока, четвёртое остаётся Postgres, nginx и таймерным воркерам. При базе на отдельном хосте — 4.

**Три вещи, которые меняют постановку:**

1. **Вход на несколько бэкендов уже существует и работает.** На A1 сегодня два веб-процесса за одним nginx (`nc-a1` :3010, `nc-a1-b` :3012) с активным контроллером апстрима, который опрашивает `/api/ready` каждого бэкенда и публикует `upstream { ip_hash; … }` (`infra/nginx/bin/nc-upstream-controller:7-12`). Готовый vhost на N бэкендов с Socket.IO-upgrade, небуферизованным SSE и пробросом `Last-Event-ID` лежит в `docs/operator/WEB093-P23-TWO-BACKENDS.md`. Проектировать заново не надо.

2. 🔴 **Главное препятствие — не «нет кластера», а ровно наоборот: в продукте есть аренда, которая ЗАПРЕЩАЕТ второму процессу работать.** `ActivePassiveLease` допускает ровно один слот; **40 файлов маршрутов** оборачивают обработчик в `withActivePassiveLease`, и на не-держателе каждый отдаёт `HTTP 503 active_passive_lease_denied`. Второй процесс сегодня не ломается — он отказывает. Пара A/B — это active/**passive**, а не два рабочих. Хорошая новость про безопасность, плохая про ёмкость.

3. **Второй слой — состояние в памяти процесса**, и оно делится на две разные кучи: то, что станет **N-кратным** (лимиты и счётчики расхода — 72 места вызова одного лимитера) — это деньги и безопасность; и то, что станет **невидимым** (потоки, SSE, колоды, warmup-конвейеры) — это 404 у пользователя.

**Сводка по 51 строке разбора:** блокирует — **9**, чинится — **21**, не мешает — **20**.

Девять блокирующих названы поимённо: аренда; slot id по PID; исходящие звонки; колоды; SSE видео; Socket.IO polling без липкости; podcast warmup; шлюз пула отказывает в старте; пара A/B как active/passive. Полная таблица с колонками «что именно происходит» и «чем чинить» — `4311MULTIPROC-evidence/obstacles.md` на A1.

**Поставлен шаг 1 (волна 4314):** разделить 40 маршрутов по тому, **что делает обработчик**, а не по имени — на те, где аренда защищает единственность владельца побочного действия (деньги, идентификаторы, исходящие звонки, фоновые задания), и те, где она стоит просто потому, что обёртка была под рукой. Сузить аренду до первых. Доказать двумя процессами против одной базы: маршрут второй группы отвечает 200 на обоих, маршрут первой на не-держателе по-прежнему 503 (красный контроль обязан остаться красным), побочное действие при одновременном запуске выполняется ровно один раз — выборкой из базы, не логом. Снятие аренды со всех сорока без разбора объявлено `NO-GO` по построению: это снимает защиту денег ради ёмкости.

[19.09 19:36Z координатор] ✅ Сдача 4314 (A1) = `VERDICT=GO` — **два процесса обслуживают запросы одновременно**, доказано на настоящем PostgreSQL 16.

Из 40 файлов маршрутов, обёрнутых в `withActivePassiveLease`, **8** отнесены к группе (б) — обработчик либо только читает, либо пишет идемпотентно под собственным ключом. Три из них (`session-start/turn/end`) уже освободила волна WEB-659; **пять освобождены здесь**. Остальные **32** остаются в группе (а): у них есть побочное действие, которому нужен ровно один владелец-процесс.

**Ось разбора оказалась не той, что я задала в брифе, и волна это объяснила.** Вопрос не «нужна ли тут аренда», а **чья именно единственность защищается**. `withActivePassiveLease` уже имеет два режима, и оба ходят в базу (`src/lib/activePassiveLease.ts:274-278`): чужой `ownerId` отвергается в обоих, а при `sharedOwner` строка сохраняет `slotId`/`token`/`generation` держателя — durable fencing token **не проворачивается**. То есть для части маршрутов достаточно «жива ровно одна физическая копия», а не «ровно один процесс».

**Проверено двумя живыми процессами против одной базы:**
- маршруты группы (б) отвечают **200 на обоих** процессах;
- маршруты группы (а) на не-держателе **по-прежнему 503** — красный контроль остался красным;
- побочное действие группы (а), запущенное на обоих процессах одновременно, выполнилось **ровно один раз**;
- фоновое задание при подъёме процесса выполнилось один раз, **в том числе при одновременном старте**.

Ветка и доказательства: `4314TWOPROC-evidence/` на A1 (логи обоих процессов, выборки из базы, красные контроли, точечный tsc). Материал 4311 проверен перед работой: `sha256sum -c` → 16/16 OK.

Напомню контекст из 4311: вход на несколько бэкендов уже существует и работает (два процесса за одним nginx с контроллером, опрашивающим `/api/ready` каждого), а на 4-ядерной машине осмысленно 3 процесса приложения — четвёртое ядро нужно Postgres, nginx и таймерным воркерам.

[19.09 21:06Z координатор] 🔴 Независимая приёмка 4323 (A1, маршрут codex) = **`VERDICT=REWORK`**. Приёмщик поднял **три** реальных процесса против одной базы сам, как требовал бриф.

**Пять починок автора подтверждены собственными прогонами приёмщика:**

| пункт | до | после |
|---|---|---|
| A2 идентичность слота | `process-PID`; после перезапуска другой PID и 503 | `port-39301`; после перезапуска тот же id, аренда 200 |
| B6 колоды | deck A → B/C: 404 | A → B: `c1,c2`, C: `c3,c4` |
| C1 SSE | чужой поток отдал только hello, шагов нет | на B пришли steps `1,2,3`; cross-process `1..5`, resume на C `3,4` |
| C2 липкость | старый контроллер принимал `least_conn` при требуемой липкости, exit 0 | три backend + `ip_hash`; `least_conn` и round-robin отказаны exit 2 |
| F1 шлюз пула | over-budget отказ | green: demand 37 ≤ budget 67; over-budget fail-closed exit 78, demand 106 > 67 |

Красные контроли на месте: аренда `200/503/503`, me-bridge `201/503/503`, ровно одна строка `MeBridgeRequest`; boot job при последовательном и одновременном старте трёх процессов — **ровно одна строка**.

## Почему REWORK: «названная цена» оказалась видимой пользователю

**B5 — телефония.** Прогон приёмщика:
```
POST /api/telephony/v1/lease              holder=200, non-holder=503, 503
POST /api/telephony/v1/me-bridge/enqueue  holder=201, non-holder=503, 503
error.code=active_passive_lease_denied
```
Это обычный пользовательский запрос, попавший не на тот процесс. И хуже: проверка C2 показывает в upstream **все три** backend, то есть попадание именно на держателя ничем не гарантировано. Цена такого закрепления — видимый 503, а не «ограничение ёмкости».

**C3 — podcast warmup.** Три процесса дают три разных ответа на один вопрос:
```
A: 200 state=live    progress=1        done=true
B: 200 state=warming progress=0.000125 done=false
C: 200 state=warming progress=0        done=false
```
`STUDIO_PRESENCE_REDIS_URL` выключен, warmup держит таймеры и запись в памяти процесса. Пользователь видит не ошибку, а **неверный ответ** — это хуже 503.

## Поставлено

Волна **4325**: B5 — довести запрос до держателя (маршрутизация у входа, проксирование внутри приложения, или разделение маршрута на «читать всем» / «владеет один»), при этом **не ослабляя саму аренду**; C3 — сделать ответ одинаковым на всех трёх процессах (общее хранилище состояния либо закрепление комнаты, причём закрепление обязано пережить перезапуск процесса, иначе это та же поломка с отсрочкой). Доказательство — на трёх процессах: одинаковый успешный ответ с каждого, исходящее действие ровно один раз по выборке из базы, одинаковые `state`/`progress`/`done`. Вариант «оставить как есть, это цена» объявлен неприемлемым — он уже отклонён приёмкой.

[20.09 13:18Z координатор] [CAP-06/WEB-660 — ответ владельцу: оптимизация Astra НА БОЮ СТОИТ; живой снимок прода 20.09 13:11Z; ip_hash меняет постановку замера]

ОТВЕТ НА ВОПРОС ВЛАДЕЛЬЦА: оптимизация Astra НА БОЮ СТОИТ. Снят живой снимок прода 20.09 13:11Z, только чтением, ничего не менялось и не перезапускалось.

Владелец спросил голосом 11:25: «вы же делали оптимизацию, которую написал вам когда-то Astra, чтобы использовать все ядра, потому что работали в одном потоке... Сейчас уже была полная нагрузка на машину или нет? Или вы до сих пор не интегрировали эту оптимизацию и до сих пор используете там один поток?»

ФАКТ 1 — ДВА ПРОЦЕССА ПРИЛОЖЕНИЯ РАБОТАЮТ. `nc-a1` слушает `127.0.0.1:3010`, `nc-a1-b` слушает `127.0.0.1:3012`, оба `next-server v16.2.11`, оба active/running, аптайм обоих четверо суток тринадцать часов. RSS 550 МБ и 475 МБ. MainPID 3888834 и 3889897. Это уже НЕ один поток.

Процессы различаются ТОЛЬКО двумя вещами: значением PORT и составом drop-in. Один и тот же ExecStart `/home/ubuntu/prod/shared/run/l115q-cc278e18/enforce-start-l115q.sh`, один и тот же каталог релиза `arm64-l115q-20260915T230431Z`, один и тот же NC_RELEASE_ID `cc278e1810e1e03ac277b8e3a5fe06a2aebfba30`.

ФАКТ 2 — БАЛАНСИРОВЩИК НАСТРОЕН И ОБА ПОРТА В ЖИВОМ UPSTREAM, не только в справочном файле:
```
upstream nc_backend {
    ip_hash;
    server 127.0.0.1:3010 max_fails=2 fail_timeout=5s;
    server 127.0.0.1:3012 max_fails=2 fail_timeout=5s;
    keepalive 32;
}
```
Хосты `app.sixbyy.com` и `nb.wool2.online` идут в `nc_backend`, то есть на обе копии. А вот `sixbyy.com` и `www.sixbyy.com` идут НАПРЯМУЮ в `127.0.0.1:3010`, мимо upstream — эта часть трафика вторую копию не использует вовсе. Контроллер upstream `nc-upstream-controller` сам по себе inactive, но его таймер будит его КАЖДЫЕ 5 СЕКУНД.

ФАКТ 3 — МЕТОД БАЛАНСИРОВКИ `ip_hash`, И ЭТО МЕНЯЕТ ПОСТАНОВКУ ЗАМЕРА. `ip_hash` раскладывает запросы по хэшу IP клиента. У генератора нагрузки ОДИН IP. Значит прямолинейная схема «k6 с одной машины через nginx» посадила бы ВЕСЬ поток на ОДНУ копию из двух — и мы измерили бы однопроцессную конфигурацию, будучи уверены, что меряем двухпроцессную. Рядом в конфигурации стоит пометка WEB-564 этап B: реальный IP берётся из заголовков Cloudflare, `ip_hash` обязан ключеваться по настоящему клиенту, а не по краю CF. Волне 4392 поставлено выбрать вариант и назвать цену, со строкой `IP_HASH_DECISION=`.

ФАКТ 4 — ЛОВУШКА, КОТОРУЮ ВИДНО В СНИМКЕ. `APP_ALLOWED_HOSTS` у ОБОИХ юнитов перечисляет `nb.wool2.online`, `127.0.0.1:3010`, `localhost:3010`. Порт 3012 там НЕ упомянут. Если перенести это на стенд буквально, вторая копия начнёт отвечать отказом по Host, и получится то же однопроцессное измерение с иллюзией двух процессов.

ФАКТ 5 — ВТОРОЕ НАБЛЮДЕНИЕ, ТРЕБУЮЩЕЕ ПРОВЕРКИ. Drop-in `30-backend-name.conf` у ОБОИХ юнитов задаёт `NC_UPSTREAM_BACKEND_NAME=nc-a1`, то есть копия B называет себя именем A. Может быть задумано (общее имя бэкенда для контроллера), может быть недосмотр. Не гадаю — поставил вопрос волне.

ФАКТ 6 — БЮДЖЕТ ПОДКЛЮЧЕНИЙ К БАЗЕ РАССЧИТАН НА ДВЕ КОПИИ. Файл `db-pool-budget.env`: `DB_POOL_APPLICATION_BUDGET=77`, `WEB_DB_POOL_LIMIT=15` на копию, `DB_POOL_GATE_WEB_PROCESSES=2`, `WORKER_DB_POOL_LIMIT=3` при `DB_POOL_GATE_WORKER_PROCESSES=4`. В шапке записано происхождение: `max_connections=100` минус `superuser_reserved_connections=3` = 97, минус 20% операционного резерва = 77.

ФАКТ 7 — ОТВЕТ НА «БЫЛА ЛИ ПОЛНАЯ НАГРУЗКА НА МАШИНУ». Машина четырёхъядерная (`nproc`=4). В момент снимка, в обычный воскресный полдень, БЕЗ какого-либо нашего замера: `up 9 days, load average: 2.21, 1.76, 1.20`. То есть прод сам по себе уже несёт нагрузку около 2.2 — половину своих ядер. Полной нагрузки в замере 4377 мы не достигали и достичь не могли: там стенд был однопроцессный, а загрузка самой цели не измерялась ВООБЩЕ — в сыром каталоге замера есть `generator-cpu.log`, `k6-output.log`, `tunnel-monitor.log` и ни одной строки про процессор испытуемой машины.

ФАКТ 8 — РАБОТНИКИ. Все десять `nc-a1-*` заданий периодические, постоянно висящих нет: indexing (в момент снимка РАБОТАЛ), extraction, tasks, realtime-reap, spend-reconcile, scheduled-posts, webhook-inbox-retry, metrics-alerts, beta-authorization-reconcile, upstream-controller. Они ходят по тем же четырём ядрам. Стенд без них будет оптимистичнее боя.

ЧЕСТНЫЙ ИТОГ ПО ЭПИКУ. Оптимизация интегрирована и живёт на бою. Но ИЗМЕРЕНИЯ её эффекта у нас нет: замер 4377 шёл на одной копии, а значит пять его зелёных p50 (`session` 188 мс, `list` 482.5, `open` 1515, `retrieval` 488, `status` 334) — это однопроцессная историческая точка отсчёта, и умножать её на два НЕЛЬЗЯ. Это записано отдельным файлом приёмки `what-to-do-with-old-numbers.md`.

[20.09 16:03Z координатор] [ответ владельцу про 4 ядра: разделения нет, ничего не прижато; узкое место — главный поток JS, поэтому важно ЧИСЛО КОПИЙ; плюс где какой стенд лежит]

ОТВЕТ НА ВОПРОС ВЛАДЕЛЬЦА ПРО ЧЕТЫРЕ ЯДРА (20.09 16:00, голосом): «на Oracle 4 ядра... одно ядро отдано на саму систему, которая обслуживает веб-папку, а ещё 3 ядра, наверное, могут обслуживать самих пользователей».

Отвечаю по фактам живого снимка, а не по предположению.

**Ядер действительно четыре** (`nproc`=4). Но разделения «одно ядро системе, три пользователям» НЕТ: ни один процесс к ядрам не прижат, `taskset` не применяется. По этим четырём ядрам одновременно ходят: две копии приложения (`nc-a1` на 3010, `nc-a1-b` на 3012), PostgreSQL, Redis, край nginx и десять периодических заданий, одно из которых (контроллер upstream) просыпается каждые пять секунд. Операционная система, разумеется, тоже.

**Почему число копий важнее числа ядер — и почему оптимизация Astra вообще имела смысл.** Приложение написано на Node: в одном процессе полезная работа JavaScript идёт в ОДНОМ главном потоке. Это у нас уже измерено отдельно: последовательный ресурс — именно главный поток JS, он был занят на 86.5% ядра при 99.1% выборок. То есть ОДИН процесс приложения физически не может занять больше примерно одного ядра полезной работой, сколько бы ядер ни было в машине. Три свободных ядра при одной копии остались бы недогруженными.

Отсюда и смысл второй копии: **две копии — это два главных потока JS**, то есть потенциально вдвое больше одновременной полезной работы, и край раскладывает между ними запросы методом `ip_hash`. Это ровно то, что предложил Astra, и это стоит на бою: аптайм обеих копий на снимке — четверо суток.

**Чего мы пока НЕ знаем и что покажет замер.** Сколько из четырёх ядер реально занято при десяти одновременных пользователях, и кем именно: копиями приложения, базой, Redis, краем или фоновыми заданиями. Ни один прошлый замер этого не снимал — мерили только генератор. В идущем сейчас замере-4 снятие загрузки цели поядерно и с привязкой к процессам сделано обязательным условием приёмки, и отдельной строкой сдачи будет прямой ответ `TARGET_SATURATED=да/нет/неизвестно`.

Предположение владельца про «одно ядро системе» окажется примерно верным или неверным — это покажут цифры, и я приведу их поимённо: сколько взяла каждая копия, сколько база, сколько край, сколько работники.

ГДЕ ХРАНЯТСЯ СТЕНДЫ (владелец просил записывать это в тикеты, чтобы не искать):
- **живой стенд замера** — машина A2, корень `/home/ubuntu/stand-4403/`, псевдоним рецепта `/var/tmp/4400-r2-stand`; порты: край `43900`, копия A `43910`, копия B `43912`, PostgreSQL `43927`, Redis `43932`; база `wave4400_empty`, роль `wave4400_app`; опись и команда остановки поимённо — в `4403STANDBUILD2-evidence/stand-handover.md`;
- **комплект для подъёма с нуля** — Hetzner Storage Box, `stand-kits/l115q-cc278e18-stand-v2/l115q-cc278e18-stand-v2.tar.gz`, 28 320 байт, sha256 `4265ccb7f28f3ae6de77519ad3332ac66ca43433b9391830a6d1f58df93b609e`, маркер `ready` от `2026-09-20T15:19:05Z`, обратное чтение пройдено;
- **предыдущий комплект v1** (ОДНОПРОЦЕССНЫЙ, только как история) — там же, `stand-kits/l115q-cc278e18-stand-v1/`, sha256 `280b0aa3f9c38001d5fcfe9e29a2813aa2550e1367a4e67f35d57f6e01297aa6`;
- **боевой артефакт линии** — Hetzner, `/home/app-artifact/l115q-cc278e18/artifact.tar.gz`, 244 643 102 байта, sha256 `e9cdd5b041c29d058ef3c06e11ac39862e4de57d4ea307e79a7902d2d6535d86`.

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=2026-09-20, CAP-06: на бою доказаны две копии приложения, но CPU/goodput и насыщение цели ещё не измерены; волна 4392 продолжает постановку замера.
ЧТО НУЖНО=первый шаг: завершить ограниченный 1/2/3-process замер с CPU/goodput и записать TARGET_SATURATED с датированной распиской; triage-neo 4712

[28.09 05:21Z координатор] 5158 (M4, ступени 300/400/500 на r18 5e9a999b): NO-GO до нагрузки. Refresher первой личности: «before readback is 18920 bytes, expected exactly 2MiB». Read-only БД стенда: 0/500 источников пула per-vu-4934-prod-500 по 2 MiB (18–31 КБ, contentRevision=1, updatedAt 2026-01-01). Стенд не менялся, k6 не запускался.
Дальше: 5160 (A2) ищет, кто сбросил пул, и восстанавливает 500/500 по 2 MiB с дампом до записи; при GO автоматически уходит 5161 (повтор ступеней). Параллельно 5159 (Нео) разбирает EGRESS_BOOTSTRAP_NOT_READY из 5156.