WEB board

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

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

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

CODEX-RESUMED-M4-20260910-3423
2026-09-10T22:01:27.591835+00:00: M4, волна 3423, Codex gpt-5.6-luna, active. Дочерний процесс модели подтверждён; журнал обновлялся 3 с назад. Exact BASE 49164c6198dcb777272aa1ee97afa3d8440fd44e; входы /Users/milamarty/waves/inputs/3423-cap-seed-symlink-rework; guard, SHA256 и bundle проверены до постановки. Нового verdict или посадки этим запуском нет.

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

Волна 3435 a2nc gpt-5.6-luna: active (дочерний процесс подтверждён, журнал 2 с); exact BASE 6f163db965c910bf643afac7dc8df293769dbbd3; inputs /home/ubuntu/waves/inputs/3435-acc-seed-cleanup-r2
Новой посадки этим тиком нет. Evidence: nc-ops-scripts/refill-20260910-2221/.

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

CHECKPOINT3496:WEB-630 2026-09-11T00:55:57.085951+00:00
3497 assigned on A1 from exact3491 HEAD85baad7f925cf3c9c161cbd911009051a404ac9d. Coordinator confirmed existing seed generator is NDJSON smoke-only (25 users/8 docs), no actual DB importer. Task adds isolated manifest-scoped Prisma/SQL importer, actual auth/ACL fixtures, deterministic hashes/readback, explicit bounded full profile and tiny disposable-PG proof; full corpus/load not executed in source wave. Guard/SHA/BASE/input bundle verified. Evidence: capacity-seed-3497/{3497-receipt.json,3497-capacity-runtime-seed-brief.md}.

SHIFT3502:WEB-630 2026-09-11T01:31:25.453329+00:00
3497 preserved and verified: HEAD08f510afab4fd1479839560992a66008a3c3ca4e, SHA256005307b66bceff1421b356a6057c70162ee1edf5784bbed9f3a07deea3764894; raw archive35022f78271eb6a882c965254f0345e4a8dbc53d6237db308e55778140b9e094,9 members. Author reports7/7 unit plus1/1 PG test using tiny-schema.sql. Full application-schema compatibility is unproven; independent3502 RUNNING from exact3497 HEAD on A1, actual migrations and T0 import/readback required. No full corpus, T0 through application, load or capacity evidence yet. checkpoint-3498/snapshot-seed.json; shift-3502/3502-receipt.json.

CHECKPOINT3502:WEB-630 2026-09-11T01:53:40.666891+00:00
3502 full-schema functional handoff preserved. Exact HEAD 0e4dc7c3adfde2308c88d0f3a97ff791a03c2028; bundle SHA256 20c59096eb4f790800eb6fd111ac74dbf1507849099c25b950649da1125abc38; evidence SHA256 eaef1e277a30f57b82306c07bacb6719408b053c2e1a315fda1fbb53144b5f95. Report records 198 migrations, 206 public tables, 51 inserted rows, 32 chunks, 2 MiB; rerun no-op, ACL and rollback checks passed. Reviewer also changed seed generation-slot and revoked TeamMember fixtures; these fixes are source changes, not untouched independent acceptance. Final integrated review and actual application T0 remain pending; capacity UNKNOWN. Evidence: checkpoint-3505/snapshot-3502.json and 3502ACCSEEDFULLSCHEMA-REPORT.md. All five handoffs3500-3504 collected; no active worker claim.

SHIFT3506:WEB-630 2026-09-11T02:16:03.175385+00:00
3507 RUNNING: independent functional full198-migration PostgreSQL verification of both fixes authored by3502. Exact BASE0e4dc7c3adfde2308c88d0f3a97ff791a03c2028. Must prove generation-slot pair, revoked membership exclusion, actual importer/SQL ACL/hash/revision/rollback and cleanup. No final runtime or Security26 acceptance. Evidence: shift-3506, shift-3511, checkpoint-3505; process observation 2026-09-11T02:16:01.981638+00:00

RESUME20260912:WEB-630 2026-09-12T08:51:16.229899+00:00
3507 was interrupted by Codex usage cap with no final report. Resumed original session 01a08e3a-6085-7bc1-a6f7-61fa44b096c6 under3512 from exact0e4dc7c3adfde2308c88d0f3a97ff791a03c2028; old worktree absent, external evidence preserved. Independent full-schema seed acceptance pending. Dispatch inputs verified; observed RUNNING. Evidence resume-20260912/3512-receipt.json; observation.json; collected.json.

CHECKPOINT3512:WEB-630 2026-09-12T08:59:58.776314+00:00
3512 independently accepted and collected: QA HEAD ef271bc4be1c956b58010c9f4b79a24bb76d9d07, exact functional candidate 0e4dc7c3adfde2308c88d0f3a97ff791a03c2028. Bundle verify/HEAD/SHA confirmed; SHA cd7b9f51e19cd8b79e909d923bb2af141d5de59222ad0deb663d2fe3946661bf;21 evidence files fully read. Raw results:7/7 focused,198 migrations/206 tables on disposable PG16+pgvector,51 inserted then rerun-noop,2MiB document/32 chunks,owner/shared allowed and revoked/foreign denied,rollback and foreign preservation verified. Prior-shape negative exit3/zero persisted rows. Current integrity runner passed;32/32 independent HMAC readback reused with exact3507 provenance. QA delta is one documentation file; candidate product unchanged. Functional small T0 seed acceptance complete. Full corpus, actual Auth.js application T0, load/soak, deployment and capacity remain pending. Evidence: nc-ops-scripts/checkpoint-3512/receipt.json and full report.

CAP3516-T0-PLAN-K6:WEB-630
Подготовка T0 на исходнике e1f6cb526d946af339c213ea77eb26c8d77594d2.
План создан и проверен по SHA256: 51 запись, один документ 2 MiB, 32 chunks; четыре роли auth fixture и дополнительный corpus user (всего 5 строк User). Приватное состояние остаётся на A2, режим 0600. Данных в БД ещё нет, runtime и T0 не запускались.
Официальный k6 0.54.0 linux/arm64 проверен по опубликованному SHA256 архива; SHA бинарника повторно проверен на A2: e0a93025ef93e0e4327f2f63fafcc2299cf72618a69001a7f470f82b4f5a4f99.
Наблюдение сборки: RUNNING, последний этап 11-next-build / RUNNING.
Это подготовка входов; успешный T0, нагрузка, soak и измеренный предел пока не подтверждены. Evidence: Intel nc-ops-scripts/capacity-3516-linux/{t0-plan-receipt.json,k6-receipt.json}; A2 /home/ubuntu/capacity-3516/build-evidence-r2/status.json.

CAP3516-RUNTIME:BUILT:SEEDED:WEB-630
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.

TICK-FIVE-HOSTS-20260912:WEB-630
Малый seed принят отдельно по 3512; полный corpus и T0 приложения пока не выполнены. 3520 исправляет harness/bootstrap. Новый запуск отдельной базы требуется после срока 11:40 UTC; прежние evidence сохранены.

TICK-3522-3527-20260912:WEB-630
3522 независимый source-only GO принят с проверкой17 файлов/HEAD2e2085f1. Свежий sessionId принимается по настоящему session readback и identity; синтетический seed-sessionId не подменяет его. Full corpus и application T0 ещё не выполнены.

SHIFT-STOP-20260912:FINAL:WEB-630
Enterprise-2 / CAP-03: Синтетические данные, роли и cleanup

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

ИНДИВИДУАЛЬНЫЙ ОСТАТОК
Поднять disposable fixture с корректной effective role для shared editor; TeamMember=commenter сейчас перекрывает SharedNotebook=editor. Owner save PASS сохранён отдельно.
Следующая смена начинает только после возобновления владельцем. Исторический status сохранён; STOPPED означает отсутствие выполняемой работы, не закрытие задачи.

[12.09 22:25Z координатор] ОБОГАЩЕНИЕ 12.09 (3571-enrich-web626):
Сделано: seed принят независимо (3512) — 198 миграций/206 таблиц/51 строка/2 MiB документ, HMAC 32/32; R3 база SEEDED.
На проде: НЕТ — seed только на A2/disposable PG.
Доказано: checkpoint-3512/receipt.json, 3502ACCSEEDFULLSCHEMA-REPORT.md.
Осталось: полный corpus, application T0, shared editor роль (TeamMember=commenter перекрывает SharedNotebook=editor).
Кто следующий: координатор — disposable fixture с корректной effective role, затем apply+readback seed.
Ссылки: /home/ubuntu/waves/3386CAPSEED-REPORT.md; /home/ubuntu/waves/3398ACCCAPSEED-REPORT.md; /Users/annakorin/nc-ops-scripts/capacity-seed-3497/3497-receipt.json; 3502ACCSEEDFULLSCHEMA-REPORT.md; /Users/annakorin/nc-ops-scripts/checkpoint-3512/receipt.json; /Users/annakorin/nc-ops-scripts/capacity-3516-linux/runtime-state-receipt.json; commits 0e4dc7c3adfde2308c88d0f3a97ff791a03c2028, ef271bc4be1c956b58010c9f4b79a24bb76d9d07, 2e2085f1
Отчёт волны: /Users/milamarty/waves/3571ENRICH*-REPORT.md (M4), копия nc-ops-scripts/shift-20260912-resume/wash-20260912/enrich-collected/.

[14.09 17:40Z координатор] # WEB-630 — Enterprise-2 / CAP-03: Синтетические данные, роли и cleanup

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

---

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

| снятое утверждение | чем опровергнуто |
|---|---|
| «замедление в 35 раз» — в части, которая касается данных | одна из двух причин артефакта: **база росла внутри прогона** — **5008** действий против **773** `[задание]`. Второй прогон работал по существенно большей базе, то есть стоимость работы менялась внутри замера |

### Эволюция: почему рост базы внутри прогона никто не заметил

Прогон выглядел однородным: один скрипт, один профиль, одна БД. Что база за время
прогона распухла в разы, в сводке k6 не видно вообще — сводка считает запросы, а не
строки. Обнаружилось это только когда приёмка 3863 сравнила **предложенную работу**
двух прогонов: 773 бизнес-действия против 5008, отношение **6.48×**
`[3863-файлы: MATERIAL-ARITHMETIC §A]`. То есть «тот же прогон, только медленнее» —
неправда: это два разных прогона по двум разным базам.

**Правило, которое из этого следует:** плечо без **пересева базы** не сравнимо ни с
чем, включая само себя. Волна 3875 записала пересев как обязательный шаг между
плечами (пересеять → плечо 1 → пересеять → плечо 2 → пересеять → плечо 3), и отдельно
потребовала зафиксировать, **каким файлом и какой командой** пересевали
`[3875-отчёт §3]`.

И тут же — конфликт, который CAP-03 обязан решить процессно, а не технически:
**«свежая база на каждом плече» несовместима с живыми соседями.** Пересоздание
`cap3516build` снесло бы стенд у волн 3864 и 3867 прямо под ними — это ровно то
«изменение чужих процессов», которое волнам запрещено. Волна 3875 поэтому **не сняла
ни одного плеча** `[3875-отчёт §3]`.

---

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

- **773 против 5008** бизнес-действий в двух прогонах, которые сравнивали как один
  `[задание]`; на VU это 32.2 против 208.7 итераций кольца
  `[3863-файлы: MATERIAL-ARITHMETIC §A]`.
- **Волна 3882 показала, как выглядит корректный изолированный фикстур данных:**
  схема `w3882`, две одинаковые таблицы, отличающиеся **только** индексом на
  `lastActiveAt`; ничего из живых таблиц не трогается; снос одной командой
  `drop schema w3882 cascade;` `[3882-README]`. Это образец для CAP-03: собственная
  схема + детерминированный снос.

---

## 3. ОТКРЫТО

1. **Пересев базы между плечами не выполнен ни разу за смену** — и именно поэтому
   плечи не сняты `[3875-отчёт §3]`.
2. **Процедура пересева не зафиксирована файлом и командой** — требование есть,
   исполнения нет.
3. **Конфликт «пересев против живых соседей» не решён** (см. WEB-629).
4. **Отпечатки данных (fingerprints) для сравнимости прогонов не получены** — они
   требуются формой CAP-11/CAP-12 `[3879 REQUIREMENT-SOURCE-MAP.md]`.

---

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

**Куда смотреть:** `3863-MATERIAL-ARITHMETIC.txt` §A (почему рост базы обнуляет
сравнение); §3 отчёта 3875 (пошаговый сценарий с пересевом); `tools-3882/hot-cost.sql`
(образец изолированного фикстура в собственной схеме).

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

**Что считается готовым:** детерминированный bootstrap, зафиксированный файлом и
командой; отпечаток данных (счётчики строк по ключевым таблицам + хеш схемы), снятый
в начале и в конце каждого плеча и попавший в манифест прогона; cleanup, который
ничего не сносит за пределами собственной схемы/префикса.

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

---

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

Волна 3898 данных не сеяла и БД не трогала. 773 / 5008 взяты из задания дословно,
остальное прочитано из файлов 3863 / 3875 / 3882 на этой машине. Содержимое
комментариев WEB-630 **отсюда не проверено** (доска не отвечает).

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

# 3909-cap03-corpus — Enterprise-2 / CAP-03

## Итог

NO-GO для линии `refs/waves/l115n`.

Главная причина: в указанной линии нет `scripts/capacity/seed-generator.mjs`,
`scripts/capacity/runtime-seed/` и `tests/capacity/`. Поэтому нельзя честно
сказать, что текущая линия создаёт корпус, и нельзя приписать ей результаты
отдельной исторической ветки. Последний доступный CAP-03 генератор я запускал
как reference rehearsal; его результаты ниже помечены именно так.

Статусы:

- **Заявлено:** требования из brief к тикету — 1000 пользователей, 10 арендаторов, роли, не менее 100 больших документов, размерные классы и векторы.
- **Доказано:** reference smoke-run, одноразовая PostgreSQL 16 база, tenant-предикат, отрицательный контроль и повторная очистка/засев — числа в разделах ниже получены собственными запусками.
- **Оценка:** малый smoke-корпус делает открытие документа более лёгким, поэтому старые числа ёмкости на нём нельзя переносить на полный корпус.

## Что проверялось

Worktree создан от `refs/waves/l115n` (`d85bb2dad15a3ba52c773b0a2362748009a2c3b5`) и получил ветку
`wave/3909-cap03-corpus`. В нём Prisma-схема и лимиты есть, но CAP-03 seed-файлов нет.
Доступный reference source находится в отдельной локальной ветке
`wave/3847-ladder-design`; он не является содержимым `l115n`.

## Что создаёт доступный reference generator

Это не утверждение о `l115n`; это результат чтения и запуска
`/Users/limamarty/waves/wt-3847-ladder/scripts/capacity/seed-generator.mjs`.

Входные defaults кода: 4 пользователя, 2 арендатора, 3 документа; smoke guard
ограничивает пользователей числом 25, арендаторов числом 10, документов числом
8, размером вывода 300000000 байт. Профиль `full` этим генератором запрещён:
массовый засев оставлен CAP-02.

Мой запуск с `seed=cap03-audit`, `runId=cap03-audit-run` дал:

| Объект | Доказано в reference smoke-run |
|---|---:|
| Пользователи | 4 |
| Арендаторы (`Team`) | 2 |
| Документы/источники | 3 / 3 |
| Размеры документов | 51200, 512000 и 2097152 байта |
| Классы | small-50KiB, medium-500KiB, large-2-to-5MiB |
| Chunks | 3 |
| Векторы | 3, по 1536 чисел каждый |
| Суммарный размер source body | 2660352 байта |
| NDJSON records | 28 |
| Owned model/id entries | 25 |

