portal/docs/Plugin_stack_rules_v1.md

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

**Дата:** 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 уровня 2.5).

**Принцип-аксиома (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](../CLAUDE.md) v1.84+ — оперативная карта; §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](Pravila_raboty_Claude_v1_1.md) v1.9+ — §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](Tooling_v8_3.md) **v1.14+** — реестр инструментов; #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_raboty_Claude_v1_1.md#123-когда-правило-не-применяется)** (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](../liderra_v8_handoff/docs/BRANDBOOK_v2.md).
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](../liderra_v8_handoff/docs/BRANDBOOK_v2.md)) с 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](../db/schema.sql#L2076), мапить через 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](Pravila_raboty_Claude_v1_1.md): нарушение 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](../liderra_v8_handoff/docs/BRANDBOOK_v2.md) о 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.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 уровня 2.5** (между 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.

  Связанные обновления — 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 встроенных патчей.