System Context Pack: что это и как собрать контекст проекта

SCP особенно полезен перед стартом разработки, миграцией API, аудитом интеграции, передачей проекта новой команде или подготовкой постановки по чужому наследию. Типовой сигнал: аналитик открывает четыре источника и через час уже держит в голове разные версии одного и того же процесса.

Например, PDF поставщика говорит, что токен живет 24 часа. Письмо поддержки уточняет, что в версии 2.1 токен живет 4 часа. Confluence описывает старую версию API. В Git лежит proof of concept, где часть обязательных полей не передается. Без SCP такая ситуация быстро превращается в спор мнений. С SCP она становится списком проверяемых утверждений, конфликтов и решений, которые нужно принять до разработки.

Минимальный System Context Pack обычно включает восемь блоков.

1. Scope. Что входит в рассматриваемый инкремент, что остается за рамкой.
2. Actors. Пользователи, системы, внешние сервисы, роли команды.
3. Source map. Карта источников: тип, дата, владелец, статус, надежность.
4. Функциональные области. Разделы системы: authentication, checkout, webhooks, refunds, reporting.
5. Утверждения с цитатами. Каждый важный факт связан с источником.
6. Constraints. Ограничения по безопасности, срокам, контрактам и инфраструктуре.
7. Contradictions. Места, где источники расходятся.
8. Open questions и assumptions. Что нужно спросить и что команда временно принимает как предположение.

Ключевое свойство SCP — трассируемость. Утверждение «customer_id обязателен для recurring-платежей» должно вести к конкретному источнику: разделу PDF, письму поддержки, строке в API spec или коду в POC. Если ссылки нет, это не факт проекта, а рабочая гипотеза.

SCP находится между источниками и постановкой. Он собирает картину проекта до того, как команда начнет формулировать требования в финальном виде.

В учебном кейсе Acme Pay команда готовит миграцию платежной интеграции с API v1 на v2.1. На входе четыре источника: PDF-контракт Acme Pay v2.1, устаревшая Confluence-страница по v1, Git POC текущей интеграции и email thread с поддержкой Acme.

### Authentication

Утверждение: access token в v2.1 живет 4 часа.

Источники:
- S01 §2.1 указывает expires_in = 86400.
- S04, письмо поддержки от 11.03.2026:
  для v2.1 значение изменено на 4 часа.

Статус: conflict.
Finding: RF-01 — подтвердить срок жизни токена письменно до старта разработки.

Здесь SCP не выбирает удобную версию. Он показывает конфликт: контракт и поддержка говорят разное. Дальше Review Findings фиксируют риск, а Task Pack включает вопрос к Acme и действие для backend-команды.

Другие находки в этом кейсе: POC не валидирует webhook signature, не передает Idempotency-Key, использует /v1/ endpoint и не отправляет обязательный customer_id. Все эти пункты можно заметить только при совместном чтении источников, а не при чтении одного PDF.

В продукте «Подмастерье аналитика» SCP используется как центральный рабочий артефакт. Мастер загружает или описывает источники, задает рамку задачи, а Подмастерье помогает собрать source map, вынуть утверждения, поставить ссылки на доказательства, отметить противоречия и подготовить следующие артефакты.

1. Sources: команда собирает документы, ссылки, переписки, кодовые фрагменты.
2. Project-local RAG: источники читаются в границах конкретного проекта.
3. System Context Pack: факты раскладываются по областям и связываются с evidence.
4. Review Findings: противоречия и риски становятся списком находок.
5. Task Pack: материал превращается в постановку для PM, разработки и QA.
6. Export: результат уходит в Confluence, markdown, Jira или другой формат команды.

Важная граница: SCP не заменяет решение мастера. Он делает картину системы видимой, но выбор trade-off, приоритета и финального scope остается за людьми, которые отвечают за продукт и архитектуру.

Для первого прохода достаточно одного часа и строгого шаблона. Сначала составьте source map: список источников с датой, владельцем, статусом и коротким комментарием о надежности. Затем выделите 6-10 функциональных областей. После этого выпишите утверждения в формате «факт — источник — статус». Если источники расходятся, не исправляйте текст вручную. Отметьте conflict и заведите finding.

Хороший первый SCP не обязан быть красивым. Он обязан быть проверяемым. Команда должна открыть утверждение, перейти к источнику и понять, почему аналитик так написал.