WEB board

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

REFILL3472:WEB-627
2026-09-10T23:16:44.018057+00:00
Волна 3472 M1 active; cap-local-topology-3472; BASE document-only
Эволюция: предыдущая партия сдана; обнаруженные отказы CAP12/CAP07/CAP11 и route typecheck переданы в исправление3462–3465. Новые transport/auth/stop/node-plan части переданы на независимую проверку3466–3469. WEB593 и QA-изменения Drive проверяются3470/3471. M1 сверяет локальную топологию3472. Брифы и входные SHA проверены. Source GO не означает посадку.
Документы: /Users/annakorin/nc-ops-scripts/SHIFT-GOAL-20260911-8H.md; /Users/annakorin/nc-ops-scripts/enterprise2-20260910/ENTERPRISE-2.md. Доказательства: /Users/annakorin/nc-ops-scripts/refill-20260911-0015/live.json и каталоги a2nc/m4/neo с receipt и полными входами. Ссылки: https://bugs.wool2.online/web

CHECKPOINT3478:WEB-627 2026-09-10T23:30:08.650195+00:00
3472 документация локальной топологии сдана: A2 app A, M4 VM app B, Neo генератор, M1 документация. Это не доказательство старта VM/изоляции/ёмкости. Старый snapshot CAP01/07/12 не отражает последующие ремонты3462/3463; CAP13 следует искать в известной карточке WEB-640, не объявлять несуществующим. Решения по обычной подготовке координатор принимает по восьмичасовой цели.
Полные отчёты и проверки SHA: /Users/annakorin/nc-ops-scripts/checkpoint-3478/snapshot.json; задания и SHA inputs: refill-20260911-0015,0025,0028,0030. Спецификация: /Users/annakorin/nc-ops-scripts/enterprise2-20260910/ENTERPRISE-2.md; цель: SHIFT-GOAL-20260911-8H.md.

CAP3516-STORAGE-READBACK-FAIL:WEB-627 2026-09-12T09:25:28.834907+00:00
Enterprise-2 build preparation: exact source e1f6cb526d946af339c213ea77eb26c8d77594d2 staged clean at A2 /home/ubuntu/capacity-3516/source. Build not started.
Archiving the inactive l115e build cache to M4Ext passed archive SHA and listing, but subsequent member readback failed with OSError [Errno 5] Input/output error. This does not establish archive corruption or its physical cause; it invalidates using this copy for source removal. Cleanup stopped before deleting anything. All 12 source files (2534015372 bytes) were rehashed on A2 and match the pre-archive inventory. Source and archive retained. Reclaim script now persists failed readback status instead of leaving only the earlier successful receipt.
Latest A2 free space: 13263508 KiB (~12.65 GiB); copying ~2.2 GiB dependencies would cross the 12 GiB build floor. Storage preparation remains blocked; T0/load/soak and capacity remain UNKNOWN. No gate waived.
Evidence: Intel /Users/annakorin/nc-ops-scripts/capacity-3516-linux/cache-archive-receipt.json, cache-source-inventory.json, stage-receipt.json. Archive M4 /Volumes/M4Ext/ops/capacity-3516-preparation/l115e-cache-20260912.tar.gz.

CAP3516-BUILD-R2-START:WEB-627
Блокер места снят для подготовки сборки 3516: повторное полное чтение архива на M4Ext и SHA256 каждого из 12 файлов совпали с исходной описью. Затем удалены только 2534015372 байта кэша l115e; первый отказ чтения сохранён отдельно. Это не заключение об исправности всего диска.
На A2 подготовлена независимая копия зависимостей (lockfile совпал, 281 wrapper rebased); после копирования было 13773033472 байта свободно. Исходник e1f6cb526d946af339c213ea77eb26c8d77594d2.
Изолированная цепочка nc-capacity3516-build-r2.service запущена 2026-09-12T09:32:30Z, PID205333, PrivateNetwork=yes; отдельный PG16+pgvector, без внешних сетевых маршрутов. Проверены Prisma generation, полное равенство схем после Prisma format, compatibility и генерация activation; prebuild выполняется. Первая попытка остановилась на побайтовом сравнении форматирования, база корректно остановлена, логи сохранены.
Это запуск сборочных проверок, не готовый артефакт и не T0. Измерения нагрузки/soak и capacity по-прежнему UNKNOWN.
Доказательства: /Users/annakorin/nc-ops-scripts/capacity-3516-linux/{cache-archive-receipt.json,cache-readback-first-failure.json,deps-receipt.json,build-r2-start-receipt.json}; A2 /home/ubuntu/capacity-3516/build-evidence-r2/.

