krona-staff/tests/e2e/NOTES-FOR-EXECUTORS.md

# Заметки для исполнителей (Codex / Antigravity)

Автор: Grok (стенд тестов и независимая приёмка). Я не меняю `src/`, `apps/`,
`migrations/`, `deploy/`; всё, что требует изменения продукта, описано здесь.

Как запускать:

```sh
# bootstrap-админ PostgreSQL 17 (только создаёт роли и БД; сервер и миграции под ним не работают)
export E2E_PG_ADMIN_URL=postgres://<admin>:<pass>@127.0.0.1:55433/postgres
node scripts/test/run-e2e.mjs                    # храповик known-defects (как в CI)
node scripts/test/run-e2e.mjs --no-known-defects # строгий режим: все дефекты красные
E2E_MIGRATIONS=roundtrip node scripts/test/run-e2e.mjs  # + откат всех миграций перед запуском
./scripts/test/ci-local.sh                       # локальный эквивалент verify/format/e2e
```

**Правило храповика.** Исправили дефект → его сценарий позеленел →
`run-e2e.mjs` падает с «дефект исправлен, обновите known-defects.json» —
удалите ID из `tests/e2e/known-defects.json` в том же коммите. Новый красный
сценарий, которого нет в списке, — регрессия.

## 1. Предполагаемый контракт для решений владельца (OWN-01..11) — Codex, этап 4

API пока нет, поэтому сценарии `tests/e2e/30-owner-decisions.e2e.ts` написаны
против наиболее вероятного контракта. Если выбираете другой — поменяйте тесты и
этот раздел в том же PR, смысл проверок (кто что может и когда) менять нельзя.
Все пути относительно `/api/v1/staff`.

### C1. Роли точки/бухгалтера/директора (standalone-аналог Core RBAC)

- `POST /access-grants` (только главный менеджер, `staff:employee:write`)
  тело `{ "role": "point_manager" | "accountant" | "director", "org_unit_ids": ["<ULID>"], "display_name": "..." }`
  → `201 { "id", "role", "org_unit_ids", "access_token" }`. Токен показывается один раз,
  хранится как хеш (как ключи сотрудников), используется как `Authorization: Bearer`.
- `point_manager` видит/считает только свои `org_unit_ids`; чужая точка → `403`
  (и для нового `POST /payroll/batches`, и для старого `POST /payroll/calculate`).
- В platform-режиме те же роли приходят из Core (User ≠ Employee, AGENTS.md).

### C2. Пакет зарплаты точки и согласование

| Метод и путь                                      | Кто                                   | Результат                                                                                                                            |
| ------------------------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `POST /payroll/batches` `{org_unit_id, from, to}` | accountant; point_manager своей точки | `201 {id, status:"draft", org_unit_id, lines:[{work_session_id, employee_id, org_unit_id, amount_minor}]}`                           |
| `POST /payroll/batches/:id/submit`                | только accountant                     | `200 {status:"submitted"}`; point_manager → `403`; повтор после подписи → `409`                                                      |
| `GET /notifications`                              | любой пользователь                    | `200 {notifications:[{type:"payroll.batch.submitted", subject_id:<batchId>}]}`; каждому директору ровно одно уведомление на отправку |
| `POST /payroll/batches/:id/sign`                  | только director                       | `200 {status:"signed"}`; accountant → `403`; если смена пакета изменилась после отправки → `409`, пакет получает `status:"returned"` |
| `POST /payroll/batches/:id/return` `{comment}`    | director                              | `200 {status:"returned", return_comment}`                                                                                            |
| `GET /payroll/batches/:id`                        | accountant, director                  | `200 {status, return_comment, lines:[...]}`                                                                                          |

Инварианты, которые проверяют тесты:

- до подписи в `staff_payroll_ledger` для сотрудников пакета нет ни `accrual`, ни `payout` (OWN-05);
- подпись атомарно пишет `accrual` и `payout`; после подписи `PATCH /work-sessions/:id`
  для смен пакета → `409`, пакет не отправляется повторно (OWN-06);
- строка пакета принадлежит точке, где отработана смена (`staff_work_sessions.org_unit_id`),
  а не основной точке сотрудника (OWN-09).

### C3. Согласие на биометрию

- `PUT /employees/:id/biometric-consent` `{ "status": "granted" | "revoked", "document_ref": "..." }`
  (главный менеджер) → `200`.
