--- name: strategy-session description: Стратегическая сессия — диспетчер. День-0 (маркер IWE-INITIAL-NEEDED или нет Strategy.md/WeekPlan) → initial flow (цели, неудовлетворённости, первый WeekPlan). Первая сессия календарного месяца → полный monthly flow (стратегическая сверка + линза калибра). Остальные дни → короткий weekly flow (требует черновик от session-prep). Триггеры — «проведём стратегическую сессию», «первая стратегическая сессия», «strategy session», «давай стратегировать». version: 1.0.0 layer: L1 status: active browser_safe: false triggers: slash: [/strategy-session] phrases: [] routing: executor: opus deterministic: false agents: single interaction: multi-step gates_required: [] gates_enforced: [] gates_rationale: "операционный скилл; WP Gate применим только при создании нового РП, не для операционных вызовов" --- # Strategy Session — диспетчер > Один skill, три режима. Выбор по факту наличия артефактов в `{{GOVERNANCE_REPO}}/` + календарной позиции сессии. ## When to use Стратегическая сессия — диспетчер. День-0 (маркер `IWE-INITIAL-NEEDED` в Strategy.md или нет Strategy.md/WeekPlan) → initial flow (цели, неудовлетворённости, первый WeekPlan). Первая сессия календарного месяца → полный monthly flow (стратегическая сверка + линза калибра, ~45-60 мин). Остальные сессии → короткий weekly flow (требует черновик от session-prep, ~15-20 мин). Триггеры — «проведём стратегическую сессию», «первая стратегическая сессия», «strategy session», «давай стратегировать». ## Штаб стратегирования и сессия Личный Штаб стратегирования — действующая система. В обычной конфигурации в неё входят человек как владелец решений, настроенная ИИ-среда и развёрнутое физическое рабочее место. Конкретного агента, всю ИИ-среду или место можно заменить, если продолжаются порядок принятия решений и доступ к прежним приоритетам, обязательствам и записям. Стратег и Плановик — роли внутри работы Штаба; одну или обе может выполнять назначенный исполнитель. Название роли не передаёт ИИ право утверждать решения человека. Различай три работы: отдельная система создаёт и затем помогает развивать устройство Штаба; созданный Штаб готовит и проводит первую сессию; после неё Штаб регулярно сверяет направление, план и результаты. РП исполняют назначенные исполнители, а Штаб получает факты исполнения. **Состоявшаяся сессия** — ограниченная во времени работа. Отдельную временную систему проведения сессии называй только тогда, когда показаны её собственные состав, связи, граница и способность действовать; обычно достаточно Штаба в сессионной конфигурации. Документ с повесткой, план или запись сессии не являются самой сессией. Для практического запуска фиксируй два разных рубежа. **Штаб создан**, когда человек, доступные средства и физическое рабочее место связаны устойчивым способом принимать и сохранять решения о направлении и плане. **Штаб готов к первой сессии**, когда дополнительно доступны первые наблюдения, место для записей, ответственный за решение и рабочий сценарий встречи. Готовность проверяют после создания; отсутствие повестки не отменяет существования уже созданного Штаба. В полной сессии действует один Штаб с различными назначениями внутри него. Таблица задаёт обзор этапов 0–8; файлы шагов ниже уточняют порядок и условия пропуска. Выход этапа может быть решением или обновлением существующей записи, а не отдельным РП. | Этап полной сессии | Назначение внутри Штаба | Вход | Действие | Ожидаемый выход | |---|---|---|---|---| | 0. Открытие | Исполнитель организует, человек согласует | Черновик плана и повестка | Сверить готовность и маршрут | Порядок разбора | | 1. Ревью недели | Плановик сверяет, человек решает | Прошлый план и факты | Разобрать план и результат | Решения о переносе и остановке | | 2. Разбор входящих | Стратег разбирает, человек решает | Заметки и открытые вопросы | Выделить вопросы для выбора | Разобранные входящие | | 3. Неудовлетворённости | Стратег уточняет, человек подтверждает | Наблюдения и прежние записи | Уточнить существенные разрывы | Обновлённые неудовлетворённости | | 4. Стратегическая сверка | Стратег сопоставляет, человек решает | Стратегия, результаты и разрывы | Пересмотреть приоритеты | Решения о месячной рамке | | 5. Калибровка | Назначенный исполнитель измеряет, человек решает | Данные о состоянии и намерениях | Обсудить измерение и рекомендацию | Решение и запись измерения | | 6. Планирование | Плановик собирает, человек утверждает | Приоритеты, РП и бюджет времени | Отобрать и распределить бюджет | Пул РП и черновик недели | | 7. Нерегулярные вопросы | Исполнитель зависит от вопроса | Особые пункты повестки | Разобрать отдельные случаи | Записанные решения | | 8. Утверждение | Человек утверждает, исполнитель сохраняет | Черновик недели и решения | Проверить и закрепить | Утверждённый план недели | Состав и порядок этапов короткой недельной и длинной месячной сессии заданы таблицами в `strategy-session-weekly.md` и `strategy-session-monthly.md` соответственно. Не выбирай этапы по ходу сессии и не меняй их состав в зависимости от свежести приоритетов: условия пропуска и остановки заданы в выбранном файле. Первая сессия описана отдельно в §2. Семь стадий общего цикла работы между сессиями — другой масштаб, не перечень шагов одной встречи. ## Algorithm ### Шаг 0. Рабочая копия governance-репозитория (БЛОКИРУЮЩЕЕ, ДО расширений и любой записи) > Если в установке есть `session-guard.sh` (канон под freeze), правка идёт только из изолированной копии и публикуется через `ds-publish.sh` (правило «Канон под freeze» в `{{GOVERNANCE_REPO}}/CLAUDE.md`). Если session-guard в установке нет, заморозка выключена (пустой `IWE_FROZEN_CANONICAL_PATH`) или у репозитория управления нет `origin` (установка без GitHub: `open --isolate` без `--base-sha` берёт основу командой `git fetch origin main`, а публиковать некуда), работай как раньше в найденной рабочей копии и сохраняй штатным способом. Это две явные ветки ниже, не молчаливый пропуск. ВСЕ пути записи строятся от `GOV_WT`, не от канона. ```bash CANON="{{WORKSPACE_DIR}}/{{GOVERNANCE_REPO}}" GUARD="${IWE_SCRIPTS:-}/session-guard.sh" [ -f "$GUARD" ] || GUARD="{{WORKSPACE_DIR}}/scripts/session-guard.sh" [ -f "$GUARD" ] || GUARD="$CANON/scripts/session-guard.sh" [ -f "$GUARD" ] && GUARD_MODE=required || GUARD_MODE=absent CANON_C=$(cd -- "$CANON" 2>/dev/null && pwd -P) || { echo "ERROR: канон $CANON недоступен" >&2; exit 1; } CANON_COMMON=$(git -C "$CANON_C" rev-parse --path-format=absolute --git-common-dir 2>/dev/null) \ || { echo "ERROR: $CANON_C не git-репозиторий" >&2; exit 1; } if [ -f "$CANON_C/scripts/lib/governance-repo-path.sh" ]; then CAND=$(. "$CANON_C/scripts/lib/governance-repo-path.sh" && resolve_active_worktree) \ || { echo "ERROR: resolve_active_worktree завершился с ошибкой" >&2; exit 1; } else CAND=$(git rev-parse --show-toplevel 2>/dev/null) || CAND="" fi CAND_C=""; CAND_COMMON="" if [ -n "$CAND" ]; then CAND_C=$(cd -- "$CAND" 2>/dev/null && pwd -P) || { echo "ERROR: не удалось нормализовать путь $CAND" >&2; exit 1; } CAND_COMMON=$(git -C "$CAND_C" rev-parse --path-format=absolute --git-common-dir 2>/dev/null) || CAND_COMMON="" fi # кандидат годится, только если его общий git-каталог совпадает с каноном (тот же governance-репозиторий) if [ -n "$CAND_C" ] && [ "$CAND_COMMON" = "$CANON_COMMON" ]; then GOV_WT="$CAND_C"; else GOV_WT=""; fi # изоляция нужна, только когда есть origin (обычно open --isolate берёт основу через git fetch origin main; # офлайн можно указать проверенный локальный коммит через --base-sha) и заморозка не выключена # (пустой IWE_FROZEN_CANONICAL_PATH выключает её и в самом session-guard.sh): иначе работа как раньше GUARD_OFF="" if [ "$GUARD_MODE" = required ]; then if [ "${IWE_FROZEN_CANONICAL_PATH+x}" = x ] && [ -z "$IWE_FROZEN_CANONICAL_PATH" ]; then GUARD_OFF="заморозка выключена: IWE_FROZEN_CANONICAL_PATH пуст" elif ! git -C "$CANON_C" remote get-url origin >/dev/null 2>&1; then GUARD_OFF="у репозитория управления нет origin: изоляции нечего получать (git fetch origin main) и публиковать некуда" fi [ -z "$GUARD_OFF" ] || GUARD_MODE=absent fi if [ "$GUARD_MODE" = required ]; then if [ -z "$GOV_WT" ] || [ "$GOV_WT" = "$CANON_C" ]; then echo "NOT ISOLATED: канон под freeze, запись запрещена. Открой копию: (cd -- \"$CANON_C\" && bash \"$GUARD\" open --isolate --wp ), затем повтори этот шаг внутри копии: (cd -- \"\" || exit 1; <блок шага 0>)" >&2 LOCAL_BASE_SHA=$(git -C "$CANON_C" rev-parse --verify 'HEAD^{commit}' 2>/dev/null || true) if [ -n "$LOCAL_BASE_SHA" ]; then echo "Если origin недоступен: проверь локальный коммит: git -C \"$CANON_C\" show -s --format='%H %s' \"$LOCAL_BASE_SHA\"" >&2 echo "Затем добавь к команде открытия --base-sha $LOCAL_BASE_SHA; с этим флагом сеть не нужна. Локальная ревизия может отставать от origin." >&2 fi exit 2 fi echo "GOV_WT=$GOV_WT mode=isolated" else [ -n "$GOV_WT" ] || GOV_WT="$CANON_C" echo "GOV_WT=$GOV_WT mode=legacy (${GUARD_OFF:-session-guard не найден: заморозки нет}, работа как раньше)" fi ``` - Код выхода 0 -> **запиши абсолютный путь `GOV_WT` в свой ответ пользователю** (контекст сессии): независимые вызовы Bash не разделяют переменные, а `cd` в подоболочке каталог не меняет. - Код выхода 2 (`NOT ISOLATED`) -> ничего не записывай. Открой копию из канона, возьми `worktree_path` из вывода `open --isolate` и повтори блок шага 0 внутри копии; `` и `` — пути из сообщения `NOT ISOLATED`. Переход в каталог — только в подоболочке `( … )`: верхнеуровневый `cd` хук `destructive-guard.sh` блокирует. ```bash (cd -- "" && bash "" open --isolate --wp ) ``` ```bash (cd -- "" || exit 1 <блок шага 0 без изменений> ) ``` Офлайн (нет сети, `git fetch origin main` не удаётся): проверь локальный коммит командой из шага 0 и используй готовую команду с `--base-sha`, которую напечатает `session-guard.sh`. Она создаёт копию от указанного коммита без обращения к `origin`. Пилот может отдельно решить выключить заморозку пустым `IWE_FROZEN_CANONICAL_PATH` и перейти в режим `legacy`. Не получилось -> сообщи пилоту и остановись (fail-closed), в канон не пиши. Код 1 -> ошибка резолвера или путей: покажи сообщение и остановись. - КАЖДЫЙ последующий блок записи начинается с явного задания и проверки `GOV_WT` и выполняется в подоболочке внутри копии (git — `git -C "$GOV_WT" …`, файлы — абсолютные пути от `$GOV_WT`): ```bash GOV_WT="<записанный абсолютный путь>"; : "${GOV_WT:?}" (cd -- "$GOV_WT" || exit 1 <команды записи> ) ``` - Публикация в конце: `mode=isolated` -> коммит в `GOV_WT`, затем публикация из копии, в канон не коммить. Ветка назначения — резолвится из `origin/HEAD` копии (`main`, если он не управляющая ветка — например `master`; падает обратно на `main`, если симлинк не найден, #1209) и задаётся публикатору явно (`--branch `): `session-guard.sh open --isolate` создаёт копию от этой же ветки на её собственной ветке `session-isolate/-`, которой на сервере нет. `--branch` получает только публикатор, который его знает: `update.sh` не заменяет уже лежащий `scripts/ds-publish.sh` (собственный публикатор установки или старая копия шаблона), и такой публикатор вызывается без `--branch`, как раньше. Знает или нет, функция `knows_branch` судит по тексту файла (эвристика): ветка разбора аргумента `--branch)` (также `-b|--branch)`, `--branch=*)`) в начале строки; комментарий, текст usage или `git status --branch` не в счёт. Ложный пропуск (обёртка, передающая `"$@"`) безопасен: публикатор вызывается как раньше; ложное срабатывание — нет, поэтому признак узкий. Публикатор берётся из копии; из канона — если в копии его нет (`update.sh` кладёт `scripts/ds-publish.sh` в канон без коммита, и копия от `origin/main` его не содержит) или если в копии он не знает `--branch`, а в каноне знает. Нет нигде -> ненулевой код и сообщение: запусти `update.sh`. Публикатор без `--branch` отказал -> предложи пилоту заменить `scripts/ds-publish.sh` в репозитории управления версией шаблона `seed/strategy/scripts/ds-publish.sh`. Публикатор переносит один коммит за вызов, поэтому блок публикует по очереди все коммиты копии, которых нет на `origin/main`, от старого к новому, и останавливается на первом отказе; уже опубликованный коммит публикатор пропускает, повтор блока безвреден. Коммит-слияние публикатор не переносит (код 2): блок остановится на первом таком коммите, так что «все коммиты» — это обычные коммиты. Незакоммиченные изменения в копии не публикуются: блок предупредит одной строкой «ВНИМАНИЕ…», код выхода от этого не меняется. Коммитов нет -> одна строка «Публиковать нечего», без сообщения о публикации; список коммитов не получен (ошибка git) -> код 1 и сообщение, не «Публиковать нечего». ```bash GOV_WT="<записанный абсолютный путь>"; : "${GOV_WT:?}" knows_branch() { grep -qE -e '^[[:space:]]*[(]?([^|)#[:space:]]+[[:space:]]*[|][[:space:]]*)*"?--branch(=[^|)[:space:]]*)?"?[[:space:]]*[|)]' "$1" 2>/dev/null; } PUB="$GOV_WT/scripts/ds-publish.sh"; CANON_PUB="{{WORKSPACE_DIR}}/{{GOVERNANCE_REPO}}/scripts/ds-publish.sh" if ! knows_branch "$PUB" && knows_branch "$CANON_PUB"; then PUB="$CANON_PUB"; fi [ -f "$PUB" ] || PUB="$CANON_PUB" [ -f "$PUB" ] || { echo "ERROR: публикатор ds-publish.sh не найден ни в копии, ни в каноне. Запусти update.sh (он доставляет публикатор) и повтори публикацию; коммиты остаются в копии $GOV_WT" >&2; exit 1; } # issue #1209: hardcoded "main" below broke installs whose governance repo # defaults to e.g. "master" (same class as the session-guard.sh --isolate fix, # #1097/#1195 pattern). Resolve once from the already-fetched copy's remote # HEAD symref (no network call); "main" only as fallback when it's missing. DEFAULT_BRANCH="$(git -C "$GOV_WT" symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's#^refs/remotes/origin/##' || true)" DEFAULT_BRANCH="${DEFAULT_BRANCH:-main}" git -C "$GOV_WT" rev-parse -q --verify "origin/$DEFAULT_BRANCH" >/dev/null || { echo "ERROR: в копии $GOV_WT нет origin/$DEFAULT_BRANCH, публикацию не с чем сравнить" >&2; exit 1; } COMMITS=$(git -C "$GOV_WT" rev-list --reverse "origin/$DEFAULT_BRANCH..HEAD") || { echo "ERROR: не удалось получить список коммитов копии $GOV_WT" >&2; exit 1; } [ -z "$(git -C "$GOV_WT" status --porcelain)" ] || echo "ВНИМАНИЕ: в копии есть незакоммиченные изменения, они не опубликованы: закоммитьте их" >&2 [ -n "$COMMITS" ] || { echo "Публиковать нечего: в копии нет коммитов, которых нет на origin/$DEFAULT_BRANCH"; exit 0; } for c in $(printf '%s\n' "$COMMITS"); do if knows_branch "$PUB"; then bash "$PUB" "$GOV_WT" normal --reason "strategy-session" --from-commit "$c" --branch "$DEFAULT_BRANCH" || exit $? else bash "$PUB" "$GOV_WT" normal --reason "strategy-session" --from-commit "$c" || exit $?; fi done ``` `mode=legacy` -> сохраняй штатным способом установки (коммит и push своими средствами; если у репозитория нет `origin`, достаточно коммита); `ds-publish.sh` используй, только если он есть. ### Шаг 0.1. Extensions (before) `GOV_WT="<записанный путь>" bash .claude/scripts/load-extensions.sh strategy-session before` -> Exit 0: Read каждый файл, выполнить; расширения работают с этим корнем `GOV_WT`. Exit 1: пропустить. ## Шаг 1. Определить режим Сначала проверь `$GOV_WT/docs/Strategy.md` на маркер `IWE-INITIAL-NEEDED`. Он стоит в поставляемой заготовке стратегии, пока первая сессия не завершена. Если маркер есть — выбери **initial**, даже если заготовки Strategy.md и WeekPlan уже существуют; к проверке календарного месяца не переходи. Если маркера нет, проверь наличие любого из: - `$GOV_WT/docs/Strategy.md` - `$GOV_WT/current/WeekPlan W*.md` Если хотя бы один есть — проверь ВТОРЫМ шагом, первая ли это Strategy Session календарного месяца. Записи двух легальных раскладок (issue #608, тот же корень, что #545 в day-open-scaffold.sh): плоские файлы Strategy/Day-сессий (`sessions/YYYY-MM-DD.md`) и подпапка по месяцу для peer-сессий (`sessions/YYYY-MM/`) — искать нужно по обоим адресам, иначе плоская раскладка (дефолт по `memory/routing-vocab.md`) всегда даёт «не найдено» и месячная сверка не срабатывает ни разу: ```bash GOV_WT="<записанный путь>"; : "${GOV_WT:?}" (cd -- "$GOV_WT" || exit 1 IWE_ROOT="${IWE_ROOT:-${IWE_WORKSPACE:-{{WORKSPACE_DIR}}}}" case "${IWE_SESSIONS_ROOT:-}" in ""|/*) ;; *) IWE_SESSIONS_ROOT="$IWE_ROOT/$IWE_SESSIONS_ROOT" ;; esac if [ -n "${IWE_SESSIONS_ROOT:-}" ] && [ ! -d "$IWE_SESSIONS_ROOT" ]; then echo "ERROR: IWE_SESSIONS_ROOT недоступен: $IWE_SESSIONS_ROOT" >&2 exit 1 fi SESSIONS_DIR=$( GOVERNANCE_REPO="${GOVERNANCE_REPO:-${IWE_GOVERNANCE_REPO:-{{GOVERNANCE_REPO}}}}" source "${IWE_SCRIPTS:-{{IWE_TEMPLATE}}/scripts}/lib/common.sh" 2>/dev/null \ || source "{{WORKSPACE_DIR}}/scripts/lib/common.sh" 2>/dev/null \ || exit 1 iwe_sessions_dir "$GOV_WT" ) || SESSIONS_DIR="${IWE_SESSIONS_ROOT:-$GOV_WT/sessions}" grep -rlE 'strategy-session|Strategy Session|^session_type:[[:space:]]*strategy[[:space:]]*$' \ "$SESSIONS_DIR/$(date +%Y-%m)-"*.md \ "$SESSIONS_DIR/$(date +%Y-%m)/" 2>/dev/null ) ``` Первая сессия месяца = дата сессии ≤7 числа месяца И поиск выше пуст. Записи с `session_type: strategy` распознаются и с русским заголовком; прежние текстовые маркеры сохраняются. Журнал берётся из `iwe_sessions_dir` тем же способом, что в `extensions/protocol-close.after.session-record.md`: относительный override — от корня установки, legacy — от активной governance-копии `$GOV_WT`; без библиотеки — из существующего явного `IWE_SESSIONS_ROOT` или `$GOV_WT/sessions`. Недоступный явный override — ошибка конфигурации, не отсутствие записей: сообщить её и не выбирать режим по пустому результату. > **Найдено платформенным аудитом 17.08.2026:** до этого исправления диспетчер знал только про initial/weekly — monthly-вариант (`strategy-session-monthly.md`) был реализован, но ничем не вызывался, кроме редкой ручной эскалации из weekly-stop-gate. Результат — шаги, привязанные только к monthly (стратегическая сверка, линза калибра/lifework-пакет, разбор inbox), фактически никогда не запускались ни у одного пользователя. Этот шаг — фикс маршрутизации, не новая функциональность. > > **Известное ограничение (policy, не баг, peer-review с Codex 17.08.2026):** триггер идемпотентен относительно УСПЕШНОГО запуска (файл сессии записан в `sessions/`), но не относительно прерванного/aborted запуска до записи файла — следующая попытка в том же месяце снова увидит «нет записей» и снова пойдёт в monthly. Осознанный компромисс: at-least-once per month лучше, чем zero-times (баг, который этот фикс и устраняет). Ужесточение до exactly-once — отдельный РП при появлении живого сигнала, что дублирование monthly реально мешает. | Состояние | Режим | Куда дальше | |-----------|-------|-------------| | Есть маркер `IWE-INITIAL-NEEDED` в Strategy.md | **initial** (день-0) | §2 этого файла; наличие заготовок не меняет маршрут | | Нет ни Strategy.md, ни WeekPlan | **initial** (день-0) | §2 этого файла | | Есть Strategy.md и/или WeekPlan, и это первая сессия календарного месяца | **monthly** (полный вариант) | `roles/strategist/prompts/strategy-session-monthly.md` | | Есть Strategy.md и/или WeekPlan со `status: draft`, не первая сессия месяца | **weekly** | `roles/strategist/prompts/strategy-session-weekly.md` | | Есть Strategy.md, но нет draft WeekPlan | weekly без draft | сообщи пользователю: «нет черновика, запустить session-prep?» | Наличие или отсутствие двух файлов выбирает маршрут сессии, но не доказывает существование Штаба: файлы могли сохраниться после его распада или отсутствовать при работе с другими носителями. Для initial flow сначала проверь конструкцию Штаба по §2.0. --- ## Шаг 2. Initial flow (день-0) > Цель: запустить пользователя со старта. Никакого session-prep, никакого ревью прошлой недели — их ещё нет. ### 2.0. Создание Штаба до первой сессии Это подготовительная работа отдельной системы создания Штаба, а не первый этап сессии. С тем же человеком и доступными средствами установи: кто владеет решениями; какое физическое место сейчас развёрнуто для работы; какая ИИ-среда или подручные средства доступны; где сохраняются стратегия, неудовлетворённости, реестр РП и план недели; кому назначены роли Стратега и Плановика; как продолжить после замены агента или среды. Сначала зафиксируй, собрана ли минимальная конструкция Штаба по критерию выше; если нет — помоги её собрать. Затем отдельно проверь готовность к первой сессии: первые наблюдения, доступные записи, ответственный за решение и сценарий. Недостающее подготовь вместе с человеком до перехода к 2.1. Установка IWE, создание Штаба и первая сессия не становятся одним событием от того, что их выполняют подряд. Скажи пользователю: > «Это первая стратегическая сессия. Пройдём 4 шага: цели → неудовлетворённости → первый WeekPlan → MEMORY.md.» ### 2.1. Цели (5 мин) Спроси: - «Кем хочешь быть через год?» - «Чему хочешь научиться?» - «Какие 2-3 крупные цели на ближайшие 3-6 месяцев?» Запиши ответы в `$GOV_WT/docs/Strategy.md` по структуре: - Видение (1 год) - Цели на горизонт (3-6 месяцев) - Принципы (что для меня важно) ### 2.2. Неудовлетворённости (5 мин) Спроси: - «Что сейчас мешает? Где разрыв между текущим и желаемым?» - «Что регулярно раздражает или забирает энергию?» Запиши в `$GOV_WT/docs/Dissatisfactions.md` списком: каждая неудовлетворённость = 1-2 строки. ### 2.3. Первый WeekPlan (10 мин) На основе целей + неудовлетворённостей предложи 3-5 кандидатов в РП на ближайшую неделю. Пока человек не подтвердил выбор, это варианты, а не принятые обязательства. Для каждого: - Название (существительное-артефакт) - Бюджет (часы) - Артефакт-критерий (что появится по завершении) После решения человека используй черновик `$GOV_WT/current/WeekPlan W{N}.md` (где N — номер ISO-недели). Только если файла ещё нет, создай его с пустой таблицей РП под заголовком «План». При возобновлении сохраняй существующий черновик и файловую запись сессии; сначала проверь уже созданные РП. Выполни раздел «Регистрация РП перед утверждением» ниже для каждого выбранного нового РП через `/wp-new`. Просто вписать выбранные названия в WeekPlan недостаточно. До завершения регистрации и проверки всех записей сохраняй `status: draft`. ### 2.4. Обновление MEMORY.md (2 мин) Синхронизируй «РП текущей недели» в `${IWE_ROOT:-$HOME/IWE}/memory/MEMORY.md` по проверенной таблице из 2.3 (это может быть симлинк на память рантайма). Используй тот же корень установки, что и при регистрации. Проверь номера и названия, включая новые РП со статусом `pending`. Только после итоговой проверки из раздела ниже поставь WeekPlan `status: confirmed`. ### 2.5. Закрытие initial-сессии Только после явного утверждения первого WeekPlan человеком удали маркер `IWE-INITIAL-NEEDED` из `$GOV_WT/docs/Strategy.md`. Если сессия прервалась или план остался черновиком, сохрани маркер, чтобы следующий вызов вернулся к initial flow. Скажи: «Готово. Завтра утром можешь сказать "открывай день" — назначенный исполнитель подготовит план дня. По понедельникам в 04:00 автоматически готовится черновик для следующей сессии.» **Extensions (after):** `bash .claude/scripts/load-extensions.sh strategy-session after` → Exit 0: Read каждый файл, выполнить. Exit 1: пропустить. --- ## Регистрация РП перед утверждением **Обязательно для всех режимов:** initial §2.3–2.4 и общий шаг `strategy-session-weekly/steps/08-confirm.md` недельной и месячной сессий. Агент выполняет этот порядок после утверждения человеком конкретного списка РП, до `status: confirmed` и публикации плана. Отдельного порога часов нет: каждый новый РП из принятого плана получает карточку и строку реестра. 1. **Различи существующие РП и новые кандидаты.** Проверь карточки в `$GOV_WT/inbox/WP-{N}/WP-{N}.md` и строки `$GOV_WT/docs/WP-REGISTRY.md`. Carry-over сохраняет номер и карточку. Новых кандидатов до регистрации показывай отдельным списком без окончательных номеров; не добавляй их второй таблицей РП/Статус. Утверждение конкретного списка покрывает согласие на создание именно этих РП; повторно спрашивать по одному не нужно. Это не отменяет требований `/wp-new`: сохранённый результат Артефактора, класс проверки, бюджет и отдельный consent-маркер перед каждым вызовом. Изменение состава или содержания принятого списка требует нового решения человека. 2. **Подготовь место записи.** Используй только `GOV_WT`, проверенный в шаге 0. В текущем WeekPlan должна быть одна целевая таблица под заголовком «План» с колонками `🚦 / # / РП / h / Источник / P / Статус / Результат` (существующую поддерживаемую схему можно сохранить). На первой установке создай заголовок и разделитель таблицы без строк кандидатов. Если в `current/` несколько WeekPlan, проверь, что выбираемый `create-wp.sh` файл (`WeekPlan*.md`, обратный порядок имён) — именно согласуемый план; при расхождении остановись до записи и уточни целевой план. Не меняй чужую неделю молча. 3. **Перед каждым созданием проверь повтор.** Сверь номер из файловой записи этой стратегической сессии и карточку; запись должна связывать выбранный кандидат, путь сохранённого JSON Артефактора и выданный номер. После обрыва до записи номера ищи среди `$GOV_WT/inbox/WP-*/WP-*.md` карточку по `artifactor_result_sha256` исходного JSON и сопоставь название, бюджет, репозиторий и критерий результата. Совпадение только названия либо отсутствие `wp` в JSON не доказывает повтор. Единственное подтверждённое создание — используй его номер и доведи синхронизацию без повторного вызова скрипта. Неоднозначность, историческая строка с номером без карточки или карточка без строки реестра — остановка до создания; предъяви адресный ремонт с сохранением номера. Не выдавай новый номер для маскировки повреждённой регистрации. 4. **Зарегистрируй каждый действительно новый РП через `/wp-new`.** Выполни его шаги с контекстом `GOV_WT` и сохранённым JSON. Не обходи consent/Артефактор-гейты и не заменяй вызов ручной строкой WeekPlan. Номер и фактический путь карточки бери из результата `create-wp.sh` (например, номер `1` и путь `WP-001/WP-001.md`). Сразу запиши соответствие кандидата и номера в существующую файловую запись стратегической сессии, до следующего кандидата. В строке, созданной скриптом в WeekPlan, дополни согласованные источник, режим ТВС, бюджет и критерий результата, добавь ссылку на фактическую карточку; второй строки не создавай. В карточке сохрани источник `R{N}` / `S-НЭП-X` и связь с `H-NNN`, если она есть, вместе с критерием готовности. Связь с целью должна пережить архивирование WeekPlan. `--repo` описывает репозиторий результата; карточка остаётся в governance-репозитории. Если после создания файловая запись сессии недоступна, начни восстановление с фактического пути карточки из сохранившегося вывода `create-wp.sh`. Сверь данные карточки и строки реестра/плана, затем восстанови связь кандидата и номера. Если вывод тоже утрачен, используй поиск из п.3; отсутствие однозначного свидетельства означает остановку, а не новое создание. 5. **Проверь фактические записи.** Для каждого выбранного РП проверь существование карточки, совпадение её поля `wp` с номером в отдельной ячейке реестра и плана, название и ровно одну строку в реестре и в единственной рабочей таблице «План» выбранного WeekPlan. Исторические упоминания вне этой таблицы не считай её строками; неоднозначность выбора таблицы разреши по п.2. Учитывай формы `1`, `WP-1`, `WP-001`; поиск подстроки `WP-1` не годится (он зацепит `WP-10`). Проверь пересобранный `current/active-wp.md`. Ненулевой код, предупреждение о пропущенной записи или отсутствие любой обязательной записи останавливают всю последовательность: следующий РП не создавай, WeekPlan оставь `draft`, сообщи конкретные недостающие записи. После ошибки проверь диск даже при сообщении об откате. Уже созданные РП сохрани для восстановления; не удаляй их и не повторяй создание вслепую. Нулевой код сам по себе не подтверждает запись WeekPlan или active-wp. Эту проверку выполняет скрипт, а не чтение глазами; ненулевой код — остановка, подтверждать план нельзя. Подставь номер РП и выбранный WeekPlan: ```bash : "${GOV_WT:?GOV_WT не задан — задай явно}" bash "$IWE_SCRIPTS/check-wp-registered.sh" "{N}" "$GOV_WT" "$GOV_WT/current/WeekPlan W{W}.md" || { echo "регистрация не согласована" >&2; false; } ``` 6. **Синхронизируй память и подтверди план.** Обнови раздел «РП текущей недели» в `${IWE_ROOT:-$HOME/IWE}/memory/MEMORY.md` по проверенному WeekPlan, включая `pending`; остальную память сохрани. Если файла нет, создай минимальный раздел по правилам установки. Если скрипт `memory-active-wp-update.sh` доступен, его можно использовать только после проверки, что он читает тот же `GOV_WT`: загрузка настроек может вернуть его к канону. Нет маркеров `ACTIVE-WP-START/END`, скрипт пропустил строку или недоступен — синхронизируй раздел вручную и проверь результат. Не утверждай план, если память не удалось записать. Только когда карточки, реестр, WeekPlan, active-wp и MEMORY согласованы для всего принятого списка, поставь `status: confirmed`. Это последовательная регистрация с проверкой перед утверждением, **не общая атомарная транзакция** всех РП и файлов. Повтор после частичного выполнения продолжает проверку сохранённых записей. ## БЛОКИРУЮЩЕЕ: один шаг за раз > Нарушение этого правила делает сессию бессмысленной — пилот не вносит свои данные, решения принимаются без него. **После выполнения ЛЮБОГО шага — СТОП.** Не читать следующий шаг, не продолжать. Ждать сообщения пилота. Следующий шаг — только после его ответа. Это правило действует даже после compaction, даже если gate = `auto`, даже если «очевидно что делать дальше». --- ## Шаг 3. Weekly flow Если режим = weekly: Загрузи `{{IWE_TEMPLATE}}/roles/strategist/prompts/strategy-session-weekly.md` (если файл отсутствует → `bash update.sh`) и следуй ему целиком — начни с его собственного гейта «Обзор сессии» и канонической таблицы шагов. Условия перехода на полную сессию (`strategy-session-monthly.md`) и место проверки weekly-stop-gate заданы в недельном файле. Не предвосхищай эту проверку и не выбирай переход по отдельной эвристике диспетчера. (Не добавлять в этот диспетчер собственную прозу про ревью/неудовлетворённости/стоп-критерий — только делегация выше; найдено живьём 20.10.2026, РП-518 Ф17, третий повтор одного класса разрыва за 12.10/19.10/20.10 — полная история → `inbox/WP-518/WP-518.md` Ф17.) **Ориентиры дня — спросить пилота КАЖДУЮ неделю (найдено 01.09.2026, WP-484 Ф148 — без явного вопроса «Бюджет дня» в DayPlan считался автоматически суммой оценок портфеля и доходил до нескольких сотен часов, что физически бессмысленно для одного дня):** - «Сколько физических часов в день реалистично закладывать на эту неделю?» — записать в `current/priorities.yaml: phys_hours`. Если пилот не называет новое число — держать прошлое значение (не спрашивать заново тем же вопросом на каждой сессии, если ответ уже стабилен). - «Сколько часов по РП (сумма колонки `h`) разумно паковать в план ОДНОГО дня?» — держать как ограничение при упаковке дня, наравне с WIP-лимитом (8-15 пунктов): день не должен получать многонедельные оценки сразу нескольких РП целиком, только реалистичную дневную порцию. Оба числа — ориентир пилота на всю неделю (не берутся из календаря и не считаются автоматически скриптом): пилот прямо сказал 01.09.2026, что это его сознательный выбор, не то, что можно вывести из данных. **Extensions (after):** `bash .claude/scripts/load-extensions.sh strategy-session after` → Exit 0: Read каждый файл, выполнить. Exit 1: пропустить. Если weekly перешёл в monthly, выполнить after по monthly-сценарию после его завершения; повторно здесь не вызывать.