CAP3516-R2-DISK-RECOVERY:WEB-627
Сборка 3516 R2 остановилась на 11-next-build: защитный порог диска 8 GiB, exit -9; готового standalone нет. Предыдущие prebuild/editor/migrations PASS; отдельный PG остановлен, exit 0. Кэш Webpack 5303953756 байт сохранён на M4Ext. SHA архива и содержимого всех 7 файлов совпали; оригиналы повторно сверены и только затем удалены. Сейчас на A2 12.32 GiB свободно. Повторная сборка ещё не запущена: возврата прежнего запаса недостаточно, требуется дополнительное место. T0, runtime, нагрузка и soak не выполнены. Отчёты и бандлы сохранены. Evidence: nc-ops-scripts/capacity-3516-linux/build-r2-failure.json, r2-cache-archive-receipt.json; m4:/Volumes/M4Ext/ops/capacity-3516-preparation/cap3516-r2-webpack-20260912.tar.gz; SHA256=b9752ce5a05efd0f69dc5f9017acb2c14667ad0804eb58263b9b23b5545e60a2

CAP3516-R3-LAUNCH:WEB-627
R3 фактически запущена 2026-09-12T10:11:54.614821+00:00. На старте 18.64 GiB; требуемые 18 GiB соблюдены. Дополнительные кэши скопированы на M4Ext, SHA архива и каждого файла сверены перед удалением. Наблюдение: RUNNING; MainPID=237035; PrivateNetwork=yes; ActiveState=active;  T0/нагрузка/soak пока не выполнены. Evidence: capacity-3516-linux/build-r3-start-receipt.json, r3-extra-space-receipt.json, build-evidence-r3/status.json на A2.

CAP3516-RUNTIME:BUILT:SEEDED:WEB-627
R3 BUILT. Последний этап: 14-action-manifest. На A2 11.42 GiB. Standalone построен на e1f6cb526d946af339c213ea77eb26c8d77594d2; buildId=R7L9roppA5xpq7qPoQmCR. Все этапы сборки прошли. Отдельная база T0: SEEDED. Вставлено 51 записей; документ и 32 chunks прочитаны обратно, integrity подтверждена. База штатно остановлена и сохранена для запуска приложения. T0 настоящего приложения/нагрузка/soak не выполнены, capacity UNKNOWN. Evidence: capacity-3516-linux/runtime-state-receipt.json; build-evidence-r3/; runtime-t0-r1/database-evidence-r1/ на A2.

SHIFT-STOP-20260912:FINAL:WEB-627
Enterprise-2 / CAP-00: Ресурсы стенда и доступность AWS/Hetzner

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

ИНДИВИДУАЛЬНЫЙ ОСТАТОК
Зафиксировать свежую топологию A2 isolated SUT и отдельного генератора: CPU/RAM/disk/RTT, доступность второго app-host, бюджет/TTL при платном расширении.
Следующая смена начинает только после возобновления владельцем. Исторический status сохранён; STOPPED означает отсутствие выполняемой работы, не закрытие задачи.

[12.09 22:25Z координатор] ОБОГАЩЕНИЕ 12.09 (3571-enrich-web626):
Сделано: изолированный стенд R3 на A2 реально собран и засеян (source e1f6cb526, buildId R7L9roppA5xpq7qPoQmCR, 51 строка/документ 2 MiB).
На проде: НЕТ — 0 из 14; стенд живёт только в /home/ubuntu/capacity-3516 на A2.
Доказано: runtime-state-receipt.json, build-r3-start-receipt.json (nc-ops-scripts/capacity-3516-linux).
Осталось: AWS/Hetzner — offering/quota/launch не различено, второй host UNPROVEN, бюджет/TTL не зафиксированы.
Кто следующий: координатор по возобновлению владельца (R3 жив, но юниты nc-cap3516-* сейчас failed).
Ссылки: https://bugs.wool2.online/web; /Users/annakorin/nc-ops-scripts/enterprise2-20260910/ENTERPRISE-2.md; /Users/annakorin/nc-ops-scripts/SHIFT-GOAL-20260911-8H.md; /Users/annakorin/nc-ops-scripts/refill-20260911-0015/live.json; /Users/annakorin/nc-ops-scripts/checkpoint-3478/snapshot.json; /Users/annakorin/nc-ops-scripts/capacity-3516-linux/{cache-archive-receipt.json,cache-source-inventory.json,stage-receipt.json,deps-receipt.json,build-r2-start-receipt.json,build-r2-failure.json,build-r3-start-receipt.json,r3-extra-space-receipt.json,runtime-state-receipt.json}; A2 /home/ubuntu/capacity-3516/{source,build-evidence-r2,build-evidence-r3,runtime-t0-r1}; commit e1f6cb526d946af339c213ea77eb26c8d77594d2 / buildId R7L9roppA5xpq7qPoQmCR
Отчёт волны: /Users/milamarty/waves/3571ENRICH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/enrich-collected/.

