WEB board

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

SHIFT-STOP-20260912:FINAL:WEB-640
Enterprise-2 / CAP-13: Третий узел и реальная большая машина — расширение

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

ИНДИВИДУАЛЬНЫЙ ОСТАТОК
Опциональное расширение после R1: реальная третья/большая машина, подтверждённые ресурсы и отдельные бюджет/TTL; сейчас backlog.
Следующая смена начинает только после возобновления владельцем. Исторический status сохранён; STOPPED означает отсутствие выполняемой работы, не закрытие задачи.

[12.09 22:25Z координатор] ОБОГАЩЕНИЕ 12.09 (3571-enrich-web626):
Сделано: ничего — карточка опциональная и остаётся backlog.
На проде: НЕТ (и не предполагалось в R1).
Доказано: —
Осталось: третий узел/реальная большая машина требуют отдельного manifest, VM, бюджета/TTL.
Кто следующий: координатор по решению владельца, после закрытия R1.
Ссылки: /Users/annakorin/nc-ops-scripts/enterprise2-20260910/ENTERPRISE-2.md; /Users/annakorin/nc-ops-scripts/enterprise-3532/delivery/3532CAPACITYK6RUNTIME-REPORT.md
Отчёт волны: /Users/milamarty/waves/3571ENRICH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/enrich-collected/.

[13.09 11:01Z координатор] Мойка отложенных, волна 3668. Вердикт: ОСТАВИТЬ-ОТЛОЖЕННОЙ. Линия координатора (Enterprise-2); пробуждение — возобновление после R1.

[14.09 17:41Z координатор] # WEB-640 — Enterprise-2 / CAP-13: Третий узел и реальная большая машина — расширение

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

---

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

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

- «между A1 и A2 нет сети» снято `[задание]` — значит, отказ от расширения **не может**
  обосновываться сетью;
- «потолок продукта 10-12 пользователей» снято `[задание]` — значит, потребность в
  третьем узле **не может** обосновываться этим числом.

**Обоснования «за» и «против» третьего узла, лежавшие в эпике, оба недействительны.**

---

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

**По CAP-13 за смену 14.09 замеров не проводилось.**

Что известно и что делает расширение бессмысленным **сегодня**:

1. **Даже ВТОРОЙ узел не замерен** — на A1 нет стендового приложения `[задание]`;
   волна 3898 подтвердила изнутри A1: слушателей на 3610/3611 **ноль**
   `[3898: evidence/02-a1-listeners.txt]`.
2. **Два дефекта в коде ломают многоузловую схему независимо от числа узлов**
   (блок WEB-636, §2.2 и §2.3): механизм мягкого вывода **выключен**
   (`MULTINODE_ENABLED` отсутствует), а гейт пула БД **структурно слеп** к числу
   хостов — N хостов недосчитывают ровно в N раз. Добавление третьего узла при
   `DB_POOL_GATE_WEB_PROCESSES=1` на каждом усугубит расхождение, а не проверит
   масштабирование.
3. **Потолок не найден** — ни одна ступень не встала `[задание]`. Пока неизвестен
   потолок одного узла, прирост от третьего не с чем сравнивать.

---

## 3. ОТКРЫТО

1. **CAP-13 заблокирован по зависимости:** он зависит от CAP-12, а CAP-12 —
   скелет без чисел `[3879 LIMITATIONS.md]`.
2. **Реальная большая машина отсюда не проверялась вообще** — ни offering, ни quota,
   ни launch. **Не проверено отсюда.**
3. **Условие входа в CAP-13 не сформулировано** — тикет не говорит, при каком
   результате CAP-08/09/10 расширение вообще имеет смысл.

---

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

**Куда смотреть:** блок WEB-636 §2.2 и §2.3 — два дефекта, которые надо закрыть до
любого разговора о третьем узле; блок WEB-637 §3 — потолок не найден.

**Первый шаг:** не начинать. Проверить, закрыт ли CAP-12 и снят ли NO-GO по CAP-09.
Если нет — записать в тикет одну строку: «заблокирован до CAP-12; обоснования
и за, и против сняты 14.09» — и вернуть его в очередь.

**Что считается готовым:** сначала — условие входа: названный результат CAP-08/09/10,
при котором третий узел даёт ответ, которого нельзя получить дешевле. Только потом —
сам замер.