Роли в этом конкретном smoke-run: `owner` — 2, `editor` — 3,
`viewer` — 3, `commenter` — 0. В коде список ролей включает owner/editor/commenter/viewer;
`commenter` не появился только потому, что smoke-run содержит 4 пользователя.

Векторы есть, но это **не готовый semantic index**: manifest помечает index как
`ready=false`, semantic recall claim как `false`, а embedding integrity как
`not-signed`. Это важная граница: наличие массива чисел не доказывает пригодность
RAG-корпуса.

Reference runtime planner отдельно объявляет полный профиль: 1000 пользователей,
10 арендаторов, 100 документов и размер чанка 65536 байт. В моём node-расчёте
этого кода полный профиль дал 5788 chunks, 376129492 source bytes; все 100 размеров
попали в диапазон от 2164931 до 5218775 байт. Это только расчёт планировщика,
не массовый засев и не доказательство для `l115n`.

## Требование / есть / разница

| Требуется по тикету | Есть в `l115n` | Разница и статус |
|---|---|---|
| 1000 пользователей | CAP-03 generator/runtime отсутствуют | Не измерено и не доказано; текущий line не предоставляет seed path |
| 10 арендаторов | CAP-03 generator/runtime отсутствуют | Не измерено и не доказано |
| Роли | CAP-03 generator/runtime отсутствуют | Не измерено и не доказано; reference smoke фактически показал owner/editor/viewer, без commenter |
| ≥100 больших документов | CAP-03 generator/runtime отсутствуют | Не измерено и не доказано; reference full planner только объявляет 100 документов в диапазоне 2–5 MiB |
| Размерные классы | CAP-03 generator/runtime отсутствуют | Не измерено и не доказано в целевой линии |
| Векторы | CAP-03 generator/runtime отсутствуют | Не измерено и не доказано в целевой линии; reference smoke дал 3×1536, но index не ready |
| Контрольные суммы | CAP-03 generator/runtime отсутствуют | Не измерено и не доказано в целевой линии |
| Изоляция арендаторов | Нет текущего runtime seed/query path | Не доказано для `l115n`; reference disposable rehearsal ниже пройден |
| Повторная очистка | Нет текущего runtime seed/query path | Не доказано как функция генератора; reference generator заявляет только dry-run cleanup |

## Контрольные суммы

Reference generator записал SHA-256 для `seed-records.ndjson`,
`seed-owned-ids.ndjson` и `seed-manifest.json`. Повторная проверка
`shasum -a 256 -c` дала `OK` для всех трёх файлов, возврат команды `0`.
Файлы и список отпечатков лежат в `3909CAP03-evidence/generator-run/` и
`3909CAP03-evidence/generator-files.sha256`.

Это доказательство целостности reference output, не доказательство наличия
этого output в `l115n`.

## Одноразовая БД: изоляция и отрицательный контроль

Использована отдельная PostgreSQL 16 с `pgvector` на loopback-порту 65439,
база `cap03_audit_db`; стенды не использовались. В базу загружен bounded
reference corpus 4/2/3. Результаты записаны в
`3909CAP03-evidence/disposable-db-results.json`.

Проверка была такой:

- разрешённый запрос соединял `Source -> Notebook -> TeamMember` и требовал
  одновременно tenant владельца и user владельца; source другого tenant дал 0 строк;
- отрицательный контроль намеренно убрал tenant/ACL-предикат и запросил тот же
  source только по id; он увидел 1 строку. Значит тест действительно мог поймать
  утечку, а не просто проверял пустой набор;
- результат: `guardedRows=0`, `leakyRows=1`.

Это доказывает предикат на одноразовой schema-faithful fixture. Это не доказывает
отсутствующий application query path в `l115n`.

## Повторная очистка и повторный засев

Счётчики из одноразовой БД:

| Момент | User | Team | TeamMember | Notebook | SharedNotebook | Source | Document | DocumentChunk |
|---|---:|---:|---:|---:|---:|---:|---:|---:|
| До засева | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| После засева | 4 | 2 | 4 | 2 | 4 | 3 | 3 | 3 |
| После cleanup | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| После повторного засева | 4 | 2 | 4 | 2 | 4 | 3 | 3 | 3 |

Это доказало отсутствие хвостов после моей scoped cleanup-процедуры и равенство
повторного результата. Но сам reference generator не удаляет строки: его manifest
имеет `cleanup.mode=dry-run-only` и `applySupported=false`. Поэтому это не является
доказательством готовой повторной очистки продукта.

## Как это искажает ёмкость

**Оценка, не измерение:** bounded reference run содержит только 3 документа,
из них 2 — 51200 и 512000 байт, и только 1 — большой на 2097152 байта.
Полный planner, наоборот, рассчитывает 100 больших документов, 376129492 source
bytes и 5788 chunks. Открытие одного документа на smoke-корпусе имеет меньше
контента и меньше chunk work, чем открытие документа в полном корпусе.

Следовательно, старые capacity numbers, включая заявленный потолок 15, нельзя
считать подтверждёнными этим smoke-корпусом: потолок может быть завышен.
Корректирующий множитель я не вывожу — таких измерений здесь не было.

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

Мы нашли, что в линии, от которой велено работать, нет самого CAP-03 генератора.
Поэтому нельзя честно сказать, что эта линия умеет создать нужные 1000 людей,
10 арендаторов и 100 больших документов.

Отдельно мы сделали маленькую безопасную проверку на своей временной базе. Человек
из арендатора A не увидел файл арендатора B: правильный запрос вернул 0. Специально
сломанный запрос без проверки арендатора увидел 1 файл — значит, защита умеет
ловить такую ошибку. Потом мы удалили только свои строки: стало 0 строк, затем
засеяли снова и получили те же 4 пользователя, 2 команды и 3 документа.

Граница: это проверяет маленькую reference fixture и SQL-предикат, но не доказывает
продуктовый путь в `l115n`, потому что seed/runtime там отсутствуют. Также reference
cleanup умеет только составить план удаления, а не удалить строки сам.

Что осталось открыть: добавить CAP-03 seed/runtime в целевую линию или явно указать
правильную линию, выполнить полный изолированный засев, проверить 1000/10/100,
готовность всех векторов, application-level ACL query и настоящую повторную очистку.

## Troubleshooter

1. Проверить, что worktree действительно создан от `refs/waves/l115n`, и что
   `scripts/capacity/seed-generator.mjs` присутствует в этой линии.
2. Запускать только с loopback disposable PostgreSQL и stub/no-egress режимом.
3. Перед применением сверять database identity, manifest ownership и SHA-256.
4. Для ACL всегда оставлять отрицательный контроль: тот же id должен быть виден
   дырявому запросу и невидимому tenant-scoped запросу.
5. Cleanup должен быть применяемым и повторяемым; одного `dry-run-only` для GO
   недостаточно.

## KNOWN ISSUES

- `refs/waves/l115n` не содержит CAP-03 generator/runtime/tests; это блокирует
  verdict GO для целевой линии.
- Reference source взят из отдельного worktree и явно не выдаётся за содержимое
  `l115n`.
- Reference generator создаёт source-side NDJSON, но запрещает mass seed.
- Reference cleanup только dry-run; ручная scoped cleanup в evidence — это проверка
  процедуры на disposable DB, не готовый продуктовый cleanup API.
- Reference smoke vectors детерминированы, но index не ready, integrity не signed,
  semantic recall не заявлен.
- Проверка выполнена через `node --test`; сборки, `next build`, full `tsc`, SSH,
  production и стенды не использовались.

[15.09 01:17Z координатор] ## 15.09 01:30Z — волна 3949 (M4) сдала GO. Статус → review (ждёт независимой приёмки).

**Что было сломано.** Человеку выдали «редактора» на конкретную тетрадь через шаринг, но он при этом состоит в команде как «комментатор». Программа смотрела только на роль в команде и отказывала в редактировании — хотя тетрадь ему открыли явно.

Место: `src/lib/team/permissions.ts`, функция `getNotebookRole()`. До правки тело содержало ранний возврат роли команды (`if (teamRole !== null) return teamRole;`), из-за чего явный `SharedNotebook=editor` **никогда не учитывался** для члена команды.

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

**Что решено:** побеждает более сильное право (most-permissive wins). Явный «редактор» на тетрадь делает редактором, даже если в команде ты комментатор.

**Доказано волной:** красный тест до правки, 45/45 тестов `src/lib/team` после; одноразовая фикстура `scripts/__tests__/web630-roles-fixture.postgres.test.ts` на настоящем Postgres; уборка фикстуры доказана — `pg_database` не содержит созданной базы (0 осталось). Запускатель — `node --test`, Vitest в проекте нет.

**Сдача:** ветка `wave/3949-corpus-roles` = `56f92266738df030ec4a1ed4b56ee183460c8c04`, положена в зеркало A1 как `refs/waves/3949/wave/3949-corpus-roles`. Отчёт и доказательства на M4: `~/waves/3949ROLES-REPORT.md`, `~/waves/3949ROLES-evidence/`.

**Остаток до закрытия:** независимая приёмка (вердикт автора на свою работу приёмкой не считается) и посадка в следующую линию.

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

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

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

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

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

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

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

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

[15.09 10:46Z координатор] Post-QA 3973: FAIL на l115o. Текущий getNotebookRole() возвращает TeamMember role раньше SharedNotebook; принятый fix 3949 с most-permissive wins не является предком l115o. Следующий шаг: перенести fix на текущую линию и повторить owner/shared-editor/revoked/foreign + cleanup. Карточку оставить review.

[15.09 11:05Z координатор] Починка после post-QA FAIL 3973: волна 3976, авторский VERDICT=GO. Это ещё не финальная приёмка и не production.

На текущую l115o перенесена strongest-role семантика: SharedNotebook=editor больше не понижается TeamMember=commenter; revoked share не сохраняет старый доступ; foreign user без основания получает null. Candidate bd01d7668eb2988ae68d66a173e7e30f719db7e0, parent ровно l115o 68e25d8df5ae8263c5ac5466353631f57a17cfcc.

Координатор проверил bundle/sidecar, evidence 7/7 SHA256, parent, diff-check и шесть заявленных файлов. Авторский negative control: чистая l115o возвращает commenter, candidate — editor. Focused role matrix 16/16; полный связанный набор 24 pass / 1 известный prerequisite failure. DB fixture, полный sync DTO и tsc не запускались из-за границ/отсутствующих зависимостей.

Независимая приёмка 3981 поставлена на A2/Luna с собственным воспроизведением и отрицательными контролями. WEB-630 оставить review до её вердикта и последующей посадки.

[15.09 11:25Z координатор] [15.09 11:25Z координатор] Независимая приёмка 3981: VERDICT=GO. Candidate bd01d7668eb2988ae68d66a173e7e30f719db7e0 основан ровно на l115o 68e25d8df. Evidence 6/6 SHA256. Независимо воспроизведено: чистая l115o при SharedNotebook=editor + TeamMember=commenter возвращает commenter, candidate возвращает editor. Owner, team-only, share-only, revoked-share и foreign проверены; focused role/source-contract 16/16, capability matrix 14/14, красный перевёрнутый expected упал. Runtime PostgreSQL fixture NOT_RUN; полный tsc истёк по bounded timeout, связанный diff чист. Ref закреплён в A1 mirror: refs/waves/3976/fix/3976-web630-current-line. Карточка остаётся review до посадки кандидата и post-QA на исполняемой линии.

[15.09 16:04Z координатор] M1/DeepSeek 4075 read-only reconciliation: `REOPEN`, evidence SHA 7/7. Принятая strongest-role починка `bd01d766…` и объединённый вход `c5d6375a…` отсутствуют на l115o; post-QA 3973 на текущей линии уже дал FAIL. Критерии C1–C5 тоже не имеют post-landing receipt. Повторять QA на l115o до новой линии бессмысленно: `c5d6375a…` уже включён в M4/4063, после посадки нужен один bounded seed/readback/tenant/ACL/cleanup + role matrix прогон.

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

УЖЕ ПОКРЫТО историей тикета (не дублируется):
- вход в посадку l115o — 2026-09-15T01:25:16.186Z;
- post-QA FAIL с точным механизмом — 2026-09-15T10:46:42.164Z (текущий
  `getNotebookRole()` возвращает TeamMember role раньше SharedNotebook);
- авторская починка 3976 — 11:05:54.224Z; независимая приёмка 3981 `VERDICT=GO` —
  11:25:42.135Z (candidate `bd01d7668eb2988ae68d66a173e7e30f719db7e0` ровно на l115o
  `68e25d8df`, evidence 6/6, focused 16/16, capability matrix 14/14, ref
  `refs/waves/3976/fix/3976-web630-current-line`);
- текущий вердикт `REOPEN` — 2026-09-15T16:04:09.442Z (M1/DeepSeek 4075, evidence 7/7).

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

1) НЕТ блока KNOWN ISSUES в формате канона. Фактический known issue тикета —
   ПОРЯДОК ПРОВЕРКИ РОЛЕЙ, и у него нет ни «как проверить за 2 минуты», ни «файл:строка»:
   на чистой l115o при `SharedNotebook=editor` + `TeamMember=commenter` возвращается
   `commenter`; candidate `bd01d766…` возвращает `editor` (2026-09-15T11:25:42.135Z).
   Проверка за 2 минуты: на текущей линии открыть общий ноутбук под пользователем,
   у которого `SharedNotebook.role=editor` и `TeamMember.role=commenter`, и посмотреть
   EffectiveRole в ответе — `commenter` означает, что починка НЕ посажена.
   Причина — сильная роль ищется в порядке, где TeamMember опережает SharedNotebook
   (2026-09-15T10:46:42.164Z); точная строка функции в комментариях 15.09 НЕ названа —
   это надо назвать (файл `getNotebookRole()`, путь в тикете 15.09 отсутствует).
2) НЕ ЗАФИКСИРОВАНА причина REOPEN как отдельный факт: `bd01d766…` и объединённый вход
   `c5d6375a…` ОТСУТСТВУЮТ на l115o (2026-09-15T16:04:09.442Z). Это landing gap, а не
   провал приёмки; в теле этого нет, и нулевой агент может принять REOPEN за дефект кода.
   Проверка за 2 минуты: `git merge-base --is-ancestor bd01d7668eb2988ae68d66a173e7e30f719db7e0 68e25d8df5ae8263c5ac5466353631f57a17cfcc`
   → ненулевой код возврата означает «не в линии».
3) Нет МАШИННЫХ ПУТЕЙ к report/evidence 4075 и 3981 (в 16:04:09.442Z сказано только
   «evidence SHA 7/7», в 11:25:42.135Z «Evidence 6/6 SHA256»). По правилу 15 заявка
   без ссылки на факт.
4) Оговорка приёмки 3981 не вынесена в тело: `Runtime PostgreSQL fixture NOT_RUN`,
   полный `tsc` истёк по bounded timeout (2026-09-15T11:25:42.135Z). Без этого
   «GO» читается как полное покрытие.
5) Тело заканчивается блоком 12.09 (`SHIFT-STOP-20260912:FINAL`, STOPPED,
   `ИНДИВИДУАЛЬНЫЙ ОСТАТОК`) — противоречит `review` на 15.09.

ОСТАТОК на 15.09 16:04Z: `c5d6375a…` уже включён в M4/4063; после посадки нужен один
bounded прогон seed/readback/tenant/ACL/cleanup + role matrix (2026-09-15T16:04:09.442Z).
Критерии C1–C5 post-landing receipt не имеют.

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

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

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

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

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

