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 v1.78+ — оперативная карта; §5 п.5 ссылается на этот документ как замену прежнего запрета
• docs/Pravila_raboty_Claude_v1_1.md v1.5+ — §13 «Frontend Design plugin — paired stack» ссылается сюда
• docs/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.
• Изменение установленных 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) с 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, мапить через 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: нарушение 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 встроенных патчей.