strategy-session
Стратегическая сессия — диспетчер. День-0 (нет Strategy.md/WeekPlan) → initial flow (цели, неудовлетворённости, первый WeekPlan). Первая сессия календарного месяца → полный monthly flow (стратегическа
SKILL.md.claude/skills/strategy-session/SKILL.md
GitHubStrategy 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, не от канона.
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блокирует.(cd -- "<CANON_C>" && bash "<GUARD>" open --isolate --wp <WP-N>)
Офлайн (нет сети,(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):GOV_WT="<записанный абсолютный путь>"; : "${GOV_WT:?}" (cd -- "$GOV_WT" || exit 1 <команды записи> ) - Публикация в конце:
mode=isolated-> коммит вGOV_WT, затем публикация из копии, в канон не коммить. Ветка назначения — резолвится изorigin/HEADкопии (main, если он не управляющая ветка — напримерmaster; падает обратно наmain, если симлинк не найден, #1209) и задаётся публикатору явно (--branch <DEFAULT_BRANCH>):session-guard.sh open --isolateсоздаёт копию от этой же ветки на её собственной ветке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 и сообщение, не «Публиковать нечего».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 donemode=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) всегда даёт «не найдено» и месячная сверка не срабатывает ни разу:
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:
Загрузи {{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: пропустить.