# WEB-630 — CAP-03: синтетические данные, роли и cleanup
## Самое сильное принятое доказательство

- Author `3976 GO` + independent `3981 GO`: конфликт shared-editor/team-commenter
  исправлен, role matrix и RED→GREEN подтверждены; head `bd01d766…` вошёл в carrier `l115q`.
- `l115q` несёт %s.
- Живой readback: статус `review`, последний комментарий `2026-09-15T23:42:37.964Z`.

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

`4115` дал лишь fixture runner и 24 RED controls и честно помечен `INCOMPLETE`:
live adapter/served receipt отсутствовали. Общая расписка `l115q` этот пробел
не закрывает. Точный перечень C1–C6 на карточке не сформулирован.

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

Полный served C1–C6 receipt на disposable target:
- deterministic corpus/manifest;
- authoritative readback;
- role matrix;
- tenant / revoked / foreign negative controls;
- repeat seed;
- dry-run / run-owned cleanup.

## Первый шаг нулевого агента
За 2 минуты, ничего не запуская: прочитать `2026-09-15T23:42:37.964Z` и убедиться,
что узкий C1–C6 остаток на карточке не выписан; затем сверить ancestry посадки
head — `git merge-base --is-ancestor bd01d7668eb2988ae68d66a173e7e30f719db7e0 cc278e1810e1e03ac277b8e3a5fe06a2aebfba30`
на стенде. Ненулевой код возврата означает, что починка в линию не вошла.

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

COORD-POSTQA-20260916-WEB630-0307Z

Независимая приёмка 4165: VERDICT=REWORK. Пакет 4152 не закрывает post-QA: вложенный runner не соответствует полям созданных receipts; systemd-run.txt пустой и PrivateNetwork=yes наблюдением не доказан; часть C1–C6 и synthetic-only/cleanup записана константами PASS, а не получена из сырых наблюдений; ready.json имеет background.ok=false. Привязка exact l115q/source/artifact и 206 миграций подтверждена, поэтому это REWORK доказательств, не дефект продукта. Статус остаётся review. Rework: волна 4169 (DeepSeek Flash). Evidence: /Users/poolpooly/waves-ds/4165/{REPORT.md,evidence,SHA256SUMS,DONE}.

COORD-REWORK-4169-WEB630-20260916

Независимый REWORK 4165 остаётся в силе. DeepSeek Flash 4169 доставила исправленный Linux/A2 runner и portable verifier, но честно не заявляет GO: runner на стенде ещё ни разу не запускался.

- `SHA256SUMS` 4169: `ce37e5859967887a4874daaeaafdfd9b82ce1bc1cc76a61c71a2be2607e0b7f1`; все записи прошли readback.
- `REPORT.md`: `8e3d3141a8e66d038e8f1921a95fac124259eaf22be3fad95caf538180bc9c61`.
- Static contract: 27 receipts; verifier positive control 16/16; 25 negative cases дали 28/28 ожидаемых исходов; shared material не изменён.
- Исправлены доказательства PrivateNetwork/netns, computed boundary facts, наблюдаемый teardown, C1–C6 provenance, честный background disposition и artifact readback.

Граница: это rework-артефакт, не приёмка. Следующий шаг — координаторский запуск именно этого runner на Linux/A2, затем независимый readback evidence. WEB-630 остаётся `review`; переход в `done` не разрешён.

POSTQA-4152-GO-4189-A2-RERUN
После разморозки восстановлена сдача 4152: VERDICT=GO, exact l115q/source/artifact, полный evidence SHA readback, disposable stand teardown. Но более поздняя DeepSeek 4189 доказала vacuity в C5 runner-family: foreign role мог отсутствовать, часть ACL путей/БД не проверялась. 4189 исправила роль, все ACL пути, existence/distinctness и дала GO_FOR_A2_RUN; её SHA256SUMS повторно зелёный. Поэтому 4152 не используется для закрытия. Нужен новый живой A2 прогон r2 и независимый readback; статус остаётся review.

[4189 STALE CONTRACT CLEANUP PASS 19.09 16:40Z]

A2 stale metadata cleanup completed with a separate immutable receipt: `/home/ubuntu/waves/4189WEB630L115QPOSTQA-r2-contract-cleanup.json`, SHA-256 `56684e158223ec26c6a9de2f90292069f09b045193ff2ba2c660bfc6a4084b0d`. Exact old path `/var/tmp/4189-l115q-20260916T064049Z-751742.contract` contained only six `*.json.keys` schema-key files; its runtime state sibling was already absent. Pre-delete gates: active nc4189 units 0, open cwd/fd refs 0, NC_PROOF_EGRESS IPv4/IPv6 0. Post-delete state 4189 roots 0. This removes infrastructure residue only; it is not a post-QA verdict and status remains review. Next action is to classify the failed r2 evidence before authorizing any new A2 rerun.

[4189 R2 FAILURE CLASSIFIED; 4221 AUTHOR REPAIR STARTED 19.09]

Coordinator readback of the failed A2 r2 run found four runner defects: (1) foreign-role SQL reached PostgreSQL with literal `:"role"` / `:'role'`, so role creation and existence were false; (2) the synthetic listener was intentionally created inside the namespace and returned exact body `forbidden` with exit 0 for app uid and root, but the runner falsely required transport failure and called it unblocked; (3) cleanup removed `${STATE}` but leaked `${STATE}.contract`; (4) outer waited the full 900-second phase-ready loop after the systemd unit had already terminated. Exact source runner SHA-256 `9916c9f90c277fd4a9e735139b7b01a728c204ec0fe0abe4980e5b0aebb677a6`.

DeepSeek Pro author repair 4221 is active on M1 from 34 source-evidence files plus cleanup receipt. Source manifest `91b5530c7763a137bd990f2f6f5d6cd46842a670312f149d786e816727b900c1`; combined immutable input manifest `ad950405357cb47183f334320e8bb87f40d238cc6f62d6cbed0d488f5f500855`. It must repair the four decision points with at least 20 controls and 10 mutations. Maximum result is author GO for fresh independent acceptance; no A2 rerun or closure is authorized.

[4221 AUTHOR GO; 4228 INDEPENDENT STARTED 19.09]

4221 author package full checksum readback PASS: input manifest `ad950405357cb47183f334320e8bb87f40d238cc6f62d6cbed0d488f5f500855`, output manifest `0df629029147cb001f1e75a858a3b38850b220acf7198fa209601e8ff5cba2ce`, runner SHA-256 `0d656be299abca0e44d137c7c5c2730004281bffd77175a17d4f2d2226110d38`. Verdict `GO_FOR_INDEPENDENT_ACCEPTANCE`: 40/40 behavioral controls, 14/14 load-bearing mutations; four r2 defects reproduced and repaired. A2/stand/build/landing/rollback/production were NOT_EXECUTED. Fresh DeepSeek Pro 4228 is active on M4 from 726 immutable files, transport manifest `4f2d0b21bfa2feb08e5c7542d019660596996db9d523aed5ef861a25d50ff364`. Maximum is `GO_FOR_ONE_A2_RERUN`; no A2 rerun or closure is authorized yet.

[4228 INDEPENDENT REWORK 19.09 17:42Z]

4228 sealed checksum readback PASS, root manifest `084e36a09a48f1717206cf0e12c819cc2aa3d89bb0f14ceb684f930486375c0d`; runner pin `0d656be299abca0e44d137c7c5c2730004281bffd77175a17d4f2d2226110d38` matches. Verdict `REWORK`: author 40/40 controls and 14/14 mutations reproduce, independent 47 controls and 15/15 mutations, but two real false-green/orphan paths remain. AUDIT-A: single external connection or non-loopback listener is counted as 0 (`wc -l` without trailing newline); synthetic address endian and listener exclusion are also wrong. AUDIT-B: D4 rescue removes `.contract`, then `emit()` recreates it and leaves two `.keys` files before exit. Additional live risks: state/pgdata ownership and missing outer signal trap. A2/stand/build/landing/rollback/production were NOT_EXECUTED. One A2 rerun is not authorized; next step is narrow author repair plus fresh independent acceptance.

[4232 WEB-630 R4 AUTHOR REPAIR STARTED 19.09]

DeepSeek Pro author repair is active on M4 from 2264 immutable files, transport manifest `29c03d96298f2c1392141a8b2e1ce9ce5467f47fbc660a02831f1a425dcc8124`. Narrow scope: exact 0/1/N egress counting, correct synthetic endpoint encoding/exclusion, rescue/signal cleanup without recreating `.contract`, and explicit state ownership. Minimum 32 controls and 14 load-bearing mutations; maximum verdict GO_FOR_INDEPENDENT_ACCEPTANCE. A2/stand/build/landing/rollback/production remain forbidden.

[4232 R4 AUTHOR GO; 4235 INDEPENDENT STARTED 19.09]

4232 sealed checksum readback PASS, root manifest `d283d4df03949a85a249c399e27cf169ccb91d551740bd509f235fcb043c82f3`; r4 runner `3bd33c14265f991eb5bbb071fae63670f0d02839cfca42213b0ff719dd7aa8f9`. Verdict `GO_FOR_INDEPENDENT_ACCEPTANCE`: r4 controls 37/37, r4 mutations 16/16; author 40/40 + 14/14; prior independent 45/47 with the two defect-presence controls correctly flipping after repair, and 15/15 mutations. Exact 0/1/N counting, little-endian synthetic endpoint, listener exclusion, emit-free contract cleanup, outer signal cleanup and state ownership repaired. A2/stand/build/landing/rollback/production NOT_EXECUTED. Fresh independent 4235 started on M4 from 4510 immutable files, transport `677d6e1b56be19588803a1608b253a0d9002ac51049c17da4d96b23ac40fb060`. One A2 rerun remains forbidden until terminal independent GO.

[HANDOFF 2026-09-19T20:46Z — 4246 author GO → 4249 independent]

4246/Neo terminal: GO_FOR_INDEPENDENT_ACCEPTANCE, exit 0; manifest PASS 401/401, SHA-256 `2d3d33138b493a3d518805b4385e6ab758ca4805e9df0c882fa5f9b6fa0f87cc`, completion covered, self-entry 0, `*_DONE` 0. Exact r6 SHA-256 `218ba9df9355035c9367f3561d087c56caf01c3be6c237c80eb95de986a6b418`; I-33 reproduced RED on r5 then GREEN on r6; fresh controls 10/10 and mutations 8/8. Historical C-IND-24, C-IND-36 and N-07 remain RED and were not relabelled. Exact sealed 4246 input/output were transported and read back on M4. 4249/Codex Luna high is fresh independent acceptance of the state/pgdata fail-closed boundary. Maximum GO_FOR_CONTROLLED_A2_RERUN; A2/live/build/landing NOT_EXECUTED.

COORD-4249-ACCEPTED-4327-QUEUED-20260919

Independent 4249 accepted exact r6 for one controlled A2 rerun: SHA256SUMS PASS 48/48, manifest c56c980b22f1167a8a29cad60fb4a7f139a6cf4549ea46d830003ecd526c3213, self-entry 0, DONE entries 0; fresh controls 22/22 and mutations 12/12. Verdict GO_FOR_CONTROLLED_A2_RERUN. A2/live/build/landing were NOT_EXECUTED.

The single synthetic C1-C6 A2 rerun is prepared as 4327. It is queued behind the already-running CAP-06 4326-redgates task so runtime evidence is not contaminated. WEB-630 remains in_progress until runtime evidence and independent readback.

COORD-4327-STARTED-20260919

The single controlled A2 rerun authorized by accepted 4249 is now active as 4327/Codex Luna. Immutable archive SHA-256 817196d44ce185938192badd0def3b2255cf2636b547fa2b0e232e4668b91406 was re-read before launch. Scope is synthetic C1-C6 only; production, build, landing, providers, capacity ladder and user rows are forbidden. WEB-630 remains in_progress pending terminal manifest and independent readback.

[20.09 03:21Z координатор] [WEB-630 ЭВОЛЮЦИЯ 20.09 — 4327 INCOMPLETE, дефект раннера, 4331 поставлена]

ПОЛНАЯ ЭВОЛЮЦИЯ WEB-630 — для агента, который видит этот тикет впервые.

ГДЕ МЫ. Пакет проверок r6 прошёл независимую приёмку, был допущен к одному контролируемому прогону на A2 — и на этом прогоне ОБОРВАЛСЯ ДО СОЗДАНИЯ СТЕНДА из-за дефекта в самом раннере. Продуктового вердикта по WEB-630 до сих пор нет.

ШАГ 1. Волна 4244 (M4) — вердикт REWORK, манифест 4139/4139. Два прежних дефекта закрыты, найден новый I-33: символическая ссылка на устойчивое состояние проходила настоящую предполётную проверку владельца.

ШАГ 2. Волна 4246 (Нео) — вердикт GO_FOR_INDEPENDENT_ACCEPTANCE. Манифест 401/401, SHA-256 2d3d33138b493a3d518805b4385e6ab758ca4805e9df0c882fa5f9b6fa0f87cc, записей о себе 0, записей DONE 0. Пакет r6, SHA-256 раннера 218ba9df9355035c9367f3561d087c56caf01c3be6c237c80eb95de986a6b418. Контроль I-33 КРАСНЫЙ на r5 и ЗЕЛЁНЫЙ на r6; новых контролей 10/10, мутаций 8/8; исторические C-IND-24, C-IND-36 и N-07 сохранены красными и не переименованы.

ШАГ 3. Волна 4249 (M4) — независимая приёмка, вердикт GO_FOR_CONTROLLED_A2_RERUN. Манифест 48/48, SHA-256 c56c980b22f1167a8a29cad60fb4a7f139a6cf4549ea46d830003ecd526c3213. Свежие контроли 22/22, мутации 12/12. Разрешён РОВНО ОДИН изолированный прогон на A2, только синтетические данные.

ШАГ 4. Волна 4327 (A2) — вердикт INCOMPLETE. Манифест доказательств 27/27, SHA-256 1e95b53a9c3e4c8f3473be48090c823b41b4dd42be0b078b1464d1d090a71afe, записей о себе 0, записей DONE 0. Вход не менялся: input_modified=false, архив 817196d44ce185938192badd0def3b2255cf2636b547fa2b0e232e4668b91406 сверен до и после.

ТОЧНАЯ ПРИЧИНА ОБРЫВА, самое важное в этом тикете:

    /var/tmp/4327-web630-r6-runner-exec.sh: line 143: $1: unbound variable

В раннере объявлена функция sha256_s, которая читает свой первый аргумент:
    sha256_s() { if have sha256sum; then printf '%s' "$1" | sha256sum | awk '{print $1}'; else printf '%s' "$1" | shasum -a 256 | awk '{print $1}'; fi }
Но в СЕМИ местах она вызывается как ПРИЁМНИК КОНВЕЙЕРА, без аргумента вообще: строки 150 (внутри tree_sha), 512, 843, 880, 881, 1146, 1149. Под set -u первое же обращение к несуществующему $1 обрывает прогон. При этом строка 147 (sha_str) вызывает её ПРАВИЛЬНО, с аргументом, — значит работать обязаны ОБА способа.

СЛЕДСТВИЕ ДЛЯ ПРОЦЕССА ПРИЁМКИ, которое нужно запомнить: принятый пакет r6 не мог исполниться НИКОГДА. Независимая приёмка 4249 сверила хеши, статические контроли и мутации, но ни разу не ЗАПУСТИЛА раннер. Проверка «пакет целостен» и проверка «пакет исполняется» — разные проверки, и вторая обязательна.

