CrewsForge — Шаг 9: Декомпозиция и порядок поставки

Статус: черновик на подтверждение · Шаг 9 из 9 Основание: шаги 0–8. Формат под Claude Code: каждый эпик — самодостаточный контекст со ссылкой на проектный документ; критерии приёмки — инварианты и тесты из шагов.

Размеры: S ≈ 1–2 дня, M ≈ 3–5 дней, L ≈ 1–2 недели (с учётом вашего AI-tooling множителя 3–5x — консервативно).

Волна 1 — Фундамент (всё остальное стоит на этом)

Эпик	Содержимое	Размер	Зависит	Документ / приёмка
F1. Shared-либы ядра	`money` (минорные единицы, ceil-комиссия, наибольшие остатки), `domain-events` (каталог, типы payload), `platform-calendar` (рабочие часы)	M	—	шаг 5.4, 7.1, 7.3; юнит-тесты округления — сумма сплита всегда равна холду
F2. Либа `outbox`	Модель, транзакционная запись, relay-механика (для F4)	S	F1	шаг 1; тест атомарности: откат бизнес-транзакции не оставляет события
F3. Либа `state-machine`	Декларации, executor (CAS → guards → effects → журнал → outbox), idempotentTarget, каскады, резолвер актора	L	F1, F2	шаг 3.1, 4.2; тесты: конкурентный переход, идемпотентный повтор, запись отказа актора
F4. Baseline-схема + сиды	Squash миграций в целевую схему целиком (+дельты шагов 6–7: templateVersion/documentHash, ConciergeThread/Message, частичный индекс QueueItem), raw-SQL констрейнты, сиды	S	—	шаг 8 (упрощён); чек-лист 8.3
F5. Auth: платформенные роли	claim `platformRole`, три guard’а, запрет совмещения ролей, сиды ролей	S	F4	шаг 4.1; негативные тесты кросс-ролевого доступа

Дополнение 2026-08-30 — пропущенный эпик и пропущенная модель

Внесено сессией 0 контура поставки по правилу 3 настоящего документа (расхождение решается правкой документа, а не молчаливым отступлением). Основание: сверка спроектированных артефактов шагов 2–7 со списком эпиков.

Пропущен эпик «Домен Team». Шаг 2 §3 проектирует Team, TeamMember (оси role ⟂ canSign/canSubmit), TeamInvitation и инвариант «последний admin не может уйти»; шаг 7 §2 содержит строку задачи «заявка команды на онбординг → TEAM_ONBOARDING → ADMIN, 3 дня»; шаг 2 §9 включает TEAM в SubjectType журнала переходов. Эпика в волнах ниже не было, при этом от домена команд зависят A1 (оффер команде), контрактинг (подписант с canSign), A2 (сдача с canSubmit) и B1 (PayoutAccount принадлежит команде).

Эпик	Содержимое	Размер	Зависит	Документ / приёмка
F6. Домен Team	`Team`, `TeamMember`, `TeamInvitation`; две оси — доступа и полномочий; приглашения; инвариант последнего администратора; team-поверхность и админская верификация; машина статуса команды	M	F4, F5	шаг 2 §3; шаг 7 §2 (`TEAM_ONBOARDING`); негативные тесты полномочий и последнего администратора

Машина статуса команды не имела таблицы переходов. SubjectType шага 2 §9 включает TEAM, но шаг 3 таблицы переходов для команды не содержит. Объявляется в F6: ONBOARDING → ACTIVE ⇄ SUSPENDED → ARCHIVED, актор — ADMINISTRATOR, приостановка требует причины.

ExternalPaymentDispute не объявлен в схеме. Шаг 5 §6 требует отдельной модели для карточных chargeback’ов (имя не должно пересекаться с Dispute), но в схеме шага 2 её нет. Модель вводится в эпике, реализующем chargeback’и; дельта схемы фиксируется там же.

Волна 2 — Домены (параллелизуется на 3 потока)

Поток A (ядро сделки):

Эпик	Содержимое	Размер	Зависит
A1. Project rework	Машина проекта + суб-машина контрактинга на F3, Specification-версии, PlanVersion (+F-1 WHERE-правила), Party, Offer, мягкий бюджет-гейт	L	F3, F4, F5
A2. Milestone-домен	Milestone + материализация из PlanVersion, критерии, артефакты, сдача с самопроверкой M-3, AcceptanceReview (R-1/R-2), пауза дедлайнов R-3	L	A1
A3. Dispute + Termination	Обе машины, позиции/доказательства (T-1 DTO), оценка по критериям X-2, связка оснований	M	A2

