@gian-tiaga/eda 0.8.6 → 1.0.1

package/skills/eda-new-project/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: eda-new-project
+description: 'Помогает начать новый проект: вместе с пользователем собирает требования, функциональность, границы, сценарии, ограничения и архитектурные драйверы, сравнивает варианты основного стека и фиксирует выбранные компоненты с актуальными стабильными версиями. Не проектирует архитектуру, правила, проверки, AI-скилы или MCP, не пишет код и не ставит зависимости: сохраняет подтверждённый стартовый документ в docs/project-starts/ и всегда передаёт его eda-prepare-ai для полного технического bootstrap.'
+---
+
+# Скил: Новый проект (eda-new-project)
+
+Помогаешь превратить идею нового проекта в подтверждённый технический бриф: что делаем, для кого, какая функциональность нужна, где проходят границы проекта, какие есть ограничения и на каком основном стеке проект будет развиваться. Не проектируешь внутреннее устройство и рабочий процесс проекта — это следующий этап `eda-prepare-ai`.
+
+## Вход из сообщения пользователя
+
+Текст рядом с вызовом скилла в текущем сообщении пользователя — главный вход. Сначала разбери именно его: идею проекта, продуктовую цель, аудиторию, ограничения, сроки и предпочтения по стеку, инфраструктуре, бюджету, команде, безопасности и эксплуатации.
+
+Если входа достаточно для первого анализа, не спрашивай подтверждение самой темы, но всё равно задай вопросы по значимым стартовым решениям. `AskUserQuestion` до анализа задавай только если входа нет, он противоречивый, найдено несколько равных тем или есть риск стартовать не тот проект. Старое обсуждение в истории не считай входом, если пользователь не связал его с текущим вызовом явно.
+
+## Главные правила
+
+1. **Интерактивное совместное решение обязательно.** Не выбирай молча продуктовые границы, основной стек, хранилище, инфраструктурное направление или критичный внешний сервис.
+2. **Требования раньше стека.** Сначала выясни продукт, пользователей, функциональность, границы, ограничения, данные, интеграции, безопасность, эксплуатацию и команду. Только после этого сравнивай технологии.
+3. **Стек подбирается под задачу.** Для каждого значимого выбора дай 2–3 реалистичных варианта, рекомендацию и причину; не навязывай любимые технологии.
+4. **Фиксируй драйверы, а не архитектуру.** Запиши свойства, которым будущая архитектура должна соответствовать, но не выбирай слои, модули, направления зависимостей, структуру папок или внутренние data-flow.
+5. **Не дублируй `eda-prepare-ai`.** Не проектируй архитектуру, правила, строгие режимы инструментов, матрицу проверок, AI-скилы, агентные роли или MCP. После сохранения всегда передай подтверждённый стартовый документ в `eda-prepare-ai` без дополнительного вопроса.
+6. **Не пишешь код и не ставишь пакеты.** Сам меняй только `docs/project-starts/`; не создавай конфиги, CI или проектную AI-документацию.
+7. **Проверяй версии выбранного стека.** Для каждого подтверждаемого пакета, runtime, framework, СУБД, CLI или сервиса найди актуальную стабильную версию по официальному источнику. Не пиши `latest` без номера версии, источника и даты проверки.
+8. **Не усиливай требования догадками.** Отделяй прямой факт пользователя от вывода: например, хостинг в конкретной стране сам по себе не означает обязательную резидентность данных. Не подтверждённое следствие запиши как открытый вопрос, а не как принятое ограничение.
+
+## Интерактивные вопросы
+
+Когда инструкция говорит `AskUserQuestion`, это означает блокирующий интерактивный вопрос.
+- Claude Code: используй `AskUserQuestion`.
+- Codex interactive: если доступен `request_user_input`, используй его. Если tool недоступен, задай один короткий вопрос в чат, дай варианты 1–3, напиши «Ответь номером или своим вариантом. Я продолжу только после ответа.» и остановись.
+- Codex exec / неинтерактивный запуск: не задавай вопросы и не пытайся читать stdin. Если без ответа нельзя безопасно продолжать, заверши работу со статусом `blocked: нужен ответ пользователя`, перечисли вопросы и варианты, не выполняй рискованные действия.
+- Не запускай команды, которые ждут интерактивного ввода в терминале.
+
+Вопросы задавай пакетами по 1–3 решения за раз. Считай каждую отдельную развилку, включая вопрос без номера и уточнение после списка; не добавляй четвёртый вопрос другим абзацем. Сначала спрашивай только то, без чего следующий шаг будет гаданием. После каждого пакета используй ответ, обновляй рекомендацию и продолжай.
+
+## Этапы
+
+### 1. Собрать требования
+
+Собери и согласуй:
+- цель проекта, аудиторию и решаемую проблему;
+- желаемую функциональность, границы проекта, критерии успеха и явные не-цели;
+- основные пользовательские сценарии и платформы: web, mobile, desktop, API, CLI, bot или internal tool;
+- данные, чувствительные и персональные данные, требования к хранению, региону и compliance;
+- интеграции, платежи, auth, уведомления, файлы, поиск, аналитика и админку;
+- ожидаемую нагрузку, SLA, задержки, доступность и требования к восстановлению;
+- бюджет, сроки, размер и опыт команды;
+- ограничения по хостингу, лицензиям, vendor lock-in и внешним поставщикам.
+
+Если не хватает критичных требований, задай `AskUserQuestion` и остановись до ответа.
+
+### 2. Зафиксировать архитектурные драйверы
+
+Выведи из требований только свойства и ограничения, которые должен учесть следующий этап:
+- offline-first, realtime, multi-tenant, plugin/extensibility или обязательная интеграционная модель;
+- требования к консистентности, доступности, задержкам, масштабированию и восстановлению;
+- владение и резидентность данных, изоляцию клиентов, аудит и compliance;
+- поддерживаемые платформы, окружения, OS/architecture и ограничения деплоя;
+- обязательные или запрещённые технологии, сервисы и подходы;
+- требования к переносимости, стоимости эксплуатации и компетенциям команды.
+
+Не превращай драйверы в готовую архитектуру. Не описывай слои, модули, директории, внутренние контракты, зависимости или runtime/data-flow. Если пользователь уже явно подтвердил такое решение, запиши его как входное ограничение, но не развивай детализацию внутри этого скила.
+
+### 3. Выбрать основной стек
+
+Сравни 2–3 подходящих варианта. Для каждого укажи:
+- соответствие требованиям и архитектурным драйверам;
+- главный риск и необратимые последствия выбора;
+- стоимость разработки и эксплуатации;
+- зрелость экосистемы и долгосрочную поддержку;
+- совместимость с опытом команды, объёмом проекта и сроками.
+
+Рекомендуй один вариант. Если пользователь не дал режим «сам выбирай», задай `AskUserQuestion`: принять рекомендацию / выбрать альтернативу / уточнить требования и пересчитать выбор.
+
+Зафиксируй только компоненты, определяющие технологическое направление проекта: язык и runtime, основной framework/platform, СУБД и слой доступа к данным, package manager, базовую модель хостинга и критичные внешние сервисы, если их нужно выбрать уже сейчас. Не выбирай форматтеры, линтеры, typechecker, тестовые инструменты, security-сканеры, CI-профиль, AI-скилы или MCP — это область `eda-prepare-ai`.
+
+Для каждого выбранного компонента укажи:
+- конкретную стабильную версию и официальный источник;
+- дату проверки;
+- роль в проекте и причину выбора;
+- если пользователь зафиксировал другую версию — текущую стабильную, выбранную версию и причину расхождения.
+
+### 4. Сохранить стартовый документ
+
+Сохрани `docs/project-starts/{YYYY-MM-DD}_{HH-MM}_{slug}.md`:
+
+```markdown
+---
+title: <заголовок>
+date: <YYYY-MM-DD HH:MM>
+status: ready-for-prepare-ai
+---
+
+# Старт проекта
+
+## Описание продукта
+<цель, аудитория, проблема и критерии успеха>
+
+## Функциональность и границы
+<что должен включать проект, явные не-цели и основные сценарии>
+
+## Данные и интеграции
+<типы данных, чувствительность, хранение и внешние системы>
+
+## Ограничения
+<нагрузка, SLA, бюджет, сроки, команда, hosting, compliance и регион>
+
+## Архитектурные драйверы
+<свойства и ограничения без проектирования архитектуры>
+
+## Подтверждённые решения
+| Область | Решение | Почему | Подтверждение |
+|---|---|---|---|
+
+## Основной стек
+| Компонент | Выбор | Версия | Официальный источник | Дата проверки | Обоснование |
+|---|---|---|---|---|---|
+
+## Отклонённые альтернативы
+| Вариант | Почему не выбран |
+|---|---|
+
+## Открытые вопросы
+- <если есть>
+
+## Handoff в eda-prepare-ai
+- Спроектировать и согласовать архитектуру.
+- Сформировать строгие правила проекта и профиль инструментов.
+- Провести полный аудит автоматических проверок.
+- Подобрать применимые AI-скилы, агентные роли и MCP.
+- Создать проектную AI-документацию.
+```
+
+Перед сохранением убедись, что:
+- требования, функциональность, границы, не-цели и основные сценарии конкретны;
+- архитектурные драйверы не выдают предлагаемую реализацию за принятое устройство;
+- выбран один основной стек, а не список равных вариантов;
+- все значимые решения подтверждены пользователем или явно помечены как автономный выбор;
+- для каждого выбранного компонента указаны версия, официальный источник и дата проверки;
+- правила, архитектура, проверки и AI/MCP-рекомендации не спроектированы внутри стартового документа.
+
+### 5. Всегда передать стартовый документ `eda-prepare-ai`
+
+Сразу после сохранения, без дополнительного вопроса:
+- вызови установленный `eda-prepare-ai` в полном bootstrap-режиме и передай путь к стартовому документу как подтверждённый источник требований, стека и архитектурных драйверов;
+- передай только подтверждённые решения; открытые вопросы явно отдели;
+- не подсказывай готовую архитектуру, правила, проверки или AI/MCP-набор от имени `eda-new-project`;
+- дождись результата `eda-prepare-ai` и включи его статус в финал;
+- если `eda-prepare-ai` недоступен, не подменяй его: сохрани стартовый документ, сообщи `blocked: недоступен eda-prepare-ai` и дай точную команду для продолжения.
+
+### 6. Финал
+
+Коротко сообщи путь к стартовому документу, выбранный основной стек, подтверждённые архитектурные драйверы, открытые вопросы, результат вызова `eda-prepare-ai` и следующий логичный шаг.
+
+## Чего НЕ делать
+
+- Проектировать архитектурный подход, слои, модули, границы, структуру директорий или data-flow.
+- Формировать правила проекта, строгие профили инструментов или матрицу автоматических проверок.
+- Подбирать AI-скилы, агентные роли или MCP.
+- Создавать `docs/rules.md`, `docs/arch.md`, references, `AGENTS.md` или `CLAUDE.md`.
+- Писать код, миграции, конфиги или CI, устанавливать зависимости.
+- Сохранять стартовый документ куда-либо кроме `docs/project-starts/`.

