Протокол закрытия недели (Week Close). Ретро 7 дней + carry-over в новую неделю + платформенные шаги (бэкап, dirty repos).
argument-hint
version
1.2.0
layer
L1
status
active
triggers
{"slash":["/week-close"],"phrases":[]}
routing
{"executor":"sonnet","deterministic":false}
agents
single
interaction
multi-step
gates_required
[]
gates_enforced
[]
gates_rationale
операционный скилл; WP Gate применим только при создании нового РП, не для операционных вызовов
Week Close (протокол закрытия недели)
Роль: R1 Стратег. Бюджет: ~30 мин.
Принцип: SKILL.md = L1 платформенный файл. Пользователь не редактирует напрямую — только через extensions/.
Стиль текста: ретро недели и новый WeekPlan читает пилот → весь текст синтезировать в базе разговорного стиля (S0 база + S1 автор, источник DP.SC.050): русский, без машинных меток, главная мысль первой, код РП и путь не подлежащее.
When to use
Протокол закрытия недели (Week Close). Ретро 7 дней + carry-over в новую неделю + платформенные шаги (бэкап, dirty repos).
БЛОКИРУЮЩЕЕ: пошаговое исполнение
Week Close = протокол. Исполнять ТОЛЬКО пошагово через TodoWrite.
Шаг 0 — ПЕРВОЕ действие: создать список задач прямо сейчас (до любых других действий).
Каждый шаг алгоритма → отдельная задача (pending → in_progress → completed).
Algorithm
0. Extensions (before)
Загрузить: bash .claude/scripts/load-extensions.sh week-close before. Exit 0 → Read каждый файл из вывода (alphabetic) → выполнить как первые шаги. Exit 1 → пропустить. Поддерживает extensions/week-close.before.md И extensions/week-close.before.<suffix>.md.
1. Сбор данных за 7 дней
Предзаготовка (WP-484 Ф4a, если есть). Проверить DS-my-strategy/archive/WeekClose-facts-{YYYY-MM-DD}.md ({YYYY-MM-DD} = понедельник закрывающейся недели). Файл найден → прочитать generated_at из frontmatter. Свежий = generated_at не раньше конца недели (воскресенье того же периода — неделя завершилась → факты полные; прогон в середине недели, например ручной тест, даёт частичный срез — не финальный). Свежий → читать из него §1 (коммиты, календарь), §5b (pending-фазы), §6 (полнота переноса), §7a (здоровье бэкапов), §7d (Memory Validate), semantic-check реестра, счётчик [no-registry-touch] и §9 (данные R-вопросника, шаг 6b) вместо живого сбора ниже (тот же скрипт scripts/week-close-scaffold.sh --as-of YYYY-MM-DD можно прогнать заранее вручную, если ещё не запускался автоматически). Файла нет, или generated_at раньше конца недели → выполнять шаги ниже вручную, как раньше (никогда не блокировать Week Close частичной предзаготовкой — тот же принцип «нет данных → явный шаг, не тихая подмена»).
Сверить запланированные встречи/задачи с фактом: что состоялось, что перенеслось, что отменилось. Для задач с отчётами (🔧 backup stress-test и т.п.) — проверить наличие артефакта.
Сопоставить коммиты и календарь с РП в WeekPlan → определить статусы (done/partial/not started).
2. Headless week-review (если включён launchd Пн 00:00)
Условный шаг: если запущен через strategist.sh week-review (Пн 00:00 launchd) — алгоритм идёт через {{IWE_TEMPLATE}}/roles/strategist/prompts/week-review.md. В интерактивном режиме /week-close (вечер Вс) — выполнять следующие шаги вручную.
3. Ретро (closed/partial/not_started/blocked)
3a. Закрытые РП: что сделано, ключевые артефакты, мультипликатор за неделю.
3b. Частичные: % выполнения, что осталось, перенос в W+1.
3c. Не стартовавшие: причина, перенос или закрытие.
3d. Заблокированные: блокер, ETA снятия.
4. Метрики недели
Completion rate: X/Y РП (N%)
Коммитов всего, активных дней
WakaTime итог недели (физическое время)
Бюджет закрыт (сумма done × бюджет + partial % × бюджет)
Мультипликатор недели = Бюджет закрыт / WakaTime
Калибровка гипотез (WP-496, из шага 6a): сверено N записей за неделю; из них с уверенностью ≥80% — доля подтвердившихся (порог: ≥0.9 от заявленной уверенности, иначе «уверенность завышена» — явно отметить в WeekReport). Если сверок не было на этой неделе — не считать, пропустить строку.
5. Carry-over → W+1
Незавершённые РП с pending/in_progress статусами → перенести в новый WeekPlan W{N+1} (создаст session-prep автоматически в Пн 04:00 либо вручную).
5b. Pending фазы внутри активных РП (B-005)
Зачем: carry-over §5 работает на уровне РП (status: in_progress → перенос). Pending фазы внутри Ф-таблиц context-файлов могут потеряться: если родительский РП в in_progress — pending-фаза не выделяется автоматически; если родительский ушёл в done — фаза теряется вместе с context-файлом.
bash ${IWE_SCRIPTS}/pending-phases-sweep.sh
Скрипт обходит все {{WORKSPACE_DIR}}/{{GOVERNANCE_REPO}}/inbox/WP-*.md со status: in_progress (или без явного status), извлекает строки Ф-таблицы со статусом ⏳ pending / pending, выводит сводку формата:
Для каждой pending-фазы решить: (a) делать на этой неделе → добавить в W{N+1} как явный пункт; (b) переоценить (блокер? устарела?); (c) оставить как есть (если ожидание внешнего события — записать ожидаемый триггер).
Если скрипта нет — fallback: grep -l "status: in_progress" {{WORKSPACE_DIR}}/{{GOVERNANCE_REPO}}/inbox/WP-*.md → для каждого grep -E "⏳.*pending|Ф[0-9]+.*pending".
6. Captures и уроки
Просмотреть inbox/fleeting-notes.md за неделю → маршрутизировать невыключенные.
Drift-scan недели: что в MEMORY.md устарело за 7 дней.
Проверка полноты переноса перед архивацией (WP-5, 2026-07-10):bash {{IWE_SCRIPTS}}/check-wp-transfer-completeness.sh --all {{IWE_ROOT}} по inbox/WP-N/ — выводит results_not_captured-флаги (проставленные при закрытии без заполненного results_in) и файлы в подпапках без учёта в основном контекст-файле. Для каждого warning — пилот решает: (a) действительно нужен перенос знания, найти куда; (b) файл технический/устарел, можно оставить; (c) results_in заполнить постфактум. Не блокирует Close.
Прочитать hypotheses-log.md — отфильтровать записи со статусом «на сверке» И датой сверки ≤ сегодня. Записи со статусом «черновик» (не подтверждённые пилотом Note-Review) — пропустить, они не в цикле сверки.
Для каждой найденной записи: сверить критерий фальсификации с доступной фактурой (коммиты недели, domain_event, инфраструктурные логи, факты из ретро §3-4 этого протокола).
Предложить вердикт: подтверждена / опровергнута / частично подтверждена / неприменимо (если условие критерия физически не выполнено — например, зависимый артефакт не был доставлен — гипотеза не проверяема, не «опровергнута»).
Пилот утверждает или правит вердикт → записать новой записью в конец журнала со ссылкой на исходную (Сверка H-NNN). Исходную запись не редактировать.
Для каждого вердикта — явное действие (обновить уверенность на будущее / добавить шаг в чек-лист / завести РП / зафиксировать кандидат в паттерн — §6 Capture-to-Pack). Вердикт без действия = «повисший», не закрывать неделю с повисшими вердиктами.
Если сверенных записей нет — пометить явно «сверка гипотез: 0 записей с наступившей датой» в WeekReport (не пропускать шаг молча).
WP-484 Ф4c. Раньше существовал только в чек-листе внизу файла (не в нумерованном алгоритме) — реальный Close его пропускал, пока check-trace-satisfaction не блокировал финализацию постфактум на шаге 12. Теперь явный шаг здесь.
Данные предзаготовлены §9 предзаготовки Ф4a (week-close-scaffold.sh), если файл фактов свежий — иначе прогнать behaviour-report.sh --period YYYY-MM и прочитать PACK-agent-rules/incident-journal.md вручную.
3 вопроса (полный текст, критерии и антипаттерны → memory/r-questionnaire.md):
Системный паттерн из Behaviour Report/incidents — разовое или регулярное?
Какой РП взял больше времени, чем планировалось — и почему одним словом?
Если бы мог отменить одно действие этой недели — что?
Ответы → раздел «R-ответы» в WeekReport. «Нечего ответить» — валидный ответ (3 недели подряд → вопрос кандидат на удаление, решение пилота).
bash .claude/hooks/rule-engine.sh mark-gate week-close-g3 (WP-484 Ф4d — трассировка по ходу, не постфактум на шаге 12).
6c. Архивация done-WP (sweep, [[gate]])
WP-484 Ф4d. Гейт "Архивация done-WP" уже проверяется на шаге 12 (check-trace-satisfaction), но раньше не имел собственного явного шага здесь — archive-done-wp.sh вызывается по одному WP за раз из Day Close сразу при закрытии; Week Close нужна sweep-проверка: не остался ли done-WP в inbox/, пропущенный предыдущими Close.
for d in {{WORKSPACE_DIR}}/{{GOVERNANCE_REPO}}/inbox/WP-*/; do
n=$(basename"$d"); f="$d/$n.md"
[ -f "$f" ] && grep -q "^status: done""$f" && echo"$f"done
Шаблон намеренно узкий — только канонический WP-N/WP-N.md (конвенция WP-434), не любой файл внутри папки. Более широкий WP-*/WP-*.md ложно матчит суб-файлы (handoff-заметки, транскрипты занятий), у которых status: done относится к суб-артефакту, не к самому РП — проверено живьём при написании этого шага (WP-484 Ф4d): широкий шаблон дал 6 ложных совпадений из 7, только 1 реальный (WP-486/WP-486.md, done и не заархивирован).
Найден файл → архивировать: bash {{IWE_SCRIPTS}}/archive-done-wp.sh <WP_NUM>. Пусто — нечего архивировать, gate удовлетворён без действия.
Обязательный шаг перед бэкапом. Запускает iwe-backup-check.sh (WP-317 supplement).
bash ${IWE_SCRIPTS}/iwe-backup-check.sh
Если вернул ❌ (exit 2) — устранить критичные gaps ДО бэкапа (устаревший бэкап >14 дней, нет iCloud).
Если вернул ⚠️ (exit 1) — зафиксировать warnings в WeekReport, продолжить.
Если ✅ (exit 0) — бэкап в норме.
7b. Бэкап IWE в iCloud
Условный шаг: только macOS с iCloud Drive. Запускать ТОЛЬКО если 7a не вернул ❌.
${IWE_SCRIPTS}/backup-icloud.sh
Архив всех файлов IWE (без .git, node_modules, .venv) → iCloud Drive. Хранит 4 последних архива.
7c. Скан незакоммиченных файлов
${IWE_SCRIPTS}/check-dirty-repos.sh
Если есть грязные репо → закоммитить и запушить ДО завершения Week Close.
Нарушения (HOT-лимит, orphans, superseded_by без ссылки) → исправить до коммита Week Close.
Кандидаты на понижение горизонта → информативно, пользователь решает при следующем Month Close.
Container iwe-hindsight → статус Up (если Down → bash ~/IWE/FMT-exocortex-template/exocortex/hindsight/start.sh)
Лог без FAIL за неделю. Если есть FAIL → docker logs iwe-hindsight → диагностика (OpenAI key? network? disk?)
Размер БД: docker exec iwe-hindsight ls -lh /data/hindsight.db — если >100MB → флаг ротации
Whitelist review: нужно ли добавить новые скиллы в RECALL_SKILLS (созданные за неделю)?
8. Запись итогов в WeekReport (split, ОПТ-5)
Split (WP-297 ОПТ-5): факты недели живут в WeekReport W{N}, не в WeekPlan. WeekPlan — только намерения.
Открой текущий WeekReport W{N} YYYY-MM-DD.md (если нет — создай при следующем session-prep, см. CLAUDE.md §9 правило split).
Дополни секцию «Итоги W{N}» (структура — см. roles/strategist/prompts/week-review.md).
Также дополни секцию «Сверка РП↔НЭП» в WeekPlan W{N}: для каждого закрытого РП — какая НЭП снята / какой R-результат продвинут? Это вход в Strategy Session W{N+1}.
Заполни секцию «Рекомендации изменений в НЭП и Стратегию» в WeekPlan W{N} — что узнали на этой неделе → что менять в Dissatisfactions.md / Strategy.md.
Загрузить: bash .claude/scripts/load-extensions.sh week-close after. Exit 0 → Read каждый файл из вывода (alphabetic) → выполнить. Exit 1 → пропустить. Поддерживает extensions/week-close.after.md И extensions/week-close.after.<suffix>.md.
10. Оценка качества недели (WP-310 Gap-А)
Спросить пользователя: «Оцени качество недели 1-5:
1 = механически (шёл по инерции, голова не работала)
2 = поверхностно (что было, что сделано — без анализа паттернов)
3 = норма (осознанно, видишь паттерны, без прорывов)
4 = хорошо (конкретные решения, что-то понято по-новому)
5 = прорывная (изменилось понимание системы, ключевые решения)»
Ответ N → включить q:N в commit message следующего шага.
Если пользователь пропускает → commit без q:.
11. Закоммитить governance-репо
Защита от гонки параллельных сессий (WP-484 Ф4b). Week Close — долгая (~30 мин) ручная сессия; за это время параллельные агентские сессии (Kimi/другие) гарантированно продолжают коммитить в тот же репозиторий (найдено 19.07: финальный коммит пришлось перезапускать 3 раза вручную). week-close-commit-guard.sh оборачивает commit+push тем же принципом, что git-dirty-guard.sh уже даёт открытию дня: pull --rebase --autostash перед стейджингом, retry (до 3 попыток) при отклонённом push, коммитит и пушит ТОЛЬКО переданный pathspec — независимо от того, что успело прилететь на origin между попытками.
cd {{WORKSPACE_DIR}}/{{GOVERNANCE_REPO}}
git status --short
# НЕ git add -A/git add ./git add -u — AGENTS.md CRITICAL (может захватить работу других агентов)# Файлы, изменённые в шагах 1-10 (в массив для pathspec):
WC_FILES=(<каждый файл явным путём: WeekPlan, WeekReport, WP-REGISTRY, inbox/WP-*.md и т.д.>)
bash {{IWE_SCRIPTS}}/week-close-commit-guard.sh "$(pwd)""week-close: W{N} итоги q:{score}""${WC_FILES[@]}"
Exit 0 — закоммичено и запушено (возможно после retry). Exit 1 — нечего коммитить (уже сделано на предыдущей попытке этого же шага). Exit 2 — реальный конфликт после исчерпанных попыток или ошибка окружения → разобраться вручную (git status, git log --oneline -5), не игнорировать.
12. Верификация (Haiku R23)
Перед запуском R23 — bash .claude/hooks/rule-engine.sh check-trace-satisfaction --protocol memory/protocol-close.md --section "Week Close" (WP-481 Ф5.1: 5 гейтов, размеченных в protocol-close.md §Week Close — Бэкап, Memory Validate, R-вопросник, Архивация done-WP, Обновить WeekPlan). С WP-484 Ф4d каждый mark-gate week-close-gN вызывается по ходу своего шага (6c, 7c/7a, 7d, 6b, 8 выше) — эта проверка теперь читает уже расставленные по ходу маркеры, а не собирает их одним блоком постфактум. Verdict block → вернуться на незакрытый gate, потом R23. JSON вердикта приложить к вводу R23.
Запустить sub-agent Haiku в роли R23 Верификатор (context isolation).
Передать: чеклист, итоги недели, список обновлённых файлов, JSON вердикта trace-satisfaction.
Чеклист Week Close
Все изменения закоммичены и запушены (по всем репо)