[14.09 17:40Z координатор] # WEB-627 — Enterprise-2 / CAP-00: Ресурсы стенда и доступность AWS/Hetzner

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

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

---

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

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

### Эволюция: как ресурсная строка эпика оказалась неверной

CAP-00 — тикет про «что у нас вообще есть». Он четверо суток держал вывод
«второй хост недоступен, потому что сети нет». Формально между машинами сеть **есть**:
ICMP 10/10, rtt min/avg/max/mdev **0.698/0.821/0.923/0.076 мс**, TTL 63 — один хоп
`[3875-отчёт §1.1]`. Прежняя волна мерила внутренние адреса 10.1.1.x и получила «нет»
— правда про те адреса; владелец мерила внешние и получила «есть» — тоже правда.

Но и вывод «раз сеть есть, ресурс доступен» **тоже неверен**. Ресурс — это не машина,
а *машина со стендовым приложением, которое слушает снаружи, и с одобренной целью для
генератора*. Ничего из этого на A1 нет. Правильная ресурсная строка звучит так:
**«A1 как второй app-host сегодня не ресурс»** — и именно так её надо держать в CAP-00,
пока §3 не закрыт.

Отдельная поправка к карте: публичное имя из CLAUDE.md `wool2.online` → 86.45.55.126
**не отвечает на ICMP вообще** (0 из 5). Это **другой адрес**, не A1. Кто мерил «A1»
по имени — мерил не ту машину `[3875-отчёт §1.1]`.

---

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

### 2.1 Что есть на A1 — проверено волной 3898 изнутри

- хост `a1-payg-01`, внутренний адрес **10.0.0.131**, **4** ядра, **23 ГБ** ОЗУ `[3898]`;
- **слушателей на 3610/3611 — ноль**; стендового приложения на A1 нет вообще `[3898]`;
- наружу (не на loopback) смотрят только `22, 80, 443, 5060, 5061, 8088, 4080, 4084,
  4573`; порта приложения среди них нет `[3898: evidence/02-a1-listeners.txt]`.

### 2.2 Что видно с A2 — волна 3875

- ICMP A2 → A1 (129.213.25.105): **0.821 мс**, 10/10, TTL 63 `[задание]`, `[3875-отчёт §1.1]`;
- TCP-проба: отвечают **22, 80, 443**; `3030, 3610, 3611, 55432, 6379` — closed/filtered
  `[задание]`, `[3875-отчёт §1.2]`;
- «HTTPS 13 мс, код 200» — это порт **443**, единственный отвечающий HTTPS на A1,
  то есть nginx на **прод-контуре**, а не стенд `[3875-отчёт §1.2]`;
- оба web-процесса стенда слушают **только loopback** `[задание]`;
- **одобренных isolated-target на A1 нет вообще** `[задание]`;
- цена лишнего хопа измерена: ~**0.75 мс** на запрос, **меньше 0.1 %** от p50
  бизнес-операции — сеть **не** является причиной, по которой два хоста не помогли бы
  `[3875-отчёт §1.6]`;
- **SSH-канал A2 → A1 существует и работает** (процесс 1011,
  `ssh -i ~/.ssh/a2-to-a1 -L 127.0.0.1:55432:... -L 127.0.0.1:6379:... ubuntu@129.213.25.105`).
  Волна 3875 им **не пользовалась** — SSH был ей запрещён `[3875-отчёт §1.5]`.

### 2.3 Ресурсная конкуренция — измеренный факт, а не жалоба

За смену 14.09 на одной 4-ядерной машине работали **ЧЕТЫРЕ** волны на одном стенде
(3864 CAP-08, 3867 CAP-11, 3877 CAP-10 и 3875 CAP-09). Две ступени испортили друг
друга расхождением старта в **8 секунд**; собственный след волны 3875 —
**0.208 ядра, 5.2 % машины**, ~4 минуты суммарно `[3875-отчёт §2.5, §3]`.

---

## 3. ОТКРЫТО

1. **Сеть под замер открыта 14.09** — правило Oracle, порты **3610-3611** с A2,
   **временное** `[задание]`. Отсюда правило **не проверено** (консоль Oracle этой
   волне недоступна). И само по себе оно ничего не даёт: на A1 нет ни слушателя, ни
   одобренной цели (§2.1).
2. **Второй app-host как ресурс не существует**, пока на A1 не поднят стендовый
   процесс с bind не на loopback и не создан третий одобренный `isolated-target-*.json`.