- `GET /terminal/employees/:id/enrollment` (терминальный токен) →
  `200 { "employee_id", "registration_allowed": boolean, "reason": "consent_missing" | "consent_revoked" | null }`.
  Без записи о согласии — `false/consent_missing` (OWN-10); после отзыва — `false/consent_revoked` (OWN-11).
- Шаблоны отпечатков на сервер не передаются (docs/TERMINAL-API-REQUIREMENTS.md);
  сервер хранит только факт согласия. Тот же флаг стоит отдать в `/sync/pull` (employee payload).

Сейчас все OWN красные с `404 Route ... not found` (C1–C3 не реализованы);
OWN-03..09 дополнительно упрутся в K3/N2 (подтверждение смены падает 500).

ID в названиях тестов — двойные «владелец/мой» (`[K3/N2]`, `[D6/OWN-01]`, `[K17/OWN-10]`,
`[K19/OWN-07]`), по таблице TASK-GROK-2 §2 и AUDIT.md.

### C4. Проверочный пересчёт подписанной ведомости (K8/D1)

- `GET /payroll/runs/:id/verify` (право `staff:payroll:read`) →
  `200 { "run_id", "stored_total_minor", "recalculated_total_minor", "matches": boolean }`.
- Пересчёт идёт по снимку версий правил, параметров и ставок, действовавших при подписи
  (и ревизиям смен), а не по текущим значениям. После смены ставки `matches` остаётся `true`.

### C5. Параметры пресета в назначении оплаты (K9/D3)

- `PUT /employees/:id/pay-assignment` принимает `params: { <key>: integer }`, ключи — из
  `param_declarations` выбранного правила (например, `shift_rate_minor`, `percent_bp`,
  `upsell_rate_minor`, `avg_check_target_minor`, `avg_check_bonus_minor` у `waiter_upsell`);
  неизвестный ключ → 400. `GET .../pay-assignment` возвращает их в `params`.
- Старые поля `rate_minor`/`percent_bp`/`guarantee_minor` можно оставить как сокращения.

### C6. Перенос арендатора пилота (PILOT-REHOME, TASK-CODEX-2 п.2.2)

Что проверяет `tests/e2e/60-pilot-rehome.e2e.ts` (`[PILOT-REHOME]`):

- Запуск: `DATABASE_ADMIN_URL=<админ БД> node scripts/rehome-tenant.mjs --from 01J00000000000000000000000 --to 01M2R6AC5652NPT3MG34DKN4ZP [--dry-run] [--json]`.
  Стенд передаёт `DATABASE_ADMIN_URL` суперпользователя в БД стенда (`E2E_DB_ADMIN_URL` или
  `E2E_PG_ADMIN_URL` с именем БД).
- `--json`: последней строкой stdout — `{"tables":{"<таблица>":<строк у --from>},"ledger_amount_minor_sum":<число или строка>}`
  (счётчики — число или строка с числом).
  Таблицы с нулём можно не печатать.
- `--dry-run`: exit 0, те же числа, в БД ничего не меняется.
- Перенос: exit 0; под `--from` 0 строк во **всех** таблицах с `tenant_id` (список из
  `information_schema.columns`, не вручную); у `--to` те же счётчики и та же
  `SUM(amount_minor)` в `staff_payroll_ledger`; другие арендаторы не тронуты.
- В `staff_audit_log` у нового арендатора появляется запись с `action`, содержащим `rehome`
  (например, `tenant.rehomed`, старый tenant — в `new_values`).
- После переноса `krona_staff_app` видит тех же сотрудников (те же `id`) под новым tenant и никого
  под старым; `UPDATE staff_payroll_ledger` ролью приложения по-прежнему отклоняется.
- Повторный запуск (под `--from` пусто / у `--to` уже есть данные) — exit ≠ 0, ничего не меняет.

Что нужно учесть (видно по схеме, `pg_policy`/`pg_constraint` на PG17):

- У `staff_payroll_ledger` нет политики UPDATE/DELETE, у приложения нет права UPDATE, FORCE RLS
  действует и на владельца: `krona_migrator` строки журнала не перенесёт. Нужна роль с обходом RLS
  (суперпользователь/BYPASSRLS) — поэтому `DATABASE_ADMIN_URL`.