ВТОРОЙ, ОТДЕЛЬНЫЙ ДЕФЕКТ — договор о выходном каталоге. Одна подготовительная попытка была отвергнута раннером с rc=1, потому что NC_OUT уже существовал. В записи прогона NC_OUT=/home/ubuntu/waves/4327WEB630A2-evidence, а бриф просил .../evidence/runtime. Двусмысленность сохранена в runtime-inputs.json.

ЧТО ПРИ ЭТОМ ВСЁ-ТАКИ ПРОВЕРЕНО. Точный smoke-static прошёл с rc 0. Раннер запускался РОВНО ОДИН раз. Расписки required-inputs.json и runner-identity.json выпущены. Расписок C1-C6, привязки обслуживаемой версии, синтетического происхождения, отказа роли, детерминированного зерна и общей расписки НЕТ — поэтому проверяльщик расписок даёт INCOMPLETE, а НЕ NO_GO: красного продуктового вердикта не существует. Независимая сверка показала, что своих остатков волна не оставила (ни состояния, ни юнита, ни процесса, ни слушателя, ни базы, ни пространства имён, ни метки межсетевого экрана), но собственная расписка уборки не выпущена из-за раннего выхода, поэтому уборка засчитана как наблюдение, а не как PASS.

ЧТО СДЕЛАНО СЕЙЧАС (20.09 03:0xZ). ВОЛНА 4331 ПОСТАВЛЕНА НА A2 (Codex Luna, high, SOLO), работает. Задача в три части: (1) собрать r7 = точная копия r6 с ОДНОЙ правкой — sha256_s обязана работать и с аргументом, и как приёмник конвейера, плюс явный договор о NC_OUT; (2) доказать, что правка только про исполняемость: точный diff r6→r7, негативный контроль на непочиненном r6 с тем же обрывом на строке 143, позитивный контроль на равенство хешей обоими способами минимум на трёх входах включая пустую строку и строку с переводом строки; (3) провести РОВНО ОДИН контролируемый прогон r7 на своём приватном стенде с префиксом /var/tmp/4331-web630-l115q-, ролью web630_foreign_4331, фикстурами web630_fixture_%, на запечатанной базе доказательств 4139WEB662WEB629STAND-evidence. Решающую логику менять запрещено. Красный продуктовый вердикт — честный результат, подкручивать нельзя. Сдача: /home/ubuntu/waves/4331WEB630R7-REPORT.md, доказательства 4331WEB630R7-evidence с манифестом SHA256SUMS, бандл, маркер WEB630R7_DONE.

ГДЕ СМОТРЕТЬ. Всё на A2: копия исполнявшегося раннера /home/ubuntu/waves/4327WEB630A2-evidence/4327-web630-r6-runner-exec.sh (sha256 218ba9df…), обрыв в runtime.stderr.log, двусмысленность пути в runtime-inputs.json, разбор в /home/ubuntu/waves/4327WEB630A2-REPORT.md. Установленная линия l115q: исходник cc278e1810e1e03ac277b8e3a5fe06a2aebfba30, артефакт e9cdd5b041c29d058ef3c06e11ac39862e4de57d4ea307e79a7902d2d6535d86.

ЧЕГО ДЕЛАТЬ НЕЛЬЗЯ. Не считать 4327 успешным прогоном. Не закрывать WEB-630 до расписок C1-C6. Не трогать чужие стенды на A2 (слушатели 3610 и 3611 живут с 13-14 сентября, служба nc-dev — чужая). Не запускать больше одного прогона за волну.

[20.09 03:47Z координатор] [WEB-630 4331 NO-GO — второй дефект исполняемости, строка 855; 4335 поставлена]

ВОЛНА 4331 — VERDICT=NO-GO. Манифест 62/62, SHA-256 6534c48242ccb9d6df16f269602759f71d45f3ccecb66aeb26e7f5009d9e3c19, записей о себе 0, DONE 0. Это честный NO-GO без продуктового вердикта, и он нашёл ВТОРОЙ дефект исполняемости в принятом пакете.

ЧТО ПОЧИНЕНО (r6 → r7). r7-runner.sh, SHA-256 7bc1744715de79ff2d6848a0b9152f2c15dfe409cf581f484db82471a537c6bf. Изменены ровно шесть строк, все про исполняемость:
- строки 143-144 r6 удалены (небезопасная аргументная ветка sha256_s для GNU и BSD);
- строки 143-144 r7 добавлены: «если аргумент есть — подать его, иначе читать стандартный ввод», затем общий приёмник SHA-256 для обоих способов;
- строка 1087 — явная документация договора NC_OUT;
- строка 1087 r6 заменена на 1088 r7: NC_OUT должен отсутствовать или быть существующим каталогом; раннер создаёт его позже через mkdir -p, существующий переиспользует, файл с тем же именем отвергает. Это убирает отказ подготовки, наблюдавшийся в 4327.
Доказательства исполняемости: bash -n код 0; smoke-static код 0 с согласованностью 30/30 расписок; sha256_s совпал аргументом и через конвейер на трёх входах (пустая строка, обычная строка, строка с переводом строки), caseCount=3, allEqual=true; негативный контроль на непочиненном r6 воспроизвёл ровно тот обрыв на строке 143.

ЧТО ПРОИЗОШЛО НА ПРОГОНЕ. Единственный фактический прогон r7 создал приватный стенд и дошёл ЗНАЧИТЕЛЬНО дальше: netns-inner, PostgreSQL, Redis, готовность приложения, синтетическая ловушка, loopback-контроль. Выпущены netns-inner.json, synthetic-trap.json, loopback-control.json, input-integrity.json, runner-identity.json, required-inputs.json, source-binding.json. И снова rc=1 — СНОВА на исполняемости, не на продукте.

ТОЧНОЕ МЕСТО ВТОРОГО ДЕФЕКТА, строка 855 принятого раннера:
    listeneruid="$(awk -v p=":$appport" '$4 ~ p {print $0}' ... | grep -o 'users:(\("[^"]*"\)' | head -1 | tr -d 'users:("')"
Фактический вывод ss: users:(("next-server (v1",pid=261374,fd=21)). После закрывающей кавычки идёт ЗАПЯТАЯ, а шаблон требует скобку — grep возвращает rc=1, и под set -euo pipefail внутренний шаг останавливается. Имя процесса содержит пробел и скобку, шаблон это не предусматривал. Разбор: 4331WEB630R7-evidence/abort-diagnosis.txt.

C1-C6, привязка обслуживаемой версии, отказ роли, детерминированное зерно и повторяемость, общая расписка и расписка уборки НЕ выпущены. Проверяльщик расписок: result=INCOMPLETE, acceptancePass=false. Продуктовый красный вердикт не получен и не выдуман — это прямо сказано в отчёте.

УБОРКА. Раннер не успел выпустить свою расписку; выпущена независимая сверка cleanup-receipt.json с runnerCleanupReceiptEmitted=false и result=OBSERVED-MATCH: состояние и contract отсутствуют, юнит nc4189-web630-3994118 в LoadState=not-found, своих портов, процессов, nc4189dummy и остатков межсетевого экрана нет, ЧУЖИЕ 3030, 3610 и 3611 сохранены.

ГЛАВНЫЙ ВЫВОД ДЛЯ ПРОЦЕССА. Это ВТОРОЙ дефект исполняемости подряд в пакете, который прошёл независимую приёмку 4249 (манифест 48/48, контроли 22/22, мутации 12/12). Приёмка ни разу не ЗАПУСКАЛА раннер. Находить такие дефекты по одному за волну — значит тратить полный прогон на каждую строку.

ЧТО СДЕЛАНО СЕЙЧАС. ВОЛНА 4335 ПОСТАВЛЕНА НА A2 и работает. Она обязана СНАЧАЛА пройти весь раннер по тексту и выписать ВСЕ места того же класса до первого прогона: конвейеры под pipefail, где пустой результат нормален по смыслу но убивает прогон; разыменование позиционных переменных под set -u; шаблоны под предполагаемый формат вывода утилит; арифметика на пустой строке. Потом собрать r8, доказать что правка только про исполняемость (diff, таблица строка→класс→починка→проверка, негативный контроль на r7), и довести прогон до продуктовых решений. Если встанет на новом дефекте — чинить в этой же волне и делать следующий прогон, но каждый цикл обязан быть записан отдельно; молча перезапускать нельзя. Красный продуктовый вердикт остаётся честным результатом. Сдача: 4335WEB630R8-REPORT.md, доказательства с манифестом, маркер WEB630R8_DONE.

[20.09 04:12Z координатор] [WEB-630 4335 — прогон дошёл до продукта; три продуктовые находки; 4342 поставлена]

ВОЛНА 4335 — ПРОРЫВ: прогон ВПЕРВЫЕ дошёл до продуктовых решений. VERDICT=NO-GO, и это ПРОДУКТОВЫЙ NO-GO, а не обрыв. Манифест 428/428, SHA-256 6718d63c0ec31c39caed4365a75ac3e77a22bc3368f1cdaef81d6531fcdf74d5, записей о себе 0, DONE 0.

ПОЧЕМУ МЫ ТРИ РАЗА ЛОВИЛИ ОБРЫВЫ ПО ОДНОМУ. В принятом пакете было ВОСЕМЬ дефектов исполняемости, а не один. Бриф 4335 потребовал СНАЧАЛА вычитать весь раннер и выписать все места разом. Предпрогонный разбор нашёл пять: динамическое $unit в observe_unit_state; пустой grep -v на строке 711; разбор ss на 855; пустой grep для отпечатка утверждений на 880-881; пустой конвейер norm_keys на 1533. Ещё три вылезли в прогоне: same-declaration expansion synth_hex на 1354; чтение root-овских файлов состояния (из-за чего applied migrations наблюдались как 0); реальные формы /proc/net/tcp на 222-240 (сохранённый replay нёс 12 полей, а строки LISTEN имеют 17). Полный список — executability-sweep.md.

ЧЕТЫРЕ ФАКТИЧЕСКИЕ ПОПЫТКИ, все с отдельными логами в run-attempts/ и ни одна не скрыта:
1) rc=1 — synth_hex unbound на 1354, плюс нефатальное предупреждение прав при чтении root-created listener.uid;
2) rc=1 — живой /proc/net/tcp отвергнут проверяльщиком на tail:2 по формату полей;
3) rc=2 — дошла до продуктовых решений, обнаружен нефатальный откат внешних чтений root-created файлов состояния;
4) rc=2 — финальная, новых дефектов исполняемости нет, 206/206 миграций, artifact-binding=OBSERVED-MATCH, уборка OBSERVED-MATCH. rc=2 — штатный fail-closed результат существующего overall=INCOMPLETE.

ЧТО ИМЕННО ИЗМЕНЕНО В r8 (всё исполнительное, r7-to-r8.diff): безопасное чтение динамического имени юнита под set -u; пусто-безопасные конвейеры для адресов, отпечатков утверждений и ключей; извлечение из ss, сохраняющее пробелы и скобки в имени процесса и возвращающее пустую строку без остановки при отсутствии слушателя; раздельное вычисление synth_hex и synth_pat; совместимость разбора с наблюдаемыми заголовками tcp/tcp6 и строками ядра на 12 и 17 полей; открытие точных файлов состояния через sudo, чтобы расписка видела настоящие PID и счётчики. ПОРОГИ, условия решений, формулировки вердиктов, пути ACL в SQL, продуктовые утверждения и цели уборки НЕ менялись.

ПРОВЕРКИ ИСПОЛНЯЕМОСТИ: bash -n rc=0; smoke-static rc=0 с 30/30 расписок; повтор сохранённых живых tcp/tcp6 фикстур rc=0 с классификацией синтетической точки; негативный контроль на r7 воспроизвёл rc=1 ровно на строке 855 с сохранённым фактическим форматом ss; самохеш финального раннера совпал с runtime/runner-identity.json.

ТРИ ПРОДУКТОВЫЕ НАХОДКИ — ради них всё и делалось:
1) C3 = OBSERVED-MISMATCH. Отпечатки для зерна A и зерна B РАЗЛИЧАЮТСЯ: 1a1bdf33d02f8cf05c746389e7542ce68001f8f1e4b0435ec6913da47e6cb58 против cef54e1adfa28dc678af7f84f0be115c84fb5fe7ceae2dde7985aee8602041d2. Проверка C3 существует ровно для повторяемости: один вход — один результат. Либо в пути есть источник недетерминированности, либо проверка сравнивает не то.
2) C5 = UNOBSERVED. Проба прав получила от PostgreSQL 42P07: ACL arrays must be one-dimensional. Это ошибка ФОРМЫ передаваемого значения, а не отказ прав. Проверка честно НЕ перекрашена в зелёную, но пока она не отработала, о правах мы ничего не знаем.
3) Readiness = INCOMPLETE. Четыре фоновые проверки — extraction, tasks, webhookRetries, scheduledPosts — не имеют сигнала работоспособности при строгой политике готовности.

УБОРКА. Финальная runtime/cleanup-receipt.json и независимая cleanup-independent.log подтверждают отсутствие приложения, PostgreSQL, Redis, юнита, сокетов, корня состояния, корня договора и остатков межсетевого экрана. Чужие 3030, 3610, 3611 и nc-dev целы.

ЧТО ПОСТАВЛЕНО. ВОЛНА 4342 НА A2. По каждой из трёх находок обязана ответить на три вопроса: это дефект продукта, стенда или самой проверки; чем доказано СОБСТВЕННЫМ наблюдением; и что конкретно делать дальше. По C3 — развести три возможности: в отпечаток попадает заведомо меняющееся (время, случайное, идентификатор строки, порядок выборки без сортировки, порядок ключей) / зерно не доходит до места решения / проверка сравнивает разные вещи. По C5 — найти, откуда берётся многомерность ACL, и различить ошибку пробы от ошибки продукта. По readiness — для каждой из четырёх проверок отделить «служба не запущена на стенде» от «признак не реализован вовсе» от «строгая политика требует того, чего продукт не обещает». Свой стенд поднимать МОЖНО с префиксом /var/tmp/4342-web630-l115q-, только синтетика, с полной уборкой. Чинить продуктовый код этой волной запрещено — сначала понять. Если наблюдения не хватает — назвать его точно, а не догадываться: на гипотезе про параллельность в CAP-06 мы уже обожглись.

[20.09 04:46Z координатор] [WEB-630 4342 — C3 и C5 оказались дефектами проверок; 4343 чинит, 4346 перепроверяет]

ВОЛНА 4342 — три находки разобраны до файлов и строк. VERDICT=GO, манифест 9/9, SHA-256 ae3965ec03045d6d886dd3a7739c9334bb744fa5b09535ec9a37c61fa8cd8e82. По ДВУМ находкам вывод один: виноват не продукт, а сама проверка.

НАХОДКА C3 — повторяемость. Источник: дефект границы фикстуры, не продукта.
Отпечаток не непрозрачный: r8-runner.sh:521-533 собирает имена таблиц по порядку, число строк и md5 полных строк (t.*)::text, отсортированных по текстовому виду. Сырьё зёрен A и B СОВПАЛО для Document, Notebook, SharedNotebook, Source, Team, TeamMember. Различаются ТОЛЬКО User, UserSession, DocumentChunk. Повтор зерна A совпадает с A точно. Зерно доходит до детерминированного пути документов и векторов (runtime-seed/index.mjs:465 и :474).
Случайность в другом месте, и она законная: pg-smoke.test.mjs:15-22 создаёт свежий приватный каталог на каждый вызов; runtime-seed/index.mjs:271-280 создаёт случайные токены сессий и случайный ключ HMAC встраиваний; src/lib/auth/password.ts:17-19 создаёт свежую соль bcrypt при хешировании паролей фикстуры. Эти значения попадают в отпечаток полных строк как User.password, UserSession.token и DocumentChunk.embeddingIntegrityHash. Объяснений через несортированный порядок строк или порядок ключей НЕТ.
Действие: владелец харнесса обязан либо разделить детерминированное приватное состояние фикстуры между A и B, либо задокументировать проекцию, исключающую секретные и случайные поля хранения, и перезапустить C3. Порог не трогать.