**Чего делать нельзя:** обосновывать расширение снятыми числами; покупать VM;
планировать третий узел, пока `MULTINODE_ENABLED` выключен и гейт пула слеп к
топологии; трогать production, прод-БД, sudo, secrets.

---

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

Волна 3898 по CAP-13 ничего не мерила. Сама проверила только отсутствие стендового
приложения на A1. Облако и большие машины **отсюда не проверены**. Содержимое
комментариев WEB-640 **отсюда не проверено** (доска не отвечает).

[14.09 21:33Z координатор] **Сюда переезжает всё, что выше доказанного потолка.** Решение принято координатором 14.09 при закрытии CAP-10 (WEB-637); владелец делегировал словами «делайте как положено по уму».

**Что переезжает из CAP-10:**
- ступени **50 / 100 / 1000 VU** — не выполнялись и на текущем железе и корпусе невыполнимы;
- поведение выше **25** пользователей — неизвестно.

**Два входных условия, без которых этот тикет не стартует** (оба измерены, не предположены):
1. **Корпус.** Сейчас **48 личностей** (CAP-03). Ступень 50 нечем населить. Нужен корпус, растущий вместе со ступенью, иначе замер описывает повторное использование одних и тех же данных, а не нагрузку.
2. **Железо.** Потолок **N=15** упирается в **одну нить JS** (`0.880` ядра, полка с пятого пользователя), а не в базу, не в сеть и не в диск. Третий узел **сам по себе потолок не поднимет** — это уже доказано на двух узлах: разнесение дало `+5.2 %` пропускной и **ухудшило** хвост. Значит смысл этого тикета — не «добавить машину», а **проверить масштабирование после того, как снята однопоточность**.

**Арифметика, ради которой тикет существует** (оценка, не измерение): один процесс ≈ 23.5 действия/с; активный человек ≈ 1.2 действия/с ⇒ **≈19 человек на процесс** ⇒ 1000 человек ≈ **51 процесс ≈ 25 машин** сегодняшнего класса. Если 42 мс процессора на действие удастся довести до 10 мс — те же 1000 укладываются примерно в **6 машин**. Отсюда очевидный порядок: **сначала оптимизация, потом третий узел**, а не наоборот.

Связь: работа по снятию 42 мс ведётся отдельным эпиком оптимизации; этот тикет ждёт её результата.

[14.09 23:06Z координатор] **🔴 Аудит живого стенда (волна 3940, `VERDICT=NO-GO`) поймал в этом тикете ЧЕТЫРЕ ошибки. Тикет я писала по памяти и по чужим отчётам — ровно тот способ, за который ругаю волны. Владелец справедливо потребовал проверку; она нашла всё.**

## Что было неверно

**1. «Порт 3611 — мишень для замеров» — УЖЕ НЕТ, и это срочно.**
Сегодня за 3611 сидит **распределитель очереди от совсем другой работы**. Настоящие копии стенда переехали на **3621 и 3622**. Кто придёт мерить на 3611 — **померит не продукт**. Любая инструкция, называющая 3611, теперь вредна.

**2. «В корпусе 48 личностей» — НЕВЕРНО: их 2185.**
Аудит пересчитал сам. **48 — это сколько можно вести одновременно** (два пула по 24), а не размер корпуса. ⚠️ Предыдущая волна (3935) это уже объясняла, **а тикет повторил старую ошибку**.

**Последствие: моё решение по CAP-10/CAP-13 стояло на неверном основании.** Я унесла ступени 50/100/1000 в CAP-13 с формулировкой «корпус 48, ступень 50 нечем населить». **Корпус 2185 — ступень 50 возможна.** Решение подлежит пересмотру: в CAP-13 остаётся «1000», но «50 и 100» надо вернуть в область достижимого и сказать, что мешает на самом деле.

**3. «Egress отрезан» — НЕВЕРНО.**
Запрет на машине есть, но выписан **на другого жильца**: правило на `uid 999`, а стенд работает под **`uid 1001`**. Стенду наружу **никто ничего не запрещал**. Это прямая дыра в изоляции и отдельная причина, по которой **CAP-02 (WEB-629) не закрывается**.

**4. «Стенд — один экземпляр на двух портах» — НЕВЕРНО.**
Экземпляров **два**, из **разных сборок**, с **разными хранилищами**: у одного своя отдельная база и свой склад, у другого — в общем. А `cap3610stand` — это **имя базы**, а не имя экземпляра.

## Что аудит добавил сверх тикета

