Аудит инсталляции IWE
SkillAI & modelsAudit of the user IWE installation. Runs scripts/iwe-audit.sh + MCP healthcheck + smoke-test ritual via sentinel mechanics (contract dry-run-contract.md), passes the report to a subagent in the VR.R.002 Auditor role (context isolation) → verdict ✅/⚠️/❌ across 6 components (Inventory, L1 drift, DS-st
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Аудит инсталляции IWE skill
What this skill tells your AI
The instructions your AI receives, as published by tserentserenov/fmt-exocortex-template in .claude/skills/audit-installation/SKILL.md and read by ahel’s review.
Service Clause: VR.SC.005-installation-audit Роль: VR.R.002 Аудитор (PACK-verification) — субагент с context isolation Принцип: детектор отчитывается, оператор делает (см.
scripts/iwe-drift.sh:7-11). Auto-fix не входит в обещание.
Аргументы: $ARGUMENTS
When to use
Аудит пользовательской инсталляции IWE. Запускает scripts/iwe-audit.sh + MCP healthcheck + smoke-test ритуала через sentinel-механику (контракт dry-run-contract.md), передаёт отчёт subagent'у в роли VR.R.002 Аудитор (context isolation) → verdict ✅/⚠️/❌ по 6 компонентам (Inventory, L1 drift, DS-strategy, L3 customizations, MCP, ритуал). Используй после restore из бэкапа, после update.sh, или при еженедельной сверке.
Обещание
За ≤5 минут — markdown-отчёт ✅/⚠️/❌ по 6 компонентам инсталляции:
- Inventory — все ли критичные L1-файлы (CLAUDE.md, скиллы, протоколы) на месте
- L1 drift — расхождения с FMT-exocortex-template
- DS-strategy — git status + diff с FMT-strategy-template
- L3 customizations — extensions/, отличия params.yaml от skeleton, AUTHOR-ONLY зоны
- MCP healthcheck — 4 tools отвечают (с уважением к подписочному гейтингу DP.SC.112)
- Ритуал smoke-test —
/run-protocol close dayзапускается под sentinel-защитой, доходит до write-шагов (см.memory/dry-run-contract.md)
Verdict выносит subagent в роли Аудитора, читая отчёт без знаний о текущей сессии (context isolation).
Шаг 1. Детерминированные проверки (bash)
Найти и запустить iwe-audit.sh через fallback-цепочку (author-mode → workspace, user-mode → $IWE_SCRIPTS из ~/.iwe-paths):
# issue #688: a non-interactive top-level Bash call doesn't go through
# .bashrc/.zshenv (interactive-shell guard) or BASH_ENV (read before the
# harness can set it) — $IWE_SCRIPTS is unset here on plenty of real
# installs even though ~/.iwe-paths exists and is correct. Source it
# directly, in this same shell, before reading the variable — `.` doesn't
# depend on interactive/BASH_ENV machinery at all.
IWE_PATHS="${IWE_PATHS_FILE:-$HOME/.iwe-paths}"
[ -r "$IWE_PATHS" ] && . "$IWE_PATHS"
if [ -n "${IWE_SCRIPTS:-}" ] && [ -f "$IWE_SCRIPTS/iwe-audit.sh" ]; then
# $IWE_SCRIPTS first (#566): the hardcoded workspace copy, when it exists at
# all, is a stale leftover — the installer points IWE_SCRIPTS at the template.
AUDIT_SCRIPT="$IWE_SCRIPTS/iwe-audit.sh"
elif [ -f "$HOME/IWE/scripts/iwe-audit.sh" ]; then
AUDIT_SCRIPT="$HOME/IWE/scripts/iwe-audit.sh"
else
echo "iwe-audit.sh не найден. \$IWE_PATHS ($IWE_PATHS) не даёт рабочий \$IWE_SCRIPTS — проверь, что файл существует и содержит export IWE_SCRIPTS=... (запусти setup.sh из FMT-шаблона, если файла нет)."
exit 1
fi
bash "$AUDIT_SCRIPT" $([ "${ARGUMENTS:-}" = "--critical" ] && echo "--critical")
Сохранить вывод в переменную bash_report. Проверить exit code:
- 0 → bash-часть ✅
- 1 → warnings (отметить, продолжать)
- 2 → critical gaps в bash-проверках (отметить, продолжать — Аудитор оценит совокупно с MCP)
Скрипт покрывает разделы 1-3 отчёта (Inventory, L1 drift, DS-strategy).
Шаг 2. MCP healthcheck (если не --skip-mcp)
Параллельно вызвать 4 MCP tool'а с минимальной нагрузкой, замерить латентность:
| Tool | Параметры | Уровень | Что считаем |
|---|---|---|---|
mcp__claude_ai_IWE__knowledge_search | query: "test", limit: 1 | бесплатный | ✅ если ответ <15s |
mcp__claude_ai_IWE__github_status | (без параметров) | бесплатный | ✅ если ответ |
mcp__claude_ai_IWE__personal_search | query: "ping", limit: 1 | подписочный | ✅ если ответ; 403/subscription_required → ⏸️ (не считать failure) |
mcp__claude_ai_IWE__dt_read_digital_twin | path: "1_declarative" | подписочный | ✅ если ответ; 403/subscription_required → ⏸️ (не считать failure) |
Подписочное гейтование (DP.SC.112). personal_* и dt_* требуют активной БР в subscription_grants. Без подписки — это не сбой инсталляции, а ожидаемый отказ. Помечать как ⏸️ subscription_required, не ❌. Coverage считать только по доступным для пользователя tool'ам.
Сформировать markdown-секцию ## 4. MCP healthcheck:
## Algorithm
## 4. MCP healthcheck
| Tool | Статус | Латентность | Примечание |
|------|--------|-------------|------------|
| personal_search | ✅/❌ | Nms | ... |
| knowledge_search | ✅/❌ | Nms | ... |
| github_status | ✅/❌ | Nms | ... |
| dt_read_digital_twin | ✅/❌ | Nms | ... |
Coverage: N/4
Если --skip-mcp → секция «⏸️ MCP healthcheck — пропущен по флагу».
Шаг 2.5. Smoke-test ритуала (sentinel + subagent)
Контракт: memory/dry-run-contract.md. Защита через sentinel-файл + PreToolUse-хук
dry-run-gate.sh.
Алгоритм
-
Создать репетицию через begin-helper (issue #549 stage 2 — эксклюзивное создание под транзакционным замком; token печатается один раз в stdout):
bash "$IWE_SCRIPTS/dry-run-begin.sh" audit-installation "${CLAUDE_SESSION_ID:-}"Helper печатает
gate_id=,owner_token=,owner_session_id=. Запомни все три значения из вывода tool-call'а — shell-переменные между твоими Bash-вызовами не живут (Codex r2), а token хранить в файле нельзя (его прочитает репетиция). Активная чужая репетиция → helper завершится ошибкой с её gate_id. -
Запустить subagent через Agent tool (subagent_type=general-purpose, модель Sonnet) с промптом:
Запусти ритуал /run-protocol close day по обычной процедуре. Не изобретай — следуй SKILL.md как написано. ВАЖНО: в текущем окружении активен sentinel /tmp/iwe-dry-run.flag — это означает dry-run mode. PreToolUse-хук dry-run-gate.sh заблокирует любой write-tool (Write/Edit/git-write/MCP-write). Это ожидаемо — твоя задача дойти максимально далеко, фиксируя на каком шаге упёрся. После прогона отчитайся в формате: ## Smoke-test /run-protocol close day - Шагов выполнено: N из M - Упёрлось на: <шаг>: <tool>: <причина блокировки> - Read-логика: ✅ работает / ❌ упало раньше write-шага - Заключение: ✅/⚠️/❌ -
Дождаться завершения subagent'а.
-
Завершить репетицию (атомарный переход active→completed с capability token; sentinel снимается самим helper'ом после completed — Stop-хук теперь только идемпотентный fallback). Подставь значения, запомненные на шаге 1:
bash "$IWE_SCRIPTS/dry-run-complete.sh" "<gate_id из шага 1>" rehearsal-finished "<owner_session_id из шага 1>" "<owner_token из шага 1>" -
Сформировать секцию 6 отчёта:
## 6. Ритуал smoke-test (/run-protocol close day) <вывод subagent'а> **Интерпретация:** - Block на write-шаге после успешных read-шагов → ✅ (read-логика работает, это ожидаемое поведение smoke-теста) - Block на шаге 1-2 → ❌ (ритуал ломается рано — нет source-файла, MCP отвалился) - Все шаги без block → ⚠️ (подозрительно — ритуал должен иметь write-шаги) - Hook-error → ❌ (инфраструктура поломана)
Защита от sticky-sentinel
Если subagent упал/завис → попытаться удалить sentinel явно (всегда). Stop владельца удалит capability-файл; чужой Stop не затронет защиту. TTL 10 мин в самом хуке защищает от случаев, когда даже это не отработало (kill -9, краш CLI).
Шаг 3. Сборка единого отчёта
# IWE Installation Audit — YYYY-MM-DD HH:MM
[bash_report — секции 1-3]
[mcp_section — секция 4]
---
[передаётся Аудитору на шаг 4]
Шаг 4. Запустить subagent в роли Аудитора (VR.R.002)
Использовать Agent tool с context isolation (subagent_type=general-purpose, модель Sonnet):
⛔ Subagent НЕ получает:
- Историю текущей сессии
- Знания о том, что пользователь чинил/восстанавливал
- Промежуточные рассуждения
Subagent получает (промпт):
Ты исполняешь роль VR.R.002 Аудитор (PACK-verification). Твоя задача — прочитать markdown-отчёт по аудиту инсталляции IWE и вынести verdict.
Эталон:
- VR.SC.005 (Service Clause): инсталляция должна иметь все критические L1-файлы, ритуалы должны загружаться, MCP должен отвечать, DS-strategy — быть git-репо.
- Gate-критерии (из WP-265 §Gate-критерии):
- ✅ — 0 critical gaps, ≤2 warnings
- ⚠️ — 1+ warning или ≥3 minor gaps; работоспособно
- ❌ — ≥1 critical: L1 broken (>5 файлов drift), ритуал падает, MCP <2/4 отвечают
Принцип context isolation (VR.SOTA.002): не используй знания о том, как создавалась инсталляция. Оценивай ТОЛЬКО по отчёту.
Отчёт:
[вставить полный собранный отчёт]
Выдай verdict в формате:
## Verdict: [✅ / ⚠️ / ❌]
**Сводка по компонентам:**
- L1 (платформа): ✅/⚠️/❌ — короткое объяснение
- Ритуалы: ✅/⚠️/❌ — ...
- MCP: ✅/⚠️/❌ — ...
- DS-strategy: ✅/⚠️/❌ — ...
**Критичные gaps (если есть):**
- [список с указанием файла/компонента]
**Рекомендации:**
- Что чинить через `update.sh` (Синхронизатор)
- Что чинить руками (с конкретным шагом)
- Что отложить (некритично)
Не предлагай auto-fix. Не лезь в реализацию. Твоя роль — Аудитор, не Кодировщик.
Шаг 5. Сохранить отчёт + показать пользователю
- Сохранить полный отчёт + verdict в файл:
# Priority (#566): $IWE_SCRIPTS convention first, hardcode only as fallback → $HOME/IWE if [ -d "${IWE_SCRIPTS:-$HOME/IWE/scripts}" ]; then AUDIT_LOG_DIR="${IWE_SCRIPTS:-$HOME/IWE/scripts}" else AUDIT_LOG_DIR="$HOME/IWE" fi mkdir -p "$AUDIT_LOG_DIR" AUDIT_LOG="$AUDIT_LOG_DIR/iwe-audit-$(date +%Y%m%d-%H%M%S).log" # Записать конкатенацию: full_report + verdict - Вывести пользователю:
- Полный markdown-отчёт (секции 1-6)
- Verdict от Аудитора
- Краткое резюме одной строкой:
Verdict: ⚠️ Работоспособно с N оговорками. Лог: <AUDIT_LOG>
Пользователь сам решает, что чинить.
Ограничения текущей реализации
- Smoke-test покрывает один ритуал (
/run-protocol close day). Расширение на week-close / month-close — мини-РП, копия шага 2.5 с другими subcommand'ами. - DS-strategy diff — работает только если существует
FMT-strategy-template/(илиtemplates/strategy-skeleton/). Если нет — секция пометится «N/A». - MCP healthcheck — зависит от текущих доступных tools. Если набор изменится, обновить шаг 2.
- Sentinel sticky-state — защита: TTL 10 мин в хуке + Stop-cleanup. Edge case: если хук изменён и не читает sentinel → блокировки не будет (fail-open). Защита: периодический re-test
/audit-installationловит регрессию.
Signals
- GitHub stars
- 54
- Forks
- 150
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
audit-installation- Source
- github.com/tserentserenov/fmt-exocortex-template