krona-staff/docs/audit/2026-09-26/ACCEPTANCE-2.md
Victor Trushenko b0243d5001
Some checks are pending
ci / verify (push) Waiting to run
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

12 KiB
Raw Blame History

Приёмка №2: Grok, Codex, Antigravity — 2026-09-26

Проверка независимая, на живой PostgreSQL 17.10, в отдельных рабочих копиях. Ветки исполнителей не менялись. Основная ветка — f5ac179.

Итог

Исполнитель Ветка Вердикт
Grok grok/e2e-harness @ ba59a48 Принять и влить первым. Всё из TASK-GROK-2 сделано и подтверждено
Codex codex/fix-live-database @ b289dd6 K3 и K4 исправлены (подтверждено мной и Grok). Влить после пересборки ветки форматирования
Codex codex/fix-format-baseline @ fd1ec3d Переделать: в коммит форматирования попало функциональное изменение Antigravity
Antigravity antigravity/fix-reject-device-shifts @ 1df2019 Не принимать пока: S1 исправлен, но интеграционный тест на реальной базе по-прежнему красный
Antigravity antigravity/fix-sync-c0-bootstrap @ 8baad55 SYNC-C0 исправлен, но тест падает в afterAll, и ветка конфликтует с предыдущей. См. дополнение ниже
Codex codex/fix-format-baseline @ 513cdff (перезалив) По-прежнему переделать: синхронизация Antigravity осталась в коммите. См. дополнение ниже

Grok — принято

Проверено мной:

  • Windows. node scripts/test/run-e2e.mjs запускается на Windows 11 без правок: 54 сценария, 45 красных (все — известные дефекты), 9 зелёных, проверка списка известных дефектов проходит. После прогона рабочая копия чистая — прогонные файлы в git больше не попадают.
  • Сопоставление ID. Сделано по таблице аудита: сценарии называются двойными ID вида K3/N2, ключи known-defects.json переименованы так же.
  • Недостающие сценарии добавлены: K6, K7, K8, K9, S9, A4, N12-DATE. Все красные, как и должно быть. K7 уже показывает потерю денег при импорте: итог 22 200 вместо 33 300 и 37 700.
  • Приёмка веток исполнителей подтверждена. На ветке Codex codex/fix-live-database я сам прогнал стенд Grok и получил 41 красный и 13 зелёных — ровно как в его отчёте. Позеленели K3/N2, K4/N1, K13/SYNC-A, K13/SYNC-B.
  • Зона не нарушена, все коммиты с объяснением причины.

Замечания на следующий круг:

  • Windows-раннера нет, поэтому задача windows в CI выключена переменной. Это честно отмечено в отчёте.
  • В приёмке веток запускались только сценарии tests/e2e, а интеграционные тесты самих исполнителей — нет. Из-за этого не пойман красный тест Antigravity (см. ниже).

Codex

codex/fix-live-database: K3 и K4 исправлены.

  • Подтверждение смены, расчёт и утверждение работают на реальной базе; создание сотрудника отвечает 201.

  • Цепочка расчёта теперь доходит до денежных дефектов, и они подтверждаются по существу:

    • K5 — одна смена начисляется дважды: 196 800 вместо 98 400;
    • K6 — после отклонения оплаченной смены нет сторно.

    Это следующий этап задания (этап 3), а не ошибка ветки.

  • Остаток A4: month=2026-13 по-прежнему отвечает 500 и возвращает код PostgreSQL.

codex/fix-format-baseline: переделать. Grok установил, что «стилевой» коммит fd1ec3d содержит функциональное изменение: после нормализации форматирования src/domain/sync/service.ts совпадает с исправлением Antigravity, а tests/unit/sync.test.ts — тоже. Два нарушения AGENTS.md сразу:

  • смешение тем — поведение спрятано в коммите форматирования;
  • правка чужой зоны: синхронизация принадлежит Antigravity.