- Внешние ключи составные `(tenant_id, …)` и не DEFERRABLE: переносить родителя раньше детей
  нельзя — нужен порядок, отложенные проверки или `session_replication_role = replica` в одной транзакции.
- Политики INSERT `staff_audit_log`, `staff_payroll_ledger`, `staff_attendance_events`,
  `staff_timesheet_entries` требуют `actor_id/created_by/updated_by = current_setting('app.user_id')` —
  для записи аудита без обхода RLS выставить `app.user_id`.

**Расхождение с `codex/fix-tenant-rehome` (c73bb3b, 16:48 NOVT; ACCEPTANCE-3 с просьбой держаться C6 — 16:35).**
Сценарий на ветке: `dry-run exit: Tenant rehome stopped. Unknown option --from.` По существу скрипт делает
всё, что проверяет сценарий (см. REPORT «Круг 3б»); не совпадает только интерфейс:

| C6 (сценарий)                               | c73bb3b                                                                 | Итог в сценарии                                    |
| ------------------------------------------- | ----------------------------------------------------------------------- | -------------------------------------------------- |
| `--from`, `--to`                            | `--source`, `--target`                                                  | `Unknown option --from`, exit 1                    |
| без флага — перенос                         | нужен `--apply`, без режима — `Specify --dry-run or --apply.`           | —                                                  |
| —                                           | `--apply` требует `--actor <ULID>` и `--backup-evidence <json>`         | у сценария нет ни того, ни другого                 |
| `--json`                                    | неизвестный флаг → exit 1; JSON печатается всегда                       | —                                                  |
| `DATABASE_ADMIN_URL`                        | `DATABASE_REHOME_URL` (запасной вариант `DATABASE_MIGRATION_URL`)       | —                                                  |
| одна строка JSON, числа                     | многострочный JSON (`JSON.stringify(…, null, 2)`), счётчики — строки    | парсер сценария ищет JSON в последней строке       |
| `ledger_amount_minor_sum` в dry-run и apply | в dry-run суммы нет; в apply `payrollLedger: [{currency, amountMinor}]` | с адаптером: `expected 'undefined' to be '328228'` |
| `tables` — строки у `--from`                | в apply `tables` — у `--to` после переноса (`staff_audit_log` +1)       | не проверяется                                     |

**d52ecf3 (17:02)** закрыл строки 1, 4, 5 таблицы: `--from/--to`, `--json`, `DATABASE_ADMIN_URL` принимаются. Без
флага теперь **dry-run** (по C6 — перенос), так что запуск сценария без `--apply` не переносит данные. Открытыми
остаются многострочный JSON (сценарий: `dry-run без JSON-отчёта`), сумма журнала в dry-run и обязательные
`--apply --actor --backup-evidence` (разд. 6.3 в `report-evidence/round3-k18-and-rehome.md`). Типы счётчиков
расходились из-за ошибки сценария; она исправлена в d477dde, сравнение идёт через `Number()`.

Какой интерфейс оставить, решает владелец. Варианты: (а) Codex добавляет в скрипт C6-совместимые
`--from/--to/--json`, `DATABASE_ADMIN_URL`, сумму журнала в dry-run, а `--actor`/`--backup-evidence`
берёт из переменных окружения (например, `REHOME_ACTOR_ID`, `REHOME_BACKUP_EVIDENCE`); (б) владелец утверждает
интерфейс c73bb3b — тогда я меняю сценарий под него отдельным коммитом, а сумму журнала в dry-run
оставляю требованием (TASK-GROK-3 §4 п.3: «`--dry-run` — ничего не меняет, печатает те же числа», то есть числа п.2, включая `SUM(amount_minor)`). В TASK-CODEX-2 §2.2 п.4 dry-run
описан как «только отчёт о количестве строк по таблицам», то есть по этому пункту c73bb3b задание
выполняет, а расходится только с C6.

## 2. Дефекты продукта, найденные сценариями (все красные сейчас)

Команда и фактический вывод — `tests/e2e/evidence/e2e-run.txt`; таблица — `tests/e2e/REPORT.md`.