Поток B (деньги и документы):

Эпик	Содержимое	Размер	Зависит
B1. billing-api каркас + PayoutAccount	Сервис, Stripe-конфиг, Express-онбординг, `account.updated`, машина аккаунта, Y-правила	M	F3, F4, F5
B2. Холды и фондирование	Checkout Session, вебхуки интента, Hold-машина, каскад в FUNDED, ACH+карты	L	B1, A2
B3. Settlements и выплаты	Системный расчёт по основаниям, двухфазное исполнение D-6, transfer c source_transaction, маппинг payout.paid, refund/split, ExternalPaymentDispute	L	B2, A3
B4. Сверка	Ночная reconciliation, зависшие состояния, алерты	S	B3
B5. Контракты и подписание	Шаблоны+PDF-рендер, порт SigningProvider, адаптер BoldSign (sandbox), конверты K-4, вебхуки, хэши	L	A1

Поток C (операционка):

Эпик	Содержимое	Размер	Зависит
C1. platform-worker каркас + relay	Приложение, консьюмеры-скелеты, DLX, метрики	S	F2, F4
C2. task-generator + timer-scheduler	Таблицы маппинга задач и окон, дедуп-индекс, SLA-расчёт по календарю, тест полноты Q-4	M	C1, F1
C3. notification-dispatcher	Таблица адресности, F-1/T-1-фильтры, шаблоны 7.3, email через email-sender	M	C1
C4. admin-api: три рабочих места	Операторская поверхность (approve/reject/эскалация, DTO без денег + линтер), администраторская, арбитражная; core-модули из потоков A/B	L	F5, A1–A3, C2
C5. Консьерж	Треды, первая линия, эскалация	S	C4, C2

Волна 3 — Интеграции и закалка

Эпик	Содержимое	Размер	Зависит
G1. ai-agent: типизация плана	Контракт вилок C-1, запись Specification-версий через core-модуль	M	A1
G2. tracker-integration заглушка	Порт (no-op), TrackerLink, вебхук-приёмник, integration-dispatcher в worker	S	C1
G3. Кросс-QA	Матрица-раннер шага 4.9, escrow-линтер (схема+шаблоны+уведомления), e2e сквозного happy path (проект → PAID → COMPLETED), e2e спора и расторжения	M	всё
G4. Переключение на baseline + смоук	Окно обслуживания, drop+baseline+сиды на проде, редеплой всех сервисов, чек-лист 8.3	S	всё выше
G5. Нагрузочное (k6)	Целевые сценарии беты (регистрация→контракт, фондирование, приёмка) до публичного запуска	S	G4

Критический путь

F3 → A1 → A2 → B2 → B3 → C4 → G3 → G4 — машины, ядро сделки, деньги, рабочие места, сквозные тесты. Всё остальное параллелится вокруг него. B5 (контракты) не на критическом пути формально, но блокирует happy path e2e — держать в темпе потока B.

graph LR
  F1 --> F2 --> F3
  F4 --> F3
  F3 --> A1 --> A2 --> A3
  F5 --> A1
  F3 --> B1 --> B2 --> B3 --> B4
  A2 --> B2
  A3 --> B3
  A1 --> B5
  F2 --> C1 --> C2
  C1 --> C3
  A3 --> C4
  C2 --> C4 --> C5
  A1 --> G1
  C1 --> G2
  C4 --> G3 --> G4 --> G5
  B3 --> G3
  B5 --> G3

Правила исполнения под Claude Code

Один эпик = одна ветка = один контекст; в промпт эпика кладутся: соответствующий step-документ целиком, конвенции репо, декларации соседних машин (read-only).
Инварианты-тесты пишутся внутри эпика, который вводит механизм (не отдельным QA-эпиком): денежный линтер — в C4, тест полноты Q-4 — в C2, тесты округления — в F1. G3 только собирает сквозные сценарии.
Расхождение реализации с step-документом решается правкой документа через подтверждение (сессия продолжается как ревью), не молчаливым отступлением.
Определение готовности эпика: тесты приёмки зелёные + документ актуален + чек-лист конвенций (*-core.module, барели, границы Nx).

Актуальная нарезка исполнения (2026-08-30)

Волны и критический путь выше остаются основанием, но исполняется проект по вертикальным срезам продукта, а не по эпикам-слоям: см. docs/delivery/ROADMAP.md — 27 единиц, каждая (кроме фундамента и закалки) заканчивается работающими эндпоинтами. Причина замены: эпик-слой закрывается формально зелёными тестами, не давая проверяемого продукта, — риск, который вертикальная нарезка снимает.