Если влить обе ветки, изменение Antigravity придёт дважды, и одна из веток получит конфликт. Нужно пересобрать коммит форматирования без изменений в src/domain/sync/** и tests/unit/sync.test.ts. Исправление S1 должно прийти только из ветки Antigravity.

Antigravity

antigravity/fix-reject-device-shifts @ 1df2019.

  • S1 исправлен: у Grok SYNC-A и SYNC-B зелёные.
  • Сообщение коммита приведено к формату: короткий заголовок, причина в теле.
  • Очистка теста переведена на роль мигратора.

Но тест по-прежнему красный на реальной базе. Теперь он падает раньше, на подготовке данных: column "created_by" of relation "staff_employees" does not exist (tests/integration/sync-rejection.test.ts:81). Оба теста файла пропускаются, файл целиком — FAIL. Значит, на настоящей базе тест снова не запускали. Пункт 1 задания не закрыт.

Как проверить у себя до пуша:

DATABASE_TEST_URL=<роль приложения> DATABASE_MIGRATION_URL=<мигратор> npx vitest run tests/integration/sync-rejection.test.ts

Готово, когда: Tests 2 passed.

Порядок влития

  1. grok/e2e-harness — влить сейчас: только тесты и CI.
  2. Codex пересобирает codex/fix-format-baseline без синхронизации, затем вливаются форматирование и codex/fix-live-database. Grok отдельным коммитом убирает K3/N2 и K4/N1 из known-defects.json.
  3. Antigravity чинит тест, затем вливается его ветка. Grok убирает K13/SYNC-A и K13/SYNC-B.

Новое: задача по пилоту от сессии платформы

Сессия «БП» по просьбе владельца и в режиме только чтения выяснила два факта.

  1. Пилот на 192.168.1.81 пишет все данные под арендатором-заглушкой 01J00000000000000000000000. Настоящий арендатор владельца в платформе — 01M2R6AC5652NPT3MG34DKN4ZP («Сушигедза»).
  2. Скрипта сопоставления standalone → platform, обещанного в docs/PLATFORM-INTEGRATION.md, нет.

В репозитории я подтвердил:

  • заглушку записывает сам deploy/pilot/setup.sh:20;
  • она же стоит значением по умолчанию в compose.yaml:16 и в .env.example:14;
  • в scripts/ скрипта сопоставления нет.

Задание — TASK-CODEX-2.md.

Договор идентичности с платформой (модуль ждёт JWT, платформа шлёт неподписанные заголовки) исправляется на стороне платформы: пункты А-5, С-6, С-7 её плана. Этим занимается сессия «БП». Модулю — не менять PlatformIdentityAdapter под неподписанные заголовки.

Дополнение: перезаливы после первой версии приёмки

antigravity/fix-sync-c0-bootstrap @ 8baad55 (от f5ac179).

  • Статус точки при начальной загрузке теперь вычисляется из is_active и deleted_at. На стенде Grok SYNC-C0 зелёный, итог стенда — 44 красных, 10 зелёных.
  • tests/integration/sync-bootstrap.test.ts на реальной базе: Tests 2 passed, но файл FAIL. Пул закрывается дважды: app.close() уже закрывает его через хук onClose (src/app.ts:148), а тест в afterAll (строка 96) закрывает его снова — Called end on pool more than once.
  • Конфликтует с antigravity/fix-reject-device-shifts в src/domain/sync/service.ts: обе ветки созданы от одной основы.

codex/fix-format-baseline @ 513cdff (перезалив от f5ac179).

  • Я нормализовал prettier'ом версии из основы, из ветки Codex и из ветки Antigravity. src/domain/sync/service.ts и tests/unit/sync.test.ts у Codex построчно совпадают с веткой Antigravity и отличаются от основы на 255 и 139 строк. Исправление S1 по-прежнему в коммите форматирования. Пункт 1 TASK-CODEX-2 не выполнен.
  • codex/fix-live-database перебазирован на него (8e955b0), поэтому тоже несёт эту копию.

Конфликты между ветками (git merge-tree):

Пара Результат
AG reject + AG c0 конфликт
Codex format + AG c0 конфликт
Codex format + AG reject чисто — потому что в Codex лежит копия исправления AG
Grok + AG c0 чисто

Задания следующего круга:

  • TASK-ANTIGRAVITY-3.md — починить оба теста, выстроить ветки в цепочку, отдельный коммит форматирования синхронизации, дальше S2–S9 и push;
  • TASK-GROK-3.md — приёмка с интеграционными тестами и проверкой конфликтов, проверка «форматирование без поведения», храповик после влития, сценарий переноса арендатора;
  • TASK-CODEX-2.md — без изменений.

Порядок влития, уточнённый:

  1. Grok.
  2. Цепочка Antigravity: reject → c0.
  3. Codex: форматирование без синхронизации, затем fix-live-database.

Цепочка Antigravity идёт раньше Codex, потому что после пересборки форматирования у Codex не останется пересечений с синхронизацией.