НАХОДКА C5 — права доступа. Источник: дефект пробы; реальный результат продукта ПО-ПРЕЖНЕМУ НЕ НАБЛЮДЁН.
Роль создана и независимо наблюдена. Проба передаёт coalesce(c.relacl, '{}'::aclitem[]) и равнозначные запасные варианты в aclexplode (r8-runner.sh:339-353). На обычных строках каталога с NULL в ACL пустой литерал массива имеет НОЛЬ измерений, и PostgreSQL отвергает его ровно как 42P07: ACL arrays must be one-dimensional.
4342 воспроизвела это на СВОЕЙ одноразовой PostgreSQL: синтетическая таблица без чужих прав, relacl_is_null=t, foreign_select_privilege=f, точное выражение раннера падает с 42P07, а исправленный запрос с защитой от NULL отрабатывает и даёт ноль строк чужого ACL. Значит ошибка в ФОРМЕ запаса пробы, а не доказательство, что продукт собрал неверные права.
Действие: владелец пробы безопасности обязан сделать раскрытие ACL безопасным к NULL и пустому значению, СОХРАНИВ все объявленные пути прав, владения и членства, и перезапустить на тех же собственных базах прогона. Исправленный результат для web630_foreign_4335 нужен ДО того, как отказ продукта в доступе между ролями можно будет назвать наблюдённым.

НАХОДКА ГОТОВНОСТЬ — дело покрытия стенда, а не отсутствия кода.
У всех четырёх проверок есть реализованные писатели и читатели: extraction — process-source-indexing-queue.ts:306-328 пишет расписку вызова в EXTRACTION_WORKER_HEARTBEAT_PATH, читает extractionWorkerReadiness.ts:22-45; tasks — /api/cron/process-tasks оборачивает вызов на route.ts:182-191, читается TASKS_HEARTBEAT_PATH; webhook retries — /api/cron/webhook-inbox-retry:11-39; scheduled posts — /api/cron/process-scheduled-posts:27-36. Снятый ответ /api/ready даёт по каждой status=missing с пустыми возрастом, временем вызова и исходом. Доказательства юнитов r8 показывают, что запускался только собственный веб-раннер: ни работник извлечения, ни задания по расписанию не вызывались. Это НЕ «кода пульса нет».

ЧТО ПОСТАВЛЕНО.
- 4343 на A2: починить обе проверки и получить настоящий вердикт. По C3 — явная проверяемая проекция или разделённое детерминированное состояние; исключать «все различающиеся поля» ЗАПРЕЩЕНО, это превратит проверку в тавтологию; обязателен негативный контроль — внести настоящее различие в детерминированные данные и показать, что C3 его ЛОВИТ. По C5 — сделать раскрытие безопасным к NULL, сохранив ВСЕ объявленные пути, и обязательный негативный контроль: создать чужую роль с РЕАЛЬНО выданным правом и показать, что исправленная проба это право ВИДИТ (проба, всегда дающая ноль строк, ничего не проверяет). Плюс поднять на стенде четырёх производителей пульса; если какой-то поднять нельзя — сказать прямо и оставить missing честно. Затем прогон r9 и настоящий продуктовый вердикт. Продуктовый код менять запрещено.
- 4346 на A1: НЕЗАВИСИМО перепроверить оба вывода по исходникам. Это защита от того, что мы замажем настоящий дефект продукта. Ключевые вопросы, которых 4342 не задавала: точно ли ВСЕ различия A/B объясняются тремя названными источниками (если в User/UserSession/DocumentChunk различается что-то ещё — это может быть недетерминированность продукта); и возникает ли ошибка 42P07 ДО того, как проба увидела бы реальные права, или она падала бы и при НЕпустых правах. Плюс составить полный список объявленных путей прав, владения и членства — чтобы потом убедиться, что починка пробы ни один не выбросила: выброшенный путь это тихо снятая проверка безопасности.

[20.09 05:10Z координатор] [WEB-630 4346 — выводы подтверждены, но права ПО СУЩЕСТВУ ещё не проверены]

ВОЛНА 4346 (A1) — независимая перепроверка выводов 4342, VERDICT=GO. Манифест 6/6, SHA-256 2bc347dc15d76f0f01831c750a2d463d313ed00698461166e3d39bc674243d17.

Все три вывода подтверждены по исходникам. НО с важнейшей оговоркой, которую надо держать в голове при закрытии тикета:

C5 ОСТАЁТСЯ НЕПРОВЕРЕННЫМ ПО СУЩЕСТВУ ПРАВ. Исходная проба аварийно завершается ДО валидного результата, поэтому этот GO означает только правильность КЛАССИФИКАЦИИ находок, а НЕ зелёный результат безопасности для WEB-630. Пока исправленная проба не отработает и не покажет реальный результат прав, отказ продукта в доступе между ролями наблюдённым считать нельзя.

По C3 вывод 4342 подтверждён по каждому пункту: договор проверяльщика r8-runner.sh:521-533 — сортировка имён таблиц, счёт, полный текст строк PostgreSQL (t.*)::text, сортировка строк перед string_agg, затем отпечаток файла; поэтому несортированный порядок строк A/B не объясняет. Наблюдение подтверждает совпадение Document, Notebook, SharedNotebook, Source, Team, TeamMember; различаются только User, UserSession, DocumentChunk; повтор зерна A совпадает с A. pg-smoke.test.mjs:15-22 создаёт новый приватный каталог на каждый вызов.

Отдельно отмечено честное ограничение проверки: сам раннер r8 НЕ входит в архив исходников l115q, поэтому утверждение о конкретных строках проверяльщика сохранено как исполненное доказательство из материала 4342, а генератор фикстуры и его данные проверены независимо по исходникам.

ПОЧЕМУ ЭТА ВОЛНА ВООБЩЕ СТАВИЛАСЬ. Вывод «виноват не продукт, а проверка» лёг в основу волны 4343, которая прямо сейчас ЧИНИТ ПРОВЕРКИ. Если бы вывод оказался неверным хотя бы по правам, мы бы замазали настоящий дефект безопасности и объявили его зелёным. Перепроверка это исключила. Дополнительно 4346 составила полный список объявленных путей прав, владения и членства — по нему надо будет убедиться, что починка пробы ни один путь не выбросила: выброшенный путь это тихо снятая проверка безопасности.

Волна 4343 на A2 продолжает работу: проекция отпечатка C3 с негативным контролем (внести настоящее различие и показать, что C3 его ЛОВИТ), починка пробы прав с негативным контролем (создать чужую роль с реально выданным правом и показать, что проба его ВИДИТ), подъём четырёх производителей пульса, затем прогон r9 и настоящий продуктовый вердикт.

[20.09 05:46Z координатор] [WEB-630 4343 GO — прогон зелёный, права проверены по существу; 4349 принимает]

ВОЛНА 4343 — ПРОГОН ЗЕЛЁНЫЙ ПО СУЩЕСТВУ. VERDICT=GO, манифест 140/140, SHA-256 36c5e9b104abfe6db50aa8c9575214127111470e13568fa007397e52616b360d, записей о себе 0, DONE 0.

overall.json: result=PASS. Исходник cc278e1810e1e03ac277b8e3a5fe06a2aebfba30, запечатанный артефакт e9cdd5b041c29d058ef3c06e11ac39862e4de57d4ea307e79a7902d2d6535d86, готовность строгая PASS со всеми четырьмя производителями свежими и без подтверждений, разборка стенда OBSERVED-MATCH.

C3 — ПОВТОРЯЕМОСТЬ ЗАКРЫТА ЯВНОЙ ПРОЕКЦИЕЙ. Исключены РОВНО ТРИ поля, случайные по устройству: User.password, UserSession.token, DocumentChunk.embeddingIntegrityHash. Все остальные столбцы остаются в отпечатке; строки сортируются ПОСЛЕ проекции, поэтому проверка нечувствительна к порядку строк. Негативный контроль: изменили детерминированное Document.name — отпечаток изменился относительно базового, после восстановления вернулся к базовому; результат PASS. Это доказывает, что проекция по-прежнему ЛОВИТ настоящие изменения детерминированных данных, а не превратилась в тавтологию.

C5 — ПРАВА НАКОНЕЦ ПРОВЕРЕНЫ ПО СУЩЕСТВУ. Каждый вызов aclexplode защищён условием relacl IS NOT NULL вместо передачи пустого массива нулевой размерности. Пути таблиц, последовательностей, схем, баз данных, ACL по умолчанию, владения и членства — ВСЕ сохранены, ни один не выброшен. Финальное наблюдение чужой роли web630_foreign_4343: проба ok, ноль чужих привилегий после уборки, ошибки 42P07 не возникало. Негативный контроль: выдали НАСТОЯЩИЙ SELECT на public."User" — исправленная проба увидела tableGrantCount=1, затем право отозвали. Тем самым снята оговорка приёмки 4346 о том, что права оставались непроверенными.

ГОТОВНОСТЬ — ПУЛЬС НАСТОЯЩИЙ. Прогон вызвал работника извлечения с ограничением --max-jobs 1 и все три настоящих маршрута по расписанию. Работник завершился вхолостую с пульсом; расписки заданий, повтора webhook и отложенных публикаций успешны. readiness.json: backgroundOk=true, пустой список отказавших подсистем, строгое распоряжение, без подтверждений.

ОБЪЁМ. Изменён только собственный харнесс прогона. Рабочее дерево продукта осталось на поставленном коммите, его посторонние грязные файлы сохранены, продуктовый исходник НЕ правился. Уборка: расписка раннера подтверждает отсутствие собственных юнита, приложения, PostgreSQL, Redis, сокета, корня состояния, корня договора и остатков межсетевого экрана; независимая сверка совпала с базовым состоянием для чужих слушателей 3030, 3610, 3611 и службы nc-dev.

ЧТО ПОСТАВЛЕНО. ВОЛНА 4349 НА M4 — независимая приёмка. Её главный вопрос сформулирован прямо: починить проверку и ОСЛАБИТЬ её внешне одно и то же, а зелёное, полученное ослаблением, хуже красного, потому что выглядит как успех. Приёмщику велено: собрать СВОИ негативные контроли, отличные от авторских (по C3 изменить другое детерминированное поле в другой таблице; по C5 выдать право ДРУГОГО вида — на последовательность, на схему, через членство в роли или ACL по умолчанию — и показать, что проба его видит); сверить исправленную пробу ПОШТУЧНО со списком объявленных путей прав, составленным волной 4346 в c5-acl-paths-inventory.md, и по каждому сказать сохранён он или выпал, потому что выпавший путь это тихо снятая проверка безопасности; проверить, что пульс пришёл от самих производителей, а не записан обходным путём; и сравнить набор проверок ДО и ПОСЛЕ, чтобы ни одна не исчезла, не стала необязательной, не получила запасной путь «если не получилось — считаем пройденным» и не поменяла порог.

ТОЛЬКО ПОСЛЕ этой приёмки WEB-630 можно будет двигать к закрытию. Зелёный прогон автора сам по себе основанием не является.

[20.09 06:11Z координатор] [WEB-630 4349 NO-GO — ложное зелёное в C6 и потерянные пути прав; 4353 чинит]

ВОЛНА 4349 — НЕЗАВИСИМАЯ ПРИЁМКА r9 ОТКАЗАЛА. VERDICT=NO-GO, манифест 8/8, SHA-256 95c8687d696471c730026ec025f17545e7c8782e01f4cbf4ba1ffbe570f2e9e1, отчёт sha256 78ec64ed3410b91fe271e408fd1e0f9814e027a9866a7e4a893d72d19b146d2b.

Отказ ровно того класса, ради которого приёмка и ставилась: зелёное оказалось куплено. Две независимые причины.

ПРИЧИНА 1 — ЛОЖНОЕ ЗЕЛЁНОЕ В C6. c6-rerun.tap РЕАЛЬНО УПАЛ: tapExit=1, tapFail=1, ошибка 42P07 relation "User" already exists. Но controls/C6.json всё равно сообщает OBSERVED-MATCH, потому что сравнивает ДВА ОТПЕЧАТКА, снятых вокруг УПАВШЕГО повтора. Сводка контролей и финальные ворота доверяют этой строке и игнорируют упавший статус TAP. Два одинаковых отпечатка вокруг падения означают лишь, что падение ничего не изменило, — а не что проверка прошла.

ПРИЧИНА 2 — C5 ПОТЕРЯЛА ПУТИ ПРАВ. Исправленный SQL фильтрует строки ACL по OID НАЗВАННОЙ роли. Независимый тест приёмщика на собственной PostgreSQL показал: прямое право USAGE на последовательность обнаруживается; право на последовательность, УНАСЛЕДОВАННОЕ ЧЕРЕЗ ГРУППУ, в счёте прав на объект НЕ представлено (членство считается только отдельно); реальный grant на схему для PUBLIC ДЕЙСТВУЕТ, а проба сообщает ноль строк ACL названной роли. PUBLIC grants явно указаны как обязательные в списке путей, составленном волной 4346. Выпавший путь — это тихо снятая проверка безопасности.

Именно от этого страховала волна 4346, когда составляла полный список путей: без него выпадение никто бы не заметил, и мы объявили бы безопасность зелёной с дырой.

ЧТО ПРИ ЭТОМ ПРИНЯТО И ПЕРЕДЕЛЫВАТЬ НЕ НАДО. C3 прошёл НЕЗАВИСИМЫЙ негативный контроль приёмщика: изменение Notebook.title изменило отпечаток, восстановление вернуло его к базовому. Разбор исходников подтвердил ровно три исключения, случайных по устройству. Приёмщик отдельно зафиксировал честное ограничение объёма: осмысленная смена пароля после проекции НЕВИДИМА — это ограничение, а не доказательство полного покрытия, и его надо называть вслух. Четыре производителя пульса вызывались с уникальными путями расписок; разбор исходников и расписок показал настоящие пути записи, строгое распоряжение, отсутствие подтверждений и свежие пульсы. Уборка без остатков; защищённые слушатели 3030, 3610, 3611 не тронуты.

ЧТО ПОСТАВЛЕНО. ВОЛНА 4353 НА M4 — исправление r10. По C6: ворота и сводка обязаны учитывать СТАТУС повтора, а не только сравнение отпечатков; упавший TAP обязан делать контроль красным независимо от совпадения отпечатков. Отдельно велено объяснить по исходникам САМУ причину 42P07 (повтор не на чистой базе, не отработала подготовка, или повтор не рассчитан на вторую итерацию) и починить так, чтобы повтор проходил честно, а не чтобы ошибка игнорировалась. По C5: вернуть права, унаследованные через членство в группе, с отнесением к ОБЪЕКТУ, а не только в отдельный счёт членства; вернуть гранты PUBLIC как самый широкий класс доступа; сверить поштучно со списком c5-paths-checklist.md и c5-acl-paths-inventory.md. Для КАЖДОГО возвращённого пути — свой негативный контроль на одноразовой PostgreSQL: выдать право, показать что проба видит, отозвать, показать что перестала видеть. Плюс сравнение до и после по всем ранее работавшим путям, чтобы ничего не потерять. Плюс отдельный файл, где ограничение C3 названо прямо. Стенд эта волна не поднимает — прогон сделает следующая; максимум GO_FOR_STAND_RERUN.