| ID                     | Файл                                                                                    | Что исправить                                                                                                                    |
| ---------------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| K4/N1                  | `src/portal.ts` POST /employees                                                         | `42P08 inconsistent types deduced for parameter $2`: явные `$2::varchar(26)`, `$5::text` или отдельный запрос профессии          |
| K3/N2                  | `src/portal.ts` PATCH /work-sessions, `src/domain/payroll/service.ts` calculate/approve | `staff_outbox.occurred_at` NULL (23502): передавать `occurred_at` или `DEFAULT now()` новой миграцией                            |
| K5/N4                  | `service.ts`                                                                            | после N2 проверить: пересекающийся период не должен начислять смену повторно (409 или исключение уже начисленных смен)           |
| K12/N3                 | push-подписки                                                                           | allowlist push-сервисов / запрет приватных адресов, `redirect:'manual'`; сейчас сервер подключается к `127.0.0.1`                |
| N9                     | `push-dispatcher.ts`                                                                    | `ON CONFLICT ... DO UPDATE SET employee_id` → 409 для чужого endpoint                                                            |
| N10                    | GET /professions, /org-units                                                            | требовать право справочника; терминал сейчас получает 200                                                                        |
| N11                    | импорт                                                                                  | валидировать `kind` и схему `items` → 400 вместо 500 (23514)                                                                     |
| N12                    | PUT pay-assignment                                                                      | `additionalProperties:false`, верхние границы сумм                                                                               |
| N12-DATE               | `POST /payroll/calculate`                                                               | `month=2026-13` → 500 `22008`; проверять месяц 01–12 → 400 (диапазон `2026-02-30` уже даёт 400)                                  |
| K6/D5                  | `portal.ts` PATCH /work-sessions                                                        | смена подписанной ведомости: `409`, либо сторно в ledger; сейчас (на fix-live-database) 200 и начисление остаётся                |
| K7/D2                  | `operations.ts` импорт `payroll_entries`                                                | дельта по сумме всех записей дня, вставка по ключу: две точки за день → 222,00 вместо 333,00 ₽; считать дельту по ключу          |
| K8/D1                  | расчёт/подпись                                                                          | снимок правил и ставок в подписанной ведомости; контракт проверки C4 (ниже)                                                      |
| K9/D3                  | PUT pay-assignment                                                                      | сохранять `params` по `param_declarations` правила (C5 ниже); сейчас `shift_rate_minor` официанта теряется                       |
| S9                     | миграция 0011 FK устройств                                                              | `ON DELETE SET NULL` на составном `(tenant_id, org_unit_id)` обнуляет `tenant_id` → 23502; `SET NULL (org_unit_id)` или RESTRICT |
| A4                     | обработчик ошибок                                                                       | в теле 5xx нет SQLSTATE (`code`) и текста PostgreSQL; подробности только в лог                                                   |
| K1/F2                  | `config.ts`/`identity.ts`                                                               | standalone без токенов не должен выдавать права (процесс без токенов отдаёт 200 на /portal, /payroll, POST /professions)         |
| K10/F3                 | POST/DELETE /session                                                                    | в cookie — идентификатор сессии, а не сырой токен; logout отзывает сессию                                                        |
| K11/F4                 | вход                                                                                    | rate limit (тест ждёт 429 не позже 30 неверных попыток; идёт на отдельном процессе, чтобы лимит не мешал другим сценариям)       |
| F7                     | POST /attendance/events                                                                 | использовать `Idempotency-Key` / `staff_idempotency_keys`                                                                        |
| F10                    | `assertSameOrigin`                                                                      | мутации по cookie без `Origin` отклонять                                                                                         |
| K13/SYNC-A, K13/SYNC-B | `src/domain/sync/service.ts`                                                            | устройство не должно выставлять `confirmed`/`approved` (сейчас `applied`)                                                        |
| SYNC-C0                | `pull()` bootstrap                                                                      | `SELECT ... status FROM staff_org_units` — такого столбца нет → 500 на любой начальной загрузке                                  |
| S5/SYNC-C              | `pull()` bootstrap                                                                      | при `has_more=true` отдаётся `next_cursor=latest`, остаток после 100 сущностей теряется; нужен курсор снимка                     |
| S5/SYNC-D              | портал/импорт                                                                           | изменения вне sync не пишутся в `staff_sync_change_log` → терминал не узнаёт о новых/изменённых сотрудниках                      |
| S4/SYNC-E              | `executeCommand`                                                                        | проверять `status='active'` сотрудника                                                                                           |
| S4/SYNC-F              | `executeCommand`                                                                        | сохранять `org_unit_id` в `staff_attendance_events`; payload не может переопределить точку устройства                            |
| S3/SYNC-G              | `push()`                                                                                | ошибки БД одной команды → `rejected` для неё, а не 500 и откат всего пакета                                                      |
| S8/SYNC-H              | `/sync/devices`                                                                         | `assertCookieMutationOrigin` как в портале                                                                                       |
| K1/SYNC-I              | `requireManagerContext`                                                                 | без токенов не выдавать права (как F2)                                                                                           |
| S2/SYNC-J              | `executeCommand`                                                                        | окно времени отметки как в POST /attendance/events (−180 дней … +5 мин)                                                          |
| SYNC-K                 | `acknowledge()`                                                                         | отклонять курсор больше `MAX(cursor_seq)`                                                                                        |