**Стенд никем не сторожится.** Он поднят руками в ssh-сессии: пока окно открыто — работает. Закроется окно или перезагрузится машина — **стенд исчезнет, и поднять его будет некому**. Настоящий сайт рядом под присмотром systemd, стенд — нет.

**Тетрадка с секретами (`app.env`) заперта** и аудиту недоступна; он нашёл рядом открытую копию такой же и переписал из неё.

**Сторож замерялки работает:** проверяет, что манифест приложен к той сборке, из которой собрана копия; не та сборка — замер не начнётся.

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

1. **Тикет переписывается по фактам аудита**, а не по моей памяти — порты, число экземпляров, размер корпуса, состояние egress.
2. **Решение по ступеням 50/100 пересматривается** — основание было ложным.
3. **Дыра в egress (`uid 999` вместо `uid 1001`) идёт в CAP-02** как отдельный пункт: «изоляция объявлена, но правило выписано не на того пользователя».
4. **Отсутствие присмотра за стендом** — первое требование к воспроизводимой сборке: стенд обязан подниматься как служба, а не из ssh-окна.

**Урок, который стоит записать явно:** я потребовала от волны ловить мои ошибки — и она поймала четыре, включая одну, на которой стояло принятое решение. Описание инфраструктуры **по памяти** недопустимо; только командой на живой машине.

[15.09 00:36Z координатор] **Требование к корпусу СНИМАЮ — оно стояло на неверном числе.**

При переносе сюда ступеней 50/100/1000 я написала входным условием: «корпус сейчас **48 личностей**, ступень 50 нечем населить». Аудит живого стенда (волна 3940) пересчитал сам: в корпусе **2185**. Число 48 — это сколько личностей можно **вести одновременно** (два пула по 24), а не размер корпуса.

**Корпус есть. Материала на ступень 50 и 100 хватает.**

**Верная причина, по которой эти ступени здесь, а не в CAP-10:** они **выше доказанного потолка**. Потолок N=15 подтверждён дважды; ступень 20 нездорова на обеих конфигурациях, 25 — воспроизводимо нездорова. Гонять 50 и 100 имеет смысл **не для поиска потолка**, а чтобы увидеть, что происходит **за** ним: деградация плавная или обвал. Это отдельный вопрос, и он законно живёт здесь.

**Второе входное условие остаётся в силе и оно главное:** потолок упирается в **одну нить JS**, а не в железо. Третий узел сам по себе потолок не поднимет — это уже доказано на двух узлах (`+5.2 %` пропускной при **худшем** хвосте). Смысл появляется только после того, как снята однопоточность, то есть после работы в **WEB-660** и после починки неразделяемого состояния живых сессий (**208 сорванных сессий из 273**, волна 3932).

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

[15.09 01:17Z координатор] ## 15.09 01:30Z — решение владельца: этот тикет НЕ блокирует закрытие эпика Enterprise-2.

Дословно (15.09, голосом): «по третьему вопросу ступени выше потолка выносим отдельный тикет, мы это уже обсуждали».

То есть: третий узел и большая машина — **отдельная работа за границей эпика**, а не остаток внутри него. Эпик WEB-626 закрывается без этого тикета; тикет остаётся в backlog и живёт своей жизнью.

**Что к нему относится по существу.** Потолок продукта до сих пор **не найден** — ни одна ступень не встала. Ступени 16 и 24 пользователей прогонялись и дали числа (`open` p95: 156.7 / 168.0 / **544.7** мс). Ограничение, о которое мы упирались, — это **бюджет прибора**, а не продукта: на 4-ядерной A2 приложению нужно ≥2 ядра и генератору при нынешней цене столько же, отсюда «с этой машины честно прокачивается 10–12 пользователей». Я однажды назвала бюджет прибора потолком продукта, владелец это поймал.

Поэтому работа этого тикета — **дать генератору отдельное железо**, чтобы измерить продукт, а не прибор. Тогда и только тогда слово «потолок» станет применимо: оно допустимо лишь для ступени, которая ВСТАЛА, с названной причиной остановки.

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

УЖЕ ПОКРЫТО историей тикета (не дублируется):
- СНЯТИЕ требования к корпусу — 2026-09-15T00:36:13.127Z: корпус 2185, а не 48
  (48 — сколько можно вести ОДНОВРЕМЕННО, два пула по 24);