[20.09 06:46Z координатор] [WEB-630 r10 — ложное зелёное устранено, пути прав возвращены; 4356 гоняет, 4358 проверяет]

ВОЛНА 4353 — исправление r10, VERDICT=GO, максимум GO_FOR_STAND_RERUN. Манифест 53/53, SHA-256 b55ef9563e50cfb08c772da735f15968b84bb8e2aa9dab94f6ef326fff4aeb40. Стенд не поднимался, как и было велено.

ПРИЧИНА ЛОЖНОГО ЗЕЛЁНОГО НАЙДЕНА ПО-НАСТОЯЩЕМУ. Падение в r9 было вызвано тем, что харнесс запускал тест, который БЕЗУСЛОВНО создаёт таблицы tiny-schema.sql на УЖЕ ЗАПОЛНЕННОЙ базе web630_seed_a. PostgreSQL корректно отверг второй CREATE TABLE "User" с ошибкой 42P07. То есть ошибка была честной реакцией базы на неверный порядок действий харнесса, а не случайностью. r10 использует отдельную чистую базу web630_seed_c6, поэтому тест доходит до своего настоящего второго вызова applyRun и действительно проверяет повторяемость. Локальный результат: один тест, один проход, ноль падений, код выхода 0.

ВОРОТА БОЛЬШЕ НЕ МОГУТ ДАТЬ ЛОЖНОЕ ЗЕЛЁНОЕ. C6, сводка контролей и финальные ворота ТРЕБУЮТ успешного статуса TAP. Равные отпечатки или любое другое наблюдение не могут перебить tapExit != 0 или tapFail != 0.

ПУТИ ПРАВ ВОЗВРАЩЕНЫ. Проба теперь следует прямому и транзитивному членству через pg_auth_members для счёта ACL на ОБЪЕКТ, а не только в отдельный счёт членства, и отдельно сообщает строки PUBLIC (grantee=0). Есть независимые контроли на прямую таблицу, на унаследованную через группу последовательность и на грант PUBLIC на схему; каждый обязан увидеть выдачу и вернуться к исходному после отзыва. Существующие пути таблиц, последовательностей, схем, баз, ACL по умолчанию, владения, личности и членства сохранены и перечислены поимённо. Ограничение проекции C3 названо явно отдельным файлом. Продуктовый код не менялся.

ЧТО ПОСТАВЛЕНО — ДВЕ ВОЛНЫ ПАРАЛЛЕЛЬНО, намеренно разделены.
- 4356 на A2: применить правку и провести ОДИН прогон на приватном синтетическом стенде с префиксом /var/tmp/4356-web630-l115q-. Отдельно велено доказать ИСХОДОМ, что ворота теперь краснеют: искусственно уронить повтор C6 и убедиться, что контроль КРАСНЫЙ несмотря на совпадающие отпечатки. Плюс на живом стенде выдать и отозвать по очереди прямое право на таблицу, право на последовательность через членство в группе и грант PUBLIC на схему, показав что проба видит каждое и возвращается к исходному. Красный продуктовый вердикт остаётся честным результатом.
- 4358 на Нео: независимая проверка САМОЙ правки, по исходникам и на собственной одноразовой PostgreSQL, параллельно и независимо от прогона. Вопрос сформулирован прямо: не куплено ли зелёное снова, только иначе. Велено попробовать ОБОЙТИ ворота минимум тремя способами (подделать поле статуса, вернуть пустой TAP, сделать чтобы TAP не создался, заставить ворота читать не тот файл); проверить, что причина 42P07 устранена БЕЗ потери смысла проверки, а не просто убрано условие, при котором тест падал; и проверить ПЯТЬ путей прав своими руками, включая два, которых автор явно не проверял — ТРАНЗИТИВНОЕ членство роль-в-роли-в-роли и право по умолчанию через ALTER DEFAULT PRIVILEGES. Если прогон даст зелёное, а проверка найдёт ослабление — находка проверки важнее.

[20.09 07:11Z координатор] [WEB-630 — логика r10 принята независимо, но правка не запускается; 4360 делает сплошной разбор]

ДВА РЕЗУЛЬТАТА: логика правки ПРИНЯТА независимо, но правка НЕ ЗАПУСКАЕТСЯ.

ВОЛНА 4358 (Нео) — независимая проверка правки r10, VERDICT=GO. Манифест 9/9, SHA-256 dfc52de2c941f941dc01641b90ba94b99dba2c4c5fd14035a96eeadcecc8d4fa, отчёт sha256 288d9f80d768b4b69aaf23932ba2aacf92da2aea4867c91ae190e2906a7b144b. Проверка велась по исходникам и на собственной одноразовой PostgreSQL. Фактический хеш архива совпал; внутренний манифест содержит ровно 53 записи, не включает себя и проходит сверку полностью. Патч меняет ТОЛЬКО раннер: один заголовок файла, 16 блоков, 246 добавлений, 49 удалений; продуктовых путей в патче нет; изменены только заявленные ворота C6/C5, база C6, рекурсивная проба ACL и PUBLIC и необходимые негативные контроли; смена создаваемой роли пробы на INHERIT прямо нужна для проверки эффективного членства. bash -n и smoke-static прошли с кодом 0.

ВОЛНА 4356 (A2) — прогон на стенде, VERDICT=NO-GO. Манифест 119/119, SHA-256 53515684ffe729ceae749cca522d2e5797429b4dd1dfaed102f38441643f67af, отчёт sha256 17a331c87759e837b36b62e00a850adca096266b3863e9c5a72a85af681c83c6.

Патч применился чисто: хеши до и после, сухой прогон, применение, bash -n и smoke-static записаны; патченый раннер побайтово совпал с включённым в архив. И всё равно прогон оборвался:

    line 327: $3: unbound variable

Вызов на строке 1168 патченого раннера делает psql_bound "$pgport" web630_app с ДВУМЯ позиционными аргументами, хотя psql_bound требует порт, базу, имя переменной и значение. Под set -u прогон остановился на подготовке контроля C5 для унаследованного через группу права — ДО контролей группы и PUBLIC и ДО выпуска расписок C1-C6, сводки, общей расписки и расписки уборки. Харнесс после обнаружения дефекта не менялся.

ЧТО ПРИ ЭТОМ УСПЕЛО ПРОЙТИ И ЭТО ВАЖНО: C1, C2, C3, C6 и прямой табличный контроль C5 ПРОШЛИ. То есть починка ложного зелёного C6 работает — она дошла до дела и дала честный результат.

ЧЕТВЁРТЫЙ ОБРЫВ ИСПОЛНЯЕМОСТИ В ЭТОЙ ЛИНИИ. До него были sha256_s (строка 143), listeneruid (строка 855) и восемь мест, найденных сплошным разбором r8. Каждый раз чинили найденное место, тратили полный прогон на стенде около часа и находили следующее. bash -n и smoke-static этот класс НЕ ловят: синтаксис верен, а падает разыменование под set -u на ветке, которая при статической проверке не исполняется.

ВОЛНА 4360 НА M4 — r11. Требование: сплошной разбор ВСЕГО раннера ДО любой правки, со списком мест того же класса и номерами строк — вызовы с числом аргументов МЕНЬШЕ, чем функция разыменовывает; переменные, задаваемые не на всех ветках; конвейеры под pipefail, где пустой результат нормален; шаблоны под предполагаемый формат вывода; арифметика на возможно пустой строке; обращения к массивам без значения по умолчанию. Для КАЖДОЙ функции выписать, сколько позиционных аргументов она разыменовывает и сколько получает в КАЖДОМ месте вызова. Список сдать файлом ДО раздела с правками. Плюс сделать проверку, которая ловит именно несоответствие числа аргументов, и показать, что на непочиненном r10 она находит дефект строки 1168, а на r11 ничего. Плюс прогнать на одноразовой базе ветки C5, которые раньше не достигались — групповое наследование и PUBLIC. Починка только строки 1168 без сплошного разбора — NO-GO: мы это уже проходили четыре раза.

[20.09 07:46Z координатор] [WEB-630 — сплошной разбор нашёл ПЯТЬ мест вместо одного; 4363 гоняет r11]

ВОЛНА 4360 — сплошной разбор нашёл ПЯТЬ мест, а не одно. VERDICT=GO, максимум GO_FOR_STAND_RERUN. Манифест 43/43, SHA-256 eebe61b4d3cf00c4723d9c03b573757d5e8d236eb2cceb4df138c25fd98d291a.

Разбор написан ДО изменения раннера. Цель разбора: 4353-web630-r10-runner.sh, 2034 строки, SHA-256 4b1bf1397bffb38bcbcaff0317c8e37a05779492cd33e1d9703bba49b9bba819. Покрыты каждая функция оболочки, каждое место вызова, конвейеры под set -euo pipefail, разбор вывода, числовые операции, массивы и подстановки по умолчанию.

ГЛАВНОЕ: psql_bound разыменовывает $1, $2, $3 и $4 на строке 327, а ПЯТЬ мест вызова через heredoc передавали только порт и базу. Все пять упали бы под set -u ещё до вызова psql. Прогон 4356 нашёл ПЕРВОЕ из них и остановился — то есть при прежнем подходе «чиним найденную строку» нам понадобилось бы ПЯТЬ прогонов и около пяти часов только на этот один класс дефекта.

Это оправдывает требование, поставленное в брифе: сплошной разбор ДО правок, с таблицей «сколько аргументов функция разыменовывает / сколько получает в каждом месте вызова», плюс отдельная проверка, ловящая именно несоответствие числа аргументов. bash -n и smoke-static этот класс не ловят: синтаксис верен, а падает разыменование на ветке, которая при статической проверке не исполняется.

Напоминание о четырёх предыдущих обрывах этой же природы: sha256_s (строка 143), listeneruid (строка 855), восемь мест, найденных сплошным разбором r8, и теперь пять мест psql_bound.

ЧТО ПОСТАВЛЕНО. ВОЛНА 4363 НА A2 — прогон r11. Обязана: применить правку и прогнать приложенную проверку числа аргументов; сделать ОДИН прогон на приватном синтетическом стенде с префиксом /var/tmp/4363-web630-l115q-; дойти до ОБЕИХ веток C5, до которых r10 не доходил — право на последовательность через членство в группе и грант PUBLIC на схему, с отдельными расписками; искусственно уронить повтор C6 и показать ИСХОДОМ, что контроль краснеет несмотря на совпадающие отпечатки. Если встанет на НОВОМ дефекте — чинить в этой же волне, но записывать каждый цикл отдельно И объяснять, почему сплошной разбор его не нашёл, чтобы улучшить разбор. Красный продуктовый результат остаётся честным результатом.

[20.09 08:11Z координатор] [WEB-630 4363 — прогон r11 ПРОШЁЛ полностью, C1-C6 зелёные, обе ветки C5 дошли; 4367 принимает]

ВОЛНА 4363 — ПРОГОН r11 ПРОШЁЛ ПОЛНОСТЬЮ. VERDICT=GO, манифест 186/186, SHA-256 0c49f32c7f04f0a435e2adbf8671e14e4c56c3b29a8682e944d1ffb72c48e3a6 (сверять ИЗНУТРИ каталога доказательств: пути записаны как ./имя).

Применённый раннер побайтово совпал с включённым в архив r11, SHA-256 8acd349153048f5c47bb973d9726c186363baa967a36992bb3d615b3c1360bb7. bash -n, smoke-static и авторская проверка числа аргументов прошли.

Единственный полный прогон завершился rc=0 и overall.json.result=PASS. Нового дефекта исполняемости НЕ БЫЛО и тихих перезапусков не было — впервые за пять заходов. Проверяльщик расписок не нашёл ни одной с result=INCOMPLETE; controls-summary.json — OBSERVED, receipt-contract.json — PASS.

Границы прогона: syntheticOnly=true, externalProvidersUsed=false, productionTouched=false; приватный стенд с изолированной сетью; префикс /var/tmp/4363-web630-l115q-, роль web630_foreign_4363, фикстуры web630_fixture_%, запечатанная база 4139WEB662WEB629STAND-evidence; исходник cc278e1810e1e03ac277b8e3a5fe06a2aebfba30, артефакт e9cdd5b041c29d058ef3c06e11ac39862e4de57d4ea307e79a7902d2d6535d86. Привязка исходника, обслуживаемая версия, привязка артефакта, готовность, синтетическая ловушка, loopback, граница исходящего трафика и уборка — все решения пройдены. Продуктовый исходник, боевая служба или база, релизная сборка, next build, k6, нагрузка, лестница, доска, Telegram, секреты и защищённые стенды не использовались.

КОНТРОЛИ:
- C1 и C2 — ASSERTED-PINNED-TEST, TAP код 0, один проход, ноль падений.
- C3 — OBSERVED-MATCH, оба детерминированных отпечатка f2628778b3b16088bcd822dc17b6753f8699ea936a0b8240305f1524be32ed11.
- C4 — OBSERVED-MATCH, остаточных фикстурных баз и таблиц нет.
- C5 — OBSERVED-MATCH, чужая роль существовала и имела НОЛЬ наблюдённых прав: прямых, унаследованных, владения и членства.
- C6 — OBSERVED-MATCH, чистая база, ПЕРВЫЙ И ВТОРОЙ applyRun оба отработали, TAP код 0, один проход, ноль падений, тот же детерминированный отпечаток.

ОБЕ ВЕТКИ, ДО КОТОРЫХ r10 НЕ ДОХОДИЛ, ПРОЙДЕНЫ: унаследованное через членство в группе право на последовательность — выдано, наблюдено, исчезло после отзыва, result=PASS; грант PUBLIC на схему — выдан, наблюдён, исчез после отзыва, result=PASS. Это ровно те два пути, потеря которых была причиной отказа приёмки 4349.

ЧТО ПОСТАВЛЕНО. ВОЛНА 4367 НА M4 — независимая приёмка, и от неё зависит, можно ли двигать WEB-630 к закрытию. Приёмщику сказано прямо: линия шла пять заходов, дважды мы едва не приняли зелёное, купленное ослаблением, поэтому вопрос у него один — настоящее это зелёное или опять куплёное. Требуется: пройти по КАЖДОМУ контролю и ответить, мог ли он дать OBSERVED-MATCH при неисправности; по C6 убедиться, что «первый и второй applyRun» это действительно два разных вызова, а не один, посчитанный дважды; по C5 проверить, что «ноль прав» означает «прав нет», а не «проба их не видит» — то есть что наблюдение действительно менялось при выдаче и отзыве; по C3 убедиться, что совпадение отпечатков не следствие сравнения пустого. Плюс СВОИ контроли на собственной одноразовой PostgreSQL, включая путь, которого в авторских нет — право по умолчанию через ALTER DEFAULT PRIVILEGES или транзитивное членство роль-в-роли-в-роли. Плюс сверка набора проверок с r9 и r10: ни одна не должна была исчезнуть, стать необязательной, получить запасной путь «если не получилось — считаем пройденным» или поменять порог.

[20.09 09:06Z координатор] [WEB-630 ПОЛНАЯ ЭВОЛЮЦИЯ 20.09 — шесть заходов, все находки, для агента с нуля]

