# Задание для Grok, круг 2: Windows, сопоставление ID, недостающие сценарии, приёмка - Репозиторий: https://git.ochenstarik.ru/ochenstarik/krona-staff - Основа: текущая основная ветка `codex/bootstrap-platform-foundation` (`331e490`) и твоя ветка `grok/e2e-harness` (`421da72`) - Полный аудит владельца теперь в репозитории: `docs/audit/2026-09-26/AUDIT.md`; таблица соответствия ID ниже дублирует главное. ## Итог приёмки прошлого круга Ветку `grok/e2e-harness` проверили на живой PostgreSQL 17.10. Вердикт: **принять после правок из пункта 1**. **Что сделано хорошо:** - Зона соблюдена: код продукта не тронут. - Все коммиты с объяснением причины. - Прогон дал ровно те же 38 красных и 9 зелёных сценариев, что в твоём отчёте. - Логика `known-defects.json` верная. - SYNC-C0 — настоящая находка, которой не было в аудите владельца: начальная загрузка синхронизации на реальной базе отвечает 500 (`column "status" does not exist`). - Перекрёстная проверка: исправление Antigravity (`antigravity/fix-reject-device-shifts`) на твоих сценариях переводит SYNC-A и SYNC-B в зелёные. **Что не так:** 1. **Под Windows стенд не запускается** (проект разрабатывается под Windows). Все три места падают с `ENOENT`, потому что в Windows это `.cmd`: - `scripts/test/run-e2e.mjs:35` — `spawn('npx', …)`; - `tests/e2e/harness/global-setup.ts:67` — `spawn(node_modules/.bin/tsx, …)`; - `scripts/test/n13-race.mjs:102` — то же, что в предыдущем пункте. 2. **ID аудита владельца не сопоставлены** — таблица ниже. 3. **`tests/e2e/evidence/` коммитится в репозиторий** и будет меняться при каждом прогоне. ## Правила — как раньше - Ветка `grok/e2e-harness` (дописывай в неё), маленькие коммиты с причиной в теле. - Твоя зона: `tests/e2e/**`, `tests/integration/**` (только очистка и стенд), `.forgejo/workflows/ci.yml`, `scripts/test/**`. - `src/`, `apps/`, `migrations/`, `deploy/` не трогать. Нужна правка продукта — пиши в `tests/e2e/NOTES-FOR-EXECUTORS.md`. ## 1. Правки, без которых ветку не влить (сегодня) | Что сделать | Готово, когда | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Запуск без `.cmd`-обёрток: `spawn(process.execPath, [<путь к tsx/dist/cli.mjs>, 'src/server.ts'])`, vitest — через `process.execPath` и его `vitest.mjs`, либо `shell: true` на `win32`. Добавить в CI проверку запуска на Windows, если есть раннер; если нет — записать это в REPORT | `node scripts/test/run-e2e.mjs` работает на Windows 11 с Node 22+ без правок | | `tests/e2e/evidence/` убрать из git и добавить в `.gitignore`. Результаты прогона — артефакт CI. В репозитории оставить `REPORT.md` и таблицу | Повторный прогон не меняет отслеживаемые файлы | | Перебазировать ветку на `331e490` | Вливается без конфликтов | ## 2. Сопоставление с ID аудита владельца Переименуй теги в названиях сценариев в формат `[K3/N2]`, а ключи в `known-defects.json` — в двойные. | ID владельца | Твой сценарий | Суть | | -------------------------- | -------------- | ----------------------------------------------------------------------------------- | | K1 | F2 | Без токенов анонимный запрос получает права | | K3 | N2 | Вставка в outbox без `occurred_at`: подтверждение, расчёт, утверждение падают с 500 | | K4 | N1 | `POST /employees` падает с 500 (`42P08`) | | K5 | N4 | Пересекающиеся расчёты начисляют смену повторно | | K10 | F3 | Сырой токен в cookie, выход не отзывает сессию | | K11 | F4 | Нет ограничения частоты | | K12 | N3 | SSRF через push-подписку | | K13 (S1) | SYNC-A, SYNC-B | Устройство создаёт подтверждённые смены и табель | | S2 | SYNC-J | Отметка задним числом через синхронизацию | | S3 | SYNC-G | Одна битая команда откатывает пакет | | S4 | SYNC-E, SYNC-F | Лишние данные на устройство, отметки уволенных, чужая точка | | S5 | SYNC-C, SYNC-D | Курсор теряет изменения | | S8 | SYNC-H | CSRF на управлении устройствами | | K19 (D4) | OWN-07 | Подпись устаревшего пакета | | D6 | OWN-01, OWN-02 | Управляющий вне своих точек | | K17 | OWN-10, OWN-11 | Согласие на биометрию | | N9, N10, N11, N12, F7, F10 | те же | — | ## 3. Недостающие сценарии Все проверяют правильное поведение. Сейчас они красные — внеси их в `known-defects.json`. | ID владельца | Сценарий | Ожидаемое поведение | | ------------ | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | K6 (D5) | Подтверждённую смену включают в расчёт, руководитель подписывает, затем смену отклоняют | 409 или создаётся сторнирующая запись. Сейчас: 200, сторно нет, начисление остаётся | | K7 (D2) | Импорт книги: начисления за один день на двух точках, затем повторный импорт с изменённой суммой | Итог в реестре равен сумме по книге. Сейчас теряется: вторая точка пишется как отрицательная корректировка, изменение суммы пропадает | | K8 (D1) | Расчёт подписан, затем меняется правило оплаты или ставка, затем подписанную ведомость пересчитывают для проверки | Сумма та же, что в подписанной ведомости | | K9 (D3) | Сотрудник с пресетом «официант» (оклад смены, процент от личных продаж, допродажи, премия за средний чек) | Начисление по параметрам пресета. Сейчас 0 ₽: сохраняются только ставка, процент и гарантия | | S9 | Удаление точки, к которой привязано устройство синхронизации | Точка удалена или получен понятный отказ. Сейчас 500, `23502 null value in column "tenant_id"` | | A4 | Любой ответ 500 | Без кода и текста ошибки PostgreSQL в теле. Сейчас наружу уходят, например, `42P08` и `23502` с текстом | | N12-дата | Расчёт с `month = 2026-13` | 400. Сейчас 500 | ## 4. Приёмка 1. **Ветка Antigravity `antigravity/fix-reject-device-shifts`.** После того как Antigravity исправит очистку в `sync-rejection.test.ts` и ветку вольют, убери SYNC-A и SYNC-B из `known-defects.json` отдельным коммитом. 2. **Ветки Codex `codex/fix-format-baseline` и `codex/fix-live-database`** (этапы 0 и 1: форматирование, K3, K4). Прогони стенд на каждой и дай таблицу «ID — было — стало — доказательство». Если K3 и K4 зелёные, убери их из списка известных дефектов после влития. 3. **Дальше** — каждая новая ветка Codex и Antigravity, по той же схеме. На слово ничего не принимать. ## Порядок Пункт 1 → пункт 2 → пункт 3. Приёмку из пункта 4 веди параллельно, по мере появления веток. ## Отчёт Обновлённый `tests/e2e/REPORT.md`: что изменилось, таблица «ID владельца / твой ID — цвет — фактический вывод», приёмочные таблицы по веткам исполнителей.