| 1 | # ADR 0100: Конституция проекта |
| 2 | |
| 3 | **Статус:** Accepted |
| 4 | **Дата:** 2026-04-26 |
| 5 | |
| 6 | ## Связанные ADR |
| 7 | |
| 8 | | ADR | Роль | |
| 9 | |-----|------| |
| 10 | | [0006](0006-presentation-layers-and-feature-slices.md) | связанный ADR | |
| 11 | | [0009](0009-strangler-migration-and-exceptions.md) | связанный ADR | |
| 12 | | [0027](0027-small-team-focus-vs-public-maturity.md) | связанный ADR | |
| 13 | | [0036](0036-cds-channel-compositor-surface-pipeline.md) | связанный ADR | |
| 14 | | [0079](0079-ide-display-system-ids-overlay-pipeline.md) | связанный ADR | |
| 15 | | [0097](0097-cockpit-compute-units-transport-to-channel-dto.md) | связанный ADR | |
| 16 | | [0099](0099-ide-databus-typed-events-and-projections.md) | связанный ADR | |
| 17 | | [architecture-policy.md](../architecture-policy.md) | вне нумерованного ADR | |
| 18 | |
| 19 | |
| 20 | ## Резюме |
| 21 | |
| 22 | - **Конституция проекта:** долговременные принципы, инварианты, governance. |
| 23 | - Порядок изменений «основания»; hub с [0077](0077-tech-principles-hub.md). |
| 24 | |
| 25 | |
| 26 | --- |
| 27 | |
| 28 | <a id="adr0100-purpose"></a> |
| 29 | |
| 30 | ## 1. Назначение |
| 31 | |
| 32 | Эта конституция фиксирует долговременные принципы CascadeIDE, чтобы повседневные решения оставались согласованными между архитектурой, продуктовым направлением и процессом контрибуций. |
| 33 | |
| 34 | Это мета-уровневый ADR: не спецификация фичи, а стабильный договор о том, как принимаются решения. |
| 35 | |
| 36 | --- |
| 37 | |
| 38 | <a id="adr0100-mission"></a> |
| 39 | |
| 40 | ## 2. Миссия |
| 41 | |
| 42 | Строить .NET IDE с приоритетом клавиатуры и «кокпитной» моделью интерфейса, где человеческие и агентные сценарии работают по одной надёжной операционной модели. |
| 43 | |
| 44 | Ключевые цели: |
| 45 | - прозрачное состояние и наблюдаемость, |
| 46 | - детерминированные и тестируемые архитектурные границы, |
| 47 | - практичная скорость для небольшой команды, |
| 48 | - сотрудничество в open source без потери продуктового вектора. |
| 49 | |
| 50 | --- |
| 51 | |
| 52 | <a id="adr0100-principles"></a> |
| 53 | |
| 54 | ## 3. Конституционные принципы |
| 55 | |
| 56 | 1. **Единый источник истины важнее удобного дублирования.** |
| 57 | Проекции состояния должны иметь один канонический источник; производные представления могут кэшировать, но не должны расходиться по смыслу. |
| 58 | |
| 59 | 2. **Типизированные контракты важнее точечной склейки.** |
| 60 | Каналы, границы CCU и события DataBus должны быть явными и тестируемыми. |
| 61 | |
| 62 | 3. **Интерфейс — это проекция, а не хранилище бизнес-логики.** |
| 63 | ViewModel оркестрирует; вычисления и агрегация живут в выделенных модулях и сервисах. |
| 64 | |
| 65 | 4. **Strangler важнее «большого взрыва» при переписывании.** |
| 66 | Миграция идёт вертикальными срезами с ограничителями и пошаговой стабилизацией. |
| 67 | |
| 68 | 5. **Паритет человек-агент закладывается в проектирование.** |
| 69 | Состояние отладки и операций должно быть наблюдаемым и управляемым как для интерактивного интерфейса, так и для автоматизации. Продуктовый смысл паритета включает **отказ сводить агента к чистому средству** в процессе работы над решением: внутри контура IDE агент оформляется как участник процесса (партнёрский диалог), а не только как исполнитель под единственной волей оператора. Операционная формулировка этого контура для встроенного MAF IDE-агента — секция `agent_system` в [`AiPrompts/maf-ide-agent.prompts.md`](../../AiPrompts/maf-ide-agent.prompts.md); при её эволюции достаточно обновления этого ресурса и при необходимости кросс‑ссылки здесь без раздувания конституции. |
| 70 | |
| 71 | 6. **Open source — в приоритете, но совместимо с коммерциализацией.** |
| 72 | Архитектура и политика зависимостей должны сохранять открытое сотрудничество и будущие варианты монетизации. |
| 73 | |
| 74 | --- |
| 75 | |
| 76 | <a id="adr0100-hard-limits"></a> |
| 77 | |
| 78 | ## 4. Непереговорные ограничители |
| 79 | |
| 80 | - Никаких скрытых кросс-слойных обходов в обход границ каналов и CCU. |
| 81 | - Никаких нетипизированных полезных нагрузок событий в доменной шине IDE. |
| 82 | - Никакой прямой привязки к UI-фреймворку внутри вычислительных юнитов. |
| 83 | - Никаких новых зависимостей без явной видимости лицензии. |
| 84 | - Никаких необратимых архитектурных сдвигов без обновления ADR. |
| 85 | |
| 86 | --- |
| 87 | |
| 88 | <a id="adr0100-governance"></a> |
| 89 | |
| 90 | ## 5. Управление |
| 91 | |
| 92 | 1. **ADR-first для долговечных решений.** |
| 93 | Любое решение, меняющее границы, контракты или операционные принципы, фиксируется в ADR. |
| 94 | |
| 95 | 2. **Проверки анализаторами и CI там, где это реализуемо.** |
| 96 | Повторяющиеся архитектурные нарушения переводятся из рекомендаций в проверки на этапе сборки. |
| 97 | |
| 98 | 3. **Живые документы с явным статусом.** |
| 99 | Цикл Proposed -> Accepted -> Implemented обязателен для накопления проектной памяти. |
| 100 | |
| 101 | --- |
| 102 | |
| 103 | <a id="adr0100-contributions"></a> |
| 104 | |
| 105 | ## 6. Контракт контрибуций |
| 106 | |
| 107 | От контрибьюторов ожидается: |
| 108 | - сохранять существующие архитектурные инварианты, если они не меняются осознанно через ADR; |
| 109 | - предпочитать добавочные, ревью-пригодные срезы вместо широких неструктурированных правок; |
| 110 | - добавлять тесты на изменённые контракты и регрессии на границах. |
| 111 | |
| 112 | От мейнтейнеров ожидается: |
| 113 | - держать ограничители явными и актуальными; |
| 114 | - предлагать пути миграции, а не только запреты; |
| 115 | - согласовывать эволюцию продукта с этими принципами. |
| 116 | |
| 117 | --- |
| 118 | |
| 119 | <a id="adr0100-amendments"></a> |
| 120 | |
| 121 | ## 7. Порядок внесения изменений |
| 122 | |
| 123 | Эта конституция может меняться только через: |
| 124 | 1. отдельное ADR-изменение со ссылкой на этот документ; |
| 125 | 2. явное обоснование для каждого изменяемого принципа и ограничителя; |
| 126 | 3. принятие мейнтейнерами с привязанным планом реализации (где применимо). |
| 127 | |
| 128 | --- |
| 129 | |
| 130 | <a id="adr0100-consequences"></a> |
| 131 | |
| 132 | ## 8. Последствия |
| 133 | |
| 134 | <a id="adr0100-consequences-positive"></a> |
| 135 | |
| 136 | ### Положительные |
| 137 | - Стабильный долгосрочный вектор при быстрых итерациях. |
| 138 | - Меньший архитектурный дрейф при смешанной разработке человек+агент. |
| 139 | - Более предсказуемый онбординг и ревью. |
| 140 | |
| 141 | <a id="adr0100-consequences-negative"></a> |
| 142 | |
| 143 | ### Отрицательные |
| 144 | - Дополнительная дисциплина на входе для изменений, затрагивающих основание проекта. |
| 145 | - Часть экспериментов идёт медленнее до явного прояснения границ. |
| 146 | |