## 3. deploy/ (K1/PILOT-1, K2/PILOT-2) — Codex

- PILOT-1: все подстановки в `deploy/pilot/compose.yaml` → `${VAR:?VAR is required}`
  (сейчас 14 без `:?`: пустой `STANDALONE_MANAGER_TOKEN` молча превращает pilot в F2).
- PILOT-2: `NODE_ENV: development` в `app`. Конфликт: `config.ts` запрещает
  `STAFF_RUNTIME_MODE=standalone` при `NODE_ENV=production`. Нужно решение: либо
  разрешить standalone в production при обязательных токенах и HTTPS, либо
  отдельный режим для pilot. Тест требует только «не development».
- N6: `scripts/create-app-role.mjs` не работает мигратором без SUPERUSER
  («Only roles with SUPERUSER may change the SUPERUSER attribute»). CI и e2e
  обходятся `scripts/test/provision-pg.mjs` (роли создаёт bootstrap-админ, как
  `docker/postgres/init-app-role.sh`). В pilot мигратор = `POSTGRES_USER` =
  суперпользователь; рекомендую схему как в provision-pg.mjs.

## 4. CI

- Задаче `docker-build` нужен раннер с меткой `docker-host` (Docker daemon).
  Без него задача ждёт в очереди; остальные задачи не блокируются.
- `format` красная, пока не исправлен F14 (23 файла на замер 2026-09-26, в основном `src/`, `docs/`, `tests/unit/`).
- `format` станет зелёной после влития `codex/fix-format-baseline` (проверено на ветке).
- Задача `windows` выключена, пока нет раннера с меткой `windows`: включается переменной
  репозитория `KRONA_WINDOWS_RUNNER=true`; для полного e2e нужен секрет
  `WINDOWS_E2E_PG_ADMIN_URL` (локальная PostgreSQL 17 на раннере).
- `tests/e2e/evidence/` не хранится в git; в CI это артефакт `e2e-evidence`.
- Реальный Forgejo-раннер мной не запускался (нет API-токена) — не проверено.

## 5. N13 (гонка первого расчёта) и утечка текста ошибок БД

- `scripts/test/n13-race.mjs`, вывод `tests/e2e/evidence/n13-race.txt`: 10/25/50
  параллельных первых `POST /payroll/calculate` × 5 попыток. Как есть — все 500 (N2),
  гонку не видно. В одноразовой БД с обходом N2 (`DEFAULT now()` только там) — 0 из 30
  некорректных попыток (без смен и с подтверждённой сменой): один `run_id`, один расчёт в БД.
- Почему не воспроизводится (вывод из кода, не проверено отдельным экспериментом):
  `calculatePayroll` сначала вызывает `ensureDefaultPayRules`, а там
  `INSERT ... ON CONFLICT DO UPDATE` по одним и тем же строкам `staff_pay_rules` тенанта.
  Первая транзакция держит блокировки этих строк до коммита, остальные ждут — расчёты
  одного тенанта выполняются по очереди случайно. Если upsert правил вынесут из расчёта
  или сделают `DO NOTHING`, окно `SELECT ... FOR UPDATE` (строки нет) → `INSERT ... ON
CONFLICT DO NOTHING` со своим `runId` → строки/UPDATE по несуществующему `runId` вернётся.
  Рекомендация: явный `pg_advisory_xact_lock` по (tenant, org_unit, period_start) или
  `INSERT ... ON CONFLICT DO UPDATE ... RETURNING id`. Скрипт стоит перезапустить после
  такого изменения.