ПОЛНАЯ ЭВОЛЮЦИЯ ЛИНИИ ЗА 20.09 — шесть заходов, для агента с нуля.

Главный урок этой линии: КАЖДЫЙ РАЗ ошибка была в проверках, а не в продукте, и ДВАЖДЫ мы едва не приняли зелёное, купленное ослаблением. Поэтому здесь не сокращают приёмку.

ЗАХОД 1 — волна 4327, INCOMPLETE. Прогон оборвался ДО создания стенда: sha256_s написана под аргумент, но в семи местах вызывается как приёмник конвейера (строки 150, 512, 843, 880, 881, 1146, 1149); под set -u первое обращение к $1 убивает прогон на строке 143. Манифест 27/27. ВЫВОД, который надо помнить: принятый приёмкой 4249 пакет r6 не мог исполниться НИКОГДА — приёмка сверила хеши 48/48, контроли 22/22 и мутации 12/12, но раннер ни разу не запускала.

ЗАХОД 2 — волна 4331, NO-GO. r7 починил sha256_s (6 строк, доказано diff-ом, негативным контролем и равенством хешей обоими способами на трёх входах). Прогон дошёл ЗНАЧИТЕЛЬНО дальше — стенд, netns-inner, PostgreSQL, Redis, готовность приложения, синтетическая ловушка, loopback — и встал на ВТОРОМ дефекте исполняемости, строка 855: grep -o 'users:(\("[^"]*"\)' не совпал с фактическим выводом ss users:(("next-server (v1",pid=…, потому что после кавычки идёт запятая, а шаблон требует скобку; имя процесса содержит пробел и скобку. Манифест 62/62.

ЗАХОД 3 — волна 4335, NO-GO ПРОДУКТОВЫЙ. Впервые прогон дошёл до решений. Манифест 428/428. Сплошной разбор до прогона нашёл ПЯТЬ мест ($unit, 711, 855, 880-881, 1533), ещё три вылезли в прогоне (synth_hex на 1354, чтение root-овских файлов состояния, форматы /proc/net/tcp на 222-240) — итого ВОСЕМЬ дефектов исполняемости в одном принятом пакете. Четыре попытки, все залогированы. Три продуктовые находки: C3 OBSERVED-MISMATCH (отпечатки зерна A и B различаются), C5 UNOBSERVED (PostgreSQL 42P07: ACL arrays must be one-dimensional), Readiness INCOMPLETE (extraction, tasks, webhookRetries, scheduledPosts без пульса).

РАЗБОР НАХОДОК — волна 4342 (GO, 9/9) и независимая перепроверка 4346 (GO, 6/6). C3: недетерминированность НЕ в продукте, а в фикстуре — bcrypt-соль (password.ts:17-19), случайные токены сессий и ключ HMAC (runtime-seed/index.mjs:271-280), свежий приватный каталог на вызов (pg-smoke.test.mjs:15-22) попадают в отпечаток полных строк как User.password, UserSession.token, DocumentChunk.embeddingIntegrityHash; повтор зерна A совпадает с A. C5: дефект ПРОБЫ — coalesce(c.relacl,'{}'::aclitem[]) даёт массив нулевой размерности при NULL ACL, PostgreSQL отвергает ровно как 42P07; воспроизведено на одноразовой базе. Readiness: у всех четырёх есть реализованные писатели и читатели (process-source-indexing-queue.ts:306-328 и extractionWorkerReadiness.ts:22-45; /api/cron/process-tasks route.ts:182-191; /api/cron/webhook-inbox-retry:11-39; /api/cron/process-scheduled-posts:27-36) — причина в покрытии стенда, производителей просто не запускали. Перепроверка 4346 подтвердила все три вывода, но с оговоркой: C5 остаётся непроверенным ПО СУЩЕСТВУ прав, и это НЕ зелёный результат безопасности.

ЗАХОД 4 — волна 4343 (GO, 140/140) починила проверки и дала зелёный прогон. НО приёмка 4349 (NO-GO, 8/8) нашла, что зелёное КУПЛЕНО: c6-rerun.tap реально упал (tapExit=1, tapFail=1, 42P07 relation "User" already exists), а controls/C6.json дал OBSERVED-MATCH, потому что сравнивал два отпечатка ВОКРУГ упавшего повтора; и проба прав потеряла два пути — право на последовательность через ЧЛЕНСТВО В ГРУППЕ не попадало в счёт прав на объект, а реальный grant PUBLIC на схему действовал при нулевом отчёте. PUBLIC был явно указан обязательным в списке путей, составленном волной 4346 — без этого списка пропажу бы не заметили.

ЗАХОД 5 — волна 4353 (GO, 53/53) исправила. Причина 42P07 названа по-настоящему: харнесс запускал тест, безусловно создающий таблицы tiny-schema.sql на УЖЕ заполненной web630_seed_a. Теперь C6 работает на чистой web630_seed_c6 и доходит до настоящего второго applyRun; ворота требуют успешного статуса TAP — равные отпечатки не могут перебить tapExit!=0; проба следует прямому и транзитивному членству pg_auth_members и отдельно сообщает PUBLIC (grantee=0). Логика независимо принята волной 4358 (GO, 9/9) построчно. НО прогон 4356 (NO-GO, 119/119) снова оборвался: line 327: $3: unbound variable — вызов на строке 1168 давал psql_bound два аргумента вместо четырёх. ЧЕТВЁРТЫЙ обрыв подряд.

ЗАХОД 6 — волна 4360 (GO, 43/43) сделала сплошной разбор ВСЕГО раннера ДО правок (цель: 4353-web630-r10-runner.sh, 2034 строки, SHA-256 4b1bf1397bffb38bcbcaff0317c8e37a05779492cd33e1d9703bba49b9bba819) и нашла ПЯТЬ мест вызова psql_bound с двумя аргументами вместо четырёх, а не одно. При старом подходе «чиним найденную строку» это стоило бы пяти прогонов и около пяти часов. bash -n и smoke-static этот класс не ловят: синтаксис верен, падает разыменование на ветке, не исполняемой при статической проверке.

ПРОГОН 4363 (GO, 186/186) — ПРОШЁЛ ПОЛНОСТЬЮ. rc=0, overall.result=PASS, нового дефекта исполняемости и тихих перезапусков НЕ было впервые за пять заходов. Раннер 8acd349153048f5c47bb973d9726c186363baa967a36992bb3d615b3c1360bb7. C1/C2 ASSERTED-PINNED-TEST TAP exit 0; C3 OBSERVED-MATCH, оба отпечатка f2628778b3b16088bcd822dc17b6753f8699ea936a0b8240305f1524be32ed11; C4 OBSERVED-MATCH; C5 OBSERVED-MATCH, у чужой роли НОЛЬ прав (прямых, унаследованных, владения, членства); C6 OBSERVED-MATCH, чистая база, первый и второй applyRun оба отработали. ОБЕ ранее недостижимые ветки C5 дошли: группа-наследование и PUBLIC — выдано, наблюдено, исчезло после отзыва, PASS. Границы: syntheticOnly=true, externalProvidersUsed=false, productionTouched=false.

ПРИЁМКА 4367 (NO-GO, 65/65) — И ОПЯТЬ НАШЛА. По существу приняты C5 и C6: приёмщик САМ проверил на своей одноразовой PostgreSQL транзитивную цепочку foreign→mid→leaf (sequenceGrantCount 0→1, inheritedGrantCount 0→1, отзыв вернул 0) и PUBLIC (publicSchemaGrantCount 3→4, publicGrantCount 66→67, отзыв вернул исходное); мутация C6 с тем же отпечатком но TAP exit 1 дала RED — C6 больше не покупается равным отпечатком. НО три fail-open:
1) C1 и C2 имеют происхождение asserted-pinned-test и observedMatches=false, а итоговый controls_result фильтрует ТОЛЬКО provenance=observed — подмена TAP на exit 1 ничего не меняет, проверка объявлена и ни на что не влияет;
2) pinnedSourceSha256 равен SHA-256 ПУСТОГО файла — привязка теста к исходнику не доказана;
3) C4 строит result только по remaining, игнорируя residual_tables — мутация residualTableCount=1 оставляет OBSERVED-MATCH.
Плюс замечание: каталоги c5-group-inherited/ и c5-public/ несут устаревшие имена 4353, поэтому приёмщик не засчитал их как самостоятельное доказательство.

СЕЙЧАС В РАБОТЕ — волна 4370 на M4 (r12). Обязана: сделать C1 и C2 решающими с предъявлением обеих сторон; найти, почему pinnedSourceSha256 пуст, и привязать к реальному исходнику; включить residual_tables в построение result; составить ТАБЛИЦУ ПО ВСЕМ контролям с ответом «попадает ли его результат в итог и что будет, если он покраснеет» — любой контроль, чей результат никуда не входит, это четвёртый дефект того же класса; переименовать каталоги со стальными именами; прогнать проверку арности и подготовить применимый патч.

[20.09 10:14Z координатор] [WEB-630 r13 GO — четвёртый дефект закрыт; 4380 строит СВОЮ таблицу и ищет пятый]

ВОЛНА 4378 — r13, VERDICT=GO, манифест 15/15. Четвёртый дефект закрыт.

Напомню весь список болезни «проверка работает, а решение её не читает», найденной в этой линии:
1. ложное зелёное C6 — сравнение отпечатков ВОКРУГ упавшего повтора (нашла приёмка 4349);
2. потерянные пути прав — через членство в группе и PUBLIC (она же);
3. три fail-open сразу — C1/C2 отбрасывались фильтром provenance=observed, pinnedSourceSha256 равнялся отпечатку ПУСТОГО файла, C4 игнорировал residual_tables (нашла приёмка 4367);
4. runner-identity.json (PASS/FAIL) и required-inputs.json (COMPLETE/INCOMPLETE) пишут результат, а overall его не читает (нашла приёмка 4376).

Каждый раз автор чинил названное, и каждый раз следующая приёмка находила следующее того же класса. Поэтому в бриф r13 было заложено жёсткое требование: таблицу по ВСЕМ распискам построить ЗАНОВО ПО КОДУ, а не переписывать прошлую — именно переписанная таблица пропустила четвёртый дефект.

ЧТО ПОСТАВЛЕНО. Волна 4380 на A1 — независимая приёмка r13. Её главная задача сформулирована прямо: НЕ проверять авторскую таблицу, а ПОСТРОИТЬ СВОЮ. Способ задан: взять каждую расписку из сдачи прогона r11 (4363WEB630R11RUN-evidence), сделать по каждой мутацию в худшую сторону и посмотреть на исход; расписка, чья порча не меняет исход, — дефект. Если приёмщик найдёт ПЯТЫЙ — это NO-GO и ровно та ценность, ради которой приёмка существует. Если не найдёт — обязан сказать, сколько расписок проверил и каким способом, чтобы было видно, что поиск был настоящим.

Плюс приёмщик проверяет переносимость доказательств: прошлая сдача ссылалась на каталог чужой волны, которого на приёмной машине не существует, и приёмщик 4376 был вынужден сверять сторону «до» по отказному отчёту и по формулам внутри патча. Ссылка на недоступный путь доказательством не является.

[20.09 13:18Z координатор] [r13 принят приёмкой 4381 GO; прогон поставлен на A2 волной 4393; вся эволюция 13 редакций]

ПАКЕТ r13 ПРИНЯТ ПОЛНОСТЬЮ, ПРОГОН ПОСТАВЛЕН НА A2 (волна 4393). Сохраняю всю эволюцию линии, потому что она поучительная: тринадцать редакций раннера и шесть попыток приёмки.

ЧЕТЫРЕ ОБРЫВА ИСПОЛНЯЕМОСТИ ПОДРЯД. r10 (волна 4356) упал на `line 327: $3: unbound variable`. Волна 4360 разобрала ВЕСЬ раннер ДО правок (манифест 43/43, цель — `4353-web630-r10-runner.sh`, 2034 строки, sha256 `4b1bf1397bffb38bcbcaff0317c8e37a05779492cd33e1d9703bba49b9bba819`) и нашла не одно место, а ПЯТЬ: `psql_bound` разыменовывает четыре позиционных аргумента, а пять мест вызова через heredoc передавали два. Прогон находил бы их по одному — пять прогонов и пять часов. С тех пор в пакете едет проверка арности `arity-checker/check-arity.sh`, и она запускается ДО подъёма стенда.

ЧЕТЫРЕ ДЕФЕКТА РЕШАЮЩЕЙ ЛОГИКИ, все найдены приёмками, а не прогонами.
1. `tapExit=1, tapPass=0, tapFail=1` не краснило C1 и C2.
2. Привязка обслуживаемой версии не менялась при подмене исходника.
3. Остаточная таблица (`residualTableCount=1`) не краснила C4.
4. ГЛАВНЫЙ: расписки `runner-identity.json` и `required-inputs.json` объявлялись, но их поле `result` НЕ участвовало в решении. Раннер печатал «я — это я» и «входные данные полны», а если бы там стояло `FAIL`/`INCOMPLETE`, общий вердикт всё равно был бы `PASS`. Это ровно то устройство, которое у нас уже записано отдельным уроком: ОБЪЯВЛЕННАЯ ЗАЩИТА, НЕ УЧАСТВУЮЩАЯ В РЕШЕНИИ. За смену это третий её экземпляр (были failClosed, ufw на чужом uid, флаг в 28 из 29 карточек).

ПРИЁМКА 4380 построила СОБСТВЕННУЮ таблицу по коду r13: 30 объявленных расписок, 29 с полем `result`. Для каждой из 29 сделала отдельную мутацию — все 29 краснят решение. Пятого дефекта нет. Отдельно проверила с обеих сторон, что мутации `runner-identity.json.result=FAIL` и `required-inputs.json.result=INCOMPLETE` краснят `overall` на r13 и остаются НЕЗАМЕЧЕННЫМИ на доступном r12. Вердикт был `NO-GO` — но по причине, не зависящей от автора: координатор не доставил каталог `4363WEB630R11RUN-evidence` и положил отчёт `4376R12ACCEPT-REPORT.md` с правами, недоступными пользователю волны. Это моя ошибка. Урок записан: проверять не только наличие материала, но и ПРАВА на него.

ПРИЁМКА 4381 (после доставки 89 файлов и исправления прав) закрыла единственный оставшийся вопрос — покрывает ли таблица из 29 именно те расписки, что выпускает фактический прогон, — и дала `VERDICT=GO`. Выводы 4380 в ней помечены как принятые и не переделывались.

ПОЧЕМУ ПРОГОН НУЖЕН, ХОТЯ r11 УЖЕ ДАЛ PASS. Прогон r11 (волна 4363) закончился `overall.result=PASS`, все расписки зелёные, привязка сошлась: исходник `cc278e1810e1e03ac277b8e3a5fe06a2aebfba30`, артефакт sha256 `e9cdd5b041c29d058ef3c06e11ac39862e4de57d4ea307e79a7902d2d6535d86`, дерево артефакта `079d6294…`, миграций 206, `migrationsMatch=true`, 29675 членов артефакта. НО он шёл на раннере r11, где `runner-identity` и `required-inputs` НЕ были несущими. Его `PASS` означает «ничто не покраснело из того, что умело краснеть». Нужен `PASS`, полученный логикой, где краснеет всё объявленное. Это разные утверждения.