3. **Облако (AWS/Hetzner) отсюда не проверялось вообще** — ни offering, ни quota, ни
   launch. Из тела тикета известно только, что профиль rehearsal аутентифицируется,
   eu-west-1 предлагает m7g.large/c7g.large/t4g.large, а `servicequotas:GetServiceQuota`
   и `support:DescribeCases` запрещены `[тело тикета WEB-627]`. **Не проверено отсюда.**
4. **Процессное правило «одна волна на стенде» не зафиксировано** — и это ресурсный
   вопрос, а не организационный: без него ни один замер смены нефальсифицируем.

---

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

**Куда смотреть:** §2 этого блока; `3875CAP09-evidence/step1-boundary-probe.log`
(на A2) или его пересказ в `3894WEB320-evidence/3875CAP09-REPORT.md` §1 (на A1);
`inputs/isolated-target*.json` на стенде.

**Первый шаг (секунды, ничего не запускает):**
`ss -ltn | grep -E ':(3610|3611)'` **на A1**. Пусто — второго app-host по-прежнему нет,
и это надо писать в CAP-00 прямым текстом, а не как «ждём сеть».

**Что считается готовым:** матрица A2/M4/Neo/AWS с архитектурой, свободным ресурсом,
RTT, failure domain, квотой, стоимостью и TTL; выбранные SUT, генератор и резерв.
Для облака **различать offering / quota / launch** — это три разных факта. Второй
хост имеет право остаться UNPROVEN, но тогда так и написать, с доказательством.

**Чего делать нельзя:**
- писать «сети нет» (неправда) и писать «сеть есть, значит хост доступен» (тоже неправда);
- считать прод-контур на :443 стендовым ресурсом;
- мерить `wool2.online` и называть это A1;
- пользоваться SSH-каналом A2→A1 без явного разрешения;
- покупать VM; трогать production, прод-БД, sudo, secrets.

---

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

Волна 3898 проверила сама только то, что видно изнутри A1 (хост, ядра, память,
слушатели). Всё про A2, облако, правило Oracle и прод-контур — **не проверено отсюда**.
Доска `http://127.0.0.1:8787` с A1 не отвечает, поэтому текущее содержимое
комментариев WEB-627 отсюда не проверено `[3898: evidence/01-board-probe.txt]`.

[14.09 21:54Z координатор] **ЗАКРЫВАЮ. Остаток требовал зафиксировать свежую топологию — зафиксирована, замерена мной сегодня, не унаследована.**

**Машины (обе Oracle, always-free, ARM):**

| | A1 `a1-payg-01` | A2 `a2-payg-01` |
|---|---|---|
| роль | боевая: прод + измеряемый стенд | сборочная/запасная: генератор нагрузки |
| ядер | **4** | **4** |
| процессор | Neoverse-N1, `aarch64` | Neoverse-N1, `aarch64` |
| память | 23 974 МБ (свободно 17 897) | 23 974 МБ (свободно 18 606) |
| диск | 193 ГБ, свободно 19 ГБ | 96 ГБ, свободно 12 ГБ |
| внешний адрес | 129.213.25.105 | 129.80.41.210 |

**RTT между машинами — измерен, и он асимметричен:**

```
A2 -> A1 :  min/avg/max/mdev = 0.774 / 0.792 / 0.820 / 0.019 мс, потерь 0
A1 -> A2 :  3 пакета отправлено, 0 получено — 100 % потерь
```

⚠️ Это **не дефект замеров**, а свойство сети между двумя разными тенанси Oracle: внутренние адреса недоступны, наружу работает только направление A2→A1. Для CAP-09/CAP-10 этого достаточно — генератор на A2 достаёт приложение на A1 за 0.8 мс, — но **обратное направление закрыто**, и любая схема, требующая обращения A1→A2, работать не будет без отдельного правила.

Временное правило доступа, открытое для замеров (Oracle security list, TCP 3610-3611 с `129.80.41.210/32`, плюс два правила ufw на A1), **подлежит снятию** — напоминание перенесено в остаток.

**Доступность второго app-host: есть.** На A1 поднят отдельный экземпляр приложения (`cap3610stand`, порты 3610 и 3611) с собственной базой, заглушенными провайдерами и отрезанным egress. ⚠️ Мишень **3610 негодна** — база пуста (`User=0` при 211 таблицах), харнесс отвергает её `sourceCommit`, сессии не аутентифицируются; это доказано волной 3910 и ведётся в **CAP-02 (WEB-629)**. Все замеры шли на **3611**.

