ochenstarik/krona-staff
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions
krona-staff/docs/audit/2026-09-26/TASK-CODEX-2.md
Victor Trushenko b0243d5001
Some checks are pending
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

8.8 KiB
Raw Blame History

Задание для Codex, круг 2: исправить ветку форматирования, перевести пилот на настоящего арендатора

  • Репозиторий: https://git.ochenstarik.ru/ochenstarik/krona-staff
  • Основа: codex/bootstrap-platform-foundation (f5ac179)
  • Итоги приёмки: docs/audit/2026-09-26/ACCEPTANCE-2.md. Основное задание TASK-CODEX.md остаётся в силе, этот файл его дополняет.

1. Пересобрать ветку форматирования (сегодня)

По данным приёмки, коммит fd1ec3d в ветке codex/fix-format-baseline содержит, кроме форматирования, функциональное изменение Antigravity. После нормализации prettier файлы src/domain/sync/service.ts и tests/unit/sync.test.ts совпадают с его исправлением S1. Это одновременно смешение тем и правка чужой зоны (AGENTS.md). Кроме того, при влитии обеих веток изменение придёт дважды.

Что сделать: пересобрать коммит форматирования от f5ac179 так, чтобы в нём было только prettier --write, без изменений в src/domain/sync/** и tests/unit/sync.test.ts. Исправление S1 должно приходить только из ветки Antigravity. Затем перебазировать codex/fix-live-database на новый коммит форматирования.

Готово, когда:

  • git diff <новый коммит>~1 <новый коммит> -w после prettier --check не содержит изменений поведения;
  • стенд Grok на codex/fix-live-database даёт K3/N2 и K4/N1 зелёными, а K13/SYNC-A и K13/SYNC-B — красными (они придут от Antigravity).

2. Пилот — на настоящего арендатора

По данным сессии «БП» (запросы только на чтение к krona-staff-pilot-postgres-1), под заглушкой 01J00000000000000000000000 сейчас лежит:

Таблица Строк
staff_employees 51
staff_payroll_ledger 3 830
staff_work_items 3 353
staff_daily_metrics 2 894
staff_audit_log 49

Остальные таблицы — единицы строк.

Настоящий арендатор владельца в платформе — 01M2R6AC5652NPT3MG34DKN4ZP («Сушигедза»).

2.1 Чтобы заглушка не вернулась

Где Что сделать
deploy/pilot/setup.sh:20 Не генерировать STANDALONE_TENANT_ID со значением-заглушкой: требовать его явно, без значения по умолчанию, с понятной ошибкой
compose.yaml:16 ${STANDALONE_TENANT_ID:?…} вместо ${STANDALONE_TENANT_ID:-01J000…}
.env.example:14 Оставить пустым с комментарием, откуда берётся значение (идентификатор организации в платформе)
src/config.ts Вне режима разработки на loopback отклонять 01J00000000000000000000000 при старте как известную заглушку

2.2 Перенос уже внесённых данных

Способ выбираешь сам: однократная перезапись tenant_id или переимпорт книги владельца. В обоих случаях обязательно:

  1. Сначала резервная копия (задача K18 из основного задания) и проверка, что из неё действительно можно восстановиться. Без этого перенос не начинать.
  2. Сначала прогон на копии пилотной базы, затем на пилоте в согласованное окно, при остановленном приложении. Терминалы на это время копят отметки у себя.
  3. Перезапись выполняет привилегированная роль администратора БД, а не роль приложения. RLS с FORCE, составные внешние ключи (tenant_id, id), неизменяемые журналы (staff_payroll_ledger, staff_audit_log) — всё это нужно учесть явно: одна транзакция, внешние ключи переустанавливаются в ней же, триггеры неизменяемости отключаются только внутри неё.
  4. Скрипт в репозитории: scripts/rehome-tenant.mjs (или аналог) с режимом --dry-run (только отчёт о количестве строк по таблицам) и отказом работать, если целевой арендатор уже содержит данные.
  5. Запись о переносе в staff_audit_log нового арендатора: кто, когда, откуда, куда, сколько строк.

Готово, когда:

  • SELECT DISTINCT tenant_id по всем таблицам со столбцом tenant_id возвращает только 01M2R6AC5652NPT3MG34DKN4ZP;
  • количество строк в каждой таблице до и после совпадает;
  • сумма amount_minor в реестре начислений до и после совпадает;
  • пилот под новым арендатором показывает тех же 51 сотрудника;
  • тест изоляции арендаторов зелёный.

Вывод --dry-run и итоговые запросы приложи к отчёту. Grok проверит скрипт на копии: данные под старым арендатором → перенос → сверка.

2.3 Скрипт сопоставления с платформой

docs/PLATFORM-INTEGRATION.md обещает сопоставление standalone ULID с записями Core, но скрипта нет. После пункта 2.2 перенос арендатора уже решён, поэтому скрипт сводится к заполнению core_user_id у сотрудников:

  • вход — выгрузка пользователей платформы (JSON или CSV: идентификатор пользователя Core и признак сопоставления — табельный номер, e-mail или телефон);
  • режим --dry-run с отчётом: сопоставлены, не найдены, найдены неоднозначно;
  • идемпотентность: повторный запуск ничего не меняет, существующие core_user_id не перезаписываются без флага;
  • запись в журнал аудита.

Готово, когда скрипт есть, покрыт тестом на реальной PostgreSQL и описан в docs/PLATFORM-INTEGRATION.md.

3. Не делать

Не менять PlatformIdentityAdapter под нынешние неподписанные заголовки x-tenant-id, которые платформа передаёт модулю. Договор будет с подписью: пункты А-5, С-6, С-7 плана платформы. Им занимается сессия «БП» в репозитории business-platform. Режим platform остаётся недоступным, пока платформа этого не сделает.

Порядок

Пункт 1 → пункт 2.1 → резервная копия (K18) → пункт 2.2 на копии → 2.2 на пилоте → пункт 2.3. Параллельно продолжается основное задание: этап 2 — доступ и пилот, этап 3 — деньги (K5 и K6 теперь воспроизводятся по существу).