ЧТО ПОСТАВЛЕНО (4393 на A2, взята в работу 13:16:38Z). Раннер `4370-web630-r13-runner.sh`, sha256 `7fbb9d0befc2cb3884f1bd54416dd78616366ce157783379ae9739945eadd3e2`, 2104 строки — в сдаче лежит ГОТОВЫЙ полный файл, не только патч. Волне даны точные входные значения, проверенные мной на машине: артефакт `/home/ubuntu/l115q-artifact/me2-standalone-linux-arm64-cc278e181-20260915T230431Z.tar.gz` (на месте, 233 МБ), рабочее дерево `/home/ubuntu/wt-l115q` (на месте), запечатанная база `4139WEB662WEB629STAND-evidence` (на месте), роль-чужак `web630_foreign_4393`, префикс состояния `/var/tmp/4393-web630-l115q-`.

Порядок шагов жёсткий: сначала сверка sha256 раннера, `bash -n`, проверка арности и `smoke-static` — и ТОЛЬКО если всё зелёное, подъём стенда. Иначе `NO-GO` с точным местом и без потраченного часа.

Отдельно потребовано доказать, что четвёртый дефект закрыт НА ФАКТИЧЕСКОМ ПРОГОНЕ: испортить на КОПИИ своей сдачи `runner-identity.json.result` в `FAIL` и `required-inputs.json.result` в `INCOMPLETE` и показать, что проверяльщик краснит `overall` в каждом случае. Плюс сверка состава расписок с прогоном r11. Плюс доказательство уборки И того, что чужие слушатели 3030, 3610, 3611 и служба `nc-dev` целы после неё — в одном из прошлых заходов стенд едва не снёс чужое.

Материал доставлен и права проверены: 206 файлов в `/home/ubuntu/waves/4393-material/`, оба архива сверены по sha256 на приёмной машине.

[20.09 14:11Z координатор] [приёмка прогона r13: 26 несущих полей, 26/26 краснеют, пятого дефекта НЕТ; NO-GO только за пересказ вместо сырья о чужих ресурсах]

ПРИЁМКА ПРОГОНА r13 (волна 4397 на M4): VERDICT=NO-GO, LOAD_BEARING_FIELDS=26, манифест 59/59. Но причина отказа УЗКАЯ, и содержательно линия подтверждена.

СНАЧАЛА ГЛАВНОЕ: ПЯТОГО ДЕФЕКТА НЕТ, И ЭТО ДОКАЗАНО КАК НАДО. Приёмка НЕ переписывала чужую таблицу — именно переписывание однажды и пропустило четвёртый дефект. Она построила свою по коду раннера (2104 строки, sha256 `7fbb9d0befc2cb3884f1bd54416dd78616366ce157783379ae9739945eadd3e2`): `receipt_contract()` объявляет 30 расписок, у 29 есть ключ `result`, единственная без него — `stand-executed.json`.

Собственная трассировка финального вентиля дала **26 полей, которые реально несут обычное решение PASS**: расписка рукопожатия, расписки личности, входных данных, привязки, сети, готовности и разбора, C1–C6 через `controls-summary`, сам `controls-summary`, остаток, уборка и `receipt-contract`. Почему 26, а не 29: `orchestration-refusal.result` и `rescue-cleanup-receipt.result` существуют ТОЛЬКО в ветке отказа, где `overall.result` безусловно `INCOMPLETE`, а сам `overall.result` — финальный выход, не вход вычисления. Это не расхождение в числе объявленных расписок, а уточнение, что именно несёт решение.

МУТАЦИИ: 26 из 26 покраснели. Для каждой создавалась отдельная временная копия ВСЕЙ сдачи; раннер, стенд, база, служба, сборка и нагрузка не запускались; базовый повтор дал `PASS`, каждая мутация — `computedOverall=INCOMPLETE`; оригинал не изменён. `runner-identity.result=FAIL` и `required-inputs.result=INCOMPLETE` проверены ВМЕСТЕ СО ВСЕМИ ОСТАЛЬНЫМИ, а не приняты на основании двух авторских примеров.

ПРОГОН БЫЛ НАСТОЯЩИЙ — следы связные: юнит `nc4189-web630-1246877`, отдельный внутренний PID `1269642`, приватное сетевое пространство, PostgreSQL на 48077 готов в `13:18:53Z`, Redis на 48078 в `13:19:00Z`, приложение на `127.0.0.1:48079`, успешные проверки загрузки, базы, релиза и фоновых задач, упорядоченное выключение в `13:19:45Z`. Сходятся одноразовое число, внутреннее и внешнее сетевые пространства, исходник, артефакт, дерево и 206 миграций. **Из 155 общих с r11 путей только 102 имеют тот же отпечаток**, и это в основном статические ключи, фикстуры и детерминированные отрицательные контроли — то есть сдача НЕ выглядит копией r11.

МАНИФЕСТ: 164 записи, 164 уникальных пути, 164 файла кроме самого манифеста; `sha256sum -c` — PASS; записей о самом манифесте 0, о маркерах 0, нечитаемых файлов 0.

СОСТАВ РАСПИСОК: у r11 25 имён, у r13 — 26, пересечение 25. Добавился только `cleanup-receipt.json`, исчезнувших нет.

УБОРКА ОДНОРАЗОВОГО СТЕНДА ДОКАЗАНА: `cleanup-receipt.result=OBSERVED-MATCH`, ноль остаточных баз и таблиц, база-фикстура отсутствует, финальный юнит inactive/not-found, процессов и сокетов нет, следы выключения есть.

ПРИЧИНА NO-GO РОВНО ОДНА: **сохранность ЧУЖИХ ресурсов хоста не доказана.** По слушателям 3030, 3610, 3611 и службе `nc-dev` предъявлен только пересказ в файле `cleanup-and-foreign-intact.md` — ни сырых выводов `ss` и `systemctl` до и после, ни обратного чтения PID и состояния, ни отпечатков этих снимков. Пустой `forbidden-listener.log` проверяет приватное сетевое пространство, а не ресурсы хоста. Приёмка права: «я посмотрел, всё цело» — это заявление, а не доказательство.

ПРО ЗАБЫТЫЙ МАРКЕР приёмка высказалась справедливо: волна 4393 не создала `WEB630R13RUN_DONE`, это нарушение порядка сдачи, но на содержательную мутационную проверку оно не влияет, и сам маркер — процедурная обязанность, автору содержательной сдачи не засчитывается.

ПОСТАВЛЕНО: 4402 в очередь A2 (за стендом) — предъявить СЫРЬЁ. Задание честное: сначала сказать, существует ли вообще снимок «до» (стенд разобран, его может не быть — тогда так и сказать, а не выдумать), затем снять полное состояние сейчас с соответствием `порт → PID → юнит`, и главное — **сопоставить ВРЕМЯ СТАРТА каждого чужого процесса с окном прогона `13:17`–`13:24`**. Если процесс стартовал раньше прогона и жив сейчас, значит прогон его не трогал: это доказательство сильнее любого пересказа и не требует снимка «до». Отдельно волна обязана показать, что сама чужого не задела, и прямо сказать, закрывает ли это претензию.

[20.09 14:49Z координатор] [линия закрыта содержательно: претензия приёмки снята сырьём; пятого дефекта нет; перевожу в review]

ЛИНИЯ ЗАКРЫТА СОДЕРЖАТЕЛЬНО. Единственная претензия приёмки 4397 снята волной 4402: `VERDICT=GO`, `BEFORE_SNAPSHOT_EXISTS=да`, `FOREIGN_INTACT=да`, манифест 31/31.

ЧТО ПРЕДЪЯВЛЕНО ВМЕСТО ПЕРЕСКАЗА. Снимок «до» НАЙДЕН — как неполный фрагмент в журнале самой волны прогона, `/home/ubuntu/waves/4393-web630r13run-codex.log`, строки 274–284: там записаны 3030→PID 1142, 3610→PID 261374, 3611 без PID, `nc-dev=active/enabled`, PID 1115 для PostgreSQL на 55450. Отдельного полного снимка хоста с отпечатком и временем захвата не сохранилось, и волна написала это прямо, а не выдумала недостающее.

Сырьё «сейчас» снято только чтением около 14:12–14:13 UTC отдельными файлами: полный `ss -ltnp`; отдельные `ss` по 3030, 3610, 3611; `systemctl status` и `is-active` для `nc-dev`; `systemctl show` для `nc-dev.service`, `nc-dev-pg.service` и `wave-dispatcher-a2.service`; `ps` и `/proc/*/cgroup` для PID 1115, 1142, 261374; сырые проверки владельца 3611 с его socket inode `2438090` и cgroup `session-133.scope`.

ГЛАВНОЕ ДОКАЗАТЕЛЬСТВО — СОПОСТАВЛЕНИЕ ВРЕМЁН СТАРТА С ОКНОМ ПРОГОНА `13:17–13:24 UTC`:
- `:3030`, PID 1142, `nc-dev.service` — старт 13.09 19:58:18 → жил до прогона и жив сейчас, не тронут;
- `:3610`, PID 261374, cgroup `wave-dispatcher-a2.service` — старт 13.09 23:45:49 → не тронут;
- `nc-dev.service`, MainPID 1142 — старт 13.09 19:58:18, `active/running` → не тронут;
- `nc-dev-pg.service`, PID 1115 — старт 13.09 19:58:18 → не тронут;
- `:3611` — установить не удалось и волна честно сказала почему: у LISTEN-сокета не был доступен PID (`ss -lnptoe` без нужных прав показывает только inode и cgroup), `lsof` и `fuser` не дали результата. При этом сам LISTEN, inode и cgroup совпадают до и после.

У 3030 и 3610 текущие PID СОВПАДАЮТ с найденным до-прогонным фрагментом. Ни один из процессов не стартовал в окне прогона.

ИТОГ ПО ЛИНИИ. Собираю все части воедино: пакет r13 принят приёмкой 4381; прогон выполнен волной 4393 с `overall.result=PASS`, манифест 164/164; приёмка 4397 построила СВОЮ таблицу по коду, нашла 26 полей, реально несущих решение, испортила каждое на отдельной полной копии сдачи и получила 26 из 26 красных; следы фактического прогона независимо подтверждены (юнит `nc4189-web630-1246877`, внутренний PID `1269642`, PostgreSQL 48077 готов `13:18:53Z`, Redis 48078 `13:19:00Z`, приложение `127.0.0.1:48079`, упорядоченное выключение `13:19:45Z`; из 155 общих с r11 путей лишь 102 совпали по отпечатку); состав расписок сверен (r11 — 25 имён, r13 — 26, добавился `cleanup-receipt.json`); уборка одноразового стенда доказана; сохранность чужих ресурсов теперь доказана сырьём.

**Пятого дефекта решающей логики нет. Четвёртый — «объявленная защита, не участвующая в решении» — закрыт и проверен на фактическом прогоне.** Перевожу тикет в review.

ОСТАТОК, КОТОРЫЙ НЕ СКРЫВАЮ: маркер завершения `WEB630R13RUN_DONE` волна 4393 не создала — волна не закрылась штатно, хотя сдача полная. Это процедурный долг, на содержание не влияет; в новые брифы на эту машину внесено отдельное требование создавать маркер.

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=Приёмка 4402: VERDICT=GO, BEFORE_SNAPSHOT_EXISTS=да, FOREIGN_INTACT=да, манифест 31/31; production landing принятого r13 в тикете не записан.
ЧТО НУЖНО=Ссылка на production landing r13: линия, полный commit/artifact и дата с readback.
triage-m1 4607

РЕШЕНИЕ=in_progress
ОСНОВАНИЕ=Волна 4402, VERDICT=GO, 2026-09-20: r13 и сохранность чужих ресурсов доказаны, но production landing принятого r13 не записан.
ЧТО НУЖНО=Добавить production landing r13: линия, полный commit/artifact и дата с readback; triage-neo 4710

[25.09 13:44Z координатор] 2026-09-25 13:44Z — по просьбе владельца начата некодовая работа Enterprise 2. Волна 5002 передана диспетчеру M4, пока QUEUED, старт не подтверждён. Сверка WEB-630 (пул, tenants, роли, документы, vectors, cleanup) и WEB-633 (сценарии, canaries, отрицательные проверки) с существующими доказательствами; для WEB-637 — остаток измерений и readiness. Новая нагрузка и изменения стенда запрещены. Результат: матрица PASS/FAIL/UNPROVEN, воспроизводимые офлайн-проверки, точные следующие действия. Закрытия тикетов авансом нет. Бриф: waves-20260921/5002-enterprise-evidence-audit-brief.md; материал M4 ~/waves/5002-material/tickets.json; ожидаемый отчёт ~/waves/5002ENTERPRISEEVIDENCEAUDIT-REPORT.md.

[25.09 14:07Z координатор] 25.09: аудит 5002 завершён, фактический evidence M4 ~/waves/5002-work/evidence; SHA256SUMS RC=0, DONE и dispatcher done подтверждены. GO относится к завершению аудита, не к закрытию карточки.

# Board comment draft — WEB-630

`KEEP_OPEN`

## Что принято

- r13 isolated line was accepted by independent review: 26 load-bearing fields mutated independently and all 26 turned the decision red; cleanup and foreign-resource preservation were supplied as raw evidence (#5740, 2026-09-20).
- Bounded seed/runtime controls are real: small full-schema seed (198 migrations / 206 tables / 51 rows / 2 MiB document) and r13 owner/shared/revoked/foreign ACL plus cleanup checks are recorded in the ticket history. No private auth/session fixture values are copied here.
- Repeatability, bounded isolation, negative ACL paths and idempotent `applyRun` are accepted only within those isolated scopes.

## Что реально осталось

1. WEB-630 body asks for 1000 users, 10 tenants, roles, at least 100 unique large docs, size classes, vectors and cleanup. The available proofs do not show that full corpus. 4996 has 500 runtime fixtures/pool entries, and WEB-637's pool-1000 is not a WEB-630 seed proof.
2. Vector HMAC/integrity does not prove vector dimensionality. A sanitized dimension/shape aggregate is missing.
3. Triage comment #6087 (2026-09-23) leaves a production-landing receipt for r13. This audit cannot perform or accept production/live work under the current stop rules.

## Следующая минимальная задача

Produce a fresh disposable full-corpus manifest proof: 1000 users, 10 tenants, role map, >=100 unique large documents, size histogram, vector dimensions, tenant-negative controls and run-owned cleanup replay. Then attach the exact r13 landing/readback receipt only if the owner still requires it. Keep fixture/auth/session values private.

## Safe commands / paths for the next authorized agent

- Verify preserved evidence only: `cd /Users/milamarty/waves/4996APPCPUPROFILE300-evidence && shasum -a 256 -c SHA256SUMS`.
- Read aggregate seed/runtime facts from the ticket-linked `checkpoint-3512` and r13/4402 receipts; do not print fixture files.
- For the full-corpus run, record only counts, SHA256, dimensions, tenant/role result counts, residual count and cleanup exit codes.

## Errors and stop conditions

- Stop if the manifest is stale, if a private fixture would be printed, if run ownership cannot be proven, or if cleanup observes a non-run-owned resource.
- Stop on any production/live endpoint, battle database, A1/Neo/M1, board, Telegram, Hetzner or secret request.
- Do not close from the r13 isolated result alone; do not equate 1000 pool entries with 1000 seeded or sustainable users.

Проверка координатора: внутренний SHA256SUMS самого архива r27-v26 действительно имеет 3 расхождения из 55: approved-source.mjs и k6-script.js отличаются, r27-v21.md отсутствует. Причина и соответствие использованной версии требуют разбора; старые сдачи не переписывать. Отсутствие k6 в PATH аудита не доказывает отсутствие бинарника на машине. Уточнение WEB-637: после красной ступени выше не идём; цель — честно измеренный предел, а не обязательное достижение 1000.