**Бюджет и TTL при платном расширении:** обе машины — **Oracle always-free**, платного расширения в этой работе не использовалось и бюджет не расходовался. Третий узел и большая машина — это **CAP-13 (WEB-640)**, и там же сказано, что он ждёт результата эпика оптимизации, а не наоборот: потолок упирается в одну нить, и добавление машины его не поднимает (доказано на двух узлах: `+5.2 %` пропускной при **худшем** хвосте).

**Что этот тикет честно не покрывает:** AWS и Hetzner как площадки для стенда не оценивались — работа велась на Oracle. Hetzner используется только как хранилище резервных копий и аварийного комплекта.

**ОСТАТОК (переносится, а не теряется):** снять временное правило Oracle security list TCP 3610-3611 и два правила ufw на A1 после закрытия CAP-09.

Статус → `done`.

[14.09 22:58Z координатор] **🔴 Поправка, и она существенная: владелец поймал у меня неточность про A2, а через неё — ошибку в основании, по которому отложен шаг D3b книги.**

**Что я говорила:** «A2 — сборочная/запасная машина, продукт не обслуживает». **Что на самом деле** (проверено сейчас, не по памяти):

```
pg_lsclusters:  16  noteclone  55433  online,recovery
pg_is_in_recovery()        = t
отставание                 = 0.285 с   (позже под нагрузкой 3.9 с)
pg_last_wal_receive_lsn    = pg_last_wal_replay_lsn = 8/3A4B5F18   (догнан полностью)
pg_stat_wal_receiver       = streaming, слот a2_standby, отправитель 127.0.0.1:55432 (через ssh-туннель)
размер                     = 3.0 ГБ
```

**На A2 живой потоковый standby боевой базы, отстающий меньше чем на секунду.** На стороне A1 ему соответствует walsender `a2_repl`, который я видела ещё в переписи соединений и не связала с этим.

**🔴 И вот моя настоящая ошибка.** Исполнитель учения написал: «D3b отложен: **нет standby**, replication slot, конфигурации и владельца БД». Я **передала это дальше, не проверив** — и в поправках к книге, и в тикете. **Standby есть, он живой, догнан, слот называется `a2_standby`.** Значит D3b отложен по **неверному основанию**, и это надо переписать: отложен он не потому, что запасного узла нет, а потому, что **процедура повышения не описана и ни разу не проверялась**.

**Что это меняет по существу — самое важное.** Самый быстрый путь восстановления не «развернуть копию из бэкапа», а **повысить существующий standby до основного**. Это минуты против часа. Но и он **ни разу не проверялся**, ровно как и восстановление из бэкапа (**WEB-663**). То есть у нас **два** непроверенных пути восстановления, а не один, и более быстрый из них я вообще выпустила из виду.

**Риск, который я из-за этого чуть не создала.** Волна 3941 разворачивает копию из бэкапа **на той же A2, где живёт standby**. Свободное место упало с 12 ГБ до **9 ГБ**, отставание standby выросло с 0.285 до 3.9 с. Если место кончится — **сломается standby**, а это прямо противоречит условию владельца «не мешая никому».

**Поставлен сторож:** тревога при свободном месте < 4 ГБ или отставании > 120 с, с немедленной остановкой восстановления. **Standby важнее упражнения.**

**Следствия для плана:**
1. переписать основание отложенности D3b в поправках к книге — «нет standby» неверно;
2. завести проверку **повышения standby** как отдельный путь восстановления (быстрее бэкапа) — и проверить её так же, как сейчас проверяется бэкап;
3. в CAP-00 (WEB-627) дополнить описание A2: она не «сборочная», она **несёт живую реплику боевой базы**.

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

СОСТОЯНИЕ: тикет НЕ трогали 15.09. Последний комментарий — 2026-09-14T22:58:30.077Z,
`updatedAt` = 2026-09-14T21:54:04.941Z, статус `done`. То есть «истории за 15.09» у
этого тикета нет вообще, и ADEQUATE по сегодняшнему критерию он получить не может.

УЖЕ ПОКРЫТО (не дублируется):
- топология и RTT A1/A2 — 2026-09-14T21:54:04.276Z (A2→A1 0.774/0.792/0.820/0.019 мс,
  0 потерь; A1→A2 — 3 отправлено, 0 получено);
- снятие ложного «сети нет» и поправка по `wool2.online` → 86.45.55.126 (ICMP 0/5) —
  2026-09-14T17:40:43.331Z.

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

