brain/project-files/docs/Plugin_stack_rules.template.md

Plugin Stack Rules — Superpowers + Frontend Design (v1.7)

Дата: 10.05.2026 (поздний вечер) Назначение: свод правил совместного использования плагинов Claude Code в проекте Лидерра — paired-stack ядро obra/superpowers (14 skills) + anthropics/frontend-design, плюс расширенный пул UI-инструментов ui-ux-pro-max (skill, marketplace nextlevelbuilder/ui-ux-pro-max-skill) и 21st.dev Magic MCP (MCP-сервер magic), плюс инфраструктурный claude-md-management (skills, marketplace anthropics/claude-plugins-official), плюс правила runtime motion-стойки. Снимает запрет CLAUDE.md §5 п.5 на Frontend Design plugin (действовал до v1.77 включительно). Документ — внутренне непротиворечив: 8 первичных конфликтов закрыты в v1.0 + 5 патчей по реальным трениям A–E в v1.1 + 4 новых правила R10–R13 против перекрытий с другими плагинами в v1.2 + 6 уточняющих патчей F–K по найденным трениям второго порядка в v1.3 + 2 новых правила R14 (pipeline внешних UI-генераторов: UPM + 21st Magic MCP) и R15 (motion-системы: framer-motion hard-запрет + motion-v узкое окно по 4 условиям) в v1.4 + 5 структурных правок аудита в v1.5 (R10.1 разбит на 3 блока, R0.4.A SoT cross-ref, R10.4/R14.7 tier-метки, R8 +тай-брейкер FD↔21st, R0.1 scope-метка) + 3 правки второго аудита в v1.6 (R0.4.A свёрнут до cross-ref на Pravila §12.3 SoT — устраняет дрейф формулировок; R0.6 hard-стопы пронумерованы 1–11 для надёжности cross-refs «пункт 9/10/11»; R0.1 +Tooling Прил. Н slot уровня 2b) + 1 правка третьего аудита в v1.7 (sync cross-refs на актуальные версии связанных документов после bump'ов CLAUDE.md v1.86 / Tooling v1.15; description-fix описки «уровня 2.5»→«уровня 2b» внутри changelog'а v1.6, сверка с фактическим R0.1).

Принцип-аксиома (v1.2, уточнён в v1.3, расширен в v1.4): Stack (Superpowers + Frontend Design) — головной при решении любой задачи в части плагинов и поведенческих слоёв. Stack-gate (R0) — единственная и первая точка входа. Все остальные плагины (ui-ux-pro-max, 21st Magic MCP, claude-md-management, review, security-review, init, simplify и др.) — инструменты, инвокируемые внутри stack-flow как подзадачи, не как альтернативы или параллельные решатели. Stack исполняет Pravila/CLAUDE.md, а не перебивает их (см. R0.1 для точного scope «головенства»). Другие плагины могут получить работу только по делегированию из stack'а или по явному /имя-плагина от пользователя. Runtime-зависимости проекта (motion-библиотеки и т.п.) подчиняются R15.

Связанные документы:

• CLAUDE.md v1.86+ — оперативная карта; §1 priority chain, §3.3 строка #33, §5 п.5 ссылается на этот документ (расширенный пул UI-инструментов: FD + UPM + 21st), §5 п.11 cross-ref на Pravila §12.3 SoT, §5 п.12 — на R15 (motion-системы)
• docs/Pravila_raboty_Claude_v1_1.md v1.10+ — §12.3 SoT для exclusions, §13 «paired stack + расширенный пул UI-инструментов» + claude-md-management как off-pool, §13.6 hard-rule tier-таблица, §13.9/§13.10 hard-link на R10/R14
• docs/Tooling_v8_3.md v1.15+ — реестр инструментов; #30 Frontend Design + #31 UPM + #32 21st Magic MCP + #33 claude-md-management + §6 +5 конфликтов v1.4 + §7 7-уровневая иерархия (с v1.14 +Tooling explicit slot 2b) + §9.2 motion-runtime denylist отсылают сюда; §10.3 шаг 2 sync (14 skills) с v1.14

Техническая особенность Claude Code: при первой установке Frontend Design plugin в долгой сессии плагин не появляется в системном списке доступных skills до старта новой сессии (новый чат, не reload). Это конструктивная особенность Claude Code (skill list = constant per conversation), не правило и не баг. Файлы плагина доступны на диске сразу, инвокация через Skill tool — только в новом чате.

---

Правило 0 — базовое: единый stack и обязательный gate

0.1. Уровень и головенство

Superpowers и Frontend Design — парный stack одного приоритетного уровня внутри stack'а. Между этими двумя плагинами нет иерархии «главный/вспомогательный». Оба подключены к gate stack'а одновременно — gate всегда обращается к обоим. Какой именно плагин получает работу внутри stack'а — определяется Правилом 1.

Stack — головной по отношению к не-stack плагинам и поведенческим слоям ниже. Точный scope «головенства» (по CLAUDE.md §1 priority chain):

Scope этой таблицы: головенство stack'а внутри общей 7-уровневой файловой иерархии CLAUDE.md §1 (с v1.6 — расширена до 8 уровней через подразбиение уровня 2 на 2a CLAUDE.md + 2b Tooling Прил. Н). Не дублирует Pravila §0 (внутрипараграфный приоритет внутри Pravila) и не дублирует CLAUDE.md §1 (общая файловая иерархия) — это третья ось «над чем именно у stack'а есть приоритет». Tooling §7 — то же самое представление, что CLAUDE.md §1, синхронно с v1.14.

