manager

# Manager — двусторонний мост между сессией и GitHub issues

## Железные инварианты — читать первым, повторять перед каждым синком

**1-3 обязательны для любого issue, который трогает manager. 4-5 добавляются для активного issue текущей недели. 6-9 действуют в режиме записи и при закрытии.**

1. **W-label** — текущая неделя, будущая неделя или дата конкретной менторской сессии. Нет в репо — создать.
2. **Родительский эпик** — ровно один parent через GitHub Sub-issues API. Всё, что не эпик само, имеет parent. Подробно: [reference/parent-epic-rules.md](reference/parent-epic-rules.md).
3. **Трек различается по title + членству в эпике** — track-labels (`x26-bloom`, `ai-native-s2` и т.п.) больше не заводим.
4. **Project placement** — активный issue текущей недели стоит на канонической GitHub Project-доске своего слоя и в глобальном недельном Project `ris © corp` / Project `#4`. W-label без Project placement = `Расхождение Project`.
5. **Родитель виден в Project** — для активного child одного `parent_issue_url` мало. Видимый parent/root эпик тоже должен быть в нужном Project view с непустой status lane.
6. **Комментарий-запись о работе** (режим записи, только при РЕАЛЬНОЙ работе по issue) — GitHub-комментарий в таймлайне: что сделано + ссылки на коммиты. Смена status/label/Project placement его **не заменяет**. Чисто механический re-label или Project-fix — **без** комментария.
7. **Дробность задач: никакого чат-журнала** — если по треку появилось больше одного самостоятельного следующего шага или founder говорит, что за ходом тяжело следить, не превращать один issue в длинный журнал. Parent/track issue держит короткий канон: `Status`, `Next issues`, `Decisions`. Исполняемые шаги выносить в отдельные child/sibling issues под тем же эпиком — с W-label, Project placement и понятным критерием готовности.
8. **Чек-лист закрытия** — закрывать issue можно, только когда: (а) нерешённые развилки и секция «Открыто» из тела перенесены в отдельный открытый issue; (б) каждый follow-up с датой вписан в `tasks/WNN/<дата>.md` своей даты; (в) параллельные открытые issues того же контура закрыты комментом-указателем «продолжение в #N» либо оставлены открытыми с причиной.
9. **Переход «нетронута → In progress» и запись предложений/драфтов в issue** — при создании задача находится в статусе `Backlog` / Untouched (не тронута). Как только по задаче появилось первое предложение, черновик текста, драфт поста, спецификация или решение:
   - Статус задачи (в Project и body) **ОБЯЗАТЕЛЬНО переводится в `In progress`**.
   - Само подготовленное предложение/драфт/спецификация **записывается прямо в тело задачи** (в `## Proposed draft / solution` или `## Updates`), чтобы наработки и варианты не терялись в чате сессии.

**Если родительского эпика нет ни в одном репо** — вынести в предложение founder'у: создать новый или выбрать существующий, **до** синка.

**ВАЖНО:** не использовать generic-скиллы `github-issues` / `gh-issues`. Manager сам является каноническим workflow.

---

## Выбор режима

**Режим записи:** founder сказал «синкни сессию», «зафиксируй», «обнови issues», ИЛИ вызвал `/manager` без аргументов в конце сессии.

**Режим чтения:** founder спросил о состоянии — «что по», «статус», «есть ли», «какие issues по».

**Режим среды (денежный gate):** «/manager midweek», «mid-week gate», «среда-чек», ИЛИ автозапуск по расписанию в среду утром. Агент инициирует сам, founder не просит. По умолчанию ничего не пишет в GitHub, но цель не статус-справка, а раннее предупреждение по денежным обещаниям недели — пока неделя ещё не сгорела.

**Голый `/manager`:** вывести артефакты из текущего разговора. Не просить founder'а перечислять всё заново. Составить короткий план исполнения (5-15 строк) и сразу выполнить — постоянное разрешение действует.

**Manager НЕ используется для:** идей без артефактов (это брейншторм); закрытия issue без явной команды founder'а; **пакетных обновлений CRM** — это CRM-процессы в репо `crm`, не manager.

Подробный алгоритм обоих режимов: [reference/modes-read-write.md](reference/modes-read-write.md).

---

## Постоянное разрешение на запись

Founder подтвердил: GitHub-записи manager'а разрешены по умолчанию. После тихой преднастройки и короткого плана исполнять точечные GitHub-записи **не спрашивая** отдельное «подтверди».

Покрыто: правки body, комментарии-записи о работе (инвариант 6), создание W-label, привязка parent/sub-issue, Project placement, статус `In progress` на затронутых активных issues, assignee `@me` (founder) по умолчанию, правки дневного плана в `tasks/WNN/YYYY-MM-DD.md`, создание issue, когда эпик, репо и рамка очевидны.

Спрашивать только когда: нет подходящего эпика; неясно, чей это репо или трек; риск приватности в публичном репо; разрушительные или массовые изменения; закрытие issue, чья рамка явно не выполнена.

---

## Преднастройка (ЖЁСТКОЕ ПРЕДУСЛОВИЕ)

**Выполнить до ЛЮБОЙ команды `gh search`, `gh issue` и прочих GH-вызовов.** Бюджет вывода в чат: 0 строк. Полный алгоритм: [reference/search-algorithm.md](reference/search-algorithm.md) → «Pre-flight».

1. **Прочитать `~/Documents/obsidian/0_hq/tasks.md` ПЕРВЫМ** — это курируемый индекс: Project ID, активные треки, указатели на репо. Без него поиск бьёт наугад.
2. Снять снимок Project #4: `gh project item-list 4 --owner serejaris --format json --limit 1000 > /tmp/manager-proj4.json` (один раз за прогон; `--limit 1000` обязателен).
3. **Страж дрифта HQ** — если активная задача в `tasks.md` без `repo#N`, вывести `Расхождение HQ tasks`.
4. Тихо проверить git status; показать только незакоммиченные артефакты, названные в сессии.
5. Вычислить ISO-неделю, если `tasks.md` устарел.

**Красный флаг:** собираешься запустить `gh search issues`, не прочитав `tasks.md` — СТОП.

---

## Где правда

| Нужно | Источник |
|---|---|
| Текущая неделя, активные треки | `~/Documents/obsidian/0_hq/tasks.md` (читать ПЕРВЫМ) |
| Сегодняшний план | `tasks/WNN/YYYY-MM-DD.md` + `tasks/WNN/README.md` |
| Отдельные задачи | GitHub issues в `serejaris/*`