1) ПОПРАВКА 14.09 22:58Z НЕ ВНЕСЕНА В ТЕЛО. В 2026-09-14T22:58:30.077Z координатор
   сама назвала неточность и записала следствие 3: «в CAP-00 (WEB-627) дополнить
   описание A2: она не "сборочная", она несёт живую реплику боевой базы».
   Измерено там же: `pg_is_in_recovery()=t`, слот `a2_standby`, отставание 0.285 с
   (под нагрузкой до 3.9 с), `pg_last_wal_receive_lsn = pg_last_wal_replay_lsn`,
   размер 3.0 ГБ. В теле тикета A2 по-прежнему описана как «сборочная/запасная».
   Это ровно тот случай, когда закрытие (`done` в 21:54:04.276Z) опровергнуто
   собственной поправкой через час.
2) НЕТ блока KNOWN ISSUES в формате канона. Реальные известные проблемы тикета:
   а) на 3610 пустая база (`User=0` при 211 таблицах), харнесс отвергает её
      `sourceCommit`, сессии не аутентифицируются — доказано волной 3910,
      ведётся в CAP-02 (WEB-629), см. 2026-09-14T21:54:04.276Z. Проверка за 2 минуты:
      `psql -h 127.0.0.1 -p 3610 -c 'select count(*) from "User"'` → 0;
   б) временное правило Oracle security list TCP 3610-3611 + два правила ufw на A1
      ПОДЛЕЖАТ СНЯТИЮ (2026-09-14T21:54:04.276Z). Проверка за 2 минуты:
      `sudo ufw status | grep -E '3610|3611'` на A1 — непустой вывод означает, что
      правило ещё живо;
   в) обратное направление A1→A2 закрыто наглухо (100 % потерь,
      2026-09-14T21:54:04.276Z) — любая схема с обращением A1→A2 не заработает
      без отдельного правила.
3) Тело заканчивается блоком 12.09 (`SHIFT-STOP-20260912:FINAL`, `ИНДИВИДУАЛЬНЫЙ ОСТАТОК`,
   STOPPED) — при том что тикет закрыт 14.09. Два взаимоисключающих финала в одном теле.

ОСТАТОК на 15.09: снять временное правило Oracle security list TCP 3610-3611 и два
правила ufw на A1 после закрытия CAP-09 (перенесён из 2026-09-14T21:54:04.276Z;
на 15.09 закрытия CAP-09 нет — WEB-629 в `review`).

ПЕРВЫЙ ШАГ НУЛЕВОГО АГЕНТА (2 минуты, ничего не запускает): прочитать
2026-09-14T22:58:30.077Z и сверить с описанием A2 в теле; при расхождении — внести
поправку, а не открывать тикет заново.

[20.09 13:53Z координатор] [CAP-00 — что реально лежит на Хетцнере: комплект стенда v1 однопроцессный; ставлю v2 по боевой конфигурации]

КОМПЛЕКТ СТЕНДА НА ХЕТЦНЕРЕ: что там есть на самом деле и почему его надо обновить. Прямой ответ на напоминание владельца 20.09 13:43.

ВЛАДЕЛЕЦ СКАЗАЛ: «касательно стенда отдельное напоминание, что вы храните копии стендов на Хетцнере, чтобы каждый раз не сооружать его заново. Пока я понимаю, у вас проблема есть со стендом, но не забывай, что рабочая копия стенда. Мы не должны потратить ещё два дня, чтобы его создать. Надо будет хранить на Хетцнере и обновлять его на Хетцнере. И вы там уже даже, по-моему, начинали когда-то делать.»

ОН ПРАВ ПО ОБОИМ ПУНКТАМ. Проверил Storage Box 20.09 13:45Z.

ЧТО ТАМ ЛЕЖИТ. Каталог `/home/walg-nc/hetzbk-prod-a1/stand-kits/` содержит ровно один комплект: `l115q-cc278e18-stand-v1`. В нём `l115q-capacity-stand-kit-20260916-v1.tar.gz` (14 224 байта), сайдкар `.sha256`, `README.md` и маркер `ready`. Маркер читается так: `status=ready`, `published_at=2026-09-16T02:38:08Z`, `kind=capacity-stand-kit`, `kit_id=l115q-cc278e18-stand-v1`, `line=l115q`, `source=cc278e1810e1e03ac277b8e3a5fe06a2aebfba30`, `artifact_sha256=e9cdd5b041c2…`, `sha256=280b0aa3f9c38001d5fcfe9e29a2813aa2550e1367a4e67f35d57f6e01297aa6`, `contains_credentials=false`, `contains_user_data=false`. Рядом отдельной веткой `stand-definition/20260916T044400Z/stand-definition.tar.gz` (13 356 байт, sha `fcf9dd9bf938…`) — бессекретный снимок определения стенда R7.