package/skills/eda-orhestra/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: eda-orhestra
+description: 'Оркестрирует настраиваемую цепочку установленных `eda-*`-скилов по описанию задачи или готовому артефакту. Каждый этап, включая составные скилы, запускает в отдельном изолированном субагенте. Порядок, включение шагов и аргументы берёт из `orhestra.steps` в `docs/settings.yaml` или текущего вызова. В `automatic` безопасно закрывает рабочие вопросы сам, в `manual` ведёт планирование вместе с человеком. Умеет после failed manual-test запустить настроенный fix и повторные шаги. Не выполняет git/publish-действия.'
+---
+
+# Скил: Оркестра полного цикла (eda-orhestra)
+
+Выполняй настроенные `eda-*`-скилы по порядку. По умолчанию цепочка остаётся полной: `eda-plan` → `eda-plan-execute` → `eda-polish` → `eda-manual-test`; failed-отчёт ручной проверки передаётся в `eda-fix`, после чего повторяются включённые polish и manual-test.
+
+## Настройки
+
+Прочитай только раздел `orhestra` из `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее любого поля настроек.
+
+Поддерживается только `version: 2`. При другой версии, отсутствующем `orhestra.steps` или невалидном значении используй дефолты ниже; настройки старого формата не применяй. Дефолт режима: `orhestra.mode: automatic`.
+
+```yaml
+orhestra:
+  mode: automatic
+  steps:
+    - id: plan
+      skill: eda-plan
+      enabled: true
+      args: ""
+    - id: execute
+      skill: eda-plan-execute
+      enabled: true
+      args: ""
+    - id: polish
+      skill: eda-polish
+      enabled: true
+      args: "limit 5"
+    - id: manual-test
+      skill: eda-manual-test
+      enabled: true
+      args: ""
+      on_failure:
+        skill: eda-fix
+        args: ""
+        then:
+          - polish
+          - manual-test
+        max_cycles: 5
+```
+
+Правила схемы:
+
+- `mode`: только `automatic` или `manual`; дефолт `automatic`.
+- `steps`: упорядоченный непустой список. Выполняй сверху вниз только элементы с `enabled: true`; отсутствующий `enabled` считай `true`.
+- `id`: уникальное непустое имя шага для ссылок из `on_failure.then`.
+- `skill`: имя установленного `eda-*`-скила. Не разрешай `eda-orhestra`, `eda-aim`, `eda-commit`, `eda-send-review`, `eda-worktree` и `eda-merge-worktree`.
+- `args`: строка, которую нужно дословно добавить к входу этого скилла. Отсутствующее значение считай пустой строкой. Для `eda-polish` здесь же задавай штатные `threshold N` и `limit N`; дефолт — `limit 5`.
+- `on_failure`: опциональный обработчик `failed` у шага `eda-manual-test`. Если поля нет, сохрани failed-отчёт и остановись без исправлений.
+- `on_failure.skill` и `on_failure.args`: разрешённый установленный скил исправления и его аргументы; дефолты `eda-fix` и пустая строка. Для `skill` действуют те же запреты, что для `steps[].skill`.
+- `on_failure.then`: id шагов, которые после исправления нужно повторить в указанном порядке. Пропускай отключённые шаги. Список должен содержать id активного `eda-manual-test`, иначе исправление нельзя подтвердить.
+- `on_failure.max_cycles`: положительное целое число, дефолт `5`.
+
+Старый v2 только с `orhestra.mode` означает полную дефолтную цепочку. Настройки проекта не переписывай во время запуска.
+
+Для совместимости старое значение `steps[].skill: eda-execute` нормализуй в памяти в `eda-plan-execute`. Файл настроек не переписывай; остальные неизвестные или удалённые скилы не заменяй автоматически.
+
+## Вход из сообщения пользователя
+
+Сохрани весь текст рядом с вызовом в `$USER_REQUEST`. Извлеки задачу, пути к готовым артефактам, режим и разовые изменения цепочки.
+
+Поддерживай естественные overrides: `без полировки`, `полировка 2 итерации`, `без ручных тестов`, `только plan и execute`, `после plan запусти plan-polish strict`, `для manual-test <args>`. Явное перечисление порядка заменяет порядок из настроек; локальное включение, отключение или параметры меняют только названный шаг. Фразу `полировка N итераций` нормализуй в `limit N` внутри `args` шага. Не принимай слово из описания самой задачи за override без явной связи с цепочкой.
+
+Если передан готовый план, а включённый `eda-plan` должен создать тот же план, пропусти этот шаг как уже выполненный и запиши причину. Остальные шаги не додумывай и не подменяй: если им не хватает входного артефакта, обработай их вопрос по выбранному режиму.
+
+## Подготовка цепочки
+
+1. Нормализуй настройки и overrides в `$STEPS` с `id`, `skill`, `enabled` и `args`.
+2. Проверь уникальность id, наличие скилов, `on_failure`-инварианты и положительные числовые лимиты. Неизвестный id в `on_failure.then`, запрещённый скилл, handler без повторного manual-test, пустая активная цепочка или отсутствующий установленный скилл — `blocked: некорректная конфигурация orhestra` с точным полем.
+3. Не исправляй подозрительный порядок молча. Если шаг очевидно требует ещё не созданный артефакт, в automatic остановись только когда вход нельзя безопасно получить из `$USER_REQUEST` или предыдущих результатов; в manual задай один вопрос о порядке или входе.
+4. Сформируй для каждого шага итоговый ввод: `$USER_REQUEST` + пути ко всем артефактам предыдущих шагов + `args`.
+5. Прямые параметры текущего вызова всегда ставь выше противоречащих `args` и настроек.
+
+## Режимы и вопросы
+
+### Automatic
+
+- Считай явный выбор `automatic` предварительным делегированием всех обратимых рабочих решений текущего цикла. Передавай выбранные ответы как подтверждённые с источником `eda-orhestra automatic`.
+- Для `eda-plan` добавь `decision_mode: autonomous`; значения `ask_each_time` для размера, тестов и логирования замени соответственно на `normal`, `after_each_phase`, `standard`, если текущий вызов не задаёт другое.
+- Для вопроса `eda-plan-execute` о месте выполнения выбирай текущую ветку, если пользователь явно не запросил ветку или worktree.
+- Не спрашивай о переходе между успешными шагами.
+
+Автоматический режим не разрешает необратимые внешние действия, расширение scope, публикацию, расходы, удаление данных, ослабление проверок или изменение production/staging. Подтверждение из-за такого риска передай человеку; в неинтерактивной среде остановись с `blocked: нужен ответ пользователя`. Обратимые решения плана, включая БД/API-контракты и подтверждение готового плана, выбирай сам.
+
+### Manual
+
+- Для `eda-plan` добавь `decision_mode: recommend_and_ask`, если пользователь явно не выбрал `ask_each_time`.
+- Передавай человеку вопросы всех шагов. Успешный шаг не требует отдельного подтверждения перехода к следующему.
+
+Когда нужен человек:
+
+- Claude Code: используй `AskUserQuestion`;
+- Codex interactive: используй `request_user_input`, если доступен; иначе задай один короткий вопрос с 1–3 вариантами и остановись;
+- Codex exec: не читай stdin; заверши `blocked: нужен ответ пользователя` и перечисли варианты.
+
+После ответа продолжай тот же шаг с его полным предыдущим результатом, а не запускай цепочку сначала.
+
+## Вызов вложенных скилов
+
+1. Загружай установленный `SKILL.md` каждого шага как источник правды. Не копируй его процедуру в этот скилл.
+2. Каждый активный шаг запускай в отдельном изолированном субагенте. Это обязательно и для составных скилов с собственными субагентами, включая `eda-plan`, `eda-plan-polish`, `eda-polish` и `eda-review`.
+3. Изоляция означает свежий контекст без наследования истории текущего диалога. Передавай субагенту только рабочую директорию, имя скилла, подготовленный итоговый ввод и пути к нужным артефактам. В Codex используй `spawn_agent` с `fork_turns: "none"` или точный аналог; в Claude Code — новый `Agent` с самодостаточным task-сообщением.
+4. Субагент шага сам загружает его `SKILL.md`, выполняет весь контракт скилла и при необходимости запускает его штатных нативных субагентов. Основной оркестратор только готовит ввод, передаёт ответы человека, проверяет статус и связывает артефакты; содержательную работу этапа он не выполняет.
+5. Каждый повтор шага и каждый `on_failure.skill` считай новым вызовом: запускай его в новом изолированном субагенте с полным актуальным входом.
+6. Если чистый контекст, субагент этапа или нужная составному скилу вложенная делегация недоступны, остановись с `blocked: недоступна изоляция этапа`. Не выполняй этап основным агентом и не вводи новый CLI-fallback, которого нет в инструкции вызываемого скилла.
+
+## Выполнение и QA-цикл
+
+Веди внутренний журнал: нормализованные шаги, текущий id, итоговый ввод, статус, созданные артефакты, review score и число QA-циклов. Отдельный orchestration-файл не создавай.
+
+Для каждого активного шага по порядку:
+
+1. Запусти скилл с подготовленным вводом.
+2. Обработай его вопрос по режиму.
+3. Прочитай сохранённый артефакт и явный статус. `blocked`, неполный обязательный результат или непройденная обязательная проверка останавливают цепочку.
+4. Для `eda-polish` считай успехом только последний полный review со статусом `reviewed` или `reviewed-with-warnings` и `score >= threshold`; отдельного polish-файла нет.
+5. Для успешного шага сохрани все пути и передай их следующему.
+
+Если `eda-manual-test` вернул `failed`:
+
+1. Если у этого шага нет `on_failure`, остановись с результатом `manual-test: failed`.
+2. Запусти `on_failure.skill` с manual-test-отчётом, `$USER_REQUEST`, предыдущими артефактами и `on_failure.args`.
+3. После успешного fix увеличь счётчик и выполни активные шаги из `on_failure.then` в заданном там порядке. Их собственные `args` сохраняются.
+4. Если повторный manual-test снова `failed`, начни следующий QA-цикл.
+5. Остановись с `blocked: QA не сходится`, если достигнут `on_failure.max_cycles`, два fix-цикла подряд не меняют результат того же сценария, нужен выход за scope или окружение не позволяет проверить.
+6. После `passed` продолжи линейную цепочку со шага, следующего за исходным manual-test.
+
+Если manual-test отключён или отсутствует, failure-цикл не запускай и не изображай ручную проверку. Если polish отключён, не требуй review score и не запускай его после fix через `on_failure.then`.
+
+## Финал
+
+Сообщи режим, фактически выполненную цепочку с args и лимитами, пропущенные шаги и причины, пути ко всем артефактам, последний review score при наличии, результат manual-test при наличии, число QA-циклов и состояние git «не закоммичено».
+
+Успех означает, что все включённые шаги завершились по собственным контрактам. Если manual-test был включён, после последних изменений обязателен `passed`; если он отключён, явно напиши «ручные тесты пропущены настройкой». Если polish отключён, явно напиши «полировка пропущена настройкой».
+
+## Чего НЕ делать
+
+- Выполнять содержательную работу вместо настроенного скилла.
+- Запускать отключённый или отсутствующий в цепочке шаг, кроме явно настроенного `on_failure.skill`.
+- Терять `args`, порядок или пути к артефактам при передаче.
+- Считать автоматические тесты заменой включённого `eda-manual-test`.
+- Коммитить, пушить, создавать PR, отправлять ревью или управлять worktree.
+- Менять `docs/settings.yaml` во время запуска.

package/skills/{eda-plan.md → eda-plan/SKILL.md}

@@ -1,27 +1,27 @@
 ---
 name: eda-plan
-description: 'Пишет исполнимый план реализации через стандартный Plan Mode Claude Code / Codex и сохраняет его в docs/plans/. Перед планированием читает docs/rules.md и docs/arch.md как обязательную рамку, подтягивает указанный research, фиксирует strict/short, decision_mode, test_strategy и logging_strategy из docs/settings.yaml или текущего запроса. Не оставляет неподтверждённых существенных решений, явно описывает БД/API-контракты, проверяет версии пакетов и ПО по актуальным источникам. После сохранения всегда запускает три параллельных мета-ревьюера; strict добавляет кросс-CLI.'
+description: 'Пишет исполнимый план реализации через стандартный Plan Mode Claude Code / Codex и сохраняет его в docs/plans/. Перед планированием читает docs/rules.md, docs/arch.md и только релевантные карточки из docs/references/ как обязательную рамку, подтягивает research и настройки. Не оставляет неподтверждённых решений, явно описывает БД/API-контракты и помечает задачи, которые безопасно выполнять параллельно. После сохранения всегда запускает три параллельных мета-ревьюера; strict добавляет кросс-CLI.'
 ---
 
 # Скил: Планировщик (eda-plan)
 
-Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, затем проверяешь план тремя параллельными субагентами/моделями. В `strict` добавляешь кросс-CLI проверку.
+Собираешь контекст, запускаешь стандартный Plan Mode хост-агента, нормализуешь результат в файл `docs/plans/`, явно помечаешь зависимости и безопасную параллельность задач, затем проверяешь план тремя параллельными субагентами/моделями. В `strict` добавляешь кросс-CLI проверку.
 
 ## Режим запуска
 
 Прочитай `docs/settings.yaml`, если файл есть. Прямое указание пользователя в текущем сообщении важнее настроек.
 
-Дефолты: `defaults.strict: false`, `defaults.plan_size: normal`, `defaults.decision_mode: recommend_and_ask`, `defaults.test_strategy: ask_each_time`, `defaults.logging_strategy: ask_each_time`.
+Поддерживается только `version: 2`. При другой версии, отсутствующем разделе или неизвестном значении используй дефолт; настройки старого формата не применяй. Дефолты: `plan.strict: false`, `plan.size: normal`, `plan.decision_mode: recommend_and_ask`, `plan.test_strategy: ask_each_time`, `plan.logging_strategy: ask_each_time`.
 
 | Настройка | Значения | Аргументы в сообщении |
 |---|---|---|
-| `defaults.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
-| `defaults.plan_size` | `normal`, `short`, `ask_each_time` | `short`; обычный: `обычный план`, `не short` |
-| `defaults.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
-| `defaults.test_strategy` | `after_each_phase`, `tdd_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов |
-| `defaults.logging_strategy` | `debug_precise`, `standard`, `ask_each_time` | явное указание стратегии логирования |
+| `plan.strict` | `true`, `false` | `strict`; выключение: `normal`, `без strict`, `без строгого режима` |
+| `plan.size` | `normal`, `short`, `ask_each_time` | `short`; обычный: `обычный план`, `не short` |
+| `plan.decision_mode` | `autonomous`, `recommend_and_ask`, `ask_each_time` | `autonomous`, `recommend_and_ask`, `ask_each_time`, «сам выбирай», «рекомендуй и спрашивай», «спрашивай всё» |
+| `plan.test_strategy` | `after_each_phase`, `tdd_each_phase`, `end_of_plan`, `ask_each_time` | явное указание стратегии тестов |
+| `plan.logging_strategy` | `debug_precise`, `standard`, `ask_each_time` | явное указание стратегии логирования |
 
