portal/docs/Plugin_stack_rules_v1.md

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

**Дата:** 09.05.2026
**Назначение:** свод правил совместного использования двух плагинов Claude Code в проекте Лидерра — `obra/superpowers` (14 skills) и `anthropics/frontend-design`. Снимает запрет 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.

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

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

- [CLAUDE.md](../CLAUDE.md) v1.78+ — оперативная карта; §5 п.5 ссылается на этот документ как замену прежнего запрета
- [docs/Pravila_raboty_Claude_v1_1.md](Pravila_raboty_Claude_v1_1.md) v1.5+ — §13 «Frontend Design plugin — paired stack» ссылается сюда
- [docs/Tooling_v8_3.md](Tooling_v8_3.md) v1.10+ — реестр инструментов; #30 Frontend Design отсылает сюда

> **Техническая особенность 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):

| Уровень | Что | Stack головной над этим? |
|---|---|---|
| 0 | Pravila §12 (Superpowers hard rule) | ❌ нет — это часть stack'а же, hard rule сильнее |
| 1 | Pravila (§§1–13) | ❌ нет — stack **исполняет** Pravila, не перебивает |
| 2 | CLAUDE.md (оперативная карта) | ❌ нет — stack **исполняет** 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 не требуется):

| Исключение | Что разрешено без gate |
|---|---|
| Read-only исследование | Read, Grep, Glob, git log/status/diff |
| Тривиальная синхронизация текста | опечатки, обновление номера версии, починка кросс-ссылки |
| Справочный ответ без действия над кодом | объяснение, анализ, сравнение |
| Работа с открытыми вопросами реестра | смена статуса записи, без правок кода |

Список исчерпывающий. Расширение — через явное правило.

**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** — обязательная остановка независимо от классификации, при любом из триггеров:

- Впервые на этой сессии создаю компонент из брендового семейства (`AppButton`, `AppCard`, `AppDataTable`, `AppDialog` и т.п.) и в `resources/js/components/` ещё нет precedent'а того же типа.
- Изменение структуры brand-токенов (`resources/js/plugins/vuetify.ts` palette config, font-family bindings, theme variants).
- Создание нового aesthetic-направления, не описанного в [BRANDBOOK_v2](../liderra_v8_handoff/docs/BRANDBOOK_v2.md).
- Изменение установленных UX-флоу из ТЗ v8.5 (auth-flow, deal-flow, billing-flow, admin-flow, webhook-flow).
- Cross-cutting refactor, затрагивающий ≥3 компонентов или layout-структуру (`AppLayout`, `AuthLayout`, `AppShell`).
- Добавление новой технологии в стек (новый фреймворк, новая UI-библиотека, новый шрифт, новая иконографическая библиотека).
- Изменение брендовой палитры/шрифтов — даже одного значения (Teal, Ivory, теало-нуар, Inter, JetBrains Mono).
- Изменение 14 OKLCH-статусов воронки или их slug-маппинга на UI.

В этих ситуациях — обязательный стоп + вопрос пользователю, без попытки «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 — стековый фильтр для Frontend Design

Frontend Design предполагает дефолтные стеки (React/Tailwind/shadcn). В Лидерре стек — Vue 3 + Vuetify 3 (CLAUDE.md §2). Адаптация на стек проекта — **обязательная внутренняя часть ответа Frontend Design**, не отдельный шаг и не работа другого плагина.

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

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

### 6.1. Hard-override (этот проект)

`SKILL.md` плагина Frontend Design содержит директивные «NEVER» в отношении ряда брендовых решений Лидерры. Эти рекомендации **полностью игнорируются** — в проекте они зафиксированы как источники истины:

| Артефакт | Что говорит SKILL.md плагина | Что у нас (источник истины) |
|---|---|---|
| Шрифт UI-текста | «NEVER use Inter, Roboto, Arial, system fonts» (overused) | **Inter** — primary UI font ([BRANDBOOK_v2 §4.1](../liderra_v8_handoff/docs/BRANDBOOK_v2.md)) с axis `opsz` 14..32 |
| Шрифт numerics/code | — | **JetBrains Mono** с feature `tnum` (BRANDBOOK_v2 §4.1) |
| Палитра primary | «Avoid timid palettes» (бери жирные, неожиданные) | **Teal `#0F6E56`** (Forest, BRANDBOOK_v2 §3.6) — неоспариваемый |
| Палитра background | «Avoid solid colors, add atmosphere/textures/gradients» | **Ivory `#F6F3EC`** — однородный page bg (Forest) |
| Палитра sidebar | — | **Теало-нуар `#012019`** (Forest sidebar) |
| Aesthetic направление | «Bold maximalism / brutalism / retro-futuristic / маx тематика» | **Restrained / minimal Forest** — спокойный тон, без brutalism/maximalism |
| Иконки | — | **Lucide** (CLAUDE.md §2) |
| Статусы воронки | — | 14 OKLCH-статусов из [db/schema.sql:2076](../db/schema.sql#L2076), мапить через slug |
| Brand направление в целом | «Bold aesthetic direction», «UNFORGETTABLE differentiation» | **Forest v8** как зафиксированная эстетическая платформа — отклонения только через изменение брендбука |

**Правило применения hard-override:** при обработке ответа Frontend Design — даже если плагин использует категоричные «NEVER» / «NEVER use X» / «AVOID Y» — для пунктов из таблицы 6.1 эти запреты **полностью игнорируются**. Брендовый фундамент Forest приоритетнее любой стилевой эстетики плагина. Плагин остаётся ценен на уровне принципов, паттернов, состояний, ритма spacing — то есть в зоне таблицы 6 (универсальное).

При обнаружении нового потенциального 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) |

---

## Правило 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. Реестр внешних плагинов и их роль

| Плагин | Роль | Когда инвокировать |
|---|---|---|
| **ui-ux-pro-max** | резервная UI-библиотека (50+ стилей, 161 палитра, 99 UX-гайдлайнов, 25 типов графиков) | **только** когда Frontend Design выдал «не знаю» / не покрывает узкоспецифический вопрос (типичные случаи: chart-стек, экзотические типографические пары, региональные UX-паттерны). Активируется **внутри** фазы 2 R2 как fallback к FD, не параллельно |
| **claude-md-management** | инфраструктурный плагин для CLAUDE.md edits (`claude-md-improver` + `revise-claude-md`) | **обязательно** при любом изменении CLAUDE.md внутри stack-flow (выполнение CLAUDE.md §5 п.10). Не альтернатива stack'у, а инструмент внутри stack-фазы «реализация» |
| **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**, **keybindings-help**, **fewer-permission-prompts** | инфраструктурные настройки Claude Code | по явному вызову пользователя; не входят в stack-flow |
| **loop**, **schedule** | планировщики автоматизаций | по явному вызову пользователя |
| **claude-api** | плагин для Claude API/SDK работ | не активен в Лидерре (мы не разрабатываем под Claude API) |
| **Boost MCP** + custom guidelines | стек-знания (PHP/Laravel/Vue/Vuetify/Pest) и БД-инструменты | **автоматически** на работе с `.vue`/`.php`/`.sql` файлами; **слой ниже** stack'а — служебный, не конкурирует за gate |

### 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'а

**Категорически запрещено** инвокировать любой не-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-зависимые) — частично ослаблены до открытия нового чата.

---

## Правило 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) |

### 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/архитектуры.

---

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

> **Любая задача → Правило 0 (gate, stack-головной) → Правило 1 (классификация по типу) → Правило 9 (решение, ≤2 итерации) → Правило 13 (decision matrix по уверенности) → Правило 2 (фаза UI-фичи) → исполнение по Правилам 3, 4, 6 → завершение по Правилу 7 → ревью по Правилу 5. Источники истины — Правило 11. Паттерны решений — Правило 12. Координация с не-stack плагинами — Правило 10. Тай-брейкеры — Правило 8.**

---

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

- **Полнота:** каждая задача попадает в одну ветку Правила 1, каждая фаза имеет одного владельца (Правило 2), каждый артефакт ревью — один аспект (Правило 5), каждый тип закрытия — один gate (Правило 7), каждое дизайн-решение — один паттерн (Правило 12), каждая комбинация Auto+§12+R0.6 — одна строка matrix'а (Правило 13).
- **Головенство stack'а (v1.2 принцип-аксиома):** stack — головной при решении любой задачи. Внешние плагины — инструменты, инвокируемые внутри stack-flow (Правило 10). Иерархия источников UI — закон, не гайдлайн (Правило 11).
- **Непротиворечивость:** все найденные конфликты закрыты:
  - **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).
- **Действенность:** решение — за 3 вопроса (Правило 9) + matrix Правила 13; если не сработало — явный fallback на пользователя (0.6).
- **Симметрия:** оба плагина stack'а имеют равные права на закрытие задач в своём домене (7), на ревью в своём аспекте (5), на отмену через live-команду (0.4.B). **Асимметрия** введена только между stack'ом и не-stack плагинами: stack головной, остальные — инструменты (R10).

---

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

- **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 встроенных патчей.