Почему: TASK-GROK-3 п.1 — на общем кластере (параллельные прогоны приёмки, чужой стенд)
пересоздание ролей krona_migrator/krona_staff_app со случайными паролями ломает соседей.
Если заданы оба URL, global-setup не вызывает provision и не требует E2E_PG_ADMIN_URL;
по умолчанию поведение прежнее. provision-pg получил --roles keep: пересоздать только БД,
не меняя паролей (нужно accept-branch для отдельной БД на ветку).
ctx.adminDatabaseUrl (E2E_DB_ADMIN_URL или E2E_PG_ADMIN_URL + БД стенда) — только для PILOT-REHOME.
Проверено: run-e2e с E2E_MIGRATOR_URL/E2E_APP_URL без E2E_PG_ADMIN_URL — 45 failed | 9 passed,
как на основе; повторный прогон на уже мигрированной БД — то же.
Зачем: 156 зелёных тестов на fakeDatabase не поймали, что ключевые
сценарии (создание сотрудника, подтверждение смены, расчёт зарплаты)
всегда падают на реальной PostgreSQL. Нужен приёмочный стенд, который
проверяет продукт как чёрный ящик: настоящий процесс сервера, настоящая
БД, роли как в pilot, но с минимальными привилегиями.
- tests/e2e/harness/global-setup.ts: создаёт БД и роли через
scripts/test/provision-pg.mjs, применяет миграции ролью krona_migrator
(NOSUPERUSER), поднимает `tsx src/server.ts` под krona_staff_app с
токенами/VAPID из crypto.randomBytes; три процесса: с токенами, без
токенов (как корневой compose.yaml) и отдельный для проверки rate limit;
логи серверов пишутся в tests/e2e/evidence/.
- *.e2e.ts и отдельный vitest.e2e.config.ts: e2e не попадают в `npm test`,
поэтому `npm run check` не требует БД и не краснеет от известных дефектов.
- [HARNESS]/[CTRL] — позитивные контроли (версия PG >= 17, атрибуты ролей,
app-роль не видит schema_migrations, RBAC, уволенный теряет доступ):
если они красные, красные дефектные сценарии ничего не доказывают.
- scripts/test/run-e2e.mjs: «храповик» известных дефектов по
tests/e2e/known-defects.json (новый красный или исправленный-но-не-
вычеркнутый ID = exit 1), таблица e2e-table.md и проверка, что в
evidence нет ничего похожего на секреты стенда.
Логи названы *.txt, т.к. *.log в .gitignore.
