Strategy Session

---
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. Утверждение | Человек утверждает, исполнитель сохраняет | Черновик недели и решения | Проверить и закрепить | Утверждённый план недели |

Короткая недельная сессия использует только нужные этапы из этого маршрута; первая сессия не является его сокращённым повтором и описана в §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 <WP-N>), затем повтори этот шаг внутри копии: (cd -- \"<worktree_path>\" || 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 внутри копии; `<CANON_C>` и `<GUARD>` — пути из сообщения `NOT ISOLATED`. Переход в каталог — только в подоболочке `( … )`: верхнеуровневый `cd` хук `destructive-guard.sh` блокирует.
  ```bash
  (cd -- "<CANON_C>" && bash "<GUARD>" open --isolate --wp <WP-N>)
  ```
  ```bash
  (cd -- "<worktree_path>" || 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`, затем публикация из копии, в канон не коммить. Ветка назначения `main` задаётся явно (`--branch main`): `session-guard.sh open --isolate` создаёт копию от `origin/main` на её собственной ветке `session-isolate/<agent>-<session>`, которой на сервере нет. `--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; }
  git -C "$GOV_WT" rev-parse -q --verify origin/main >/dev/null || { echo "ERROR: в копии $GOV_WT нет origin/main, публикацию не с чем сравнить" >&2; exit 1; }
  COMMITS=$(git -C "$GOV_WT" rev-list --reverse origin/main..HEAD) || { echo "ERROR: не удалось получить список коммитов копии $GOV_WT" >&2; exit 1; }
  [ -z "$(git -C "$GOV_WT" status --porcelain)" ] || echo "ВНИМАНИЕ: в копии есть незакоммиченные изменения, они не опубликованы: закоммитьте их" >&2
  [ -n "$COMMITS" ] || { echo "Публиковать нечего: в копии нет коммитов, которых нет на origin/main"; 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 main || 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
SESSIONS_DIR=$(source "{{WORKSPACE_DIR}}/scripts/lib/common.sh" 2>/dev/null && iwe_sessions_dir 2>/dev/null) || SESSIONS_DIR="$GOV_WT/sessions"
grep -rl "strategy-session\|Strategy Session" \
  "$SESSIONS_DIR/$(date +%Y-%m)-"*.md \
  "$SESSIONS_DIR/$(date +%Y-%m)/" 2>/dev/null
)
```
Первая сессия месяца = дата сессии ≤7 числа месяца И поиск выше пуст. Журнал сессий берётся из `iwe_sessions_dir` (общий журнал вне копии), при его отсутствии из `$GOV_WT/sessions`.

> **Найдено платформенным аудитом 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-недели). До его утверждения план остаётся черновиком.

### 2.4. Обновление MEMORY.md (2 мин)

В `~/.claude/projects/{{CLAUDE_PROJECT_SLUG}}/memory/MEMORY.md` добавь раздел «РП текущей недели» со списком из 2.3.

### 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: пропустить.

---

## БЛОКИРУЮЩЕЕ: один шаг за раз

> Нарушение этого правила делает сессию бессмысленной — пилот не вносит свои данные, решения принимаются без него.

**После выполнения ЛЮБОГО шага — СТОП.** Не читать следующий шаг, не продолжать. Ждать сообщения пилота. Следующий шаг — только после его ответа. Это правило действует даже после compaction, даже если gate = `auto`, даже если «очевидно что делать дальше».

---

## Шаг 3. Weekly flow

Если режим = weekly:

### 3.1 Обход Backlog (B-005, обязательно)

Прочитай `$GOV_WT/docs/Backlog.md`. Для каждой записи `B-NNN` в разделе `## Активные записи`:

- Проверь триггеры открытия (`Триггер открытия:` блок в записи).
- **Hard-trigger сработал?** (внешнее событие случилось — например, `первый user-deletion request получен`, `legal review запланирован на эту неделю`, `Honcho API timeout ≥48ч`) — поднять для обсуждения в стратегической повестке: «B-NNN активирован, открываем РП?»
- **Soft-trigger подошёл?** (дата/процессная веха, например `при открытии WP-XXX-v2`, `при следующей ревизии DP.D.NNN`) — упомянуть в обзоре повестки как кандидата на следующие 1-2 недели.
- Ни один не сработал → оставить как есть, отметить «B-NNN живой, триггеров нет».

Если есть `??` (неопределённый статус) или `Дата открытия:` старше 90 дней без движения — пометить как кандидата на архивацию (`## Архивные записи`) с явным решением пилота.

**Цель шага:** Backlog не должен превращаться в dead inventory. Каждый Strategy Session — явная сверка триггеров.

### 3.2 Распаковка R1: discovery (Стратег) → планирование (Плановик)

> **Роль R1 распакована (РП378):** Стратег ведёт WHAT/WHY (discovery неудовлетворённостей,
> состояние, приоритеты месяца), Плановик (DP.ROLE.066) — HOW MUCH/WHEN (упаковка в неделю,
> бюджеты, WIP, дни). Граница — по типу решения, не по артефакту.

**Режим discovery (Стратег, этапы 1-4 — НЭП → приоритеты).**
Если приоритеты месяца устарели ИЛИ состояние пилота изменилось ИЛИ это первый месяц —
сначала разговор-распаковка: запусти `/discovery-session` (метод DP.METHOD.053). На выходе —
state-card + 3 топ-неудовлетворённости + ранжированные приоритеты месяца + ТОС-месяца. Это
**контекст приоритетов**, передаётся в планирование.

**Режим планирования (Плановик, этапы 5-6 — упаковка недели/дня).**
Если приоритеты актуальны (discovery не нужен) — Плановик ведёт неделю один (совместный
ритуал DP.SC.051). Загрузи `{{IWE_TEMPLATE}}/roles/strategist/prompts/strategy-session-weekly.md`
(если файл отсутствует → выполни `bash update.sh` или создай вручную; продолжи по базовому
шаблону WeekPlan из этого SKILL.md)
и следуй ему: упакуй контекст приоритетов в WeekPlan с бюджетами, распредели по дням, держи
WIP-лимит (8-15).

**Связка:** discovery даёт контекст приоритетов → планирование его упаковывает. Стратег
подключается к недельному ритуалу только при триггере пересмотра; иначе — Плановик один.

**Extensions (after):** `bash .claude/scripts/load-extensions.sh strategy-session after` → Exit 0: Read каждый файл, выполнить. Exit 1: пропустить.

<!-- USER-SPACE -->
<!-- /USER-SPACE -->