Уровень	Что	Stack головной над этим?
0	Pravila §12 (Superpowers hard rule)	❌ нет — это часть stack'а же, hard rule сильнее
1	Pravila (§§1–13)	❌ нет — stack исполняет Pravila, не перебивает
2a	CLAUDE.md (общая оперативная карта)	❌ нет — stack исполняет CLAUDE.md, не перебивает
2b	Tooling Прил. Н (детальный реестр инструментов) — добавлен v1.6	❌ нет — stack исполняет Tooling, не перебивает (alongside CLAUDE.md, оба operational maps; при прямом конфликте между ними — приоритет CLAUDE.md как корневой карты)
3	PSR_v1 (этот документ)	— это и есть stack
4	settings.json (поведенческая часть)	✅ да
5	memory/*.md	✅ да
6	прочие плагины (ui-ux-pro-max, review, simplify, …)	✅ да

Любая задача проходит через stack-gate (R0) первой среди уровней 3–6. Pravila и CLAUDE.md (уровни 0–2) применяются автоматически как контекст, не «перебиваются» stack'ом — наоборот, stack действует внутри их рамок.

Все плагины вне stack'а (ui-ux-pro-max, claude-md-management, review, security-review, init, simplify, любые будущие) — инструменты, не решатели. Они инвокируются:

• по делегированию из stack-flow (например, claude-md-improver вызывается из stack'а как подзадача при изменении CLAUDE.md), или
• по явной команде пользователя /имя-плагина (live-override, действует на одно действие).

Stack никогда не уступает первенство уровням 4–6 — даже когда задача предметно ближе к чужому плагину, stack первой делает классификацию и потом делегирует инструменту, не отдаёт ему gate.

Подробности — Правило 10 (внешние плагины как инструменты), Правило 11 (иерархия источников истины UI/UX).

0.2. Обязательный gate

Каждая задача — без исключений из 0.4 — сначала проходит через stack. Stack — единственная точка входа в работу.

Любой вход (запрос / /команда / follow-up / course-correction)
            │
            ▼
   ┌────────────────────────────┐
   │   STACK GATE               │
   │   ├── Правило 1: классификация задачи
   │   └── Правило 9: формула решения
   └────────────────────────────┘
            │
            ▼
        Действие

Запрещены:

• Прямой переход к Edit/Write/Bash без прохождения gate.
• «Тривиальная задача → пропущу gate» — рационализация. Тривиальность определяется внутри Правила 1, не до него.
• Параллельный обход через subagent — subagent тоже под gate на момент его dispatch'а.

0.3. Что значит «прошла через gate»

Задача считается прошедшей gate, когда выполнено всё из:

1. Классифицирована по Правилу 1 (процессная / бэкенд / визуальная / UI-фича / вне scope).
2. Если попала в scope — назначен ответственный плагин и фаза по Правилу 2.
3. Если не попала в scope — явно зафиксировано «вне stack, действую без плагинов» (разрешённый исход, но должен быть явным).

Без всех трёх пунктов — действовать нельзя.

0.4. Исключения и live-отмены

A. Технические исключения (gate не требуется):

Single Source of Truth: Pravila §12.3 (Pravila v1.10+). Не дублировать список здесь. В v1.5 эта секция параллелила Pravila §12.3 расширенной таблицей с риском дрейфа формулировок (audit P2-02, обнаружено 6 строк vs 6 пунктов Pravila §12.3 с разными формулировками). В v1.6 свёрнута до cross-ref'а на Pravila §12.3 как единственный SoT.

Stack-расширения (специфичные для stack-flow, не противоречат Pravila §12.3 — допускают тривиальные действия без gate, но с дополнительным условием):

Stack-расширение	Условие
Документационные правки уровня §4 Pravila для CLAUDE.md	gate не требуется, но обязательно через claude-md-management:claude-md-improver (CLAUDE.md §5 п.10), не «прямой Edit»
Конкретные команды tooling'а (composer/npm/git/Boost MCP)	gate не требуется только если не являются частью «debug»/«TDD»/«review» сценария — иначе §12 hard rule перевешивает

Расширение списка exclusions — только через правку Pravila §12.3 + автоматический пересмотр stack-расширений здесь (если они продолжают быть необходимы). При расхождении между Pravila §12.3 и этой секцией — побеждает Pravila §12.3.

B. Live-команды пользователя (отмена на одно действие):

Команда пользователя	Эффект
«не используй плагины сейчас» / «без stack»	весь stack отключён на текущее действие
«не используй Superpowers сейчас»	отключён только Superpowers, Frontend Design остаётся
«не используй Frontend сейчас»	отключён только Frontend Design, Superpowers остаётся

Парность 0.1 действует по умолчанию; live-команда — единственный механизм асимметричного отключения, действует только на текущее действие, не на сессию.

0.5. Перекрытие нижних слоёв

Stack стоит выше в приоритете, чем:

• Дефолтное поведение системного промпта.
• Любые другие плагины.
• Поведенческая часть .claude/settings.json (permissions/hooks остаются техническим слоем среды).

Stack стоит ниже в приоритете, чем:

• Прямые инструкции пользователя в чате (live override).
• Файлы CLAUDE.md / Pravila / Tooling (статические инструкции проекта).

При конфликте: пользователь → CLAUDE.md → stack → остальные плагины → дефолт.

0.6. Сбой gate — действие по уверенности

Если на этапе классификации задача не маршрутизируется однозначно:

Уверенность	Что делать
Высокая — классификация очевидна	действовать без вопросов
Средняя — есть разумное предположение	в Auto mode действовать с явной фиксацией: «классифицирую как X, плагин Y; если иначе — поправь». В обычном режиме — спросить
Низкая — нет разумного предположения	остановиться и спросить пользователя независимо от режима

Тихий выбор без gate при низкой уверенности = нарушение даже в Auto mode.

Hard-стоп даже в Auto mode — обязательная остановка независимо от классификации, при любом из триггеров (нумерация введена в v1.6 для надёжности cross-refs «R0.6 пункт N»; при добавлении/удалении пункта — пересмотреть все ссылки в R8/R13/R14/R15):

1. Впервые на этой сессии создаю компонент из брендового семейства (AppButton, AppCard, AppDataTable, AppDialog и т.п.) и в resources/js/components/ ещё нет precedent'а того же типа.
2. Изменение структуры brand-токенов (resources/js/plugins/vuetify.ts palette config, font-family bindings, theme variants).
3. Создание нового aesthetic-направления, не описанного в BRANDBOOK_v2.
4. Изменение установленных UX-флоу из ТЗ v8.5 (auth-flow, deal-flow, billing-flow, admin-flow, webhook-flow).
5. Cross-cutting refactor, затрагивающий ≥3 компонентов или layout-структуру (AppLayout, AuthLayout, AppShell).
6. Добавление новой технологии в стек (новый фреймворк, новая UI-библиотека, новый шрифт, новая иконографическая библиотека).
7. Изменение брендовой палитры/шрифтов — даже одного значения (Teal, Ivory, теало-нуар, Inter, JetBrains Mono).
8. Изменение 14 OKLCH-статусов воронки или их slug-маппинга на UI.
9. [v1.4] Использование 21st Magic MCP (mcp__magic__21st_magic_component_*) для генерации компонента из брендового семейства App* (AppButton, AppCard, AppDataTable, AppDialog и любых других с префиксом App в resources/js/components/). Брендовые компоненты проходят полный R12 архитектурный flow.
10. [v1.4] Использование 21st для генерации компонента, для которого уже есть Vuetify-эквивалент (v-data-table, v-text-field, v-dialog, v-select, v-card, v-btn и т.д.) или существующий компонент в resources/js/components/. Это дублирование стека (нарушение CLAUDE.md §5 п.6 «не два инструмента на одну задачу»).
11. [v1.4] Установка motion-v или любой другой animation runtime библиотеки (gsap, anime.js, react-spring, lottie-web, popmotion, @motionone/* и т.д.) в package.json без прохождения R15.2 (а)+(б)+(в)+(г).

В этих ситуациях — обязательный стоп + вопрос пользователю, без попытки «middle confidence» обойти. Auto mode не отменяет hard-стоп.

---

Правило 1 — классификация задачи

Каждая задача попадает ровно в одну ветку:

Задача
├── Процессная (debug, plan, worktree, parallel, finishing, verify, code review, refactor логики)
│   → Внутри stack работает Superpowers. Frontend Design не вызывается.
│
├── Бэкенд / логика без UI (API, БД, миграции, бизнес-правила)
│   → Внутри stack работает Superpowers. Frontend Design не вызывается.
│
├── Чисто визуальная (палитра, типографика, layout-эскиз, выбор паттерна, иконка, состояние hover/focus, скелетон)
│   → Внутри stack работает Frontend Design. Superpowers не вызывается.
│
├── UI-фича (компонент с логикой и визуалом)
│   → Внутри stack работают оба, по фазам Правила 2.
│
└── Вне scope (тривиальная задача из 0.4.A, или live-отмена 0.4.B)
    → Действовать без плагинов, явно зафиксировав это.

Распознавание:

• Процессная — по глаголу: debug, fix bug, write tests, plan, parallel, worktree, finish branch, verify, review code, refactor.
• Визуальная — по артефакту: цвет, шрифт, spacing, layout, иконка, состояние, скелетон, иллюстрация. Чисто визуальное = эскиз, мокап, исследование стиля без поведенческого кода, не предназначенное для коммита в resources/js/.
• UI-фича — есть и логика, и визуал в одном артефакте.

Дезамбигуация по умолчанию:

Слово в запросе	Дефолт классификации
«компонент» (component, *.vue файл)	UI-фича (R2 фазы) — даже если запрос «спроектируй компонент Х», подразумевается логика + визуал
«эскиз», «мокап», «концепт», «исследование»	чисто визуальная (R1 ветка Frontend Design)
«спроектируй / придумай / сделай», без слов выше, на отдельный артефакт	смотреть на артефакт: если итог = *.vue файл с state/props/events → UI-фича; если итог = картинка/палитра/набор токенов → визуальная
«исправь», «дополни», «переделай» существующий компонент	UI-фича, лёгкое возвращение к фазе 2 или 5 (R4)
«отрисуй», «покажи варианты» — без коммита в репо	чисто визуальная

При сомнениях между «компонент» и «чисто визуальное» — побеждает UI-фича (более полный flow R2; чисто визуальное — это «опустить шаги», а не наоборот).

---

Правило 2 — фазы UI-фичи

Фаза	Что делается	Кто отвечает
1. Intent / requirements	сценарий, edge cases, критерии «готово»	Superpowers brainstorming
2. Visual design	компонент, layout, цвет, шрифт, состояния	Frontend Design
3. Plan	разбивка на шаги, очерёдность файлов	Superpowers writing-plans
4. Логика компонента	state, props, computed, события	Superpowers test-driven-development
5. Визуальная сборка	template, классы, токены — по дизайну из фазы 2	Frontend Design (look-first итерация разрешена)
6. Verification (логика)	прогон тестов, проверка edge cases	Superpowers verification-before-completion
7. Verification (визуал)	соответствие токенам, состояния, контраст	Frontend Design (UI-чеклист)
8. Review (параллельно)	по аспектам — см. Правило 5	оба

---

Правило 3 — TDD vs визуальная итерация: разделение по типу артефакта

Тип артефакта	Метод	Плагин
Поведение (state, computed, props, events, бизнес-логика, валидация)	TDD-rigid — тесты до кода	Superpowers TDD
Визуал (template, классы, токены, размеры, отступы)	look-first → snapshot/visual регрессия после	Frontend Design
Контракты a11y (aria, фокус-порядок, контраст)	автопроверка после визуала (Pa11y)	вне обоих плагинов

TDD применяется только к фазе 4 (логика). На фазу 5 (визуал) он не распространяется. Это не нарушение «rigid» дисциплины TDD, а scoping: TDD требует «implement code» — у визуала нет тестируемой пред-условной логики.

Граничные случаи:

• Computed → template binding: тест на computed достаточен; template ловится snapshot'ом.
• Сообщение об ошибке валидации в UI: логика появления — TDD; текст и стиль — визуал.
• Hover/focus state: CSS — визуал; обработчик события — TDD.

---

Правило 4 — порядок инвокации и возвраты

Базовая последовательность UI-фичи:

1. brainstorming         → 2. visual design     → 3. writing-plans
→ 4. TDD логика          → 5. визуальная сборка → 6/7. verification
→ 8. review (parallel)

Возвраты к ранним фазам разрешены, но классифицируются:

Тип возврата	Когда	Что делать
Лёгкое	артефакт меняется, intent (user story, acceptance criteria) — нет	разрешено без re-entry в brainstorming
Тяжёлое	меняется intent: новое состояние, новая ветка UX, новое требование	обязателен re-entry в фазу 1

Перед каждым возвратом — явная фиксация одной строкой:

• «лёгкое возвращение к фазе 2, intent не меняется»
• «тяжёлое возвращение, intent меняется на X»

Без фиксации возврат запрещён — это правило снимает рационализацию «я просто немного подправлю».

---

Правило 5 — ревью без конфликта

Ревью разделяется по аспекту, не по файлу. Один файл может попасть в оба ревью одновременно — параллельность сохраняется.

Аспект	Кто	Что смотрит
Логика, тесты, безопасность, читаемость	Superpowers requesting-code-review	handler, state, props, computed, импорты, error handling
UI/UX, контраст, состояния, типографика, spacing	Frontend Design	template, классы, токены, hover/focus/disabled, иерархия
A11y технический (DOM, aria, keyboard)	Pa11y (CLAUDE.md §5 п.3)	вне плагинов

Декомпозиция файла на аспекты — задача ревьюера на старте ревью. Если ревьюер один (последовательно): сначала логика (блокирует выпуск), затем UI (блокирует UX-качество).

---

Правило 6 — стековый фильтр для внешних UI-источников (FD, UPM, 21st)

Все внешние UI-источники предполагают дефолтные стеки React/Tailwind/shadcn (FD по умолчанию универсален, но примеры тяготеют к React-экосистеме; UPM держит библиотеку с 10 стеками включая React/Next/Tailwind/shadcn; 21st Magic MCP по умолчанию генерирует React + Tailwind + shadcn компоненты). В Лидерре стек — Vue 3 + Vuetify 3 (CLAUDE.md §2). Адаптация на стек проекта — обязательная внутренняя часть ответа любого из трёх плагинов, не отдельный шаг и не работа другого плагина.

6.0. Универсальная таблица фильтра (применяется ко всем трём плагинам одинаково)

Что брать (универсально)	Что отфильтровать (стек-зависимо)
Принципы (a11y, контраст, фокус, иерархия, spacing-шкала)	Конкретные имена компонентов чужого стека
Паттерны (modal-flow, form-validation UX, empty/loading/error states)	Tailwind-классы, shadcn-импорты, JSX (CLAUDE.md §5 п.2)
Структуры состояний и переходов	React imports / hooks (useState, useEffect, useRef, useMemo)
Цветовые/типографические системы как принципы	Конкретные палитры/шрифты (у нас Forest v8 + Inter/JetBrains Mono)
State-машины и переходы	Конкретные библиотеки иконок (у нас Lucide)

Ответ внешнего плагина без выполненной адаптации = неполный ответ, возвращается в плагин на доработку. Внешний пост-процессинг другим плагином не предусмотрен — каждый плагин сам обязан выдать стек-совместимый материал.

Per-plugin specifics:

• Frontend Design (anthropics/frontend-design): фильтр применяется к фразеологии плагина; типичные находки — JSX-снимки, Tailwind-классы, shadcn <Button>/<Dialog>. Конверт: JSX → Vue SFC template, Tailwind → Vuetify utility / inline CSS, shadcn → Vuetify-эквивалент.
• UI UX Pro Max (skill ui-ux-pro-max): библиотека стилей + палитр + UX-гайдлайнов. Фильтр срезает 6 из 10 стеков (React, Next, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn) — оставляем Vue + HTML/CSS как опорные. Конкретные палитры/шрифты из библиотеки не переносим (R11.3 запрет инверсии иерархии); берём только UX-принципы.
• 21st Magic MCP (mcp__magic__21st_magic_component_*): генератор по умолчанию выдаёт React + Tailwind + shadcn. Фильтр обязателен до любого использования сгенерированного кода. Сгенерированный JSX никогда не коммитится в resources/js/ напрямую — только после полного конверта (см. R14.4).

6.1. Hard-override (этот проект, применяется к FD/UPM/21st)

SKILL.md плагина Frontend Design содержит директивные «NEVER» в отношении ряда брендовых решений Лидерры. UPM держит библиотеку 161 палитры + 57 шрифтовых пар + 50+ aesthetic-стилей; 21st Magic MCP по умолчанию выдаёт trendy-стиль (часто dark mode + gradients + неоновые акценты). Все эти рекомендации полностью игнорируются — в проекте они зафиксированы как источники истины:

Артефакт	Что говорят внешние плагины	Что у нас (источник истины)
Шрифт UI-текста	FD: «NEVER use Inter, Roboto, Arial, system fonts» (overused). UPM: 57 шрифтовых пар на выбор. 21st: trendy display-шрифты	Inter — primary UI font (BRANDBOOK_v2 §4.1) с axis opsz 14..32
Шрифт numerics/code	UPM: разные mono-шрифты	JetBrains Mono с feature tnum (BRANDBOOK_v2 §4.1)
Палитра primary	FD: «Avoid timid palettes» (бери жирные, неожиданные). UPM: 161 палитра. 21st: trendy bright accents	Teal #0F6E56 (Forest, BRANDBOOK_v2 §3.6) — неоспариваемый
Палитра background	FD: «Avoid solid colors, add atmosphere/textures/gradients». 21st: gradient-backgrounds по умолчанию	Ivory #F6F3EC — однородный page bg (Forest)
Палитра sidebar	—	Теало-нуар #012019 (Forest sidebar)
Aesthetic направление	FD: «Bold maximalism / brutalism / retro-futuristic». UPM: 50+ стилей (glassmorphism/claymorphism/neumorphism/brutalism). 21st: trendy/playful по умолчанию	Restrained / minimal Forest — спокойный тон, без brutalism/maximalism/glassmorphism/неонов
Иконки	UPM: 25 иконографических наборов; 21st: lucide-react / heroicons	Lucide (CLAUDE.md §2), Vue-обёртка
Статусы воронки	—	14 OKLCH-статусов из db/schema.sql:2076, мапить через slug
Brand направление в целом	FD: «Bold aesthetic direction», «UNFORGETTABLE differentiation»; UPM/21st: множественные trendy-направления	Forest v8 как зафиксированная эстетическая платформа — отклонения только через изменение брендбука

Правило применения hard-override: при обработке ответа FD / UPM / 21st — даже если плагин использует категоричные «NEVER» / «NEVER use X» / «AVOID Y» или предлагает альтернативную палитру/шрифт/aesthetic — для пунктов из таблицы 6.1 эти рекомендации полностью игнорируются. Брендовый фундамент Forest приоритетнее любой стилевой эстетики любого внешнего плагина. Плагины остаются ценны на уровне принципов, паттернов, состояний, ритма spacing, UX-флоу — то есть в зоне таблицы 6.0 (универсальное).

При обнаружении нового потенциального hard-override (плагин противоречит ещё какому-то источнику истины проекта) — добавлять строку в таблицу 6.1 через /claude-md-management:claude-md-improver и bump PSR_v1 минор-версии.

---

Правило 7 — финальный gate готовности по типу артефакта

Тип артефакта	Кто закрывает	Дополнительные gates
Логический (бэкенд, бизнес-логика, поведение компонента)	Superpowers verification-before-completion	Pest 4 / Vitest 4 (CLAUDE.md §3.2/§3.3)
Чисто визуальный, non-deployable (мокап, эскиз, исследование стиля без коммита в resources/js/)	Frontend Design (UI-чеклист: токены, состояния, контраст)	—
Чисто визуальный, deployable (компонент, страница, layout, скелетон в репозитории)	Frontend Design (UI-чеклист)	+ Pa11y проход обязателен перед commit (CLAUDE.md §5 п.3)
Смешанный (UI-фича)	оба — Superpowers (фаза 6 = Pest+Vitest) → Frontend Design (фаза 7 = UI-чеклист)	+ Pa11y проход на компонент перед commit

Никакой плагин не может закрыть задачу за пределами своего типа артефакта. Pa11y — независимый технический gate для всех deployable артефактов с UI-выводом, не подменяемый ни одним из плагинов (правило проекта, см. CLAUDE.md §5 п.3 и Pravila §13.5). Это снимает конфликт «Frontend Design closes pure visual» vs «Pa11y is sole a11y truth» через явное разделение: Frontend Design покрывает a11y-принципы (контраст, фокус-порядок, иерархия), Pa11y — технический a11y (DOM, aria, keyboard).

---

Правило 8 — тай-брейкеры

Ситуация	Кто/что побеждает
Оба молчат — задача не в карте	действовать без плагинов, фиксируя это (Правило 1, ветка «вне scope»)
Оба активируются на одной фазе	смотреть Правило 2 — фаза однозначно определяет
Frontend Design тянет в визуальную итерацию, Superpowers требует TDD	Правило 3 — разделение по типу артефакта
Frontend Design предлагает Tailwind, у проекта другой стек	Правило 6 — фильтр внутри Frontend Design
Frontend Design «NEVER use Inter» / «bold maximalism» — vs наш Forest+Inter	Правило 6.1 — hard-override, рекомендация плагина игнорируется
Superpowers brainstorming тормозит чисто визуальную задачу	Правило 1 — задача классифицирована «визуальная», brainstorming не активируется
Нужна правка визуала во время фазы 4 (логики)	Правило 4 — лёгкое возвращение, без re-entry
Меняется intent во время фазы 4	Правило 4 — тяжёлое возвращение, re-entry в brainstorming
Один файл попал и в ревью кода, и в ревью UI	Правило 5 — параллельно по аспектам
Закрытие чисто визуальной задачи (non-deployable)	Правило 7 — Frontend Design сам, без Superpowers и Pa11y
Закрытие чисто визуальной задачи (deployable, идёт в коммит)	Правило 7 — Frontend Design + обязательный Pa11y проход
Pa11y нашёл violation, Frontend Design считает «всё ок по чеклисту»	Pa11y побеждает (CLAUDE.md §5 п.3 — единственный источник истины по техническому a11y)
Задача под §12.2 Pravila (TDD/debug/plan/parallel/review/verify/brainstorm/...) и одновременно визуальная по R1	§12.2 first — Superpowers (brainstorming → plans → TDD) запускается первым по фазам R2; Frontend Design подключается на фазах 2/5/7. Нет «либо/либо» — есть R2 phase-flow
Глагол неоднозначный («сделай», «спроектируй», «придумай», «покажи»)	смотреть на артефакт по дезамбигуации R1: state/props/events → UI-фича (R2); только токены/палитра → визуальная
Слово «компонент» в запросе при отсутствии слов «эскиз/мокап/концепт»	UI-фича по дефолту (R1 дезамбигуация)
Запрос на правку существующего .vue файла	UI-фича + лёгкое возвращение (R4)
Hard-стоп триггер R0.6 сработал в Auto mode	стоп + вопрос пользователю, Auto mode не отменяет hard-стоп
§12 Pravila hard rule «Superpowers first» противоречит R1 «Frontend Design только»	§12 побеждает над R1 для §12.2-задач: Superpowers инвокируется первым; если задача чисто визуальная по артефакту — после первой инвокации skill сам передаёт работу Frontend Design (skill не пишет визуал, поэтому это не override)
[v1.4] Хочется использовать UPM параллельно с FD на одной фазе	R10.1 + R14.5 — последовательно, не параллельно. UPM — fallback / источник материала, FD — решатель
[v1.4] Хочется использовать 21st параллельно с UPM	R14.5 — один генератор на задачу. Если кажется что нужны оба — задача декомпозируется
[v1.5] Хочется использовать FD параллельно с 21st на одной задаче	R14.4 implicit + R10.2: 21st вызывается внутри фазы 5 R2 как подзадача FD, не параллельно. FD — ведущий (решатель), 21st — генератор черновика. Параллельный запуск нарушает R10.2 «внешние плагины — read-only для решений»
[v1.4] UPM-палитра «выглядит лучше» Forest	R11.3 запрет инверсии иерархии + R6.1 hard-override. Forest — закон, не предложение
[v1.4] 21st сгенерировал готовый JSX-компонент с Tailwind, можно ли просто импортировать	нет, R14.4 требует полный pipeline: R6.0 → R6.1 → FD → возврат
[v1.4] «Поставим motion-v, у нас в Vuetify не хватает spring-physics»	без письменного кейса из ТЗ + категории (б) + Brandbook approval (в) + R12 flow (г) — R15.2 не удовлетворён, hard-стоп R0.6 пункт 11
[v1.4] «Поставим framer-motion, у других проектов работает»	R15.1 hard-запрет. React-only физически. Не отменяется live-командой
[v1.4] Для анимации список задача — какой слой?	R11.6: 1 (Vue native <Transition>) → 2 (Vuetify) → 3 (CSS) → 4 (View Transitions). На уровне 1 уже закрывается типичный case

---

Правило 9 — формула решения

При входе в задачу — три вопроса последовательно:

1. Это процесс или артефакт? → Процесс → Superpowers. Артефакт → дальше.
2. Артефакт — логика, визуал или оба? → Логика → Superpowers. Визуал → Frontend Design. Оба → Правило 2.
3. Какая фаза? → Найти фазу в Правиле 2 → плагин определён.

Лимит итераций:

• Если за 2 прохода Правил 1+9 ответ не найден — стоп, применяется Правило 0.6 (предположение в Auto mode или вопрос пользователю).
• Третья итерация запрещена — она означает, что классификационная схема не покрывает задачу, и нужен внешний ввод.

---

Правило 10 — внешние плагины как инструменты, не как решатели

Stack — головной. Все плагины вне stack'а — инструменты, инвокируемые внутри stack-flow как подзадачи. Это снимает все overlap'ы с другими установленными плагинами.

10.1. Реестр внешних плагинов и их роль

Реестр разбит на три блока по типу источника (v1.5+) — раньше всё было одним списком, что путало «отключи в settings.json» с «не вызывай /команду». Каждый блок имеет свою механику включения и отмены.

Блок 1: enabledPlugins через marketplace (включаются в ~/.claude/settings.json)

Плагин	Marketplace	Роль	Когда инвокировать
ui-ux-pro-max (skill)	nextlevelbuilder/ui-ux-pro-max-skill	резервная UI-библиотека (50+ стилей, 161 палитра, 99 UX-гайдлайнов, 25 типов графиков, 10 стеков). Не источник истины (R11 уровень 5)	(1) когда Frontend Design выдал «не знаю» / не покрывает узкоспецифический вопрос (типичные случаи: chart-стек, экзотические типографические пары, региональные UX-паттерны); (2) [v1.4] когда в фазе 1 R2 нужен «третий вариант» для архитектурного решения R12 (см. R11.5). Активируется внутри R2 как fallback / источник материала, не параллельно с FD. Категория: UI-пул (Pravila §13)
claude-md-management (skills claude-md-improver + revise-claude-md)	anthropics/claude-plugins-official	инфраструктурный плагин для CLAUDE.md edits	обязательно при любом изменении CLAUDE.md (выполнение CLAUDE.md §5 п.10). Не альтернатива stack'у, а инструмент внутри stack-фазы «реализация». Категория: инфраструктурная (вне UI-пула Pravila §13)

Отмена: через удаление из enabledPlugins в ~/.claude/settings.json или через live-override /имя-плагина (R0.4.B) на одно действие.

Блок 2: Built-in skills Claude Code (всегда доступны через Skill tool по /имя)

Skill	Роль	Когда инвокировать
review	code review tool	только при явном /review от пользователя. Дефолт код-ревью — Superpowers requesting-code-review (R5)
security-review	security audit tool	только при явном /security-review, либо в фазе 3 проекта (Semgrep). Дефолт security-проверка — Superpowers + Semgrep MCP (Tooling §3.4 фаза 3)
init	scaffold-tool для CLAUDE.md в новых проектах	никогда в Лидерре (CLAUDE.md уже существует). Только при явном /init для отдельных монорепо-пакетов
simplify	code review для упрощения	только при явном /simplify. Дефолт верификация качества кода — Superpowers verification-before-completion (R7)
update-config	конфигурация ~/.claude/settings.json	по явному вызову пользователя; не входит в stack-flow
keybindings-help	помощь по ~/.claude/keybindings.json	по явному вызову пользователя
fewer-permission-prompts	оптимизация prompts через allowlist	по явному вызову пользователя
loop	recurring task scheduler	по явному вызову пользователя
schedule	one-time / cron remote agents	по явному вызову пользователя
claude-api	плагин для Claude API/SDK работ	не активен в Лидерре (мы не разрабатываем под Claude API)

Отмена: built-in skills нельзя отключить — они часть Claude Code. Не вызываются автоматически: только по /имя от пользователя или через делегирование из stack-flow с явным reasoning.

Блок 3: MCP-серверы (включаются в ~/.claude.json или .mcp.json)

MCP-сервер	Конфиг	Роль	Когда инвокировать
21st.dev Magic MCP (magic сервер, deferred tools mcp__magic__21st_magic_component_* + logo_search)	~/.claude.json (с API-ключом, npm-пакет @21st-dev/magic@latest)	генератор стартовых шаблонов для UI-компонентов, отсутствующих в Vuetify и resources/js/components/. Не источник истины, не решатель, не закрыватель задачи	(1) задача = UI-фича по R1; (2) нужный паттерн отсутствует в Vuetify-наборе и resources/js/components/; (3) задача не попадает в R0.6 hard-стоп (не брендовый App*-компонент, не изменение токенов, не cross-cutting); (4) FD на фазе 2 R2 принял решение «нужен кастомный компонент». Активируется на фазе 5 R2 (визуальная сборка) как подзадача: генерация черновика → R6.0 фильтр → R6.1 hard-override → FD адаптация → возврат в фазу 5. Полный pipeline — R14.4. Категория: UI-пул (Pravila §13)
Boost MCP (laravel-boost сервер, 9 tools)	.mcp.json (php app/artisan boost:mcp)	стек-знания (PHP/Laravel/Vue/Vuetify/Pest) + БД-инструменты (database-query, database-schema, database-connections) + диагностика (last-error, read-log-entries, browser-logs) + docs (search-docs)	автоматически на работе с .vue/.php/.sql файлами; слой ниже stack'а — служебный, не конкурирует за gate. Через Roster auto-detect серверит только релевантные guidelines (Inertia/Livewire/Tailwind/Filament/Sail/PHPUnit не серверятся, у нас их нет)
playwright	.mcp.json (@playwright/mcp@latest)	браузерная автоматизация — открыть web/*.html, screenshot, проверка интерактива	при работе с HTML-прототипами или для UI-смоук-тестов
github	.mcp.json (HTTP api.githubcopilot.com/mcp, требует GITHUB_TOKEN)	официальный hosted GitHub MCP — issues, PRs, search-code, list-commits и т.д.	при работе с GitHub-объектами (PR, issues, branches)

Отмена: через удаление из ~/.claude.json или .mcp.json. Live-override через /команду для MCP не предусмотрен — MCP-серверы не имеют slash-интерфейса.

10.2. Принципы координации

1. Stack-gate всегда первый. Любая задача → R0 → R1 (классификация) → выбор плагина внутри stack'а. Внешний плагин получает работу только через делегирование из stack-flow или через явную /команду пользователя.
2. Внешние плагины — read-only для решений. Их вывод используется как инструмент (палитра, шаблон, gh-команда), но решение «как поступить» принимается внутри stack'а (Superpowers/FD).
3. Не параллельная работа. Если ui-ux-pro-max и Frontend Design оба «хотят» одной задачи — побеждает FD (он в stack'е). UPM подключается последовательно, как fallback, не параллельно.
4. Явная /команда — единственная отмена принципа. Если пользователь пишет /review — review плагин получает работу напрямую, минуя Superpowers requesting-code-review. Это live-override на одно действие, аналог R0.4.B.

10.3. Делегирование через stack-flow — пример

Запрос «обнови CLAUDE.md, добавь новое правило»:

1. R0 gate → задача в stack
2. R1 → классифицирована как «процессная — документация» (из §12.3 exclusions Pravila)
3. Stack определяет план: «вызвать claude-md-improver внутри R2 фазы 4 как инструмент»
4. Инвокирую claude-md-management:claude-md-improver как подзадачу
5. После выполнения — возвращаюсь в stack-flow для R7 verification

Это не конфликт с CLAUDE.md §5 п.10 — это исполнение §5 п.10 внутри stack'а.

10.4. Запрет на байпас stack'а

Tier: transitive hard-rule (через цепочку Pravila §13.9 → §13). Не explicit hard-rule как Pravila §12, но эквивалент по последствиям (фиксация в feedback memory + утрата головенства stack'а). Pravila §9 «Отступления» к этому правилу не применяется (наследуется от §13 hard-link статуса; см. Pravila §13.6). См. также Pravila §12.4 для аналогичной формулировки про §12.

Категорически запрещено инвокировать любой не-stack плагин до прохождения R0 gate, кроме случаев:

• live-команда /имя-плагина от пользователя (R0.4.B);
• технические исключения R0.4.A (read-only исследование, тривиальные синки, справочные ответы).

Прямой Skill tool на не-stack плагин до классификации задачи через R1 = нарушение R10, по последствиям сопоставимое с игнорированием §12 Pravila (потеря головенства stack'а, неуправляемая координация). Формально hard-link на это нарушение зафиксирован в Pravila §13.9: нарушение R10 PSR_v1 = нарушение §13 Pravila.

---

Правило 11 — иерархия источников истины UI/UX

При противоречии между источниками знаний по UI — выбирается верхний уровень. Это снимает тройную избыточность (Brandbook + Boost guidelines + FD + UPM + Vuetify docs).

1. BRANDBOOK_v2 (Forest v8)
       ↓
2. ТЗ v8.5 + db/schema.sql + Открытые_вопросы
       ↓
3. Frontend Design plugin (после фильтра R6 + override R6.1)
       ↓
4. Boost custom guidelines (app/.ai/guidelines/vuetify.md)
       ↓
5. ui-ux-pro-max plugin (резерв-библиотека)
       ↓
6. Default Vue 3 + Vuetify 3 documentation

11.1. Что определяет каждый уровень

Уровень	Роль	Когда определяет
1. BRANDBOOK_v2	Палитра (Teal/Ivory/теало-нуар), шрифты (Inter/JetBrains Mono), иконки (Lucide), Forest aesthetic направление, axis типографики	при любом цветовом/типографическом/направленческом решении
2. ТЗ + schema + Открытые_вопросы	14 OKLCH-статусов, состояния воронки, состав экранов, поля форм, бизнес-правила	при решениях, связанных с предметной областью (deals, billing, admin, auth)
3. Frontend Design	Принципы a11y, контраст, иерархия, паттерны (modal-flow, form-validation UX), spacing-ритм, состояния loading/empty/error	в фазе 2 R2 (визуальный дизайн UI-фичи) и для чисто визуальных задач R1
4. Boost guidelines	Паттерны кода Vue 3 + Vuetify 3: какой компонент использовать, как структурировать template, какие composables, как делать v-data-table с пагинацией	при работе с .vue файлами в resources/js/
5. ui-ux-pro-max	Дополнительные UX-гайдлайны (charts, табличная навигация, региональные паттерны), палитры/шрифты как библиотека (для внутренних утилит, не основного UI)	только когда уровни 1–4 молчат по конкретному вопросу
6. Vue/Vuetify docs	Официальный API компонентов, props/events/slots, конфигурация плагинов	как fallback для технических вопросов API

11.2. Применение

При вопросе «как стилизовать v-data-table для списка сделок»:

• уровень 1 (Brandbook): даёт палитру (Teal accent, Ivory bg, JetBrains Mono для числовых колонок)
• уровень 2 (ТЗ + schema): даёт 14 OKLCH-статусов для slug-маппинга
• уровень 3 (FD): даёт принципы (контраст 4.5:1, hover-state, фокус-порядок, sortable headers UX)
• уровень 4 (Boost): даёт паттерн v-data-table + slots для status badges
• уровень 5 (UPM): не активируется — уровни 1–4 уже дали ответ
• уровень 6 (Vuetify docs): только если нужен exact prop name

При противоречии: Brandbook (Inter) > FD «NEVER use Inter» — побеждает уровень 1, FD-рекомендация игнорируется (R6.1).

11.3. Запрет на инверсию иерархии

Никогда не использовать UPM-палитру вместо Forest, даже если UPM «лучше выглядит». Никогда не использовать FD-aesthetic «brutalism» вместо Forest-restrained. Иерархия — это не «можно нарушить ради красоты», это закон.

11.4. Fallback при технической недоступности уровня

Если источник уровня N технически недоступен в текущей сессии или контексте — он считается «молчащим», и решение опускается на уровень N+1 без потери валидности. Технические недоступности и их fallback-маршруты:

Источник	Возможная недоступность	Fallback
1. BRANDBOOK_v2	файла нет в liderra_v8_handoff/docs/ (репозиторий в неполном состоянии)	уровень 2 (ТЗ + schema), при отсутствии и того — hard-стоп R0.6
2. ТЗ + schema + Открытые_вопросы	docs не загружены в контекст	прочитать через Read-tool; если файл отсутствует физически — hard-стоп
3. Frontend Design plugin	skill не в системном списке текущей сессии (skill list = constant per conversation, см. intro)	сразу уровень 4 (Boost guidelines) + явная пометка пользователю «FD недоступен в этом чате, использую Boost+Brandbook; для полной R2 phase-flow открой новый чат»
4. Boost custom guidelines	app/.ai/guidelines/vuetify.md отсутствует или Boost MCP не подключён	уровень 5 (UPM) — только для технических вопросов API; для дизайн-решений — hard-стоп
5. ui-ux-pro-max	плагин отключён в settings.json	уровень 6 (Vue/Vuetify docs)
6. Vue/Vuetify docs	сетевая недоступность WebFetch	hard-стоп R0.6 — нельзя действовать без официального API

Правило применения: перед использованием уровня — короткая внутренняя проверка доступности. Если уровни 1 или 2 недоступны — hard-стоп независимо от R13 confidence: brand и предметная область не имеют валидного fallback'а. Уровни 3–6 — мягкий fallback с пометкой.

В этой сессии (после установки FD-плагина 09.05.2026): уровень 3 в текущем разговоре «молчит», работаю по уровням 1, 2, 4, 5, 6. R2 фазы 2/5/7 (FD-зависимые) — частично ослаблены до открытия нового чата.

11.5. Активация UPM в архитектурном решении R12 (v1.4)

Активация уровня 5 (UPM) разрешена не только при «молчании уровней 1–4», но и при архитектурном решении R12, где требуется ≥3 различающихся варианта (A/B/C) по Pravila §4.5: один из вариантов может исходить из UPM-библиотеки. Это снимает рестриктивный «only when silent» и даёт UPM роль на фазе 1 R2 (brainstorming) для архитектурных решений.

Ограничение: даже в этом случае конечное решение принимается через уровни 1–2 (Brandbook + ТЗ); UPM остаётся материалом, не решением (R10.2). UPM не может «выиграть» против Brandbook через факт «вариант UPM красивее» — иерархия R11 остаётся законом (R11.3).

11.6. Иерархия motion-источников (внутри уровня визуального дизайна, v1.4)

Параллельная под-иерархия для motion (анимаций / transition'ов / gesture'ов). Применяется при ЛЮБОЙ задаче на анимацию — последовательно сверху вниз; решение принимается на первом уровне, который покрывает кейс:

1. BRANDBOOK (motion-tokens, если/когда добавятся в v3+)
       ↓
2. ТЗ v8.5 / Открытые_вопросы (явные motion-требования)
       ↓
3. Vue 3 native <Transition> + <TransitionGroup>
       ↓
4. Vuetify 3 transitions
   (v-fade, v-slide-y, v-slide-x, v-scale, v-expand, v-dialog-transition)
       ↓
5. CSS @keyframes + transition + prefers-reduced-motion
       ↓
6. View Transitions API (с feature-detection, Chrome 111+ / Safari 18+)
       ↓
7. motion-v (Vue port framer-motion) — ТОЛЬКО при удовлетворении R15.2 (а)+(б)+(в)+(г)

framer-motion — вне иерархии (запрещён R15.1 — React-only). gsap / anime.js / react-spring / lottie-web — также вне иерархии без явного R15-аналога активации (R0.6 пункт 11 hard-стоп).

Большинство motion-задач закрываются на уровнях 3–4 без вынесения в R12 архитектурное решение. Уровни 5–6 — для произвольных кастомных анимаций. Уровень 7 — последняя инстанция, требует R15-flow.

---

Правило 12 — три паттерна дизайн-решений по типу решения

Снимает неоднозначность между §4.5 «3 варианта», Superpowers brainstorming (свободно), FD «one BOLD direction» — у каждого свой scope.

Тип решения	Примеры	Паттерн	Источник
Архитектурное	Новое компонент-семейство (AppDataTable уровня системы), новый layout-pattern, новая иконографика (замена Lucide), новая палитра, добавление новой технологии в стек, изменение брендовой основы	3 варианта A/B/C + рекомендация Claude + дефолт. Триггер hard-стопа R0.6. Override: если пользователь явно вызвал brainstorming skill или сформулировал «свободно / без вариантов / brainstorm» — формат A/B/C снимается, идёт свободный мозговой штурм по Pravila §11.1 (Superpowers override §4.5 разрешён)	Pravila §4.5; override §11.1
Тактическое с альтернативами (≥2 различных компонента/паттерна)	Выбор Vuetify-компонента из 2–3 близких альтернатив (v-text-field vs v-autocomplete vs v-select), выбор layout-варианта (v-row vs v-container для grid), выбор валидационного паттерна	A/B/C формат разрешён (для совместимости с user-стилем коротких ответов «а», «б»); либо свободный brainstorming. Не путать с архитектурным §4.5 — здесь нет рекомендации Claude как обязательной строки	Superpowers + user-стиль
Тактическое без альтернатив	layout-вариация в рамках одного компонента, расположение элементов на экране, выбор spacing-token, hover-поведение из Vuetify defaults	одна BOLD идея от FD (фаза 2 R2) или прямое решение по контексту	FD R2
Стилевое внутри направления	Цвет акцента из палитры Forest, размер шрифта из axis 14..32, отступ из spacing-шкалы, hover-state intensity, transition timing	одна готовая идея от FD — без вариантов	FD фаза 2
Тривиальное	Padding кнопки на 4px, точное значение border-radius, microcopy в tooltip	прямое решение Claude по контексту, без brainstorm и без FD	по дефолту brandbook + здравый смысл

12.1. Распознавание типа

Сомнение	Резолюция
Архитектурное или тактическое?	если решение переиспользуется в ≥3 местах или меняет foundation — архитектурное; если в одном экране — тактическое
Тактическое или стилевое?	если есть выбор между разными компонентами/паттернами — тактическое; если только параметры одного компонента — стилевое
Стилевое или тривиальное?	если затрагивает brand-токены — стилевое; если только локально влияет — тривиальное

При неуверенности — поднять на уровень выше (тривиальное → стилевое → тактическое → архитектурное). Лишний brainstorm безопаснее, чем пропуск архитектурного решения.

12.2. Запрет на смешение паттернов

• Архитектурное решение никогда не делается через одну BOLD идею FD без согласования — это нарушение Pravila §4.5. Исключение: override через явный вызов brainstorming skill или просьбу «свободно/без вариантов» от пользователя — снимает требование §4.5 (см. Pravila §11.1).
• Тактическое с альтернативами может оформляться как A/B/C для совместимости с user-стилем коротких ответов («а», «б»), но без обязательной структуры §4.5 (рекомендация + дефолт). Альтернативный формат — свободный brainstorming.
• Тактическое без альтернатив никогда не оборачивается в 3 варианта — это пустая трата времени, нет реальных альтернатив.
• Стилевое решение никогда не оформляется как brainstorm — это пустая трата фазы 1 R2.
• Тривиальное решение никогда не оформляется как brainstorm и никогда как 3 варианта — прямое действие по контексту.

---

Правило 13 — Decision matrix Auto mode + §12 + R0.6

Снимает операционную неоднозначность между Auto mode «execute immediately», Pravila §12 «Superpowers first» и PSR R0.6 «stop on low confidence». Явная таблица «тип задачи → confidence → действие».

Тип задачи	Уверенность	Действие в Auto mode
Стандартный CRUD по уже существующему precedent'у в app/Http/Controllers/ (новый endpoint типа existing)	высокая	действую, инвокируя Superpowers TDD по §12 первым шагом
Новая UI-фича из ТЗ v8.5 с готовым макетом в liderra_v8_handoff/ (1 из 13 экранов handoff)	высокая	действую по фазам R2; brainstorming фаза 1 — короткая, фаза 2 — FD по handoff
Новая UI-фича в рамках уже согласованного MVP-skopa, но без точной детализации в ТЗ (например, side-panel для модерации в admin-зоне — admin-зона есть в ТЗ, side-panel — нет)	средняя	фиксирую предположение «делаю X, исхожу из Y; если иначе — поправь», действую
Новая UI-фича вне ТЗ v8.5 и не в Открытые_вопросы (например, «добавь раздел Заметки» — нет в ТЗ, нет открытого вопроса)	низкая	hard-стоп — требуется согласование как новый Биз-/CTO-/Диз- вопрос (Pravila §2.2 + §7). Нельзя действовать с предположением, это нарушение §7 «закрытие открытых вопросов только пользователем»
Доработка существующего компонента (правка handler, добавление prop)	высокая	действую, R4 фаза 4 (TDD логика)
Изменение visual внутри компонента (добавить hover-state, поменять цвет акцента в рамках Forest)	высокая	действую, R4 лёгкое возвращение к фазе 2 без re-entry brainstorming
Изменение visual направления (добавить новое aesthetic, не описанное в Brandbook)	низкая	hard-стоп R0.6 + 3 варианта (R12 архитектурное)
Изменение vuetify.ts (palette, font, theme variant)	низкая	hard-стоп R0.6, нельзя пропустить
Cross-cutting refactor ≥3 компонентов / layout-структуры	низкая	hard-стоп R0.6 + writing-plans Superpowers
Новая абстракция в коде (composable, helper, схема API)	средняя/низкая	3 варианта Pravila §4.5 + Superpowers brainstorming фаза 1
Изменение бэкенд-логики, поведения API, бизнес-правил	средняя	Superpowers TDD по §12; если меняется поведение существующего эндпоинта — фиксирую предположение про migration impact
Изменение db/schema.sql	низкая	hard-стоп + CHANGELOG_schema (CLAUDE.md §5 п.8)
Закрытие открытого вопроса (Биз-/CTO-/Ю-/Диз-/DO-/OPEN-)	низкая	hard-стоп — закрытие только пользователем (Pravila §7)
Тривиальная синхронизация (опечатка, версия, кросс-ссылка)	высокая	действую без stack (R0.4.A), без §12, без R0.6
Read-only исследование, grep, git log	высокая	действую без stack (R0.4.A)
Справочный ответ без действия над кодом	высокая	действую без stack (R0.4.A); §12 не применяется (§12.3)
[v1.4] UI-фича из ТЗ, нужен паттерн отсутствующий в Vuetify+resources/js/components/, не брендовый	средняя	действую, инвокирую R14 pipeline: фаза 5 → 21st черновик → R6.0/R6.1 → FD адаптация
[v1.4] UI-фича из ТЗ, паттерн есть в Vuetify	высокая	используем Vuetify, 21st не вызывается (R0.6 пункт 10 hard-стоп)
[v1.4] UI-фича из ТЗ, паттерн = брендовый компонент App*	низкая	hard-стоп R0.6 пункт 9 + 3 варианта по §4.5 (R12 архитектурное), 21st не вызывается
[v1.4] Архитектурное решение R12, FD дал 1–2 варианта, нужен третий	средняя	действую, фаза 1 R2 → подключить UPM (R11.5) для третьего варианта
[v1.4] Анимация на экране, простая (fade/slide/scale/expand)	высокая	действую, использую Vuetify transition или Vue <Transition> (R11.6 уровни 3–4)
[v1.4] Анимация средней сложности (custom keyframes, hover-state с timing)	высокая	действую, использую CSS @keyframes (R11.6 уровень 5)
[v1.4] Cross-route transition (hero-transition при переходе между экранами)	средняя	фиксирую предположение: «использую View Transitions API с fallback на Vue <Transition> для не-Chromium»; если кейс требует motion-v → R15.2
[v1.4] Запрос «давай добавим framer-motion / motion-v / gsap / lottie» без явного кейса	низкая	hard-стоп R0.6 пункт 11 + R15.2 формальная проверка триггеров; нельзя действовать в Auto mode
[v1.4] Кейс из ТЗ требует gesture с физикой (drag с инерцией, swipe с pinch)	средняя	действую, R15.2 запускает brainstorming + 3 варианта (motion-v vs vanilla pointer events vs CSS scroll-snap); презентую таблицу

13.1. Принципы matrix'а

1. §12 Pravila применяется только когда задача не вышла в R0.4.A. Если задача — read-only/тривиальная/справочная, §12 не релевантен (это §12.3 exclusions Pravila).
2. R0.6 hard-стоп — неотменяемый, перекрывает Auto mode. Никакие «средняя confidence + Auto» не обходят 8 пунктов R0.6.
3. «Высокая уверенность + Auto» — это разрешение действовать без вопроса, но не разрешение пропустить §12 (Superpowers первым) или R6 (стек-фильтр FD) — они применяются автоматически в фоне.
4. «Средняя уверенность» в Auto mode — фиксирую предположение одной строкой перед действием. Не лекция, не вопрос — короткая ремарка для пользователя.

13.2. Совместимость с user-стилем «терсе»

Memory feedback: пользователь предпочитает короткие команды, минимум лекций. Поэтому:

• В «высокая + Auto» — действую молча (только сам факт инвокации skill'а Superpowers визуален).
• В «средняя + Auto» — одна строка ремарки максимум.
• В «низкая / hard-стоп» — компактный вопрос (одно предложение или AskUserQuestion с 2–3 вариантами), не развёрнутая лекция.
• Hard-стоп не отменяется ради «терпимости пользователя к вопросам» — это страховка от поломки brand/архитектуры.

---

Правило 14 — Pipeline внешних UI-генераторов (UPM + 21st Magic MCP, v1.4)

Назначение: одно правило связывает R6.0 / R6.1 / R10.1 / R11.5 / R0.6 в исполнимый pipeline для двух новых UI-инструментов. Снимает риск ad-hoc использования вне stack-flow.

14.1. Триггер активации pipeline'а

Pipeline активируется при одновременном выполнении:

• задача = UI-фича по R1 (логика + визуал) ИЛИ чисто визуальная задача из R1;
• нужный паттерн не покрыт уровнями 1–4 R11 (Brandbook самодостаточно, ТЗ-требование выполнимо без расширения, FD-самодостаточно, Boost guidelines покрывают паттерн);
• задача не попадает в R0.6 hard-стоп (особенно пункты 9, 10, 11 v1.4).

14.2. Шаги pipeline'а

Запрос
   │
   ▼
┌─────────────────────────────────────┐
│  Stack-gate R0 + классификация R1   │
└─────────────────────────────────────┘
   │
   ▼ (UI-фича)
Фаза 1: brainstorming (Superpowers)
   ├── архитектурное R12? → подключить UPM на этой фазе (R11.5) для третьего варианта
   └── продолжить
   │
   ▼
Фаза 2: visual design (FD)
   ├── FD пытается решить
   │   ├── решил → дальше фаза 3
   │   └── не покрыл / нужны альтернативы → R14.3 (UPM fallback)
   │
   ▼
Фаза 3: writing-plans (Superpowers)
   │
   ▼
Фаза 4: TDD логика (Superpowers)
   │
   ▼
Фаза 5: визуальная сборка
   ├── FD ассемблирует на основе фазы 2
   ├── если нужен черновик template для нестандартного non-brand non-Vuetify
   │   компонента → R14.4 (21st Magic MCP)
   │
   ▼
Фаза 6: verification логики (Superpowers verification-before-completion)
   │
   ▼
Фаза 7: verification визуала (FD UI-чеклист) + Pa11y проход (R7) на deployable
   │
   ▼
Фаза 8: review по аспектам (R5 — оба плагина параллельно)

14.3. R14.3 — подключение UPM (в фазах 1 или 2)

• Триггер активации (фаза 2): FD выдал «не покрывает» / «не знаю» / нужна вторая итерация для сравнения.
• Триггер активации (фаза 1): R12 архитектурное решение, нужен «третий вариант» (R11.5).
• Что делает: отдаёт принципы / палитры (как принципы, не как готовые наборы) / типографические пары (как принципы) / chart-паттерны / UX-гайдлайны.
• Обязательные обработки до использования:
  1. R6.0 фильтр стека (срезать React/Tailwind/shadcn материалы; оставить Vue + HTML/CSS-уровневые принципы);
  2. R6.1 hard-override Forest (палитра/шрифты/иконки/aesthetic — Forest, не UPM-предложения);
  3. R11.3 запрет инверсии (UPM-палитра НЕ заменяет Brandbook).
• Решение остаётся за FD (R10.2 «UPM read-only для решений»).
• Не параллельно с FD — последовательно.
• Не закрывает задачу (R7 не упоминает UPM).

14.4. R14.4 — подключение 21st Magic MCP (в фазе 5)

• Триггер активации: FD на фазе 2 принял решение «нужен кастомный компонент», для которого нет ни Vuetify-эквивалента, ни существующего компонента в resources/js/components/.
• Pre-check R0.6 пункты 9–10 ОБЯЗАТЕЛЕН до вызова mcp__magic__* tool:
  • Брендовый компонент App*? → hard-стоп, R12 архитектурное (3 варианта по §4.5).
  • Vuetify-эквивалент существует? → hard-стоп, использовать Vuetify.
  • Существующий компонент в resources/js/components/? → hard-стоп, использовать его.
  • Если на все три «нет» → переходим к генерации.
• Шаги генерации:
  1. Вызов mcp__magic__21st_magic_component_builder (или _inspiration / _refiner) с описанием паттерна;
  2. Сгенерированный черновик (по умолчанию React + Tailwind + shadcn) → через R6.0 фильтр (JSX → Vue SFC template, Tailwind → utility-CSS / Vuetify, shadcn → Vuetify-эквивалент, React imports/hooks → Vue Composition API);
  3. → через R6.1 hard-override (палитра/шрифты/иконки → Forest, Lucide);
  4. → FD адаптирует под фазу 5 (применяет принципы из фазы 2 к стек-совместимому скелету);
  5. → возврат в фазу 5 stack-flow для финальной сборки.
• Сгенерированный черновик НЕ коммитится в неизменном виде — только после полного pipeline'а.
• Не закрывает задачу (R7 не упоминает 21st).
• Pa11y обязателен на deployable артефакт (R7).

14.5. Запрет дублирования

Одна задача = один генератор. UPM и 21st не запускаются на одной фазе:

• если UPM выдал материал и FD адаптировал — 21st не вызывается;
• если 21st выдал черновик — UPM на этом этапе не нужен.

Если кажется, что нужны оба — это сигнал, что задача декомпозируется (например, на два разных компонента), и каждая под-задача проходит pipeline отдельно.

14.6. Live-override

• /ui-ux-pro-max — прямой вызов UPM (R0.4.B, на одно действие). R6.0 фильтр и R6.1 override остаются обязательными.
• «вызови magic» / «через 21st» / «дай шаблон через magic» — прямой вызов 21st (R0.4.B). R6.0 + R6.1 + R0.6 пункты 9–10 pre-check остаются обязательными.

В обоих случаях live-override снимает только требование stack-gate первенства (R0.2), но не отменяет фильтрацию и hard-override Forest.

14.7. Hard-link на §13 Pravila

Tier: transitive hard-rule (аналогично R10.4). Не explicit hard-rule как Pravila §12, но эквивалент по последствиям через цепочку R14 → R10.4 → §13.9 → §13.10 → §13. Pravila §9 «Отступления» к этому правилу не применяется (наследуется от §13 hard-link статуса; см. Pravila §13.6).

Нарушение R14 (использование UPM или 21st вне pipeline'а — без R6.0 фильтра, без R6.1 override, без pre-check R0.6, без FD-адаптации) = нарушение §13 Pravila через цепочку R10.4 → §13.9 → §13.10 → §13. Фиксируется в feedback memory аналогично §12.7 / §13.9.

---

Правило 15 — Motion-системы (animation libraries, v1.4)

Назначение: двухуровневое решение по runtime-библиотекам анимаций. Уровень 1 — постоянный hard-запрет архитектурно несовместимых. Уровень 2 — узкое легальное окно для совместимых при выполнении 4 условий.

15.1. framer-motion — запрещено всегда (hard-запрет)

framer-motion — React-only runtime библиотека (использует React fiber-tree, hooks, JSX). В Vue + Vuetify стеке физически не работает. Установка через npm бессмысленна — мёртвый код в node_modules.

Hard-запрет, не отменяется ни Auto mode, ни live-командой пользователя уровня R0.4.B. Единственный путь снятия — смена базового frontend-стека (изменение CLAUDE.md §2), что само по себе — R0.6 hard-стоп «изменение технологии в стек» с brainstorming + 3 варианта §4.5 + явное согласование Brandbook update.

15.2. motion-v — условно разрешено по 4 условиям триггера

motion-v = Vue 3 порт API framer-motion (отдельный пакет от того же maintainer'а Motion, ~30 KB gzipped). Технически совместим со стеком, но добавление в проект — R0.6 hard-стоп «новая технология в стек» (пункт 11 v1.4).

Активация motion-v разрешена ТОЛЬКО при одновременном выполнении ВСЕХ четырёх условий:

(а) Письменный кейс. Конкретный UX-кейс из ТЗ v8.5 ИЛИ из Открытые_вопросы_*.md (закрытый пользователем), который НЕ покрывается дефолтной motion-стойкой R11.6 уровни 3–6. Без явного кейса в письменном источнике — нельзя, даже если задача кажется подходящей.

(б) Категория оправданности. Кейс попадает в одну из категорий, где motion-v реально оправдан:

• gesture-driven UI с физикой (drag с инерцией, swipe, pinch);
• shared-layout transitions между route'ами (hero-transition);
• spring-physics на интерактивных контролах (где CSS-easings демонстративно недостаточно).

Все остальные категории (fade, slide, scale, expand, hover, простые route-transitions) — уровни 3–4 R11.6 их закрывают, motion-v избыточен.

(в) Brandbook approval. Brandbook v2 (или последующий) явно допускает motion-rich направление для затронутого экрана. По умолчанию Forest = restrained (R6.1) — любое отклонение требует Brandbook-update пользователем (новая запись в BRANDBOOK_v2 §X о motion-направлении или явное изменение R6.1 hard-override).

(г) Полный R12 архитектурный flow. Прохождение:

• brainstorming (Superpowers) — фаза 1;
• 3 варианта решения (Pravila §4.5): «motion-v vs CSS @keyframes vs View Transitions API» с честной сравнительной таблицей (bundle size / поддержка браузеров / совместимость с SSR / кривая обучения / Forest-совместимость);
• явное согласование пользователем («делай», «вариант X»).

15.3. Default motion stack (без motion-v) — действует всегда по умолчанию

При ЛЮБОЙ задаче на анимацию — сначала пробуем эти слои в порядке (по R11.6):

1. Vue 3 native <Transition> / <TransitionGroup> (enter/leave hooks, FLIP через TransitionGroup, JS-callbacks);
2. Vuetify 3 transitions (v-fade-transition, v-slide-y-transition, v-slide-x-transition, v-scale-transition, v-expand-transition, v-dialog-transition);
3. CSS @keyframes + transition + поддержка prefers-reduced-motion (произвольные анимации, GPU-acceleration через transform/opacity);
4. View Transitions API (Chrome 111+, Safari 18+) — для cross-document / cross-route переходов с feature-detection.

Эти четыре слоя — источники истины для motion (R11.6 уровни 3–6). Большинство задач закрываются на уровне 1 или 2, без motion-v и без View Transitions.

15.4. Триггер «дефолт не покрывает» — формальная проверка

Прежде чем поднимать вопрос motion-v, требуется явная фиксация одной строкой:

«Попробовал слои 1–4 R11.6 (R15.3). Не закрывает потому что [конкретная техническая причина]. Поднимаю R15.2 для активации motion-v.»

Без этой фиксации R15.2 (а)+(б) не считаются удовлетворёнными.

Типичные ложные триггеры (НЕ повод для motion-v):

• «хочется живее» — субъективно, не кейс;
• «в дизайне у других CRM это есть» — не источник истины;
• «framer-motion смотрится круто» — Forest = restrained (R6.1);
• «спросил пользователя — он сказал давай» — устной просьбы недостаточно, нужен письменный кейс (а).

15.5. Hard-запрет дублирования

После активации motion-v (если когда-либо) — Vuetify transitions и Vue native <Transition> не удаляются из проекта. motion-v применяется ТОЛЬКО к экранам/компонентам, прошедшим R15.2; всё остальное продолжает работать на дефолтной стойке R15.3. Это снимает риск ad-hoc «давайте перепишем всё на motion».

15.6. Live-override

• framer-motion: live-override запрещён (R15.1 hard).
• motion-v: live-override запрещён без прохождения R15.2 — пользователь может сказать «через motion-v», но это всё равно проходит через brainstorming + 3 варианта (R15.2 пункт г).

Это исключение из общего R0.4.B — обоснование: установка runtime-зависимости ≠ инвокация плагина, у неё другой класс последствий (bundle size, CI, lock-file, browser compat).

15.7. Аналогичные правила для других animation runtime библиотек

gsap, anime.js, react-spring (React-only), lottie-web, popmotion, @motionone/dom и любые другие animation runtime библиотеки — попадают под R0.6 пункт 11 hard-стоп. Активация — по аналогии с R15.2 (4 условия + R12 flow).

react-spring дополнительно — R15.1 аналог (React-only, физически не работает в Vue стеке).

---

Финальная формула

Любая задача → Правило 0 (gate, stack-головной) → Правило 1 (классификация по типу) → Правило 9 (решение, ≤2 итерации) → Правило 13 (decision matrix по уверенности) → Правило 2 (фаза UI-фичи) → исполнение по Правилам 3, 4, 6 → если нужен внешний UI-генератор: Правило 14 pipeline (UPM на фазах 1/2, 21st на фазе 5) → если нужна анимация: Правило 15 (default стойка R15.3, motion-v только по 4 условиям R15.2) → завершение по Правилу 7 → ревью по Правилу 5. Источники истины — Правило 11 (UI/UX) + R11.6 (motion). Паттерны решений — Правило 12. Координация с не-stack плагинами — Правило 10. Тай-брейкеры — Правило 8.

---

Свойства свода

• Полнота: каждая задача попадает в одну ветку Правила 1, каждая фаза имеет одного владельца (Правило 2), каждый артефакт ревью — один аспект (Правило 5), каждый тип закрытия — один gate (Правило 7), каждое дизайн-решение — один паттерн (Правило 12), каждая комбинация Auto+§12+R0.6 — одна строка matrix'а (Правило 13), каждый внешний UI-генератор имеет одно место в pipeline (Правило 14), каждая motion-задача — один слой R11.6 (Правило 15).
• Головенство stack'а (v1.2 принцип-аксиома, расширена в v1.4): stack — головной при решении любой задачи. Внешние плагины (включая UPM и 21st Magic MCP) — инструменты, инвокируемые внутри stack-flow (Правило 10) через pipeline R14. Иерархия источников UI — закон, не гайдлайн (Правило 11). Runtime-зависимости (motion) подчиняются R15.
• Непротиворечивость: все найденные конфликты закрыты:
  • v1.0 (8 первичных):
    1. «Активны» → «подключены к gate» (0.1).
    2. Закрытие визуальной задачи — Frontend Design (7).
    3. Возврат к фазе 2 — лёгкий/тяжёлый (4).
    4. Ревью по аспекту, не по файлу (5).
    5. Пост-процессинг внутри Frontend Design (6).
    6. Live-команды поддерживают частичную отмену (0.4.B).
    7. Auto mode совместим через трёхуровневую логику уверенности (0.6).
    8. Лимит 2 итерации (9).
  • v1.1 (5 трений A–E): hard-override (6.1), дезамбигуация (R1), Pa11y gate на deployable (R7), runtime-заметка (intro), hard-стоп список (R0.6).
  • v1.2 (4 проектных перекрытия): ui-ux-pro-max + другие плагины как tools (R10), иерархия источников истины UI (R11), три паттерна дизайн-решений (R12), decision matrix Auto/§12/R0.6 (R13).
  • v1.3 (6 трений второго порядка F–K): R12 override через brainstorming (F); R12 тактическое разделено на «с альтернативами»/«без» для user-стиля «а/б» (G); R13 новая фича вне ТЗ — hard-стоп вместо предположения (H); R11.4 fallback при недоступности уровней источников (I); R10.4 смягчение + hard-link в Pravila §13.9 (J); R0.1 уточнение scope «головенства» через таблицу priority chain (K).
  • v1.4 (формализация UPM + 21st Magic MCP + motion-системы): R6 расширен на FD/UPM/21st (универсальная таблица 6.0); R6.1 hard-override Forest расширен на все три плагина; R10.1 +1 строка для 21st + ослабление UPM до v1.4 двух-триггера (FD молчит ИЛИ R12 третий вариант); R11.5 активация UPM в R12; R11.6 параллельная иерархия motion-источников (7 уровней); R0.6 +3 hard-стопа (брендовый App* через 21st, Vuetify-эквивалент через 21st, motion-v без R15.2); R13 +9 строк matrix'а; R14 новое правило (pipeline UPM + 21st с R14.3/R14.4 + R14.7 hard-link на §13 Pravila); R15 новое правило (R15.1 framer-motion hard-запрет, R15.2 motion-v 4 условия (а)+(б)+(в)+(г), R15.3 default стойка, R15.4 формальная проверка триггера, R15.5 hard-запрет дублирования, R15.6 live-override запрет, R15.7 расширение на gsap/anime/lottie); R8 +7 тай-брейкеров; финальная формула расширена.
• Действенность: решение — за 3 вопроса (Правило 9) + matrix Правила 13; если не сработало — явный fallback на пользователя (0.6).
• Симметрия: оба плагина stack'а имеют равные права на закрытие задач в своём домене (7), на ревью в своём аспекте (5), на отмену через live-команду (0.4.B). Асимметрия введена только между stack'ом и не-stack плагинами: stack головной, остальные — инструменты (R10/R14). Внутри пула «инструменты» — UPM и 21st имеют разные роли (UPM = библиотека принципов; 21st = генератор кода) и разные точки активации в pipeline (R14.3 фазы 1/2 vs R14.4 фаза 5).

---

История версий

• v1.7 от 10.05.2026 (поздний вечер) — закрытие 5 находок третьего аудита правил использования плагинов и скилов («Все 13 находок (P0+P1+P2)»). Сам PSR_v1 — sync-уровень + одна description-правка:

  • Шапка cross-refs приведена к актуальным версиям связанных документов после bump'ов CLAUDE.md v1.85 → v1.86 и Tooling v1.14 → v1.15: «CLAUDE.md v1.84+» → «v1.86+», «Pravila v1.9+» → «v1.10+», «Tooling v1.14+» → «v1.15+». «+»-нотация сохранена (forward-compat). Закрывает audit P1-01/02 (PSR_v1).
  • Описка в шапке v1.6 changelog'а исправлена: «slot уровня 2.5» → «slot уровня 2b». Фактическое R0.1 (line 33 этого файла) всегда содержало «уровень 2b»; шапка v1.6 описывала ту же правку, но с опечаткой «2.5», создавая иллюзию ещё одного уровня. Закрывает третий-audit P2-01.

  Связанные обновления — CLAUDE.md v1.85 → v1.86 (§3 header «28»→«33»; §3.3 footer «из 30 номеров» → «из 33 номеров (29 phase-slot + 3 off-phase + 1 historic)»; §3.4 «итого 28»→«29»; §6 «19 инструментов из 29»→«24»; §3.3 #33 «вне Pravila §13»→«вне UI-пула §13»; §5 п.5 «v1.5+»→«v1.7+»), Tooling Прил. Н v1.14 → v1.15 (cross-refs sync; §11/§12 «28 инструментов»→«33 формализованные позиции»). Pravila v1.10 — без правок (cross-refs от других документов на Pravila уже подтянуты к актуальной v1.10). Через /claude-md-management:claude-md-improver.

• v1.6 от 10.05.2026 (вечер) — закрытие 3 структурных правок второго аудита правил использования плагинов и скилов («Все 15 находок (P0+P1+P2)»):

  • R0.4.A свёрнут до cross-ref на Pravila §12.3 SoT. Раньше параллелил список exclusions расширенной таблицей (6 строк vs 6 пунктов Pravila §12.3) с разными формулировками — риск дрейфа. v1.5 объявил Pravila §12.3 SoT, но R0.4.A продолжал держать собственную таблицу. v1.6 — таблица удалена, оставлен cross-ref + отдельный блок «Stack-расширения» (CLAUDE.md правки через claude-md-improver + tooling-команды вне debug/TDD/review). Закрывает audit P2-02.
  • R0.6 hard-стопы пронумерованы 1–11. Раньше — буллет-list, но в R8/R13/R14/R15 ссылались как «R0.6 пункт 9», «пункт 10», «пункт 11» — требует ручного счёта, при добавлении пункта все cross-refs молча ломаются. v1.6 — explicit numbering 1–11 + примечание про необходимость пересмотра ссылок при изменении списка. Закрывает audit P2-04.
  • R0.1 +Tooling Прил. Н slot уровня 2b (между CLAUDE.md уровень 2a и PSR_v1 уровень 3). Раньше R0.1 говорил «stack ниже Файлы CLAUDE.md / Pravila / Tooling», но Tooling не было ни в R0.1 таблице, ни в CLAUDE.md §1, ни в Tooling §7 priority chain — формальная дыра при конфликте «Tooling vs PSR_v1». v1.6 — explicit slot 2b «Tooling Прил. Н — alongside CLAUDE.md, оба operational maps; при прямом конфликте — приоритет CLAUDE.md». Закрывает audit P2-01. (Описание правки в шапке v1.6 содержало описку «slot уровня 2.5» вместо «уровня 2b»; фактически R0.1 таблица всегда содержала «2b». Описка исправлена при описании v1.7.)

  Связанные обновления — Pravila v1.9 → v1.10 (§0 +note про §11 override-приоритет; §11.5 «10 правил» → «v1.6, 16»; §13.2/§13.9/§13.10 v1.4→v1.6), CLAUDE.md v1.84 → v1.85 (§1 +Tooling slot 2b; §6 арифметика «33» исправлена; §3.3 #31/#32 + §5 п.12 stale v1.4→v1.6 + v1.12→v1.14), Tooling Прил. Н v1.13 → v1.14 (§7 +Tooling explicit slot; §10.3 шаг 2 «3 skills»→«14»; §13 +v1.13 +v1.14 entries). Через /claude-md-management:claude-md-improver.

• v1.5 от 10.05.2026 — закрытие 5 структурных правок аудита нормативной документации («исправь все ошибки ... сохраняй максимальную эффективность и всеобъемлющее использование всех плагинов и скилов»):

  • R10.1 разбит на 3 блока по типу источника: Блок 1 = enabledPlugins через marketplace (UPM + claude-md-management); Блок 2 = built-in skills Claude Code (review/security-review/init/simplify/update-config/keybindings-help/fewer-permission-prompts/loop/schedule/claude-api); Блок 3 = MCP-серверы (21st Magic, Boost, playwright, github). Закрывает audit находку «R10.1 смешивает плагины и встроенные skills — без явного разделения путает».
  • R0.4.A — Single Source of Truth cross-ref: добавлена шапка про SoT в Pravila §12.3 (v1.9+); список ниже отражает Pravila §12.3 расширенно для stack-flow (+документационные правки уровня §4 + tooling-команды). Закрывает audit находку «3 места для exclusions §12 — дрейф вероятен».
  • R10.4 + R14.7 — tier-метки: обозначен transitive hard-rule статус через цепочку Pravila §13.9/§13.10 → §13. Pravila §9 «Отступления» к этим правилам не применяется (наследуется от §13 hard-link статуса). Закрывает audit находку «скрытая иерархия hard-rule §12 vs §13.9/§13.10».
  • R8 +тай-брейкер FD↔21st: «21st вызывается внутри фазы 5 R2 как подзадача FD, не параллельно. FD — ведущий (решатель), 21st — генератор черновика». Закрывает audit находку «не определена пара FD↔21st».
  • R0.1 — scope-метка таблицы: «головенство stack'а внутри общей 7-уровневой файловой иерархии CLAUDE.md §1; не дублирует Pravila §0 (внутрипараграфный) и не дублирует CLAUDE.md §1 (общая 7-уровневая); это третья ось». Закрывает audit находку «4 представления приоритетной цепочки путают читателя».

  Связанные обновления — Pravila v1.8 → v1.9 (§12.3 SoT, §13.2 +claude-md-management как off-pool, §13.6 hard-rule tier-структура), Tooling Прил. Н v1.12 → v1.13 (§7 +PSR_v1, §4.7 +#33 claude-md-management, §6 +5 конфликтов v1.4, §4.6 settings → .claude.json), CLAUDE.md v1.83 → v1.84 (§1 scope, §3.3 +#33, §5 п.5 свёрнут, §5 п.11 cross-ref на §12.3, §6 счётчик 33). Через /superpowers:writing-plans + /superpowers:executing-plans + /claude-md-management:claude-md-improver + ручные Edit (Pravila §12.3 exclusion для документационных правок). Финал — /superpowers:verification-before-completion.

• v1.4 от 10.05.2026 — формализация двух новых внешних UI-инструментов (UI UX Pro Max + 21st.dev Magic MCP, оба фактически были включены в ~/.claude/settings.json и ~/.claude.json без правил) + двухуровневое решение по runtime motion-библиотекам (framer-motion / motion-v / gsap / anime.js / lottie-web):

  • R6 → R6.0 «Универсальная таблица фильтра» (применяется к FD, UPM, 21st одинаково; per-plugin specifics вынесены отдельным абзацем).
  • R6.1 расширен — hard-override Forest применяется к выводу всех трёх плагинов (а не только FD). Таблица из 9 артефактов брендового фундамента остаётся той же; в колонку «Что говорят внешние плагины» добавлены реакции UPM (161 палитра/57 шрифтов/50+ стилей) и 21st (trendy-default).
  • R10.1 +1 строка для 21st (роль «генератор стартовых шаблонов»); ослабление UPM (раньше «только когда FD молчит» → теперь «FD молчит ИЛИ R12 третий вариант»).
  • R11.5 (новое) — активация UPM в R12 архитектурном решении на фазе 1 R2 (источник «третьего варианта» по §4.5). Снимает рестриктивный «only when silent».
  • R11.6 (новое) — параллельная под-иерархия 7 motion-источников: Brandbook → ТЗ → Vue native → Vuetify → CSS → View Transitions API → motion-v (последняя только по R15.2). framer-motion вне иерархии (R15.1).
  • R0.6 +3 hard-стопа: (9) 21st для брендового App*-компонента; (10) 21st для компонента с Vuetify-эквивалентом; (11) motion-v / gsap / anime.js / lottie-web без R15.2.
  • R13 +9 строк matrix'а: 4 строки UI-фич с/без 21st-pipeline + 1 строка R12 третий вариант UPM + 5 строк motion-сценариев (простая/средняя/cross-route/произвольный motion-runtime/gesture).
  • R14 (новое правило) — Pipeline внешних UI-генераторов: R14.1 триггер активации, R14.2 шаги (схема), R14.3 UPM в фазах 1/2, R14.4 21st в фазе 5 с pre-check R0.6 + R6.0 + R6.1 + FD адаптация, R14.5 запрет дублирования, R14.6 live-override (с обязательным сохранением фильтров), R14.7 hard-link на §13 Pravila через R10.4 → §13.9.
  • R15 (новое правило) — Motion-системы: R15.1 framer-motion hard-запрет (React-only архитектурно), R15.2 motion-v 4 условия (а) письменный кейс из ТЗ (б) категория оправданности — gesture/shared-layout/spring (в) Brandbook approval (г) полный R12 flow + brainstorming + 3 варианта, R15.3 default стойка (Vue native + Vuetify + CSS + View Transitions), R15.4 формальная проверка «дефолт не покрывает» одной строкой, R15.5 hard-запрет дублирования (motion-v не вытесняет Vuetify transitions), R15.6 live-override запрещён без R15.2, R15.7 аналогичные правила для gsap/anime.js/lottie-web/react-spring.
  • R8 +7 тай-брейкеров: UPM параллельно с FD, 21st параллельно с UPM, UPM-палитра «лучше» Forest, 21st JSX import напрямую, motion-v без письменного кейса, framer-motion «у других работает», какой motion-слой R11.6 для задачи.
  • Финальная формула расширена ссылками на R14 (внешние UI-генераторы) и R15 (motion).

  Заказчик подтвердил v1.4 командой «двух уровневый» (выбор между двухуровневой R15-конструкцией и полным запретом всех motion-runtime библиотек) после полного цикла brainstorming → 3 варианта → итераций → финального предложения с alternatives. Через /claude-md-management:claude-md-improver.

• v1.3 от 09.05.2026 — закрытие 6 трений второго порядка (F–K), найденных при повторном глубинном аудите v1.2:

  • F (R12 архитектурное vs Pravila §11.1): добавлено условие override через brainstorming skill или просьбу «свободно/без вариантов» — снимает требование §4.5 на 3 варианта A/B/C. R12.2 уточнён (исключение для архитектурного override).
  • G (R12.2 тактическое vs user-стиль «а/б»): тактическое разделено на «с альтернативами» (≥2 разных компонента — A/B/C формат разрешён для совместимости с короткими ответами user'а) и «без альтернатив» (одна BOLD от FD).
  • H (R13 новая фича vs Pravila §7): R13 строка про новую UI-фичу разделена. «В рамках MVP-skopa без детализации» → средняя + предположение. «Вне ТЗ И не в Открытые_вопросы» → низкая + hard-стоп (требуется согласование как новый Биз-/CTO-/Диз- вопрос).
  • I (R11 уровень 3 vs runtime skill list): добавлен R11.4 «Fallback при технической недоступности уровня» — таблица 6 уровней с маршрутами при недоступности. Уровни 1–2 (Brandbook, ТЗ) недоступны → hard-стоп; уровни 3–6 — мягкий fallback с пометкой пользователю. В текущей сессии после установки FD (где skill list ещё без frontend-design) — уровень 3 «молчит», работаем по 1, 2, 4, 5, 6.
  • J (R10.4 декларация о уровне нарушения): формулировка смягчена («по последствиям сопоставимо с» вместо «уровня §12 Pravila»). Hard-link на нарушение R10 зафиксирован в Pravila §13.9.
  • K (R0.1 «не уступает первенство» vs §1 priority chain): добавлена таблица «scope головенства» — Stack головной над уровнями 4–6 (settings.json, memory, прочие плагины), не над 0–2 (Pravila §12, Pravila, CLAUDE.md). Stack их исполняет, не перебивает.

  Pravila v1.5 → v1.6 (добавлен §13.9 hard-link). CLAUDE.md v1.80 → v1.81 (синхр. ссылок). Заказчик подтвердил v1.3 командой «все» в ответ на повторный аудит. Через /claude-md-management:claude-md-improver (четвёртая инвокация в той же сессии).

• v1.2 от 09.05.2026 — закрытие 9 проектных перекрытий, найденных при глубинном аудите stack'а внутри проекта Лидерра:

  • Принцип-аксиома v1.2: stack — головной. Внесён в шапку и в Правило 0.1.
  • Правило 10 (новое) — внешние плагины как инструменты, не как решатели. Реестр 11 не-stack плагинов с явными ролями (ui-ux-pro-max = резерв-библиотека, claude-md-management = инструмент CLAUDE.md edits, review/security-review/init/simplify = только по явному /имя, и т.д.). Закрывает: дублирование с ui-ux-pro-max, неоднозначность с claude-md-management, перекрытия с review/security-review/init/simplify, стек-знания Boost.
  • Правило 11 (новое) — иерархия источников истины UI/UX из 6 уровней: Brandbook → ТЗ+schema → FD → Boost guidelines → ui-ux-pro-max → Vue/Vuetify docs. Snimaет тройную избыточность UI-домена. При противоречии побеждает верхний уровень — это закон.
  • Правило 12 (новое) — три паттерна дизайн-решений по типу: архитектурное (3 варианта §4.5), тактическое (brainstorming или 1 BOLD), стилевое (одна готовая идея FD), тривиальное (прямое решение). Snimaет смешение Pravila §4.5 / Superpowers brainstorming / FD aesthetic.
  • Правило 13 (новое) — decision matrix Auto mode + §12 + R0.6: 14 типов задач × confidence × действие. Закрывает операционную неоднозначность. Учитывает user-стиль «терсе» (одна строка ремарки в средней уверенности).
  • Финальная формула обновлена: добавлены ссылки на R10–R13.

  Заказчик подтвердил v1.2 командой «Создай правила которые уберут все неопределённости и конфликты, но стек superpowers and Frontend должен доставать первым и главы при решении задач!». Через /claude-md-management:claude-md-improver (третья инвокация в той же сессии).

• v1.1 от 09.05.2026 — 5 патчей по реальным трениям A–E, найденным после установки плагина:

  • A: Правило 6 → +6.1 «Hard-override» — таблица из 9 артефактов, где SKILL.md плагина противоречит брендбуку Forest (Inter, JetBrains Mono, Teal, Ivory, теало-нуар, restrained-направление, Lucide, OKLCH-статусы, Forest brand в целом). Категоричные «NEVER» плагина по этим пунктам игнорируются.
  • B: Правило 1 → дезамбигуация (таблица слов запроса → дефолт классификации; «компонент» = UI-фича по умолчанию). Правило 8 → +тай-брейке𠫧12.2 + визуальная одновременно» = §12.2 first, R2 phase-flow.
  • C: Правило 7 → разделение «non-deployable / deployable» для чисто визуального; Pa11y обязателен на deployable. Правило 8 → +строки про Pa11y vs Frontend Design.
  • D: вступительная заметка о техническом ограничении Claude Code (skill list = constant per conversation; новый чат для активации).
  • E: Правило 0.6 → hard-стоп список из 8 триггеров, не отменяемый Auto mode (новый brand-компонент, изменение токенов, новое aesthetic направление, изменение UX-флоу из ТЗ, cross-cutting refactor ≥3 компонентов, новая технология в стек, изменение палитры/шрифтов, изменение OKLCH-статусов).

  Заказчик подтвердил все 5 патчей одной командой «все». Через /claude-md-management:claude-md-improver (повторная инвокация в той же сессии).

• v1.0 от 09.05.2026 — первая версия. Создана при снятии запрета CLAUDE.md §5 п.5 на Frontend Design plugin (CLAUDE.md v1.77 → v1.78). Свод выработан и проверен на конфликты в одной сессии заказчика. 10 правил (0–9), 8 встроенных патчей.