- Ответы 500 содержат сырой текст ошибки PostgreSQL (например
  `null value in column "occurred_at" of relation "staff_outbox" ...`) — клиенту видна
  схема БД. Для 5xx отдавать нейтральное сообщение, подробности — только в лог.

## 6. Приёмка веток исполнителей (2026-09-26)

Подробно — `tests/e2e/REPORT.md` и `tests/e2e/report-evidence/acceptance-*.txt`.

- `codex/fix-live-database` (ea68e12, перепроверено на b289dd6): K3/N2 и K4/N1 зелёные на живой PostgreSQL 17.
  Дальше по цепочке открылись K5/N4 (196800 вместо 98400 — двойное начисление) и
  K6/D5 (отклонение оплаченной смены: 200, начисление осталось). A4 частично: `POST /employees`
  больше не 500, но `month=2026-13` по-прежнему отдаёт `code=22008` с текстом.
- `codex/fix-format-baseline` (fd1ec3d): `prettier --check .` чистый. **Но коммит «style»
  содержит функциональное исправление Antigravity**: `src/domain/sync/service.ts` и
  `tests/unit/sync.test.ts` после нормализации prettier совпадают с
  `antigravity/fix-reject-device-shifts` (0 строк diff) и отличаются от 331e490 на 255/139
  строк. Изменение поведения стоит вынести в отдельный коммит с объяснением или влить
  ветку Antigravity отдельно, иначе история смешивает темы (AGENTS.md).
- `antigravity/fix-reject-device-shifts` (795bba0, перепроверено на 1df2019 — уже на f5ac179):
  K13/SYNC-A и K13/SYNC-B зелёные, остальное без изменений.
- Ни одна ветка не влита в основную (f5ac179), поэтому ID из `known-defects.json` не удалены.
- Суммы в тестах кратны рублю: расчёт округляет строку до `rounding_unit_minor`
  (по умолчанию 100 коп.). Если округление должно быть другим — это решение продукта, не теста.

## 7. Круг 3 (TASK-GROK-3, 2026-09-26)

Команды и полный вывод — `tests/e2e/REPORT.md` («Круг 3») и `tests/e2e/report-evidence/round3-*.md`.
Приёмка одной командой: `node scripts/test/accept-branch.mjs <ветка>…` (нужен `E2E_PG_ADMIN_URL`
или готовые роли в `E2E_MIGRATOR_URL` + `E2E_APP_URL`).

- **Antigravity, `sync-bootstrap.test.ts` (8baad55)**: `Error: Called end on pool more than once` при
  `Tests 2 passed`. Причина: `app.close()` в тесте вызывает хук `onClose` → `database.close()`
  (`src/app.ts:148`), затем `afterAll` закрывает тот же `Database` ещё раз. На текущей голове
  `24cc18d` файл зелёный (`1 passed (1) | 2 passed (2)`).
- **Antigravity, `sync-rejection.test.ts` (1df2019)**: `column "created_by" of relation "staff_employees"
does not exist` в `beforeAll` (`Tests 2 skipped`). На `6c5bf36`/`b283736` исправлено.
- **Конфликты**: на прежних головах `1df2019 × 8baad55` и `8baad55 × 513cdff` конфликтовали в
  `src/domain/sync/service.ts`; на текущих головах (fetch 16:16 NOVT) конфликтов нет ни в одной из 55 пар.
- **Codex, `codex/fix-format-baseline`**: на `513cdff` в `service.ts`/`sync.test.ts` было 232/130 строк сверх
  prettier, все есть в `antigravity/fix-reject-device-shifts`; на `a05777c` — только форматирование (19 файлов).
- **Codex, `live-postgres-remediation.test.ts`**: выполняется только при `DATABASE_TEST_ISOLATED=true`,
  `DATABASE_TEST_GUARD_TOKEN`, таблице `krona_staff_test_guard` с этим маркером и имени БД
  `krona_staff_audit_*`. Соглашение нигде, кроме самого теста, не описано, и ни CI, ни
  `scripts/test/*` его не выполняют — в `npm run check` файл всегда `skipped`. `accept-branch` ставит
  предохранитель в одноразовой БД: `1 passed (1)`. Предложение: описать соглашение в README/AGENTS
  и после слияния включить его в CI (могу сделать в своей зоне, `.forgejo/workflows/ci.yml`).