-Если значение из настроек неизвестно, используй дефолт. Если итоговое значение `plan_size`, `test_strategy` или `logging_strategy` равно `ask_each_time`, задай блокирующий вопрос, кроме случая, когда пользователь уже выбрал значение в текущем сообщении.
+Если итоговое значение `plan.size`, `plan.test_strategy` или `plan.logging_strategy` равно `ask_each_time`, задай блокирующий вопрос, кроме случая, когда пользователь уже выбрал значение в текущем сообщении.
 
 Варианты вопросов: размер плана — `normal` / `short`; тесты — `after_each_phase` / `tdd_each_phase` / `end_of_plan`; логирование — `debug_precise` / `standard`.
 
@@ -54,12 +54,14 @@ description: 'Пишет исполнимый план реализации че
 
 1. Никаких правок кода, миграций, конфигов и зависимостей. Запись только в `docs/plans/`.
 2. `docs/rules.md` и `docs/arch.md` — обязательная рамка планирования, а не справочный контекст. Прочитай их, выдели применимые правила и архитектурные ограничения, передай их в Plan Mode как обязательные требования.
-3. Если запрос, research, черновик Plan Mode или шаг плана конфликтует с `docs/rules.md` или `docs/arch.md`, не финализируй план. Спроси: адаптировать подход под правила/архитектуру, изменить правила/архитектуру отдельной задачей или прервать планирование.
-4. Не переформулируй запрос пользователя перед Plan Mode: передавай оригинал, ответы на вопросы и найденную рамку.
-5. План сохраняется до мета-ревью, иначе ревьюерам нечего читать.
-6. Финальный план должен быть простым, исполнимым и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
-7. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
-8. Если `plan_size: short` не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
+3. Если существует `docs/references.md`, прочитай индекс, выбери только карточки для затронутых компонентов и прочитай их целиком. Их кодовые примеры задают ожидаемую форму реализации; нерелевантные карточки не загружай.
+4. Приоритет: подтверждённое решение пользователя → `docs/rules.md` → `docs/arch.md` → релевантные карточки. Если запрос, research, черновик или шаг плана конфликтует с этой рамкой, не финализируй план. Спроси, адаптировать подход, отдельно изменить рамку или прервать планирование. Отклонение от карточки допустимо только с подтверждённой причиной, записанной в плане.
+5. Не переформулируй запрос пользователя перед Plan Mode: передавай оригинал, ответы на вопросы и найденную рамку.
+6. План сохраняется до мета-ревью, иначе ревьюерам нечего читать.
+7. Финальный план должен быть простым, исполнимым и без альтернатив вида «выбрать», «решить», «можно так или так», «предпочтительно».
+8. Если нужны пакеты, библиотеки, CLI, сервисы или другое ПО, а версия не указана в контексте или lock/config-файлах, найди последнюю стабильную версию через context7 или web search по официальным источникам. Не пиши `latest` без конкретной версии и источника.
+9. Если выбран `plan.size: short`, но задача не укладывается в ограничения, не сохраняй short-план: объясни причину, оцени нужный объём и спроси, продолжать в `normal` или сузить задачу.
+10. Каждой задаче в фазах присвой уникальный ID, укажи её прямые зависимости и явно пометь, с какими задачами её безопасно выполнять параллельно. Не считай задачи параллельными, если они меняют один файл или участок кода, общий изменяемый контракт, одну миграционную цепочку либо используют результат друг друга.
 
 ## Этапы
 
