portal/docs/superpowers/plans/2026-05-09-project-audit-plan.md

Plan: Подробный аудит проекта Лидерра — 2026-05-09

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: Провести подробный аудит проекта Лидерра (docs + db + Laravel + Vue + handoff + конфиги) и сдать сводный markdown-отчёт docs/audit_2026-05-09.md с приоритетами P0/P1/P2 + O-perf/O-refactor/O-stack + секцией «Отложенное».

Architecture: Гибридный аудит из 4 этапов: (1) параллельный sweep 15 CLI-тулами в .tmp/audit/stage1_*.txt; (2) 6 параллельных субагентов (D1 narrative / D2 db / D3 handoff / D4 backend / D5 frontend / D6 configs) с шаблонными выходами stage2_<domain>.md; (3) синхронная консолидация в основном потоке (дедуп + переклассификация); (4) self-review через verification-before-completion skill + независимый code review через requesting-code-review skill. Early-stop предохранитель: если любой субагент возвращает >10 P0-находок — аудит останавливается, заказчик принимает решение.

Tech Stack: Bash (через PowerShell 5.1), npm scripts (lint:md, spell, links, a11y, format:sql:check, lint:sql), composer scripts из app/, Pest, Larastan, vue-tsc, ESLint, Vitest, Laravel Boost MCP, Frontend Design plugin (НЕ призывается, см. spec §12.2), superpowers:dispatching-parallel-agents для параллелизации, superpowers:verification-before-completion + superpowers:requesting-code-review для финала.

Spec: docs/superpowers/specs/2026-05-09-project-audit-design.md v1.1, commit b034301.

---

File Structure

Файл / каталог	Создаётся / Modifies	Ответственность
.tmp/audit/	Создаётся	Каталог для всех промежуточных артефактов аудита (в .gitignore, не коммитится)
.tmp/audit/stage1_*.txt (×15)	Создаётся	Raw output 15 CLI-тулов этапа 1, по одному файлу на тул
.tmp/audit/stage1_summary.md	Создаётся	Компактная сводка stage1 для подачи на вход субагентам этапа 2 (10-20 строк на тул)
.tmp/audit/stage2_<domain>.md (×6)	Создаётся	Отчёты 6 субагентов этапа 2 в шаблоне P0/P1/P2 + O-perf/O-refactor/O-stack + Notes
docs/audit_2026-05-09.md	Создаётся, коммитится	Финальный сводный отчёт по структуре spec §9

Out-of-scope для правок в этом плане: правки исходников проекта (находки только фиксируются в отчёт; реализация — отдельный flow по решению заказчика).

---

Phase 0: Setup

Task 0: Подготовка каталога и проверка предусловий

Files:

• Create: .tmp/audit/ (директория)

• Verify: .gitignore содержит .tmp/

• Step 1: Создать каталог .tmp/audit/

mkdir -p .tmp/audit

• Step 2: Проверить, что .tmp/ в .gitignore

grep -E "^\.tmp/" .gitignore

Expected: одна строка .tmp/ в выводе. Если нет — STOP, добавить .tmp/ в .gitignore руками и закоммитить отдельно.

• Step 3: Зафиксировать стартовые метрики

git rev-parse HEAD > .tmp/audit/stage0_head.txt
git status --short > .tmp/audit/stage0_status.txt
date -u +"%Y-%m-%dT%H:%M:%SZ" > .tmp/audit/stage0_started.txt

Expected: 3 файла в .tmp/audit/, HEAD совпадает с актуальным main, status пустой (clean tree).

• Step 4: Прочитать spec один раз, держать ссылку в контексте

Read: docs/superpowers/specs/2026-05-09-project-audit-design.md

Expected: spec v1.1, 14+ секций, §6 содержит таблицу 6 субагентов, §7 чеклисты, §12 inventory плагинов, §15 R-карта.

---