- решение владельца — 2026-09-15T01:17:13.154Z: тикет НЕ блокирует закрытие эпика,
  остаётся в backlog; ступени 50/100 больше не обосновываются корпусом, а только тем,
  что они ВЫШЕ доказанного потолка (N=15 подтверждён дважды, 20 нездорова на обеих
  конфигурациях, 25 воспроизводимо нездорова).

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

1) НЕТ блока KNOWN ISSUES В ФОРМАТЕ КАНОНА, А ЗДЕСЬ ЭТО САМЫЙ ОПАСНЫЙ ТИКЕТ.
   Аудит живого стенда (волна 3940, `VERDICT=NO-GO`) поймал в тикете ЧЕТЫРЕ ошибки
   (2026-09-14T23:06:22.962Z). Три из них — прямые ловушки с ценой «померить не то»:
   а) ЛОВУШКА ПОРТА. «Порт 3611 — мишень для замеров» — УЖЕ НЕТ: за 3611 сидит
      распределитель очереди от другой работы, настоящие копии стенда переехали на
      3621 и 3622 (23:06:22.962Z). Проверка за 2 минуты на стенде:
      `ss -ltnp | grep -E ':(3611|3621|3622)'` и сверка pid с процессом стенда;
      кто придёт мерить на 3611 — померит НЕ продукт.
   б) ЛОЖНОЕ ЧИСЛО КОРПУСА. «48 личностей» — неверно, их 2185 (23:06:22.962Z,
      00:36:13.127Z). Проверка за 2 минуты: пересчитать корпус запросом к БД стенда;
      48 — это вместимость одновременного ведения, а не размер.
   в) ДЫРА В ИЗОЛЯЦИИ. «Egress отрезан» — неверно: правило выписано на `uid 999`,
      а стенд работает под `uid 1001` (23:06:22.962Z). Проверка за 2 минуты:
      `ss -ltnp | grep -E ':(3621|3622)'`, затем `ps -o uid= -p <pid>` — uid ≠ 999
      означает, что изоляции нет. Отдельный пункт CAP-02 (WEB-629).
   г) ЧИСЛО ЭКЗЕМПЛЯРОВ. «Стенд — один экземпляр на двух портах» — неверно: экземпляров
      ДВА, из разных сборок, с разными хранилищами; `cap3610stand` — имя БАЗЫ,
      а не имя экземпляра (23:06:22.962Z).
   Плюс два факта, которых в тикете не было вовсе: стенд никем не сторожится (поднят
   руками в ssh-сессии; закроется окно — стенд исчезнет, поднять некому), и `app.env`
   заперта, аудит нашёл рядом открытую копию такой же. Проверка за 2 минуты:
   `systemctl status` по имени стенда — отсутствие юнита означает, что присмотра нет.
2) НЕ ЗАФИКСИРОВАН УРОК, который координатор сама записала: «описание инфраструктуры
   по памяти недопустимо; только командой на живой машине» (23:06:22.962Z). Это правило
   дня, и его место в теле тикета, а не в комментарии.
3) Тело заканчивается блоком 12.09 (`SHIFT-STOP-20260912:FINAL`, STOPPED,
   `ИНДИВИДУАЛЬНЫЙ ОСТАТОК`, «Следующая смена начинает только после возобновления
   владельцем») — при том что 15.09 по тикету принято решение владельца. Прямое
   противоречие: нулевой агент прочитает запрет на работу там, где работа разрешена.

ОСТАТОК на 15.09 01:17Z: тикет остаётся в backlog, живёт отдельно от эпика Enterprise-2;
входное условие — сначала оптимизация (WEB-660) и починка неразделяемого состояния
живых сессий (208 сорванных из 273), потом генератору отдельное железо, и только тогда
слово «потолок» станет применимо (01:17:13.154Z).

ПЕРВЫЙ ШАГ НУЛЕВОГО АГЕНТА (2 минуты, ничего не запускает): прочитать
2026-09-14T23:06:22.962Z и 2026-09-15T01:17:13.154Z. Перед любым замером — командой
на живой машине подтвердить порт, uid стенда и число экземпляров. Ничего не покупать.

РЕШЕНИЕ=parked
ОСНОВАНИЕ=Решение владельца от 2026-09-15: третий узел и большая машина вынесены за границы Enterprise-2, тикет остаётся backlog; движения ≥7 дней.
ЧТО НУЖНО=ЖДЁТ=владелец: решения о запуске третьего узла и большой машины после R1; triage-neo 4710