\n\nРоль: R24 Аудитор. Полное описание:
\nPACK-digital-platform/pack/digital-platform/02-domain-entities/DP.ROLE.024-auditor.md(WP-224). Маппинг: R24 = VR.R.002.\nМетод: R24 coverage по категориям + R23 pair-diff между парамикод файл ↔ docs файл.\nПолучатель отчёта: владелец репо в другой временной позиции (категория 3 — внешняя проектная роль). Это аудит в строгом смысле — не автор кода, не ты сейчас.\nТип роли (DP.D.080): R24 — контрольная роль. Read-only к аудитуемым артефактам. Отчёт = output-канал, не изменение аудитуемого.
Аргументы: $ARGUMENTS
\nПроходит указанный репо и формирует отчёт о расхождениях между кодом и документацией. Не правит ни код, ни docs — только отчёт.
\n--repo <path> (обязателен) или . (текущая директория).--init --repo <path> — направляемая подготовка конфигурации; аудит не запускает.| Ответственность | \nПодотчётная роль | \n
|---|---|
| Решить, что покрытие документацией требуется, и утвердить модель репозитория | \nВладелец репозитория | \n
| Определить категории документации и пары «источник ↔ документация» | \nR5 Архитектор совместно с владельцем | \n
| Материализовать утверждённый YAML | \nМейнтейнер или агент-исполнитель | \n
| Потреблять YAML и сообщать о расхождениях | \nR24 Аудитор / audit-docs | \n
| Поставить шаблон, схему, bootstrap и утверждение о владении | \nМейнтейнер платформы / FMT | \n
Блокирующее ограничение: агент вправе создать docs/.audit-context.yaml\nтолько после того, как владелец утвердил категории и маппинги. R24 Аудитор не\nизобретает семантическую модель ни во время аудита, ни перед ним.
--init)<repo>/CLAUDE.md; определить владельца и R5 Архитектора..claude/skills/audit-docs/.audit-context.yaml.example.source_patterns ↔ docs_patterns/file_naming. Без утверждения остановиться.<repo>/docs/.audit-context.yaml,\nпоставить owner_approved: true, approved_by и реальную дату.Корень — mapping со строгими ключами schema_version: 1,\nowner_approved: true, approved_by, approved_at, categories. categories —\nнепустой список; каждая категория содержит уникальный id, непустые списки строк\nsource_patterns и docs_patterns, строку file_naming; drift_days —\nнеобязательное положительное целое. Неизвестные ключи и пустые glob-паттерны — ошибка.
Перед аудитом выполнить этот валидатор (требуется PyYAML):
\npython3 - \"$REPO/docs/.audit-context.yaml\" <<'PY'\nimport datetime as dt\nimport sys\nimport yaml\n\npath = sys.argv[1]\ndata = yaml.safe_load(open(path, encoding=\"utf-8\"))\nroot_keys = {\"schema_version\", \"owner_approved\", \"approved_by\", \"approved_at\", \"categories\"}\ncategory_keys = {\"id\", \"source_patterns\", \"docs_patterns\", \"file_naming\", \"drift_days\"}\nassert isinstance(data, dict) and set(data) == root_keys, \"invalid root keys\"\nassert data[\"schema_version\"] == 1, \"unsupported schema_version\"\nassert data[\"owner_approved\"] is True and data[\"approved_by\"], \"owner approval missing\"\nassert isinstance(data[\"approved_at\"], (str, dt.date)), \"approved_at missing\"\ncategories = data[\"categories\"]\nassert isinstance(categories, list) and categories, \"categories must be non-empty\"\nids = []\nfor category in categories:\n assert isinstance(category, dict) and set(category) <= category_keys, \"invalid category keys\"\n assert {\"id\", \"source_patterns\", \"docs_patterns\", \"file_naming\"} <= set(category), \"category keys missing\"\n ids.append(category[\"id\"])\n for key in (\"source_patterns\", \"docs_patterns\"):\n assert isinstance(category[key], list) and category[key] and all(isinstance(v, str) and v.strip() for v in category[key]), key\n assert isinstance(category[\"file_naming\"], str) and category[\"file_naming\"].strip(), \"file_naming\"\n assert \"drift_days\" not in category or isinstance(category[\"drift_days\"], int) and category[\"drift_days\"] > 0, \"drift_days\"\nassert len(ids) == len(set(ids)) and all(isinstance(v, str) and v.strip() for v in ids), \"category ids\"\nprint(\"audit-context: valid\")\nPY\nПри старте обязательно прочитать:
\n<repo>/CLAUDE.md целиком — как любой агент в этом репо. В частности § 10 «Известные ловушки/инварианты» (если есть).<repo>/docs/.audit-context.yaml — категории docs, source patterns, file_naming. Без файла сообщить о --init и остановиться; самостоятельно создавать модель запрещено. Файл есть → выполнить схему-валидатор выше, ошибка блокирует аудит.${IWE_ROOT:-$HOME/IWE}/.claude/sync-manifest.yaml — найти пары, где source или derived пересекают этот репо. Использовать как дополнительный источник связей «код ↔ docs».Для каждой категории из .audit-context.yaml:
source_patterns).file_naming или эвристике.coverage % = docs_files / source_files.Для каждой существующей пары source ↔ docs:
drift_candidates с приоритетом (critical / warn / ok).Для каждой ловушки/инварианта из § 10 CLAUDE.md репо проверить: упомянута ли в docs? Если нет — добавить в раздел «Неочевидности».
\nЗаписать отчёт в <repo>/docs/audit-reports/audit-YYYY-MM-DD.md со структурой:
# Audit report — <repo> — <YYYY-MM-DD>\n\n## Coverage по категориям\n| Категория | Source файлов | Docs файлов | Coverage % | Статус |\n|-----------|---------------|-------------|------------|--------|\n\n## Gaps (source без docs)\n- ...\n\n## Orphans (docs без source)\n- ...\n\n## Drift candidates (pair-diff)\n| Source | Docs | mtime lag | Приоритет |\n|--------|------|-----------|-----------|\n\n## Неочевидности (§ 10 CLAUDE.md, не покрыто docs)\n- ...\n\n## Итого\n- Coverage суммарный: X%\n- Drift critical: N\n- Drift warn: N\n- Gaps: N\n- Orphans: N\n/auto-docs)./verify — проверка артефакта по эталону Pack (VR.R.001). /audit-docs — кросс-репо coverage аудит (R24/VR.R.002). Разные роли, разные методы.iwe-drift.sh — детектирует drift между парами в sync-manifest.yaml (S-класс). /audit-docs — углублённый аудит docs/ внутри одного репо. drift→решение «нужно пройтись /audit-docs» — типовой workflow.Этот скилл реализует Variant C (manual baseline) из дизайна SC.024.∞ — Auto-update docs/. После 2 недель обкатки и калибровки точности — переход на Variant A (post-merge GitHub webhook). См. README.md рядом.