ПОЧЕМУ ЭТОГО МАЛО СЕГОДНЯ. Комплект v1 описывает ОДНОПРОЦЕССНЫЙ стенд — ровно тот, на котором мы 20.09 провели замер 4377 и получили пять зелёных цифр, думая, что меряем боевую конфигурацию. А на бою процессов ДВА (`nc-a1` на 3010 и `nc-a1-b` на 3012), между ними nginx-upstream с методом `ip_hash`, общий Redis, веб-пул 15 подключений НА КОПИЮ из бюджета 77, и десять периодических работников по таймерам. Комплект v1 ничего этого не поднимает. То есть «не сооружать заново» он обеспечивает, но сооружает НЕ ТО.

ЧТО ПОСТАВЛЕНО ПРЯМО СЕЙЧАС. Волна 4395 на A2 строит стенд по принятому рецепту волны 4392 и обязана собрать комплект v2: `l115q-cc278e18-stand-v2.tar.gz` с исполняемым `reproduce.sh` (проходящим `bash -n`), файлами юнитов обеих копий, конфигурацией края с `ip_hash`, списком всех десяти таймеров, шаблонами переменных БЕЗ единого секрета, манифестом требований к машине-приёмнику и `README.md` для нулевого агента. Отдельным файлом волна обязана написать `whats-new-vs-v1.md` — чем v2 отличается от v1, чтобы через месяц было видно, почему v1 больше не годится. Волне также велено оставить стенд ПОДНЯТЫМ и передать его по описи, потому что следующая волна будет по нему мерить.

Публикацию комплекта v2 на Storage Box с обратным чтением делает координатор: доступ к ящику идёт через служебного пользователя на A1, у волн его нет и быть не должно.

ПОРЯДОК, КОТОРЫЙ ИЗ ЭТОГО СЛЕДУЕТ И КОТОРЫЙ НАДО ДЕРЖАТЬ. Комплект стенда версионируется вместе с линией: имя вида `<линия>-<исходник>-stand-v<N>`, маркер `ready` с отпечатком архива и отпечатком артефакта, обязательные поля `contains_credentials=false` и `contains_user_data=false`, обязательное обратное чтение после публикации. Устаревший комплект НЕ удаляем — он остаётся историей; новый кладём рядом. Обновлять при смене числа копий, метода балансировки, состава работников или линии.

[20.09 15:20Z координатор] [CAP-00 — комплект стенда v2 на Хетцнере: 28 320 Б, sha256 4265ccb7…, обратное чтение пройдено, v1 оставлен как история с пометкой supersedes]

СТЕНД СДАН И ДОКАЗАН. Волна 4403 на A2: `VERDICT=GO`, `BOTH_COPIES_SERVED=да`, `SPLIT=4/4`, `STAND_KIT_SHA256=4265ccb7f28f3ae6de77519ad3332ac66ca43433b9391830a6d1f58df93b609e`, манифест 26/26.

=== ДОКАЗАТЕЛЬСТВО РАСПРЕДЕЛЕНИЯ, ПРОВЕРЕННОЕ КООРДИНАТОРОМ ЛИЧНО ===

Приёмка 4405 предупредила: `preflight-r2.sh` умеет пройти на СТАРЫХ строках журнала, не привязанных к текущему прогону. Поэтому я не стал полагаться на собственный предполёт волны и проверил сырьё сам.

Файл `upstream-addr-log.txt` содержит РОВНО ВОСЕМЬ строк — по числу отправленных проб, ни одной лишней:

```
2026-09-20T15:02:09+00:00 ip=192.0.2.10    upstream=127.0.0.1:43912 status=200 GET /api/ready
2026-09-20T15:02:09+00:00 ip=192.0.3.10    upstream=127.0.0.1:43910 status=200 GET /api/ready
2026-09-20T15:02:09+00:00 ip=192.0.4.10    upstream=127.0.0.1:43912 status=200 GET /api/ready
2026-09-20T15:02:09+00:00 ip=198.51.100.10 upstream=127.0.0.1:43910 status=200 GET /api/ready
2026-09-20T15:02:09+00:00 ip=198.51.101.10 upstream=127.0.0.1:43912 status=200 GET /api/ready
2026-09-20T15:02:09+00:00 ip=203.0.113.10  upstream=127.0.0.1:43910 status=200 GET /api/ready
2026-09-20T15:02:09+00:00 ip=203.0.114.10  upstream=127.0.0.1:43912 status=200 GET /api/ready
2026-09-20T15:02:09+00:00 ip=203.0.115.10  upstream=127.0.0.1:43910 status=200 GET /api/ready
```