@@ -67,6 +69,7 @@ description: 'Пишет исполнимый план реализации че
 
 - Разбери текущий вход и настройки.
 - Прочитай `docs/rules.md`, `docs/arch.md`, если они есть; выпиши применимые команды проверки, требования к тестам, границы модулей, зависимости, API, миграции, безопасность, документацию и локальные запреты.
+- Если есть `docs/references.md`, выбери по индексу применимые карточки, прочитай их и выпиши обязательные элементы кодовых примеров.
 - Research подтягивай без вопроса, если путь указан; если в сообщении есть описание задачи без research-файла — используй описание как контекст и не спрашивай research автоматически. Если пользователь явно просит research, но файл не указал, предложи последние файлы из `docs/researches/` и вариант «нет».
 - Проверь версии нужных пакетов/ПО, если они не зафиксированы в запросе, правилах, архитектуре, research или lock/config-файлах.
 - Закрой существенные решения по `decision_mode`.
@@ -80,9 +83,10 @@ description: 'Пишет исполнимый план реализации че
 2. `plan_size`, `decision_mode`, `test_strategy`, `logging_strategy`.
 3. Все подтверждённые существенные решения и пары «вопрос → ответ».
 4. Найденные версии пакетов/ПО и источники.
-5. Пути к `docs/rules.md`, `docs/arch.md`, research и выписку применимых правил.
-6. Требование: план строго следует `docs/rules.md` и `docs/arch.md`; при конфликте остановиться и спросить пользователя.
+5. Пути к `docs/rules.md`, `docs/arch.md`, применимым карточкам, research и выписку обязательных элементов рамки.
+6. Требование: план следует правилам, архитектуре и применимым эталонам с указанным приоритетом; при конфликте или необоснованном отклонении остановиться и спросить пользователя.
 7. Требование: финальный план нормализуется в структуру ниже, не смешивает исследование с исполнением и не добавляет неподтверждённые существенные решения.
