feat(architecture): add minimal project bootstrap

README.md

@@ -31,6 +31,14 @@ Copy the generated prompt into the AI agent working on that project. The agent w
 
 Then return to your normal project work. You do not need to learn how the kit works or select rule files manually.
 
+For a new product, start with a small architecture before implementing its first scenario:
+
+```powershell
+.\ai-rules.ps1 prompt bootstrap -ProjectRoot C:\path\to\project
+```
+
+Paste the prompt with your goal and first scenario. The agent chooses where code belongs, creates only the needed parts, and checks the important dependency boundaries. Connecting an existing project does not restructure its code.
+
 For a deep project audit later, generate a dedicated prompt:
 
 ```powershell

ai-rules.ps1

@@ -65,6 +65,8 @@ Agent Engineering Kit
                            Подготовить запрос для изучения проекта.
   prompt parallel -ProjectRoot ПУТЬ
                            Подготовить запрос для параллельной задачи.
+  prompt bootstrap -ProjectRoot ПУТЬ
+                           Выбрать первоначальную архитектуру нового проекта.
   connect -ProjectRoot ПУТЬ
                            Подготовить проект и показать изменения.
   connect -ProjectRoot ПУТЬ -Apply
@@ -731,12 +733,12 @@ try {
             }
         }
         'prompt' {
-            if ([string]::IsNullOrWhiteSpace($ListTarget) -or $ListTarget.ToLowerInvariant() -notin @('audit', 'connect', 'deep-audit', 'study', 'parallel')) {
-                throw "Для команды 'prompt' укажите 'connect', 'audit', 'deep-audit', 'study' или 'parallel'."
+            if ([string]::IsNullOrWhiteSpace($ListTarget) -or $ListTarget.ToLowerInvariant() -notin @('audit', 'connect', 'deep-audit', 'study', 'parallel', 'bootstrap')) {
+                throw "Для команды 'prompt' укажите 'connect', 'audit', 'deep-audit', 'study', 'parallel' или 'bootstrap'."
             }
             $promptName = $ListTarget.ToLowerInvariant()
             $promptArguments = @('-Name', $promptName)
-            if ($promptName -in @('connect', 'deep-audit', 'study', 'parallel')) {
+            if ($promptName -in @('connect', 'deep-audit', 'study', 'parallel', 'bootstrap')) {
                 $resolvedProjectRoot = Resolve-ProjectRoot -Path $ProjectRoot
                 $promptArguments += @('-ProjectRoot', $resolvedProjectRoot)
             }

hub/ARCHITECTURE.md

@@ -51,6 +51,8 @@ AGENTS.md целевого проекта
 
 Инструкции для ограниченного процесса: подключения, первичного аудита или учебного изучения проекта. Workflow применяется только по явной команде или выбранному совместимому идентификатору и не становится нормой для всех задач проекта.
 
+Первоначальный выбор обязан состояться по `ARCHITECTURE_AND_DATA.md` до существенной реализации новой развиваемой области. Всегда читаемый `standard-product`, тема реализации и `INDEX` ведут к этому условию; локальный контракт затем определяет место нового кода. [`PROJECT_BOOTSTRAP.md`](../workflows/PROJECT_BOOTSTRAP.md) содержит только стартовый процесс, три архетипа и запрос `prompt bootstrap` в одном файле. `project-bootstrap` выбирается явно и не входит в композицию профилей. Подключение нового проекта предлагает следующий шаг, существующего — фиксирует разрыв без реализации или рефакторинга. Если процесс не установлен, краткий контракт архитектурного правила остаётся достаточным для первоначального выбора.
+
 ### `sync/` и управляемая копия
 
 `sync/catalog.json` задаёт разрешённые значения `topics`, `profiles` и их зависимости. Файл `.ai-rules/manifest.json` выбирает состав, а `.ai-rules/lock.json` хранит точную версию и SHA-256.

profiles/standard-product.md

@@ -9,6 +9,7 @@
 - Единица работы — минимальный сквозной сценарий от входа пользователя или оператора до наблюдаемого результата.
 - Каждая поставка имеет самостоятельный проверяемый пользовательский, эксплуатационный или защитный результат. Инфраструктурная работа допустима отдельно, если устраняет названный риск или создаёт проверяемую возможность для ближайшего сценария.
 - Техническая работа связана с текущим пользовательским результатом, операционным риском или явно названной обязанностью совместимости.
+- До первой существенной реализации нового продукта или крупной подсистемы без границ прочитай раздел «Первоначальная архитектура» темы `architecture-and-data` по `INDEX.md`. В существующей области используй локальный контракт размещения кода; подключение Kit само по себе не запускает перестройку.
 
 ## Рекомендуемые локальные документы
 

rules/ARCHITECTURE_AND_DATA.md

@@ -11,17 +11,32 @@
 
 - Для существенных модулей назови допустимое направление зависимостей, разрешённые точки входа и запрещённые связи. Например: `UI → прикладной сервис → репозиторий`; конкретная схема зависит от проекта.
 - Архитектурное правило должно ограничивать наблюдаемый риск, а не предписывать каждую деталь реализации. Внутри проверяемых границ сохраняй свободу выбора решения.
-- Устойчивые ограничения по слоям, импортам, схемам, именованию и размеру модулей по возможности закрепляй линтером, анализатором зависимостей или структурным тестом. Сообщение проверки объясняет нарушенную границу и способ исправления.
+- В развиваемом проекте после выбора устойчивых границ агент обязан закрепить наиболее важные разрешённые и запрещённые связи линтером, анализатором зависимостей или структурным тестом до завершения первого сквозного сценария. Используй существующий инструмент либо небольшой локальный скрипт; тяжёлая зависимость без необходимости не нужна. Сообщение проверки объясняет нарушенную границу и способ исправления.
+- Проверка должна наблюдать реальные пути зависимостей проекта, включая используемые алиасы, реэкспорты и статические динамические импорты. Докажи, что разрешённый случай проходит, а представительное нарушение отклоняется; проверка пустого каталога не защищает границу. Назови команду и место запуска в обычном наборе проверок; CI подключай в пределах задачи. Если автоматизация недоступна, запиши конкретное ограничение и следующую проверку, но не объявляй границу механически защищённой.
 - Не автоматизируй непроверенное предпочтение. Если один и тот же архитектурный дрейф повторяется, устраняй не только частный случай: уточни правило, проверку или обратную связь, которые предотвращают повторение.
 
 ## Организация кода и импортов
 
-- В новом нетривиальном проекте до накопления функций определи минимальные границы модулей, их ответственности, точки входа и направление зависимостей для первых реальных сценариев. Не создавай слои для гипотетического роста, но и не складывай независимые UI, прикладную оркестрацию, доменные правила и доступ к данным в один стартовый файл.
-- Модуль, компонент и каталог группируются по связной ответственности и причинам совместного изменения. Большой файл, смешение представления с независимым поведением или десятки несгруппированных соседних файлов — сигнал проверить границы, но не основание для механического деления по числу строк или файлов.
+- Модуль, компонент и каталог группируются по связной ответственности и причинам совместного изменения. Код одной возможности остаётся рядом с ней, включая её UI, независимую логику и узкие тесты; общие интеграционные проверки могут оставаться отдельно.
+- Корень исходников содержит точки входа и архитектурные области, а не россыпь независимой прикладной логики. Общая папка компонентов не заменяет владельцев самостоятельных сценариев. В общую область выноси фактически переиспользуемый или по природе общесистемный код; она не знает конкретные возможности.
+- Точка композиции собирает зависимости, маршруты и экраны. Она не должна заодно владеть несколькими самостоятельными экранами, сетевым доступом и независимыми расчётами. Локальные обработчики и состояние одного связного компонента не требуют отдельного слоя.
+- При заметном росте файла или перед добавлением существенной функции в файл с несколькими независимыми причинами изменения агент обязан проверить ответственности: назвать владельцев поведения и решить, сохранить связный файл либо выделить самостоятельную границу в затронутой области. Несвязанный долг фиксируй отдельно. Большой связный файл допустим; число строк или файлов не заменяет эту проверку.
 - Формат фреймворка не отменяет разделение ответственностей. Например, Vue SFC может совместно хранить `template`, локальный `script` и локальные `style`, пока они обслуживают один связный компонент; самостоятельные сценарии, доменная логика, сетевое взаимодействие и доступ к постоянному хранилищу получают подходящую границу вне компонента экрана.
 - Проект выбирает устойчивый способ импортов, соответствующий его языку, размеру и инструментам. Если принят алиас или публичная точка входа, одно и то же отображение действует во всех реально используемых средах: проверке типов, сборке, выполнении, тестах, линтере и редакторе.
 - Относительные импорты подходят внутри одной локальной границы. Переходы через несколько модулей или слоёв не должны обходить установленное направление зависимостей; конкретный предел глубины и способ проверки задаются локальной архитектурной политикой.
 
+## Первоначальная архитектура
+
+До существенной реализации нового развиваемого проекта, крупного package/application или подсистемы без установленных границ агент обязан выбрать минимальную архитектуру для первых реальных сценариев. Несколько сценариев, UI с данными и внешним доступом либо независимые причины изменения требуют выбора сразу, а не после накопления долга. Количество файлов не является критерием.
+
+Зафиксируй в локальном архитектурном контракте тип проекта, первые сценарии, выбранный архетип, области и их владельцев, направление зависимостей, точки композиции, маршрут размещения нового кода, сознательно отсутствующие слои и условия пересмотра. Несколько абзацев в `PROJECT_RULES` или существующей карте достаточно; отдельный документ не обязателен. После выбора этот контракт ограничивает дальнейшие изменения.
+
+Выбери один стартовый архетип: пользовательский frontend с локальными возможностями; сервис с независимыми сценариями и адаптерами; библиотека/CLI с минимальным техническим ядром. Имена каталогов зависят от проекта. Создавай каталог только вместе с реальным кодом его ответственности, без пустых слоёв на будущее. Пошаговый запуск и примеры архетипов доступны через `project-bootstrap` или команду хаба `prompt bootstrap`; они читаются только при первоначальном выборе. Если процесс не установлен или хаб недоступен, выполни этот краткий контракт и проверку границ из раздела выше, не откладывая выбор.
+
+Одноразовый скрипт, экспериментальный файл, минимальный воспроизводитель, очень маленький прототип или небольшой CLI с одной связной обязанностью могут остаться компактными без модульного каркаса и отдельного архитектурного guard. Назови причину и триггер возврата: превращение в развиваемый продукт, второй самостоятельный сценарий или новая независимая граница. Прототип уже запланированного продукта не является автоматическим исключением.
+
+У существующей области сначала используй действующие границы. Подключение правил не создаёт архитектуру, guard и не разрешает рефакторинг: отсутствие контракта фиксируется как разрыв. При обычной feature-задаче читай локальный маршрут размещения кода и затронутые решения, а не все стартовые архетипы.
+
 ## Целевое состояние и переход
 
 - Перед значимой реструктуризацией исследуй всю затронутую область: фактические зависимости, владельцев поведения, причины совместных изменений и уже наблюдаемый дрейф. Размер каталога или файла является сигналом, а не самостоятельным доказательством плохой архитектуры.