Планировщик

Модуль 05-planner переводит активную стратегию (strategy/current.yaml) в готовый к производству контент по трём уровням: period (арка на всё окно стратегии) → week (конкретная неделя, выведенная из арки, — слоты контента) → card+payload (один слот → production-ready карточка). Сам посты/слайды не пишет — готовит для production-модулей (06/07/08) полный валидированный payload или handoff.

/plan-period

Синтезирует period-plan.yaml — арку на всё окно стратегии: неделя-за-неделей тема + цель, плюс вехи.

Когда использовать. Запускай один раз после того, как собрана стратегия (/strategy), и каждый раз когда strategy.period меняется. Это верхний уровень: без него /plan-week неоткуда выводить конкретные недели.

Как вызвать

/plan-period <slug>

• <slug> — id аккаунта (например max-tors). Пуст — агент спросит.
• Режим определяется автоматически: synthesize (period-plan ещё нет) или refresh (окно strategy.period изменилось — пере-синтез арки).

Что на входе / на выходе

• Вход: strategy/current.yaml (period, content_pillars, bets, offer_focus, success_metrics, positioning_statement, current_focus).
• Выход: plans/period-plan.yaml — по одной записи (week, theme, goal) на каждую ISO-неделю окна, плюс milestones (эфир, старт продаж, дедлайны — с датами) и period.strategy_snapshot (ссылка на версию стратегии).

Пример

/plan-period max-tors

Агент читает окно стратегии и pillars, строит арку — на каждую ISO-неделю окна тема (1 строка) и цель (trust_builder | proof | warm | sales | retention), вносит вехи с датами из strategy/product- документов, показывает целиком и спрашивает, что подкрутить. После «сохраняй» пишет plans/period-plan.yaml.

Гейты/апрувы

• ГЕЙТ 1 — апрув человека обязателен. Без явного «сохраняй / ок» файл не пишется.
• Арка обязана покрывать всё окно периода — каждая ISO-неделя представлена.

Связанные: читает вывод /strategy; питает /plan-week.

/plan-week

Выводит конкретную неделю ИЗ арки period-plan.yaml в богатый current-week.yaml — слоты контента на 7 дней + cross-pollination + do_not + dependencies + success_checks. Заменяет legacy content-strategist.

Когда использовать. Запускай после /plan-period, когда нужен план слотов на текущую (или следующую) неделю — например в начале недели или когда прошлая неделя закрыта.

Как вызвать

/plan-week <slug> [--mode synthesize|refresh|manual]

• <slug> — id аккаунта.
• --mode synthesize (default) — вывести неделю из period-plan.
• --mode refresh — обновить уже существующую неделю.
• --mode manual — ты диктуешь слоты, агент форматирует (пропускает синтез, но всё равно прогоняет bets-mapping и богатые поля).

Что на входе / на выходе

• Вход: plans/period-plan.yaml (arc[<week>] — theme+goal рамка), strategy/current.yaml (pillars, bets, offer_focus, distribution_preferences), identity/channels.yaml (роли каналов), viral-db (viral_refs_for, get_trends), ideas/inbox/*.md, own-память (own_content_memory — прошлые own-посты по ER из viral-db, источник analytics).
• Выход: plans/current-week.yaml — distribution_mix, content_slots (id/date/platform/format/ pillar/topic/hook_seed/source/cta/status), bets_test (каждый bet стратегии → ≥1 слот), derived_from_period, cross_pollination, do_not, dependencies, success_checks. Плюс plans/archive/<prev-week>.yaml при переходе на новую неделю.

Пример

/plan-week max-tors

Агент проверяет, что period-plan и стратегия/каналы на месте, находит текущую ISO-неделю в arc, предлагает объём слотов (стартуя от distribution_preferences, если он задан в стратегии, иначе с нуля), раскладывает 1-2 слота в день Пн→Вс с pillar/topic/hook_seed/source, мапит bets на слоты, заполняет cross-pollination/do_not/dependencies/success_checks, показывает целиком и ждёт «сохраняй».

Гейты/апрувы

• ГЕЙТ 2 — апрув человека обязателен. Без явного «сохраняй / ок» — не пишем.
• Каждый слот обязан нести pillar verbatim из strategy.content_pillars.
• distribution_mix следует ролям channels.yaml — канал с role: none не планируется, даже если он в active_channels стратегии.
• Viral-ref в слоте — только реальный shortcode из ViralDB().viral_refs_for(), не выдумывается.
• Archive предыдущей версии недели перед записью новой (при переходе на новую неделю).

Связанные: выводится из /plan-period; слоты разворачивает /plan-card; пачкой по дню вызывается из /today.

/plan-card

Разворачивает один слот недели в production-ready planner-card.yaml + payload.yaml (для carousel) через критик-петлю. Это ядро стадии 2 — оркестраторный /today применяет те же шаги пачкой по слотам дня.

Когда использовать. Запускай точечно для одного конкретного слота из current-week.yaml, когда нужно собрать его в production-ready карточку вручную (вне батч-разворота /today).

Как вызвать

/plan-card <slug> <slot-id>

• <slug> — id аккаунта.
• <slot-id> — id слота из current-week.yaml (формат YYYY-MM-DD-pillar-keyword). Пуст — агент спросит.

Что на входе / на выходе

• Вход: plans/current-week.yaml (сам слот), own-память (planner_memory.own_content_memory — что уже делали и как зашло), strategy/current.yaml (do-not’ы, offer_focus), источник по source.type слота (ViralDB().get_analysis() для viral_ref, ideas/inbox/<id>.md для idea, ViralDB().get_trends() для trend), ViralDB().viral_refs_for() для рефа (carousel/reel), lead-magnets/ (ассет со status: ready).
• Выход: content/<type>/<slot-id>/planner-card.yaml (только если критик дал ready_for_production); для carousel — дополнительно content/carousel/<slot-id>/payload.yaml под контракт 06; для post — слот передаётся в /post --slot <slot-id>; для reel — в /create-viral-reel. Плюс регистрация карточки как own-контента в viral-db (память планнера).

Пример

/plan-card max-tors 2026-07-13-trust-hook

Агент находит слот в current-week.yaml, читает own-память и формирует planner_constraints, резолвит source_text и (для carousel/reel) viral_ref по shortcode из viral-db, подбирает lead_magnet со status: ready, собирает draft карточки, прогоняет её через критик (product fit, audience breadth, source/reference fidelity, lead magnet fit, CTA quality, funnel sanity, platform fit, status honesty) до 3 раундов. При ready_for_production пишет карточку, экспортирует payload (carousel) или передаёт хендофф (post/reel), регистрирует контент в памяти.

Гейты/апрувы

• Критик-петля непропускаема. До 3 раундов draft → критик → ревизия; без ready_for_production payload не экспортируется (export_payload падает ошибкой контракта), память не пишется.
• Нет подходящего viral_ref для carousel/reel → честный блокер needs_ref (кроме post — там реф опционален).
• Нет готового lead-magnet (status: ready) → честный блокер needs_lm.
• Reel без virality-analysis.md рефа в viral-db → блокер по слоту.
• Явного отдельного гейта на публикацию у этой команды нет — публикация под ручным апрувом идёт дальше по циклу, через /publish (модуль 12).

Связанные: источник слотов — /plan-week; payload/handoff уходит в /carousel, /post, /create-viral-reel; пачкой вызывается из /today; публикация — /publish.