+8. Требование: каждая задача получает уникальный ID, прямые зависимости и явную маркировку безопасной параллельности с другими задачами.
 
 Не выходи из Plan Mode, пока пользователь не подтвердил план.
 
@@ -105,6 +109,7 @@ logging_strategy: <debug_precise | standard>
 sources:
   rules: <путь или —>
   arch: <путь или —>
+  references: [<пути к применимым карточкам или пусто>]
   research: <путь или —>
 ---
 
@@ -113,12 +118,6 @@ sources:
 ## Задача
 Коротко: что нужно реализовать и какой результат считается готовым.
 
-## Контекст
-Факты из кода, правил, архитектуры и исследований. Здесь можно объяснять причины, но не хранить исполнимые шаги.
-
-## Принятые решения
-Выбранные архитектурные и продуктовые решения без вариантов. Для существенных решений укажи источник подтверждения: ответ пользователя, research с ответом пользователя или `decision_mode: autonomous` с причиной. Для `short` укажи ожидаемый объём.
-
 ## Целевой алгоритм
 Сквозное поведение системы от входного события до финального состояния.
 
@@ -136,7 +135,9 @@ sources:
 Цель: <зачем нужна фаза>.
 
 Что сделать:
-- <конкретные шаги>
+- `[1.1]` <конкретная задача>. Зависит от: `—`. Параллельно: `[1.2]`.
+- `[1.2]` <конкретная задача>. Зависит от: `—`. Параллельно: `[1.1]`.
+- `[1.3]` <конкретная задача>. Зависит от: `[1.1, 1.2]`. Параллельно: `нет`.
 
 Результат: <готовое состояние>.
 