- **N5 до сих пор в основе**: `tenant-isolation.test.ts` красный на `b0243d5` и всех ветках от
  `f5ac179` (`permission denied for table staff_employees`); исправление — в `grok/e2e-harness`.
  Локальная сборка основа + fix-live-database + fix-sync-c0-bootstrap + grok/e2e-harness:
  интеграционные 7/7, храповик просит убрать ровно K3/N2, K4/N1, K13/SYNC-A, K13/SYNC-B, SYNC-C0.
- **Схема (низкий приоритет)**: `staff_notification_deliveries.outbox_id → staff_outbox(id)` — единственный
  внешний ключ без `tenant_id`; все остальные составные `(tenant_id, …)`. База не мешает доставке
  ссылаться на событие outbox другого арендатора (RLS фильтрует чтение, но не ссылку). Предложение:
  `UNIQUE (tenant_id, id)` на `staff_outbox` и FK `(tenant_id, outbox_id)`.
- **PILOT-REHOME**: скрипта нет → `[PILOT-REHOME]` красный; контракт — C6.

## 8. Круг 3б (основа f7d3c73, 2026-09-26 ~17:00 NOVT)

Вывод — `tests/e2e/report-evidence/round3-accept-f7d3c73.md`, `round3-k18-and-rehome.md`.

- **codex/fix-tenant-config (535052e)**: `npm run check` красный —
  `tests/unit/sync.test.ts:556:18` → `STANDALONE_TENANT_ID uses the development placeholder…`
  (строка 553 — заглушка, 563 — `NODE_ENV: 'test'`). Вывод владельца подтверждён; как исправить —
  ACCEPTANCE-3 (разрешить заглушку при `NODE_ENV === 'test'`).
- **codex/fix-tenant-rehome (c73bb3b → d52ecf3)**: по существу перенос верный (копия после восстановления: счётчики,
  ledger, FK, аудит `tenant.rehomed`, изоляция, отказ повтора). `[PILOT-REHOME]` красный из-за интерфейса —
  таблица различий в C6. Интеграционный тест `rehome-tenant.test.ts` зелёный только с
  `DATABASE_REHOME_TEST_URL`/`DATABASE_REHOME_TEST_CONFIRM` — в `npm run check` и CI он всегда `skipped`.
  Тест требует подключения суперпользователя (`rehome-tenant.test.ts:92-93`) и содержит один `it` —
  запуск скрипта от не-суперпользователя (как `krona_migrator` в пилоте) не покрыт.
- **codex/fix-pilot-backups (a005c5e → b022885, K18)**: `test-backup.sh`/`test-backup-pull.sh` проходят (моки), но в
  `npm run check` и CI не входят. Учебное восстановление без Docker прошло (шим docker → pg_dump PG17,
  CMS, sha256, pg_restore, `restore-drill-report.sql` совпал). Замечания:
  - `backup.sh` снимает только `pg_dump -Fc` одной БД: ролей (globals) в копии нет. В кластере без ролей
    `pg_restore` → exit 1, 61 ошибка `role "krona_migrator" does not exist`. Шаг 4 runbook («Restore required
    roles and grants») нужно сделать исполнимым: скрипт создания ролей для восстановления или
    `pg_dumpall --globals-only --no-role-passwords` рядом с копией.
  - `restore-drill-isolation.sql` жёстко зашит на `01J00000000000000000000000` → `01M2R6AC5652NPT3MG34DKN4ZP`;
    после переноса «source/target» поменяются местами — стоит параметризовать (`psql -v`).
  - В `docs/BACKUP-RESTORE.md` личный путь `C:/Users/trush/Documents/KronaStaffBackups/` — в репозитории
    лучше указать роль или место без имени пользователя.
  - b022885: ротация копий на ПК есть (`BACKUP_LOCAL_RETENTION_DAYS`, 90 дней; в `test-backup-pull.sh` есть проверка),
    ротации на сервере нет. В новых `scripts/run-pilot-backup-pull.ps1` и `deploy/pilot/backup.home-server.example`
    тоже зашиты личные пути. Контроль отказов таймера и задачи pull пока описан только в документе.
- Предложение (моя зона, после слияния): добавить в CI `bash scripts/test-backup.sh`,
  `bash scripts/test-backup-pull.sh` и запуск `rehome-tenant.test.ts` / `live-postgres-remediation.test.ts`
  на одноразовых БД — так же, как это делает `accept-branch`.