ci / verify (push) Waiting to run

Details

docs(audit): add second acceptance and third-round tasks

Приёмка второго круга: Grok принят, у Codex форматирование
по-прежнему несёт исправление синхронизации Antigravity, у Antigravity
два интеграционных теста красные на реальной базе и две ветки
конфликтуют между собой. Задания третьего круга фиксируют, что именно
доделать и в каком порядке вливать, плюс перевод пилота с
арендатора-заглушки на настоящего.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-26 15:56:31 +07:00

9.1 KiB

Raw Blame History

Задание для Grok, круг 3: приёмка с интеграционными тестами, конфликты веток, сценарий переноса арендатора

Репозиторий: https://git.ochenstarik.ru/ochenstarik/krona-staff
Основа: codex/bootstrap-platform-foundation (f5ac179)
Итоги приёмки: docs/audit/2026-09-26/ACCEPTANCE-2.md. Ветка grok/e2e-harness (ba59a48) принята и вливается первой.

Итог прошлого круга

Принято без замечаний по существу: стенд работает на Windows без правок, ID сопоставлены с аудитом, недостающие сценарии добавлены, приёмка ветки Codex совпала с моей до цифры (41 красный / 13 зелёных). Твоя находка про поведение в «стилевом» коммите Codex подтверждена.

Одно упущение: в приёмке запускались только tests/e2e, а интеграционные тесты самих исполнителей — нет. Из-за этого два красных файла Antigravity прошли бы как «принято».

Правила — как раньше

Только твоя зона: tests/e2e/**, scripts/test/**, known-defects.json, CI. В код исполнителей не коммитишь. Ветки исполнителей не меняешь — проверяешь в отдельных рабочих копиях.

1. Приёмка = стенд + интеграционные тесты + конфликты

Добавь в scripts/test/ режим приёмки ветки, например node scripts/test/accept-branch.mjs <ветка> [<ветка>…]. Для каждой ветки он:

Создаёт отдельную рабочую копию (git worktree) и накладывает текущий стенд.
Запускает npm run check.
Запускает все tests/integration/*.test.ts на реальной PostgreSQL. Считает файл красным по итоговой строке Test Files, а не Tests: ошибка в beforeAll/afterAll делает файл красным даже при зелёных тестах.
Запускает e2e-стенд и сравнивает с основой: что позеленело, что покраснело.
Проверяет попарно слияние всех переданных веток между собой и с основой (git merge-tree --write-tree). Печатает таблицу «чисто / конфликт, файлы».
Печатает итог в markdown, чтобы его можно было вставить в отчёт.

Роли базы. Стенд пересоздаёт роли со случайными паролями на общем кластере — это ломает параллельную работу других. Сделай так, чтобы роли и пароли можно было передать переменными (E2E_MIGRATOR_URL, E2E_APP_URL) и стенд их тогда не трогал. По умолчанию — как сейчас.

Готово, когда запуск на antigravity/fix-reject-device-shifts antigravity/fix-sync-c0-bootstrap codex/fix-format-baseline сам показывает то, что я нашёл вручную:

Что	Ожидаемый результат на сегодня
`sync-rejection.test.ts` на `1df2019`	FAIL: `column "created_by" … does not exist`
`sync-bootstrap.test.ts` на `8baad55`	FAIL: `Called end on pool more than once` при `Tests 2 passed`
SYNC-C0 на `8baad55`	зелёный
AG reject + AG c0	конфликт, `src/domain/sync/service.ts`
Codex format + AG c0	конфликт
Codex format + AG reject	чисто (потому что в форматировании Codex лежит копия исправления S1)

2. Проверка «форматирование без поведения»

Для ветки codex/fix-format-baseline (сейчас 513cdff) добавь в режим приёмки проверку: для каждого изменённого файла взять версию из основы, прогнать через prettier и сравнить с версией из ветки. Любое отличие после нормализации — это поведение, а не стиль. Печатать список таких файлов.

На сегодня ожидается: src/domain/sync/service.ts и tests/unit/sync.test.ts отличаются. После нормализации они совпадают с веткой Antigravity построчно. Я проверил это на 513cdff: Codex перезалил ветку, но синхронизацию не убрал.

Готово, когда проверка ловит 513cdff и пропускает ветку, где остался только prettier.

3. Храповик после каждого влития

Когда владелец вливает ветку, отдельным коммитом убери из known-defects.json то, что стало зелёным на основе:

После влития	Убрать
`codex/fix-live-database`	K3/N2, K4/N1
цепочка Antigravity (reject → c0)	K13/SYNC-A, K13/SYNC-B, SYNC-C0

Коммит — только known-defects.json, в теле — вывод стенда на основе после влития.

4. Сценарий переноса арендатора (для TASK-CODEX-2, п. 2.2)

Codex пишет scripts/rehome-tenant.mjs: перенос всех данных пилота из заглушки 01J00000000000000000000000 в арендатора 01M2R6AC5652NPT3MG34DKN4ZP. Подготовь проверку заранее, чтобы принять скрипт в день пуша:

Наполнить базу под заглушкой: сотрудники, точки, смены, начисления в реестре, строки аудита, устройства синхронизации, push-подписки — по несколько строк в каждой таблице со столбцом tenant_id. Плюс второй, посторонний арендатор с собственными данными.
Снять контрольные цифры: число строк по каждой таблице и арендатору, SUM(amount_minor) реестра.
--dry-run — ничего не меняет, печатает те же числа.
Перенос ролью администратора БД.
Сверка:
- DISTINCT tenant_id — только новый арендатор и посторонний;
- число строк и суммы совпадают;
- данные постороннего арендатора не тронуты;
- в staff_audit_log нового арендатора есть запись о переносе;
- приложение ролью krona_staff_app под новым арендатором видит тех же сотрудников, а под старым — ничего;
- журналы остались неизменяемыми: после переноса UPDATE в staff_payroll_ledger отклоняется.
Повторный запуск отказывает: целевой арендатор уже содержит данные.

Пока скрипта нет, сценарий красный с понятным сообщением и заносится в known-defects.json как PILOT-REHOME. Список таблиц со столбцом tenant_id бери из information_schema.columns, а не руками — так новая таблица без переноса сразу даст красный.

Порядок

1 → 2 → прогнать приёмку по всем открытым веткам и выложить результат → 3 по мере влития → 4.

Отчёт

ветка и коммит;
вывод режима приёмки по всем открытым веткам (codex/*, antigravity/*) на момент отчёта;
что изменилось в known-defects.json;
что не запускалось и почему.

9.1 KiB Raw Blame History Unescape Escape