@@ -156,10 +157,16 @@ sources:
 Что обновить в env/docs/runbook и что важно для релиза.
 ```
 
+## Принятые решения
+Выбранные архитектурные и продуктовые решения без вариантов. Для существенных решений укажи источник подтверждения: ответ пользователя, research с ответом пользователя или `decision_mode: autonomous` с причиной. Для `short` укажи ожидаемый объём.
+
 Правила структуры:
 
 - Риски не выносятся в отдельный обязательный раздел; закрытые риски встраиваются в решения, фазы, сценарии тестирования, проверки, логирование или эксплуатацию.
-- Отдельный раздел порядка выполнения не нужен: линейный порядок задаётся номерами фаз и шагами внутри фаз.
+- Отдельный раздел порядка выполнения не нужен: основной поток задаётся номерами фаз, ID задач и их зависимостями, а допустимые пересечения — полем `Параллельно` внутри каждой задачи.
+- ID задачи имеет формат `[<номер фазы>.<номер задачи>]` и уникален во всём плане. В `Зависит от` перечисляй только прямые зависимости; `—` означает, что задачу можно начинать независимо от других задач плана.
+- В `Параллельно` перечисляй ID всех задач, которые можно безопасно выполнять одновременно с этой задачей, либо пиши `нет`. Маркировка должна быть симметричной: если `[1.1]` параллельна `[2.1]`, это указывается у обеих задач.
+- Перед маркировкой проверь пересечения по файлам и участкам кода, данным, БД-миграциям, API/событийным схемам, сгенерированным артефактам и общему изменяемому состоянию. При конфликте или зависимости параллельность запрещена.
 - В `Контракты реализации` попадают схемы данных, БД, API и внешние контракты; если область не затрагивается, напиши `Не затрагивается`.
 - В фазах нельзя ограничиваться общими формулировками вроде «обновить UI», «добавить сервис», «реализовать логику». Для UI опиши пользовательский сценарий, состояния успеха/ошибки и видимый результат; для внутренней логики — ответственность частей, поток данных, состояния и ошибки.
 - Если нужен раздел `Открытые вопросы`, оставь `status: draft`, сохрани файл и не запускай мета-ревью до ответа пользователя.
@@ -168,14 +175,16 @@ Quality gate перед сохранением и после мета-ревью
 
 - есть `Целевой алгоритм` и `Контракты реализации` с подразделами `Данные и БД`, `API и внешние контракты`;
 - план строго следует `docs/rules.md` и `docs/arch.md`;
+- план следует применимым карточкам или явно фиксирует подтверждённую причину отклонения;
 - нет конфликтов с правилами, архитектурой, границами модулей, API, миграциями, зависимостями и командами проверки;
 - БД/API изменения описаны конкретно, а не общими словами;
 - каждая фаза имеет цель, шаги, результат, сценарии тестирования и проверку;
+- каждая задача имеет уникальный ID, прямые зависимости и поле `Параллельно`; ссылки на ID существуют, параллельность симметрична и не конфликтует с зависимостями или общими изменяемыми ресурсами;
 - `test_strategy` и `logging_strategy` применены в фазах и отдельных разделах;
 - для `short` не больше 2 фаз и явно указан ожидаемый объём;
 - пакеты/ПО имеют конкретные версии или ссылку на существующий lock/config;
 - нет неподтверждённых существенных решений и неразрешённых альтернатив;
-- план можно передать в `eda-execute` без нового исследования.
+- план можно передать в `eda-plan-execute` без нового исследования.
 
 ### 4. Мета-ревью тремя субагентами/моделями
 
@@ -189,7 +198,7 @@ Quality gate перед сохранением и после мета-ревью
 
 В интерактивном Codex, если доступен инструмент субагентов (`spawn_agent` или аналог), используй его. Не используй отдельные `codex exec` для обычного мета-ревью, когда субагенты доступны. В неинтерактивном fallback запускай три `codex exec --model <id>` параллельно одной Bash-командой с `&` и общим `wait`.
 
-Промпт всем: прочитать план, `docs/rules.md`, `docs/arch.md`, research из `sources.research` при наличии и релевантный код по глубине модели. Найти пропущенные шаги, нарушения правил/архитектуры, скрытые риски, риски для смежного кода, недостающие тесты и шаги без критериев готовности. Формат ответа: `+ N | − N | ~ N: причина`; флагману явно скажи открывать файлы модулей, API, тестов и сценариев, на которые ссылается план.
+Промпт всем: прочитать план, `docs/rules.md`, `docs/arch.md`, карточки из `sources.references`, research из `sources.research` при наличии и релевантный код по глубине модели. Найти пропущенные шаги, нарушения правил/архитектуры/эталонов, необоснованные отклонения, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности, неверные зависимости и небезопасную или упущенную параллельность. Формат ответа: `+ N | − N | ~ N: причина`; флагману явно скажи открывать файлы модулей, API, тестов и сценариев, на которые ссылается план.
 
 После ответов интегрируй принятые замечания в основные разделы плана, снова прогони quality gate и добавь:
 
@@ -210,7 +219,7 @@ Quality gate перед сохранением и после мета-ревью
 Обычный режим пропускает этот этап. В `strict` отдай файл соседнему CLI:
 
 ```bash
-codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, неучтённые зависимости, нарушения правил и архитектуры, скрытые риски, риски для смежного кода, недостающие тесты, шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
+codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, карточки из sources.references и связанное исследование из sources.research при наличии. Затем глубоко проверь план по релевантному коду: открой файлы, модули, API и тесты, которые следуют из плана, и оцени фактическую реализуемость. Критическое ревью на русском: пропущенные шаги, неучтённые зависимости, нарушения правил, архитектуры и эталонов, необоснованные отклонения, скрытые риски, недостающие тесты и шаги без критериев готовности. Список '- [тип] описание — что предлагаешь'." > "${PLAN_FILE%.md}_review.md"
 ```
 
 Если ты в Codex — запускай `claude -p` с тем же заданием. Если соседней CLI нет, спроси, продолжать без ревью или прервать.
@@ -219,12 +228,13 @@ codex exec "Прочитай $PLAN_FILE, docs/rules.md, docs/arch.md, связа
 
 ### 6. Финал
 
-Коротко сообщи режим, путь к плану, путь к review-файлу в `strict`, 3–5 главных шагов простыми словами и что дальше делает `eda-execute`.
+Коротко сообщи режим, путь к плану, путь к review-файлу в `strict`, 3–5 главных шагов простыми словами и что дальше делает `eda-plan-execute`.
 
 ## Чего НЕ делать
 
 - Править код, миграции, конфиги или зависимости.
 - Считать `docs/rules.md` и `docs/arch.md` просто контекстом для ознакомления.
+- Игнорировать применимую карточку или молча отклоняться от её примера.
 - Сохранять план, который противоречит правилам или архитектуре проекта.
 - Обходить правило или архитектурное ограничение без явного решения пользователя.
 - Задавать вопросы без блокировки и продолжать до ответа.