# Часть 6. Конституция дата-платформы банка

Конституция дата-платформы отвечает на вопрос: какие решения не нужно заново
обсуждать в каждой витрине. В базовом томе конституция фиксировала миссию,
стек и дорожную карту приложения. Здесь она фиксирует миссию DataLakeHouse, локальный
стек, границы сопоставления с боевым контуром, политику PII и правила изменения контрактов.

## Минимальные файлы

```text
specs/mission.md
specs/tech-stack.md
specs/roadmap.md
AGENTS.md
```

`mission.md` объясняет, зачем существует платформа. `tech-stack.md` говорит,
какие инструменты разрешены. `roadmap.md` показывает порядок артефактов.
`AGENTS.md` задаёт правила поведения агента.

## Что должно быть в mission

Хорошая mission для учебного банка:

```markdown
Платформа строит воспроизводимые аналитические marts для учебного банка.
Каждый дата-продукт должен иметь владельца, потребителя, grain, политику PII,
обещание по freshness, проверочные факты и отчёт ревьюера.
```

Плохая mission:

```markdown
Сделать современную банковскую платформу данных.
```

Она звучит крупно, но не помогает агенту принять решение.

## Непереговорные правила

Запишите правила, которые нельзя менять внутри отдельной витрины:

- marts не раскрывают прямые PII-поля;
- изменение grain требует утверждения;
- обязательные поля контракта нельзя удалять без заметки о ломающем изменении;
- `dbt build --profiles-dir .` — обязательная проверка, если dbt
  доступен;
- проход ревьюера не должен редактировать файлы.

Если такое правило появляется впервые во время реализации, остановитесь и
обновите конституционный файл, прежде чем продолжать SQL.

## Разбор для читателя

Конституция дата-платформы кажется высоким уровнем, пока не появляется первый
конфликт. Агент хочет добавить удобную колонку. Аналитик просит больше
детализации. Витрина начинает раскрывать поле, которое раньше считалось
техническим. Если в проекте нет короткого набора принципов, каждое такое
решение принимается заново, часто в пользу ближайшей задачи. Конституция нужна,
чтобы ближайшая задача не ломала долгосрочный смысл данных.

В отличие от обычного технического стека, конституция говорит не только «какие
инструменты используем», но и «какие решения агент не принимает сам». Для
банковских данных это особенно важно. Grain, политика PII, SLA, ломающие
изменения и методология риска не должны появляться как побочный эффект SQL.
Если агент предлагает изменить один из этих пунктов, он должен остановиться и
попросить подтверждение, а не объяснять изменение постфактум.

Хорошая конституция короткая, но проверяемая. Плохая говорит: «соблюдай
качество и безопасность». Хорошая говорит: «marts не раскрывают прямые PII»,
«изменение grain требует подтверждения человеком», «проверочные факты пишутся до SQL».
Такие правила можно применить в ревью. Если правило нельзя проверить, оно
остаётся лозунгом и не помогает агенту.

Читателю полезно относиться к конституции как к договору с будущим собой. В
начале проекта всё кажется очевидным: Customer 360 — это одна строка на
клиента, согласия считаются отдельно, риск-флаг учебный. Через десять изменений
очевидность исчезает. Конституция сохраняет исходные решения в месте, где их
увидит следующий проход агента и следующий ревьюер.

## Практика

Составьте пять непереговорных правил для своей дата-платформы. Для каждого
правила укажите, где оно живёт: `AGENTS.md`, `mission.md`, `tech-stack.md`,
contract YAML или спецификация модели.

## Qwen-запрос

```text
Помоги составить конституцию учебной дата-платформы банка.
Перед записью файлов задай вопросы по миссии, стеку, политике PII, дрейфу контракта
и подтверждениям человеком.
SQL не пиши.
```

## Минимальный выход

После главы:

- `specs/mission.md` описывает назначение платформы;
- `specs/tech-stack.md` фиксирует локальный стек и сопоставление с боевым контуром;
- `specs/roadmap.md` ведёт по артефактам;
- `AGENTS.md` запрещает утечку PII и неутверждённый дрейф контракта.

## Типичная ошибка

Смешивать конституцию и спецификацию конкретной витрины. `mission.md` не должен
перечислять SQL-поля `mart_customer_360`; спецификация модели не должна заново выбирать
DuckDB или dbt.

## Контрольные вопросы

1. Какие решения должны жить в конституции, а какие в спецификации модели?
2. Почему политику PII лучше фиксировать до профилирования источников?
3. Когда изменение поля контракта требует отдельного утверждения?