Аудит инсталляции IWE

SkillAI & models

Audit 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.

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 компонентам инсталляции:

  1. Inventory — все ли критичные L1-файлы (CLAUDE.md, скиллы, протоколы) на месте
  2. L1 drift — расхождения с FMT-exocortex-template
  3. DS-strategy — git status + diff с FMT-strategy-template
  4. L3 customizations — extensions/, отличия params.yaml от skeleton, AUTHOR-ONLY зоны
  5. MCP healthcheck — 4 tools отвечают (с уважением к подписочному гейтингу DP.SC.112)
  6. Ритуал 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_searchquery: "test", limit: 1бесплатный✅ если ответ <15s
mcp__claude_ai_IWE__github_status(без параметров)бесплатный✅ если ответ
mcp__claude_ai_IWE__personal_searchquery: "ping", limit: 1подписочный✅ если ответ; 403/subscription_required → ⏸️ (не считать failure)
mcp__claude_ai_IWE__dt_read_digital_twinpath: "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.

Алгоритм

  1. Создать репетицию через 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.

  2. Запустить 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-шага
    - Заключение: ✅/⚠️/❌
    
  3. Дождаться завершения subagent'а.

  4. Завершить репетицию (атомарный переход 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>"
    
  5. Сформировать секцию 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. Сохранить отчёт + показать пользователю

  1. Сохранить полный отчёт + 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
    
  2. Вывести пользователю:
    • Полный 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
Аудит инсталляции IWE (audit-installation): Skill · ahel