Phase 1: Tool Sweep (этап 1 spec'а)

Task 1: Параллельный прогон 15 тулов

Files:

• Create: .tmp/audit/stage1_*.txt (×15)

15 тулов запускаются параллельно через несколько Bash-вызовов в одном сообщении. Все exit-коды захватываются (через ; echo "EXIT:$?" в конце), но не блокируют прогон — даже если тул падает, его вывод сохраняется и анализируется субагентом.

• Step 1: Группа A — Markdown / docs (4 тула, через npm scripts)

Параллельно (один tool-call message с 4 Bash):

# A1: markdownlint
npm run lint:md > .tmp/audit/stage1_markdownlint.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_markdownlint.txt

# A2: cspell
npm run spell > .tmp/audit/stage1_cspell.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_cspell.txt

# A3: lychee (links)
npm run links > .tmp/audit/stage1_lychee.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_lychee.txt

# A4: pa11y
npm run a11y > .tmp/audit/stage1_pa11y.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_pa11y.txt

Expected: 4 файла в .tmp/audit/, каждый заканчивается строкой EXIT:N (где N — exit-код). Прогон ~30-90 сек на каждый тул.

• Step 2: Группа B — БД (3 тула)

Параллельно:

# B1: grep-патрули по schema.sql — дубли CREATE TABLE
grep -nE "^CREATE TABLE\s+\w+" db/schema.sql | sort -k2 | uniq -c -f1 | sort -rn > .tmp/audit/stage1_grep_create_table.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_grep_create_table.txt

# B2: grep-патрули — orphan-FK (REFERENCES без матчующего CREATE TABLE)
grep -oE "REFERENCES\s+(\w+)" db/schema.sql | sort -u | awk '{print $2}' > .tmp/audit/stage1_grep_fk_targets.txt
grep -oE "^CREATE TABLE\s+(\w+)" db/schema.sql | awk '{print $3}' | sort -u > .tmp/audit/stage1_grep_table_names.txt
comm -23 .tmp/audit/stage1_grep_fk_targets.txt .tmp/audit/stage1_grep_table_names.txt > .tmp/audit/stage1_grep_orphan_fk.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_grep_orphan_fk.txt

# B3: squawk
npm run lint:sql > .tmp/audit/stage1_squawk.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_squawk.txt

# B4: pgFormatter dry-run
npm run format:sql:check > .tmp/audit/stage1_pgformatter.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_pgformatter.txt

Expected: 5 файлов в .tmp/audit/ (B1 1 файл, B2 3 файла финальный включает дельту, B3 1 файл, B4 1 файл). stage1_grep_orphan_fk.txt должен быть пустым или содержать только legit cross-refs (например, partition tables).

• Step 3: Группа C — Backend Laravel (4 тула, в app/)

Параллельно:

# C1: Pest (полный прогон)
cd app && composer test > ../.tmp/audit/stage1_pest.txt 2>&1; echo "EXIT:$?" >> ../.tmp/audit/stage1_pest.txt; cd ..

# C2: Larastan
cd app && composer stan > ../.tmp/audit/stage1_larastan.txt 2>&1; echo "EXIT:$?" >> ../.tmp/audit/stage1_larastan.txt; cd ..

# C3: composer outdated --direct
cd app && composer outdated --direct --format=text > ../.tmp/audit/stage1_composer_outdated.txt 2>&1; echo "EXIT:$?" >> ../.tmp/audit/stage1_composer_outdated.txt; cd ..

# C4: composer audit
cd app && composer audit --format=plain > ../.tmp/audit/stage1_composer_audit.txt 2>&1; echo "EXIT:$?" >> ../.tmp/audit/stage1_composer_audit.txt; cd ..

Expected: 4 файла. Pest должен показать 416/416 PASS (см. memory project_state — снимок 09.05.2026). Larastan — 0 errors above baseline. composer outdated/audit — справочно для O-stack.

• Step 4: Группа D — Frontend Vue (3 тула, в app/)

Параллельно:

# D1: vue-tsc
cd app && npm run type-check > ../.tmp/audit/stage1_vue_tsc.txt 2>&1; echo "EXIT:$?" >> ../.tmp/audit/stage1_vue_tsc.txt; cd ..

# D2: ESLint vue
cd app && npm run lint:vue > ../.tmp/audit/stage1_eslint_vue.txt 2>&1; echo "EXIT:$?" >> ../.tmp/audit/stage1_eslint_vue.txt; cd ..

# D3: Vitest
cd app && npm run test:vue > ../.tmp/audit/stage1_vitest.txt 2>&1; echo "EXIT:$?" >> ../.tmp/audit/stage1_vitest.txt; cd ..

Expected: 3 файла. Vitest должен показать 416/416 PASS, vue-tsc 0 errors, ESLint 0 errors (см. memory).

• Step 5: Группа E — npm outdated (1 тул, в корне)

npm outdated --json > .tmp/audit/stage1_npm_outdated.txt 2>&1; echo "EXIT:$?" >> .tmp/audit/stage1_npm_outdated.txt

Expected: 1 файл, JSON с пакетами или пустой объект. Для O-stack.

• Step 6: Проверить, что все 15 файлов созданы

ls -la .tmp/audit/stage1_*.txt | wc -l

Expected: ≥15. Если меньше — STOP, разобраться с группой, не создавшей файл.

• Step 7: Создать stage1_summary.md (компактная сводка для субагентов)

Read all 15 stage1_*.txt files и сгенерировать .tmp/audit/stage1_summary.md по шаблону:

# Stage 1 Summary — 2026-05-09
## A. Markdown / docs
### A1 markdownlint (`stage1_markdownlint.txt`, EXIT:N)
- Total errors: N
- Top files: ...
### A2 cspell (...)
...

## B. БД
### B1 grep CREATE TABLE
- Total tables: N (from grep count)
- Duplicates: N (uniq count > 1)
### B2 orphan-FK (`stage1_grep_orphan_fk.txt`)
- Содержимое файла дословно (если пустой — "0 orphan-FK")
### B3 squawk (...), B4 pgFormatter (...)

## C. Backend
### C1 Pest: X/Y PASS / N FAIL
### C2 Larastan: N errors / N above baseline
### C3 composer outdated: N direct deps outdated
### C4 composer audit: N CVEs

## D. Frontend
### D1 vue-tsc: N errors
### D2 ESLint: N errors / N warnings
### D3 Vitest: X/Y PASS / N FAIL

## E. Корень
### E1 npm outdated: N deps outdated

Это компактный snapshot ~50-100 строк, который раздаётся 6 субагентам как контекст.

• Step 8: Commit checkpoint (без stage1 raw)

stage1_* НЕ коммитятся (.tmp/ в .gitignore). Просто mark progress в TodoWrite.

---

Phase 2: 6 параллельных субагентов

Task 2: Подготовка R-rules excerpt для субагентов

Files:

• Create: .tmp/audit/r_rules_excerpt.md

• Step 1: Извлечь priority chain CLAUDE.md §1 + R-правила Plugin_stack_rules_v1

Read CLAUDE.md §1 (priority chain) и Plugin_stack_rules_v1 v1.3 (только R0.1, R6, R6.1, R10, R11, R13). Скомпилировать в .tmp/audit/r_rules_excerpt.md ~80-120 строк:

# R-Rules Excerpt for Subagents

## Priority Chain (CLAUDE.md §1)
0. Pravila §12 — Superpowers hard rule
1. Pravila
2. CLAUDE.md
3. Plugin_stack_rules_v1
4. .claude/settings.json
5. memory/*.md
6. прочие плагины

При конфликте — верхний уровень побеждает.

## R0.1 — scope «головенства» Plugin_stack_rules_v1
Stack головной только над уровнями 4-6 (settings.json, memory, прочие плагины),
не над 0-2 (Pravila §12, Pravila, CLAUDE.md).

## R6 — стек-фильтр Vue+Vuetify
[краткая выдержка из Plugin_stack_rules_v1]

## R6.1 — hard-override Forest
[краткая выдержка]

## R10 — внешние плагины как инструменты
[реестр + правило «только по явному /команде»]

## R11 — иерархия 6 источников истины UI/UX
Brandbook → ТЗ+schema → FD → Boost guidelines → ui-ux-pro-max → Vue/Vuetify docs

## R13 — decision matrix (для аудита: §12 hard rule applies)
[краткая выдержка]

## Pravila §13.9 — hard-link на R10
Байпас stack-gate без явной /команды или R0.4.A исключения = нарушение §13.

Expected: 1 файл, готовый к раздаче 6 субагентам.

Task 3: Параллельный диспатч 6 субагентов через dispatching-parallel-agents skill

Files:

• Create: .tmp/audit/stage2_<domain>.md (×6: narrative, db, handoff, backend, frontend, configs)

• Step 1: Активировать skill superpowers:dispatching-parallel-agents

Read skill content. Skill подтвердит шаблон диспатча и проверки независимости задач.

• Step 2: Подготовить 6 промптов субагентам

Каждому — единый шаблон с 4 секциями:

ROLE: Subagent D{N} — {domain}
ZONE: {точные пути из spec §6 для этого агента}

INPUTS:
- spec: docs/superpowers/specs/2026-05-09-project-audit-design.md (читать ОБЯЗАТЕЛЬНО §1, §3, §6, §7)
- stage1 summary: .tmp/audit/stage1_summary.md (твой блок: {A/B/C/D/E относится к этому домену})
- stage1 raw для твоей зоны: .tmp/audit/stage1_{соответствующие файлы}.txt
- R-rules: .tmp/audit/r_rules_excerpt.md (читать ВСЁ для R-CHECKS)

CHECKLIST (см. spec §7):
- общий чеклист DEFECT (P) + IMPROVEMENT (O) + R-CHECKS
- доменные таргеты для D{N} (см. §6 и §7 spec'а)

OUTPUT:
- Записать stage2_{domain}.md в .tmp/audit/ по шаблону spec §6 (P0/P1/P2 + O-perf/O-refactor/O-stack + Notes)
- Каждая находка содержит: файл:строка, цитата, сравнение/предложение, усилие S/M/L
- Если P0 > 10 — добавить в Notes пометку "EARLY-STOP CANDIDATE: P0 count = N"

CONSTRAINTS:
- НЕ призывать FD plugin / simplify / security-review / review / init / claude-md-management
  (R10: только по явному /команде заказчика, у тебя её нет)
- НЕ делать правок в исходниках проекта — только записать в stage2_{domain}.md
- НЕ создавать новых файлов вне .tmp/audit/
- При нахождении UI-нестыковки → фиксировать как находку, не делегировать FD

DONE WHEN:
- stage2_{domain}.md существует, валидный markdown
- Каждая находка имеет file:line + цитату + сравнение/предложение
- 0 «TBD» в выходе

Заменить {N} / {domain} / {...zone} точными значениями из spec §6 для каждого из 6 субагентов.

• Step 3: Дисспатчить 6 субагентов одним сообщением (parallel)

Через Agent tool, все 6 в одном tool-call message:

Agent D1: subagent_type=Explore, prompt=<заполненный шаблон D1 narrative>
Agent D2: subagent_type=Explore, prompt=<заполненный шаблон D2 db>
Agent D3: subagent_type=Explore, prompt=<заполненный шаблон D3 handoff>
Agent D4: subagent_type=Explore, prompt=<заполненный шаблон D4 backend>
Agent D5: subagent_type=Explore, prompt=<заполненный шаблон D5 frontend>
Agent D6: subagent_type=Explore, prompt=<заполненный шаблон D6 configs>

subagent_type=Explore — read-only агент с Glob/Grep/Read/WebFetch (без Edit/Write/Bash, кроме записи stage2_*.md). Если требуется Bash для повторного grep по живой схеме — заменить на general-purpose.

Expected wall-clock: 30-60 мин (по spec §11).

• Step 4: Получить 6 stage2_<domain>.md, проверить наличие

ls -la .tmp/audit/stage2_*.md | wc -l

Expected: ровно 6. Если меньше — STOP, разобраться какой агент не вернул файл, перезапустить только его.

Task 4: Early-stop check (предохранитель)

Files:

• Read: .tmp/audit/stage2_*.md

• Step 1: Подсчёт P0-находок в каждом stage2_<domain>.md

for f in .tmp/audit/stage2_*.md; do
  domain=$(basename "$f" .md | sed 's/stage2_//')
  p0_count=$(grep -cE "^### P0-" "$f" || echo 0)
  echo "$domain: P0=$p0_count"
done > .tmp/audit/stage2_p0_counts.txt
cat .tmp/audit/stage2_p0_counts.txt

Expected: 6 строк вида narrative: P0=N. Сохранить вывод в файл.

• Step 2: Условный early-stop

Если ЛЮБОЙ домен показывает P0 > 10:

1. STOP processing.
2. Показать заказчику:
   • Имя домена и точное число P0.
   • Список из топ-10 P0-заголовков из этого stage2_<domain>.md (через grep "^### P0-" .tmp/audit/stage2_<domain>.md | head -10).
3. Спросить через AskUserQuestion:
   • «А — продолжаем остальные 5 субагентов до конца, фиксы потом»
   • «Б — фиксим этот блок сначала, потом доделаем»
   • «В — отбой, отчёт не нужен»

Только после ответа продолжать с Task 5 или прерываться.

Если все домены P0 ≤ 10:

• Записать EARLY_STOP=NO в .tmp/audit/stage2_p0_counts.txt
• Продолжать с Task 5.

---

Phase 3: Консолидация (этап 3 spec'а)

Task 5: Сбор всех находок в единый поток

Files:

• Create: .tmp/audit/stage3_aggregated.md

• Step 1: Конкатенация 6 stage2 файлов с маркерами домена

{
  for f in .tmp/audit/stage2_*.md; do
    domain=$(basename "$f" .md | sed 's/stage2_//')
    echo "<!-- DOMAIN: $domain -->"
    cat "$f"
    echo ""
  done
} > .tmp/audit/stage3_aggregated.md

Expected: 1 файл со всеми находками, между блоками — комментарий с именем домена для последующей атрибуции.

Task 6: Дедупликация по (file, line, category)

Files:

• Read: .tmp/audit/stage3_aggregated.md

• Create: .tmp/audit/stage3_dedup_map.md

• Step 1: Парсинг находок и поиск дубликатов

Прочитать stage3_aggregated.md Read tool'ом. Для каждой находки извлечь ключ (file, line, category) (где category — из шапки ### P0-XX / ### O-perf-XX / etc).

Если две находки имеют одинаковый ключ:

• Объединить описания (взять более полное).
• В stage3_dedup_map.md записать: <key> → <merged description from domains [A, B]>.

Если ключи уникальны — оставить как есть.

Expected: 1 файл-карта со списком дубликатов и решений по ним. Если дубликатов 0 — файл содержит строку 0 duplicates found.

Task 7: Переклассификация приоритетов

Files:

• Read: .tmp/audit/stage3_aggregated.md + .tmp/audit/stage3_dedup_map.md

• Create: .tmp/audit/stage3_reclassified.md

• Step 1: Применить критерии spec §3 к каждой находке

Критерии:

• P0: orphan-FK, противоречия ТЗ↔schema, дубли CREATE TABLE, утечки секретов, RLS-провалы на tenant-таблицах, stack-нарушения (Pravila §13.9 hard-link на R10).
• P1: устаревшие метрики в шапке, битые внутрипроектные ссылки, дубли правил, расхождение версий между источниками истины.
• P2: орфография, формат, линт без семантики.
• O-perf / O-refactor / O-stack: по spec §3.

Если субагент промаркировал, например, метрику в шапке как P0 — переклассифицировать в P1.

Записать результат в stage3_reclassified.md с пометкой <!-- reclassified from <old> to <new> --> для каждой переклассифицированной.

Task 8: Генерация финального отчёта docs/audit_2026-05-09.md

Files:

• Create: docs/audit_2026-05-09.md

• Step 1: Собрать раздел 1 «Резюме»

5-10 строк по форме:

## 1. Резюме

Аудит проекта Лидерра на 09.05.2026 (commit <HEAD>). Охват: docs + db + Laravel + Vue + handoff + конфиги.

Найдено: P0=N, P1=N, P2=N, O-perf=N, O-refactor=N, O-stack=N, Отложенное=N (из реестра + workaround-маркеров).

Главные блокеры (P0): <2-3 строки самого критичного>.
Главные возможности (O): <2-3 строки самого полезного>.

Числа берутся из stage3_reclassified.md.

• Step 2: Собрать разделы 2-4 «Дефекты P0/P1/P2»

Из stage3_reclassified.md отфильтровать P0/P1/P2 находки и записать по шаблону spec §2 (точно):

## 2. Дефекты P0
### P0-01 — <имя>
- Файл: <path>:<line>
- Категория: <фактическая нестыковка | дубль | устаревшая версия | битая ссылка | stack-нарушение>
- Цитата: «...»
- Сравнение: «X в A» vs «Y в B»
- Предлагаемая правка: <конкретно>
- Усилие: S/M/L

Expected: разделы 2-4 заполнены, нумерация P0-XX/P1-XX/P2-XX последовательная.

• Step 3: Собрать раздел 5 «Возможности улучшения»

Подразделы 5.1 O-perf, 5.2 O-refactor, 5.3 O-stack по шаблону spec §6:

### 5.1 Оптимизация (O-perf)
#### O-perf-01 — <имя>
- Файл: <path>:<line>
- Категория: N+1 / missing index / bundle size / RLS predicate / ...
- Текущее поведение: <описание>
- Предлагаемое улучшение: <конкретно>
- Профит: <качественно>
- Риск: low/medium/high
- Усилие: S/M/L

• Step 4: Собрать раздел 6 «Отложенное» (НЕ дефекты)

Прочитать docs/Открытые_вопросы_v8_3.md и собрать активные вопросы по префиксам (Биз-, CTO-, Ю-, Диз-, DO-, OPEN-). Также из CLAUDE.md/narrative выгрести явные workaround until X маркеры:

• Б-1 (реквизиты юр. лица)
• pg_partman → Artisan-cron
• Histoire 1.0-beta.1 ↔ Vite 8 совместимость

Expected: 6.1 Открытые вопросы (список цитатами + ссылками на реестр), 6.2 Workaround-ы (3+ пункта).

• Step 5: Собрать раздел 7 «Метрики проекта на момент аудита»

Перепрогнать факт-метрики:

# Schema
grep -cE "^CREATE TABLE\s+\w+" db/schema.sql
grep -cE "^CREATE TABLE\s+\w+_\d{4}_\d{2}" db/schema.sql  # партиции
grep -cE "^CREATE INDEX|^CREATE UNIQUE INDEX" db/schema.sql
grep -cE "ENABLE ROW LEVEL SECURITY|CREATE POLICY" db/schema.sql
grep -cE "^CREATE FUNCTION|^CREATE OR REPLACE FUNCTION" db/schema.sql
grep -cE "^CREATE TRIGGER" db/schema.sql

# Tests (последний прогон)
grep -E "Tests:" .tmp/audit/stage1_pest.txt | tail -1
grep -E "Test Files|Tests" .tmp/audit/stage1_vitest.txt | tail -2

Сравнить с шапками CLAUDE.md (заявлено 56/12/95/37/5/13 и Pest 416/416 + Vitest 416/416). Расхождения — таблицей.

• Step 6: Раздел 8 «Что НЕ покрыто аудитом» и Приложение A

Перечислить:

• web/v8/*.html (старые концепты)
• лендинг/ (⏸ Б-1)
• node_modules/, vendor/
• Любые обнаруженные blind spots, на которые тулы не отработали.

Приложение A — список файлов в .tmp/audit/stage1_*.txt с их размерами и exit-кодами:

for f in .tmp/audit/stage1_*.txt; do
  exit_line=$(tail -1 "$f")
  size=$(wc -l < "$f")
  echo "- $(basename "$f"): $size lines, $exit_line"
done

• Step 7: Шапка отчёта и сводка

# Аудит проекта Лидерра — 2026-05-09
**Версия:** 1.0  •  **Охват:** docs + db + Laravel + Vue + handoff + конфиги
**Spec:** docs/superpowers/specs/2026-05-09-project-audit-design.md v1.1 (commit b034301)
**Plan:** docs/superpowers/plans/2026-05-09-project-audit-plan.md
**Сводка:** P0=N, P1=N, P2=N, O-perf=N, O-refactor=N, O-stack=N, Отложенное=N

Заполнить N из stage3_reclassified.

---

Phase 4: Self-Review + Code Review + Commit (этап 4 spec'а)

Task 9: Self-review через superpowers:verification-before-completion skill

Files:

• Read: docs/audit_2026-05-09.md

• Step 1: Активировать skill superpowers:verification-before-completion

Read skill content. Skill требует evidence перед claim'ом «готово».

• Step 2: Verify все file:line ссылки в отчёте существуют

Извлечь все <path>:<line> из отчёта regex'ом, для каждого:

# Пример проверки
test -f "docs/CRM_bp-gr_Инструкция_v8_5.md" && echo "OK: docs/CRM_bp-gr_Инструкция_v8_5.md" || echo "MISSING: docs/CRM_bp-gr_Инструкция_v8_5.md"

Expected: 100% ссылок существуют. Если хоть одна MISSING — STOP, поправить отчёт.

• Step 3: Verify метрики в §7 отчёта совпадают с фактом

Перепрогнать команды из Task 8 Step 5 ещё раз, сравнить с записанным в отчёт.

Expected: 100% совпадение. При расхождении — поправить отчёт (факт побеждает).

• Step 4: Verify 0 placeholders

grep -nE "TBD|TODO|FIXME|XXX|placeholder|<имя>|<path>|<line>|<категория>|<описание>|<конкретно>" docs/audit_2026-05-09.md

Expected: пустой вывод (только legitimate упоминания «0 TBD» в чеклистах НЕ должны попадать). Если есть — поправить.

• Step 5: Verify 0 цитат без атрибуции

Найти все Цитата: «...» в отчёте и проверить, что у каждой выше есть Файл: <path>:<line>.

awk '/^- Цитата:/ {print NR": цитата без файла"; next} /^- Файл:/ {has_file=1} /^### / {has_file=0}' docs/audit_2026-05-09.md

Expected: пустой вывод.

• Step 6: Verify 0 R-нарушений в самом отчёте (мета-проверка)

Проверить, что отчёт сам не нарушает Plugin_stack_rules_v1:

# Не призываем FD plugin для не-UI задач
grep -nE "FD plugin|Frontend Design|frontend-design plugin" docs/audit_2026-05-09.md | grep -v "НЕ призывается\|НЕ применяется"
# Не предлагаем simplify/security-review/review/init без явного /команды
grep -nE "simplify|security-review|/review|/init" docs/audit_2026-05-09.md | grep -v "НЕ призывается\|R10\|spec"

Expected: пусто (или только legitimate упоминания в контексте «не применяется»).

Task 10: Code review отчёта через superpowers:requesting-code-review skill

Files:

• Read: docs/audit_2026-05-09.md

• Step 1: Активировать skill superpowers:requesting-code-review

Read skill content. Skill подтвердит шаблон диспатча code review subagent'а.

• Step 2: Дисспатчить независимого reviewer-субагента

Через Agent tool, subagent_type=Explore:

ROLE: Independent reviewer of project audit report.

CONTEXT:
- Spec: docs/superpowers/specs/2026-05-09-project-audit-design.md (v1.1)
- Plan: docs/superpowers/plans/2026-05-09-project-audit-plan.md
- Report (твой объект review): docs/audit_2026-05-09.md
- R-rules excerpt: .tmp/audit/r_rules_excerpt.md

CHECK:
1. Внутренняя консистентность: §1 резюме ↔ §2-5 находки ↔ §7 метрики (числа сходятся).
2. Классификация: каждый P0/P1/P2 соответствует критериям spec §3.
3. Шаблон: каждая находка имеет файл:строку + цитату + сравнение/предложение + усилие.
4. R-консистентность: отчёт не призывает FD plugin / simplify / security-review / review / init без явного /команды (R10);
   не предписывает иерархию источников UI/UX вне R11; не байпасит §12 hard rule.
5. 0 placeholders / 0 цитат без атрибуции / 0 битых file:line ссылок.

OUTPUT:
- Записать review в .tmp/audit/stage4_code_review.md
- Формат: список замечаний по приоритетам Critical / Major / Minor / Nit.
- Вердикт: PASS / FAIL.

DO NOT MAKE EDITS to docs/audit_2026-05-09.md. Только review.

• Step 3: Прочитать review, применить замечания

Read .tmp/audit/stage4_code_review.md.

• Если PASS и 0 Critical / 0 Major — продолжать с Task 11.
• Если FAIL или есть Critical / Major — поправить docs/audit_2026-05-09.md по замечаниям. Затем перезапустить Task 9 (self-review) и Task 10 (повторный code review).
• Если есть только Minor / Nit — пометить в TodoWrite, поправить, продолжать.

Task 11: Финальный коммит

Files:

• Commit: docs/audit_2026-05-09.md

• Step 1: Verify clean stage перед коммитом

git status --short

Expected: только один файл ?? docs/audit_2026-05-09.md или M docs/audit_2026-05-09.md. Если ещё что-то — разобраться.

• Step 2: Stage и commit

git add docs/audit_2026-05-09.md
git commit -m "$(cat <<'EOF'
docs(audit): сводный отчёт аудита проекта на 2026-05-09 — P-дефекты + O-возможности

По spec v1.1 (b034301) и plan'у 2026-05-09-project-audit-plan.md:
- 4 этапа: 15 CLI-тулов parallel + 6 субагентов parallel + консолидация + self-review.
- Покрытие: docs (16 .md + Pravila/Plugin_stack_rules_v1/Tooling/CLAUDE.md/README) + db (4 файла) + handoff + Laravel + Vue + 10 конфигов корня.
- Категории: P0/P1/P2 + O-perf/O-refactor/O-stack + Отложенное (открытые вопросы + workaround-ы).
- R-CHECKS под Plugin_stack_rules_v1 v1.3 включены в чеклист и DoD.

Сводка: P0=N, P1=N, P2=N, O-perf=N, O-refactor=N, O-stack=N, Отложенное=N.

Сам отчёт — диагностический. Реализация правок — отдельный flow по решению заказчика.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
EOF
)"

Заменить N на актуальные числа из отчёта в commit message.

• Step 3: Verify commit

git log -1 --stat

Expected: 1 файл в коммите (docs/audit_2026-05-09.md), pre-commit hooks (gitleaks, markdownlint, cspell) PASS.

• Step 4: Update memory project_state.md

Через Edit tool обновить запись project_state.md в memory: добавить факт «09.05.2026 закоммичен сводный отчёт аудита (commit <hash>) — P0=N, P1=N, P2=N, O-perf=N, O-refactor=N, O-stack=N. Реализация правок — отдельные flow».

• Step 5: Cleanup .tmp/audit/

# Не удалять — может пригодиться для повторного просмотра raw output
echo "Stage 1-4 артефакты в .tmp/audit/ — НЕ коммитятся (.gitignore), НЕ удаляются. Удалить вручную при следующей чистке .tmp/."

---

DoD (соответствие spec §10)

• Этап 1 завершён — 15 тулов прогнаны, raw output в .tmp/audit/stage1_*.txt. (Tasks 1)
• Этап 2 завершён — 6 stage2_<domain>.md собраны. (Tasks 3-4)
• Этап 3 завершён — docs/audit_2026-05-09.md сгенерирован, дедуп пройден, приоритеты выровнены. (Tasks 5-8)
• Self-review (verification-before-completion) пройден. (Task 9)
• Code review через requesting-code-review skill — PASS. (Task 10)
• Коммит финального отчёта. (Task 11)

Не входит в DoD: реализация правок по находкам отчёта (отдельный flow по решению заказчика).

---

Бюджет (соответствие spec §11)

Этап	Wall-clock
Phase 0 setup	2-3 мин
Phase 1 sweep тулами (Task 1)	10-15 мин
Phase 2 субагенты (Tasks 2-4)	30-60 мин
Phase 3 консолидация (Tasks 5-8)	15-30 мин
Phase 4 self-review + code review + commit (Tasks 9-11)	10-20 мин
Итого	~1.5-2 часа

---

Early-Stop Decision Tree

Phase 2 subagents return
        ↓
For each stage2_<domain>.md: count P0
        ↓
   ┌─ Any P0 > 10? ─┐
   │                │
  YES              NO
   │                │
   ↓                ↓
STOP            Continue
Show user       Phase 3
top-10 P0       (consolidation)
   │
   ↓
AskUserQuestion:
А) continue rest 5 subagents
Б) fix this block first
В) abort
   │
   ↓
Apply user choice

Early-stop срабатывает один раз на subagent с >10 P0. После решения заказчика — продолжать или прерывать аудит.

---

Risks (соответствие spec §13)

• Риск: Какой-либо тул в Phase 1 падает (например, Pest при сломанной БД). Митигация — не блокировать прогон, exit-код фиксируется в файл, субагенту скармливаются raw outputs.
• Риск: Субагент возвращает stage2_<domain>.md с 0 находок (false-negative). Митигация — code review на Phase 4 проверяет полноту.
• Риск: Дедуп Phase 3 объединяет разные находки с одинаковым (file, line) ошибочно. Митигация — stage3_dedup_map.md фиксирует все слияния, code review проверяет.
• Риск (предохранитель): Early-stop на одном из 6 субагентов. Это не риск, а фича — позволяет заказчику решить рано, до затрат на оставшиеся 5.