Почему: пока шёл разбор, Codex запушил codex/fix-tenant-rehome d52ecf3
(17:02, синонимы C6) и codex/fix-pilot-backups b022885 (17:07, ротация на ПК).
Таблица по старым SHA устарела, поэтому все 7 веток прогнаны заново
(стенд a6a1b5e): round3-accept-f7d3c73-rerun.md.
В round3-k18-and-rehome.md, разд. 6: вывод [PILOT-REHOME] на d52ecf3 как есть
(многострочный JSON → «dry-run без JSON-отчёта»), пошаговая диагностика
в копии сценария, которую потом откатил (что упадёт дальше: сумма журнала
в dry-run, dry-run по умолчанию вместо переноса), и тесты backup на b022885.
Почему: backup.sh снимает только pg_dump -Fc одной БД, без ролей (globals). Проверено на
временном кластере PG17 без ролей krona_*: pg_restore exit=1, 61 ошибка «role krona_migrator does
not exist», данные есть, владелец — postgres. В пилоте роли, вероятно, создаются при инициализации
контейнера (POSTGRES_USER, docker/postgres/init-app-role.sh) — без Docker не проверено.
Почему: владелец просил прогнать все открытые ветки против новой основы f7d3c73, включая
codex/fix-tenant-config, codex/fix-tenant-rehome, codex/fix-pilot-backups, и проверить K18 и
scripts/rehome-tenant.mjs фактами.
round3-accept-f7d3c73.md — вывод accept-branch (7 веток, 28 пар merge-tree — конфликтов нет).
round3-k18-and-rehome.md — тесты Codex для backup; учебное восстановление без Docker (шим docker →
локальный pg_dump PG17, CMS-шифрование, sha256, pg_restore, restore-drill-report.sql совпал);
перенос заглушки на восстановленной копии интерфейсом продукта; [PILOT-REHOME] через
диагностический адаптер (не в продукте, не в сценарии) — исходники скриптов приложены.
Почему: TASK-GROK-3 требует каждый вывод с командой и фактическим выводом.
round3-accept-owner-shas.md — 1df2019/8baad55/513cdff: все ожидания владельца подтвердились;
round3-accept-owner-branches-first.md — те же ветки по именам (Antigravity уже 6c5bf36);
round3-format-proof.md — prettier-only ветка проходит, 513cdff ловится;
round3-accept-all-open.md — все открытые codex/*, antigravity/* после fetch 16:16 NOVT;
round3-combined-merge.md — локальная сборка основа+live-database+c0(+grok): конфликтов нет,
интеграционные 7/7, храповик просит убрать ровно K3/N2, K4/N1, K13/SYNC-A, K13/SYNC-B, SYNC-C0;
round3-preset-mode.md — режим E2E_MIGRATOR_URL/E2E_APP_URL (вердикт SKIP).
Файлы прогнаны через prettier (иначе format:check в CI падает), содержимое таблиц не менялось.
Почему: TASK-GROK-3 п.5 / TASK-CODEX-2 п.2.2 — данные пилота живут под заглушкой
01J00000000000000000000000, перенос на 01M2R6AC5652NPT3MG34DKN4ZP нельзя проверить руками.
[PILOT-REHOME-SEED] (должен быть зелёным): таблицы с tenant_id берутся из information_schema,
в каждую сеется 2+ строки заглушки и постороннего арендатора; новая таблица без сида → красный.
[PILOT-REHOME]: --dry-run печатает те же числа и ничего не меняет; перенос админом БД; под
заглушкой 0 строк, счётчики и SUM(amount_minor) ledger совпадают, посторонний не тронут, запись
в staff_audit_log нового арендатора, krona_staff_app видит тех же сотрудников под новым tenant и
никого под старым, UPDATE staff_payroll_ledger отклоняется, повторный запуск отказывает.
Пока скрипта нет — красный с понятным сообщением, ID в known-defects.json.
Сценарий проверен временным эталоном (не коммитился): зелёный; мутации без аудита / без отказа
на повтор / с пропущенной таблицей / с записью в dry-run — красные (report-evidence/round3-pilot-rehome.txt).
client.ts: dbQueryAs(tenant, …) — запрос ролью приложения под заданным арендатором.
Зачем: во время приёмки обе ветки обновили force-push
(codex/fix-live-database ea68e12 → b289dd6, antigravity/fix-reject-device-shifts
795bba0 → 1df2019, теперь на f5ac179). Вердикт по старому SHA не должен
выдаваться за вердикт по новому — «на слово ничего не принимать».
Что: повторный прогон стенда на новых HEAD, результат дописан в
report-evidence/acceptance-*.txt, REPORT.md и NOTES. Итог тот же:
fix-live-database 41 red / 13 green (K3, K4, K13 зелёные),
fix-reject-device-shifts 43 red / 11 green (K13 зелёный).
Зачем: TASK-GROK-2 §4 — исправления принимаются только по прогону стенда,
«на слово ничего не принимать»; исполнителям нужны ID владельца и
контракты для новых сценариев K8/K9.
Что:
- report-evidence/acceptance-*.txt: для antigravity/fix-reject-device-shifts
(795bba0), codex/fix-format-baseline (fd1ec3d), codex/fix-live-database
(ea68e12) — команда, итог vitest, таблица «ID — было — стало — вывод»
против основной ветки f5ac179 с тем же стендом (worktree, без коммитов в
их ветки). Итог: fix-live-database — K3/N2, K4/N1 зелёные, открылись K5 и
K6 по существу; обе ветки Codex — SYNC-A/B зелёные, потому что «style»-
коммит fd1ec3d содержит исправление Antigravity (после prettier 0 строк
diff с её веткой) — записано как находка для ревью.
- NOTES: таблица дефектов с двойными ID, строки K6–K9, S9, A4, N12-DATE,
контракты C4 (verify подписанной ведомости) и C5 (params пресета), CI
(windows, артефакт evidence), раздел приёмки. Ни одна ветка не влита в
основную, поэтому known-defects.json не сокращён.
Зачем: tests/e2e/evidence/ перезаписывается каждым прогоном (логи серверов
с ULID и портами, JSON vitest), поэтому любой запуск стенда менял
отслеживаемые файлы и засорял дифф (приёмка владельца, TASK-GROK-2 п.1).
Что: tests/e2e/evidence/ убран из индекса (git rm --cached) и добавлен в
корневой .gitignore (его же читает prettier, поэтому форматировать
сгенерированные файлы больше не нужно — вызов prettier из run-e2e убран).
В CI задача e2e выгружает папку артефактом e2e-evidence
(actions/upload-artifact, закреплён SHA v4.6.2; Forgejo 9.0.3 поддерживает
v4). Разовые доказательства, которые скрипты не перезаписывают (N5 до/после,
замер N13), перенесены в tests/e2e/report-evidence/ — на них ссылается
REPORT.md.
