Область и состояния
Создайте учебный workflow ручной проверки страховых заявок. Это демонстрационная система без страховых расчётов, юридических выводов, реальных удостоверений личности и загрузки настоящих персональных документов. Заявка содержит случайный ID, тип учебного случая, статус, время создания и назначенный reviewer. Документы представлены только метаданными: document_type из закрытого перечня, received boolean, checked boolean и comment до 500 символов. Не храните содержимое, номера полисов, имена, адреса, платёжные реквизиты или реальные файлы. Статусы: draft, submitted, stage_1, stage_2, manual_decision, waiting_for_info, approved, rejected. Роли clerk, checker и senior_checker получают фиксированные локальные seed-токены через Authorization header; каждый токен связан с одним tenant и ролью.
Маршруты и переходы
POST /api/v1/claims создаёт draft; PUT /claims/{id}/documents меняет флаги только в draft или waiting_for_info; POST /claims/{id}/submit отправляет заявку; GET /claims/{id} читает доступное состояние; POST /claims/{id}/stage-decisions принимает approve или request_info; POST /claims/{id}/final-decision принимает approve или reject от senior_checker. После submit система проверяет обязательные метаданные: identity_stub, incident_stub и ownership_stub должны быть помечены received и checked; это только фиктивные флаги. Иначе заявка переходит waiting_for_info с перечислением отсутствующих типов. Clerk добавляет флаги и повторно отправляет через POST /resubmit; заявка возвращается в сохранённый resume_stage (stage_1 или stage_2), а не начинает проверку заново. Checker этапа 1 может approve, переводя в stage_2, либо request_info, переводя в waiting_for_info с resume_stage=stage_1. Checker этапа 2 может approve, переводя в manual_decision, либо запросить информацию с resume_stage=stage_2. Только senior_checker принимает неизменяемое финальное решение. Автоматический расчёт суммы, тарифа и вероятности запрещён.
Каждая команда передаёт expected_revision. При несовпадении ответ 409 stale_revision. Решение содержит reason только из перечня missing_document, data_mismatch, unclear_description, duplicate_record, policy_check_required и комментарий длиной до 500 символов; approve требует comment длиной от 10 символов. Checker этапов 1 и 2 всегда являются разными пользователями; назначения фиксируются до отправки и видны в аудите. Нельзя менять документы после финального решения. Повторная команда с прежним request ID возвращает результат; другой request ID с изменённой командой при той же revision конфликтует.
Надёжность и аудит
PostgreSQL с ручным SQL и миграциями сохраняет заявку, документы, ревизию, назначения, события процесса и аудит. Любой переход, изменение document flag, назначение, пауза, resubmit и финальное решение записываются append-only с actor, временем, старым и новым статусом, причиной и безопасными именами изменённых полей. Удаление аудита обычным API отсутствует. Workflow исполнитель отправляет напоминания только для waiting_for_info старше 48 часов, максимум один раз за 24 часа; имитация получателя показывает попытки. Сроки вычисляются по UTC. Исполнитель (worker) использует право обработки на 30 секунд и повторяемые outbox события. Тело запроса ограничено 64 KiB, комментарии и поля валидируются. SQL timeout 3 секунды; ошибки хранилища не показывают клиенту SQL.
Структура программы
Предметный пакет задаёт стадии, причины решений и resume_stage; SQL хранит неизменяемый аудит, исполнитель планирует напоминания, REST-слой проверяет роль. main.go только загружает конфигурацию, связывает зависимости и управляет запуском. Пакеты без циклов, общих utils и интерфейсов без потребителя. README показывает зависимости; тесты ядра без HTTP/БД, интеграционные отдельно.
Приёмка
Детерминированные тесты используют фиктивные записи и часы. Проверяются все состояния, отсутствующие флаги, request_info, resubmit в сохранённую stage_1 или stage_2, разные checker users, запрет правки после финала, stale revision, повтор команды, напоминание после перезапуска и неизменяемость audit. Тесты дополнительно проверяют, что в схеме и API нет полей реальных документов и финансовых расчётов. Критерии готовности: финальное решение возможно только от senior_checker после обеих стадий; остановленная заявка возобновляется ровно в сохранённой resume_stage; ни один audit event не редактируется; повторная команда не создаёт двойное решение.