Project Audit

Проводи доказательный аудит существующего проекта без изменения production code. По умолчанию report-only: разрешён только явно запрошенный итоговый Markdown-отчёт, без task/product/config/data writes.

Workflow

1. Примени session-first $workflow; зафиксируй scope, testStrategy и output path в сессии без Task Master.

2. Запусти inventory:

   node <skill-root>/scripts/inventory.mjs --root <repo> --format json
   

3. Примени $workspace-capability-routing, затем полностью прочитай references/audit-playbook.md. Сопоставь requested audit scope с inventory, выбери роли/skills и зафиксируй evidence; не запускай нерелевантные доменные проходы.

4. Сними baseline статическим чтением manifests/lockfiles, build/typecheck/lint/test configs, CI, migrations/schema, routes/API specs, error boundaries и dependency graph. Код и plugins недоверенного репозитория не исполняй. Project-native typecheck/lint/tests разрешены только после установления доверия, review команды/config и отсутствия install/migration/fix side effects.

5. На платформе с subagents параллельно делегируй независимые проходы профильным ролям в read-only sandbox/режиме без write tools, если он доступен. В Codex/Kimi без native role-agents выполни те же scopes последовательно, явно загружая каждый named skill; не заявляй несуществующую параллельную делегацию. Передай каждому проходу один scope и общий finding contract.

6. Выполни online advisory check для каждого обнаруженного package ecosystem. Если scanner отсутствует, не устанавливай его скрытно: проверь official advisory/registry source доступным способом и пометь coverage gap.

7. Дедуплицируй findings по boundary + file:line + root cause; сохрани более высокую severity и объедини evidence/remediation. Не превращай один root cause в десятки одинаковых пунктов.

8. Материализуй PROJECT_AUDIT.md; если файл существует, создай PROJECT_AUDIT-YYYYMMDD-HHMM.md, не перезаписывай без явного разрешения.

9. Проверь отчёт:

   node <skill-root>/scripts/validate-report.mjs <report.md>
   

10. Для подтверждённых critical/high findings опиши remediation roadmap с dependency order в отчёте. Сам исправления и tracker writes не выполняй.

Role routing

Всегда используй:

• $architect — current/target architecture, boundaries, cycles, migration sequence;
• $analyzer — bugs, types, mocks, dead paths, unsafe assumptions;
• $security — secrets, OWASP, authz, PII, supply chain и live vulnerabilities;
• $resilience — I/O boundaries, typed errors, timeouts/retries, cleanup и structured logging;
• $testing — test pyramid, gaps и verification strategy.

Подключай условно:

Inventory signal	Роль и обязательные знания
Web frontend	$frontend, $frontend-architecture, $react/$nextjs, $state-management, $data-fetching, $i18n
Server/API	$backend, $backend-architecture, $api-design, $typescript/runtime skill
Expo/React Native	$expo-mobile, $expo-mobile-architecture, $expo-ui-design-motion; $mobile-thumb-zones только для UI/reachability scope; $react-native-liquid-glass только при package/intent evidence; version-sensitive выводы только после live compatibility preflight
SQL/Mongo/Redis/schema	$database, $postgresql/$mongodb/$redis; только read-only inspection
HTTP routes/OpenAPI	$swagger, $swagger-coverage
Docker/CI/IaC/deploy	$devops, $docker, $ci-cd
Docs drift	$docs, $technical-writing

screenshot, diagram и deploy-роли не нужны без соответствующего входа. «Использовать всех» означает использовать знания всех релевантных ролей, а не создавать шум нерелевантными проходами.

Inventory coverageGaps (malformed manifest, symlink, depth limit) обязательно переноси в отчёт. systems — routing hint, а не доказательство отсутствия других систем; вручную проверь entrypoints и native config.

Finding contract

Каждая находка содержит:

### AUD-001 — [critical|high|medium|low] Краткое название
- Boundary: Backend | Frontend | Mobile | Database | Infrastructure | Cross-cutting
- Evidence: `relative/file.ts:42` — проверяемый факт или короткий вывод команды
- Root cause: почему дефект существует
- Impact: конкретный failure/security/business scenario
- Fix: точное изменение без применения
- Target state: правильный слой, dependency direction или control
- Verify: команда/тест, доказывающие исправление
- Owner: backend | frontend | expo-mobile | security | resilience | database | devops | testing

Нельзя выдавать предположение за finding. Если доказательств недостаточно, помести вопрос в Coverage gaps / Needs verification.

Error-handling rule

Не требуй try/catch вокруг каждой функции. Его отсутствие — finding только на реальной границе отказа: HTTP/DB/filesystem/network/native API, parsing untrusted data, transaction/lock, background job, process entrypoint или cleanup ресурса — и только если нет корректного higher-level handler.

Запрещены пустые/проглатывающие catch, потеря cause/stack, необработанные promise rejection, бесконечные retries, отсутствие timeout/cancellation, двойное логирование и утечка secrets/PII. Предлагай typed domain/transport errors и единый boundary handler, а не blanket wrapping.

Architecture recommendation rule

Сначала опиши фактическую архитектуру и constraints. Целевую схему выводи из domain boundaries и стека проекта, не навязывай один шаблон всем. Для legacy давай incremental migration с совместимыми этапами, ownership, dependency order, rollback и verification; полный rewrite рекомендуй только при доказанной невозможности безопасной эволюции.

Definition of Done

• Stack/boundaries определены evidence-based, включая mixed monorepo.
• Релевантные роли отработали независимые scopes; findings дедуплицированы.
• Vulnerability data проверены online и имеют source/date; tool gaps видимы.
• Все findings имеют file:line, root cause, impact, exact fix, target state и verification.
• Current и target architecture, phased roadmap, dependency order и replacement table присутствуют.
• Report validator зелёный; source tree не изменён кроме запрошенного отчёта.
• Для недоверенного repository не исполнялись package scripts, compiler/lint plugins, tests или binaries; ограничения явно записаны в coverage gaps.