RSHB/arm-ka-docs
9
0
Fork 0
Code Issues 12 Pull Requests 1 Actions Packages Projects Releases Wiki Activity
arm-ka-docs/context/KICKOFF-PROMPT.md
Andrey Epifancev f7ee6bee55 model: DBML v5.20 — уточнение периода и счёта ОСВ аналитиком (#147) 
- document: is_modified, original_values, modified_by, modified_at — правка
  period_year / period_quarter / is_cumulative / osv_account_code на месте,
  распознанное в original_values (первичка не мутируется); копия document не
  создаётся.
- 05-domain-rules §9.5 п. 12: PATCH /documents/{id}/osv-header — проверки,
  сброс подтверждения и снятие привязок к версиям «в работе», аудит
  RECOGNIZED_DATA_EDIT; §3 п. 1 — новая точка отвязки.
- OQ-161 закрыт вариантом (2); флаг CONSOLIDATION_PERIOD_FROM_VERSION
  снимается после правки на экране.
- entities-v5.20, диаграммы, ссылки на текущую версию модели.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-21 18:57:47 +04:00

7.6 KiB
Raw Blame History

KICKOFF-PROMPT — первое сообщение агенту в workspace

Запускать claude из корня workspace (~/work/arm-ka/), когда выполнен чек-лист в конце файла.

Ты начинаешь разработку АРМ КА с нуля в workspace из нескольких git-репозиториев (docs/, fixtures/, arm-core/, tabular-parser/, scan-gateway/). Прочитай в таком порядке и не пиши код, пока не закончишь:

  1. CLAUDE.md (workspace) и docs/context/00-workspace-layout.md — как устроена рабочая область, статус аналитики, макет.
  2. docs/context/01-project-overview.md, 02-glossary.md — предметная область.
  3. docs/context/03-architecture.md, 04-data-model-guide.md, затем весь docs/model/data-model-v5.20.dbml и docs/model/entities-v5.20.md.
  4. docs/context/05-domain-rules.md — алгоритмы (особенно §1.0 и §12 — парсеры ищут структуру по содержимому); 06-test-data.md; 07-open-questions.md; 10-user-journey.md; 09-delivery-plan.md.
  5. arm-core/, tabular-parser/, scan-gateway/ — три репозитория, развёрнутые из нулевого коммита шаблона команды, и их CLAUDE.md. Выясни соглашения шаблона: структура, DI, ORM/миграции, тесты, линтеры, сборка, фронт.
  6. docs/mockup/INDEX.md — индекс макета. HTML-файлы макета не читай подряд; открывай один экран, только когда он нужен для задачи.

Затем сделай четыре вещи и остановись для ревью:

A. Дополни docs/context/03-architecture.md разделом «Соглашения шаблона» и заполни секции «Соглашения шаблона» в CLAUDE.md каждого из трёх репозиториев. Не переделывай шаблон под документ — наоборот. Зафиксируй, что вырезано из шаблона в tabular-parser и scan-gateway (фронт, лишние таргеты).

**B. Сверь docs/context/10-user-journey.md и docs/mockup/INDEX.md со снимками docs/mockup/screens/ — дополни пропуски из раздела «Что осталось уточнить», расхождения с DBML/правилами занеси в 07-open-questions.md. HTML макета не читай как текст; при необходимости рендерь scripts/mockup_crawl.py.

C. Напиши OpenSpec proposal для Среза 0 — три change, по одному в каждом сервисном репозитории (openspec/changes/slice-0-skeleton/), и один в docs/ для сквозного: docker-compose workspace-уровня (PostgreSQL, NATS, MinIO, эмулятор ИС Сканирование), контракт recognition-result.schema.json v1.0, CI-шаблон. В arm-core: миграция 0001 по DBML целиком, seed справочников/ролей/прав, auth с dev-эмитентом JWT, check_dbml_vs_orm.py. В tasks.md — задачи ≤ половины дня, в порядке зависимостей, с указанием репозитория.

D. Составь список вопросов ко мне — только те, без которых нельзя начать Срез 0 (версии Python/Node в шаблоне, секреты, реестр образов, доступ к arm-ka-fixtures из CI). Вопросы по предметной области не задавай — они в 07-open-questions.md; если нужен ответ для среза — делай допущение по правилам из этого файла.

Ограничения на всё время работы:

  • имена таблиц, колонок и enum'ов — ровно как в DBML v5.20; поля, которых нет в DBML, не изобретать;
  • алгоритмы — только из 05-domain-rules.md; из страниц ТЗ напрямую не кодировать;
  • парсеры: никаких координат ячеек, букв колонок, имён листов и номеров строк в коде — структура по содержимому, синонимы в rules/*.yaml; фикстуры — регрессия, не спецификация;
  • деньги — Decimal/numeric(18,2);
  • всё, что в DBML помечено «не хранится / вычисляется», — чистые функции в domain/;
  • любое изменение модели — через новую версию DBML с changelog и миграцию;
  • один OpenSpec change и один PR — на один репозиторий; git -C <repo>; никаких коммитов в main;
  • общение, коммиты, комментарии, документация — по-русски; идентификаторы — по-английски.

Когда Срез 0 принят: Срез 1 (справочники, arm-core), затем Срез 2 (tabular-parser + маппинг в arm-core) — его начинай с property-тестов на fixtures/osv/** и fixtures/statements-xlsx/**, потом парсер.

Подготовка workspace перед kickoff (чек-лист для пользователя)

Репозитории в Gitea: arm-ka-docs, arm-ka-fixtures (ограниченный доступ), arm-core, arm-tabular-parser, arm-scan-gateway; main защищён везде.

  • mkdir ~/work/arm-ka && cd ~/work/arm-ka — workspace, не git init
  • docs/: клонировать arm-ka-docs, положить содержимое пакета docs/ + docs/source/tz/ (22 md + _tree.json + _export.md с датой экспорта) + docs/source/biq/ (3 docx → pandoc md) + docs/mockup/dkb_24.09.26/; python ../scripts/mockup_index.py docs/mockup/dkb_24.09.26 > docs/mockup/INDEX.md
  • CLAUDE.md пакета — в корень workspace (не в docs); scripts/ — в docs/scripts/ или корень workspace
  • fixtures/: клонировать arm-ka-fixtures, разложить файлы по 06-test-data.md §6 (scripts/sort_osv_fixtures.py из инструкции), добавить statements-xlsx/ (попросить у аналитиков ББ/ОФР в Excel; пока — лист «Отчетность» из Анализ *.xlsx и рекомендуемые формы)
  • arm-core/, tabular-parser/, scan-gateway/: из нулевого коммита шаблона (00-workspace-layout.md), в каждый — CLAUDE.md из docs/repo-templates/, пустой openspec/ (openspec init), codegraph-индекс
  • .claude/settings.json workspace: хуки guard-main (по репозиторию файла), require-plan, cc-status; разрешения на git -C
  • tea login; метки slice-0 … slice-8 в каждом сервисном репозитории
  • первый коммит в каждом репозитории — «шаблон/контекст как есть», в ветке, PR, merge — единственный раз без плана