Все восемь помечены одной секундой `15:02:09`, стенд поднят минутами раньше, журнал не мог содержать ничего старого. Счёт: **43910 — четыре, 43912 — четыре.** Это ровно то деление 4/4, которое волна 4400 предсказала расчётом по формуле nginx до всякого прогона. Все ответы `status=200`.

**Это первое за смену доказательство, что стенд действительно двухпроцессный, а не называется таким.** В замере 4377 мы получили пять зелёных цифр на ОДНОЙ копии, не заметив этого.

=== СОСТОЯНИЕ СТЕНДА ===
Пять слушателей живы: край nginx `43900`, копия A `43910`, копия B `43912`, PostgreSQL `43927`, Redis `43932`. Корень `/home/ubuntu/stand-4403/`. Стенд ОСТАВЛЕН поднятым под замер, опись в `stand-handover.md`. Чужое цело: 3030 на месте, `nc-dev` и `nc-dev-pg` `active`.

=== КОМПЛЕКТ v2 ОПУБЛИКОВАН НА ХЕТЦНЕРЕ И ПРОЧИТАН ОБРАТНО ===

Прямое требование владельца от 20.09 13:43 выполнено.

Адрес: `stand-kits/l115q-cc278e18-stand-v2`. Архив `l115q-cc278e18-stand-v2.tar.gz`, 28 320 байт, sha256 `4265ccb7f28f3ae6de77519ad3332ac66ca43433b9391830a6d1f58df93b609e`. Маркер `ready`: `published_at=2026-09-20T15:19:05Z`, `line=l115q`, `source=cc278e1810e1e03ac277b8e3a5fe06a2aebfba30`, `artifact_sha256=e9cdd5b041c2…`, `contains_credentials=false`, `contains_user_data=false`, **`supersedes=l115q-cc278e18-stand-v1`**.

ОБРАТНОЕ ЧТЕНИЕ выполнено: архив скачан с ящика заново, его sha256 совпал побайтно; распаковано 43 файла; внутренний `SHA256SUMS` сошёлся на 42 записях (43-я — сам манифест); `reproduce.sh` и `preflight-r2.sh` прошли `bash -n` уже из скачанной копии.

СОСТАВ КОМПЛЕКТА: `reproduce.sh`, `preflight-r2.sh`, `MANIFEST.md`, `README.md`, `SHA256SUMS`; `config/` с `nginx.conf`, `nc_backend.conf.template`, `controller.env.template`, `redis.conf`, `timers.txt`, `identity-set-and-buckets.md`; `bin/` с `nc-upstream-controller`, `ready-verdict.mjs`, `nginx-wrapper`, `run-cron.sh`; `env/` с шаблонами `app.env.template` и `worker.env.template`; `units/` с юнитами и таймерами всех ролей.

ПРОВЕРКА НА СЕКРЕТЫ, выполненная мной ДО публикации: единственные вхождения имён секретных переменных — это плейсхолдеры `AUTH_SECRET=__AUTH_SECRET__` и `CRON_SECRET=__CRON_SECRET__` в шаблонах, плюс ссылка на переменную оболочки `$DB_PASSWORD` в `reproduce.sh`. Длинные шестнадцатеричные строки в комплекте — это коммит линии и отпечаток артефакта, то есть публичные идентификаторы. Настоящих значений нет.

КОМПЛЕКТ v1 НЕ УДАЛЁН — он остаётся на ящике как история, а v2 положен рядом с явной пометкой `supersedes`. Правило на будущее: комплект версионируется вместе с линией, старый не трогаем, новый кладём рядом, после публикации обязательно обратное чтение.

=== ОСТАТОК ПО ЭТОЙ ВОЛНЕ ===
Маркер `STANDBUILD2_DONE` волна снова не создала — третий случай на этой машине за смену. На содержание сдачи не влияет (отчёт, 26 файлов доказательств, манифест и бандл на месте), но волна не закрылась штатно. Требование создавать маркер вынесено в брифы отдельной строкой с объяснением; если повторится — буду разбирать, не ломается ли сам порядок закрытия на A2.

=== ЧТО ДАЛЬШЕ ===
Стенд стоит и доказан, прибор r3 принят. Остаётся одно: выбрать топологию генератора. Волна 4408 на Нео сейчас меряет, сколько виртуальных пользователей тянет ОДНА шестиядерная машина, оставаясь под пределом 50% — расчёт приёмки 4404 говорит, что даже десяти ядер может не хватить (`99.167 × 6 / 10 ≈ 59.5%`). Как только она ответит числом `MAX_VU_UNDER_50`, ставлю замер: десять пользователей в боевой конфигурации с обязательным измерением загрузки ядер САМОЙ ЦЕЛИ — того, чего не было ни в одном прошлом замере.