Parking

Парковка контекста

Ты выполняешь протокол парковки — фиксируешь текущее состояние работы, чтобы любая будущая сессия (или возврат в этом же чате) могла восстановить контекст с точки остановки.

Зачем это нужно

Переключение контекста стоит ~23 минуты на восстановление фокуса (исследование Ophir & Nass). Без явной точки возврата исходная задача теряется — особенно когда контекстное окно забивается новым материалом. Парковка решает эту проблему: она создаёт формализованную «хлебную крошку», которая переживает и этот чат, и следующий.

Модель роутинга задач

Парковка работает в рамках task-routing-модели (см. task-routing-methodology-2026-04.md и Правила 10–14 AGENTS.md). Ключевые инварианты:

• plan.md — медленный контракт проекта (Goal, Milestones, Blockers, Drift Guard, Contingency). Парковка обязательно меняет plan.md §Blockers, если тип прерывания — BLOCKED или DELEGATED с milestone-impact. Блокеры — first-class сущность плана, не секция tasks.md. См. §5.4 методологии.
• tasks.md — execution queue. Маркер PAUSED идёт сюда только если это NEED_INFO шаг текущего milestone (тактический сбор информации). Размышление («надо разобраться с X») идёт в plan.md как open question под milestone, не в tasks.md. Секции Blocked в tasks.md нет — она переехала в plan.md §Blockers.
• 01_now/ops/<contour>/delegations/<slug>.md — если парковка произошла потому, что задача делегирована сотруднику, маркер идёт сюда. Если блокирует milestone — параллельно запись в plan.md §Blockers с Тип: delegated-work.
• 01_now/personal/tasks.md — личное внешнее обязательство владельца. Парковка не порождает личных строк — это событие маршрутизации, а не тип прерывания.
• 00_inbox/ — только для «случайной идеи», у которой нет ни проекта, ни домашнего контура. Опять же — не парковка, а routing.

💡 SPAWNED — категориальная ошибка. Появление новой идеи в ходе работы над основной задачей — не тип прерывания, а событие маршрутизации: идея уходит в свой целевой файл (plan.md другого проекта, personal/tasks.md, 00_inbox/, delegations/), и работа продолжается без парковки. В типах PAUSED этого маркера больше нет.

Протокол (выполняй строго по шагам)

Шаг 1. Определи проект и задачу из контекста беседы

Проанализируй текущий чат и определи:

• Проект: к какому проекту из 01_now/projects/ относится работа. Если не относится ни к одному — укажи «вне проекта» и выбери destination по типу (см. Шаг 4): личное → 01_now/personal/tasks.md, curiosity → 00_inbox/.
• Задача: что конкретно делали (не «работали над проектом», а «дописали 3 из 5 пунктов анализа unit-экономики»).
• Точка остановки: на чём именно прервались — максимально конкретно.
• Влияет ли прерывание на вектор проекта? Если да — на Шаге 3 обновляется plan.md, не только log.md.

Шаг 2. Классифицируй тип прерывания

Определи тип автоматически из контекста разговора. Не спрашивай пользователя, если тип очевиден.

Маркер	Тип	Когда использовать	Триггер возврата
⏸️ BLOCKED	Жду внешнего события / результата из другого проекта / ответа клиента / дедлайна	Мяч не у пользователя, и никакого действия, приближающего результат, у него нет. Включает cross-project dependency и external-event.	Получен ответ / прошёл дедлайн / сработал fallback
🔀 DELEGATED	Отдал в проработку сотруднику	Задача в работе у делегата, SoT — трекер или delegations/<slug>.md	Результат готов, нужно проверить
🔍 NEED_INFO	Нужно найти/изучить	У владельца есть action, который приблизит результат (читать, спрашивать, пробовать) — это тактический execution-шаг, не блокер	Информация найдена и структурирована
⏹️ STOPPED	Просто остановился	Конец сессии, нет конкретного блокера	Следующая сессия по этому проекту

Правило дизамбигуации BLOCKED vs NEED_INFO: если тип неочевиден — спроси одним коротким вопросом: «У тебя есть действие, которое приблизит результат, или ты просто ждёшь?». Есть действие → NEED_INFO. Нет действия → BLOCKED.

Маркера 💡 SPAWNED больше нет — новая идея/задача не паркуется, а маршрутизируется в свой целевой файл без прерывания основной работы (см. §«Модель роутинга задач» выше).

Шаг 3. Обнови plan.md — first-class слой

Это первый слой записи. Порядок «медленные слои опережают быстрые» (write-protocol.md §5) означает, что plan.md всегда обновляется раньше log.md, tasks.md, delegations/.

По типу прерывания:

Тип	Что пишется в plan.md
⏸️ BLOCKED	Новая карточка в ## Blockers (Bx, с полями: Открыт, Тип, Ждём, Блокирует, Моё действие, Условие возврата, Fallback, Stale check) + статус каждого затронутого milestone меняется на blocked on Bx
🔀 DELEGATED без milestone-impact	plan.md не меняется — запись идёт только в delegations/<slug>.md
🔀 DELEGATED с milestone-impact (блокирует milestone)	Новая карточка в ## Blockers с Тип: delegated-work, параллельно записи в delegations/<slug>.md
🔍 NEED_INFO тактический	plan.md не меняется — строка идёт в tasks.md §Next
🔍 NEED_INFO стратегический (меняет вектор)	Правка в §Milestones или §Drift Guard — это не блокер, а изменение плана
⏹️ STOPPED	plan.md не меняется — запись только в log.md

Если первоначальный подход оказался тупиком, scope поменялся, milestone потерял смысл — это всегда правка plan.md в §Milestones / §Drift Guard / §Contingency, а не блокер.

Шаг 4. Запиши стоп-кадр в log.md проекта

Открой 01_now/projects/<project>/log.md и добавь запись в формате:

- YYYY-MM-DD: <МАРКЕР> PAUSED | Задача: <что делали>.
  Остановился на: <конкретная точка>.
  Причина: <почему переключаемся>.
  Действие: <что сделано для разблокировки — кому написал, что делегировал, куда записал идею>.
  Вернуться когда: <триггер возврата>.

Нейтральный пример:

- 2026-03-07: BLOCKED PAUSED | Задача: пересчитать модель запуска.
  Остановился на: собрал все метрики кроме одного входного показателя.
  Причина: нет подтверждённых данных от ответственного.
  Действие: записал делегирование в файл ответственного.
  Вернуться когда: получу данные или через 3 дня.

Для типа ⏹️ STOPPED формат короче:

- 2026-03-07: ⏹️ STOPPED PAUSED | Задача: <что делали>.
  Остановился на: <конкретная точка>.
  Следующий шаг: <что делать при возврате>.

Шаг 5. Создай/обнови маркер-задачу в целевом файле

Выбор файла жёстко зависит от типа прерывания:

Тип	Куда идёт маркер	Формат
⏸️ BLOCKED	<project>/plan.md §Blockers — новая карточка Bx + blocked on Bx на затронутых milestone'ах	карточка блокера со всеми полями (см. Шаг 3)
🔀 DELEGATED без milestone-impact	Только 01_now/ops/<contour>/delegations/<slug>.md Active	- [ ] YYYY-MM-DD → <суть> [tracker-link] • due: <дата> • [контекст](chat-or-log-ref)
🔀 DELEGATED с milestone-impact	delegations/<slug>.md Active + plan.md §Blockers Bx (Тип: delegated-work) со ссылкой на строку в delegations	карточка блокера + lean-index строка, двусторонне связанные
🔀 DELEGATED без трекера	delegations/<slug>.md с пометкой tracker_sot: none + plan.md §Blockers если блокирует milestone	карточка блокера + lean-index без tracker-link
🔍 NEED_INFO тактический	<project>/tasks.md §Next	- [ ] 🔍 <собрать X> → <что после> (YYYY-MM-DD)
🔍 NEED_INFO стратегический	<project>/plan.md §Milestones или §Drift Guard	правка плана, не строка-маркер
⏹️ STOPPED	Только запись в <project>/log.md (см. Шаг 4). tasks.md §Active остаётся как есть	—

Convergence rule для delegated-work blockers: если сотрудник перестаёт блокировать milestone (делегирование выполнено или больше не критично), блокер закрывается по ritual §5.4.2 методологии — карточка переезжает в ## Blockers — Resolved, статус milestone снимается, строка в delegations/<slug>.md переходит в Done (7d).

Нейтральный пример карточки блокера в plan.md:

### B1 — Недостающий показатель от ответственного
- Открыт: 2026-03-07
- Тип: delegated-work
- Ждём: подтверждённый показатель, чтобы пересчитать модель
- Блокирует: M3
- Моё действие: напомнить ответственному через 3 дня
- Условие возврата: получены подтверждённые данные
- Fallback: взять оценку из последнего отчёта и пометить как приближение
- Stale check: 7 дней

Нейтральный пример параллельной строки в delegations/responsible.md:

- [ ] 2026-03-07 → собрать недостающий показатель [TRACKER-123](url) • due: 2026-03-10 • ссылка на `plan.md#b1`

Шаг 6. Подтверди парковку

Ответь пользователю одним коротким сообщением в формате:

Припарковался. [Проект X] — записал стоп-кадр в log.md, маркер в [целевой файл]. (если применимо) plan.md обновлён: [что изменилось]. Точка остановки: [краткое описание]. Триггер возврата: [условие]. Можем переключаться.

Пример с делегированием:

Припарковался. 2026-example — log.md, делегирование в ops/2026-example/delegations/responsible.md. Точка остановки: собрал все метрики кроме одного показателя. Триггер возврата: ответственный присылает данные или 2026-03-10. Можем переключаться.

Ограничение глубины переключений

Если пользователь уже находится на первом уровне переключения (ушёл от основной задачи A к сервисной B) и хочет нырнуть ещё глубже (задача C) — заблокируй:

«Это второй уровень переключения. Записываю задачу [C] в tasks.md/inbox — вернёмся к ней отдельно. Сейчас заканчиваем [B] или паркуемся и возвращаемся к [A].»

Максимальная допустимая глубина: 1 уровень.

Протокол «длинный чат»

Если в текущем чате уже было 2+ парковки или диалог явно длинный и многотемный — предупреди:

«Чат стал длинным. Рекомендую продолжить в новой сессии — я подхвачу контекст из log.md при вызове /resume.»

Проактивная парковка

Если пользователь начинает говорить о другом проекте/задаче без явной команды парковки, и при этом в текущем чате шла содержательная работа — предложи:

«Вижу, что переключаемся. Сделать стоп-кадр по [текущая задача], чтобы не потерять точку возврата?»

Не навязывай — если пользователь говорит «не надо» или переключение тривиальное (короткий вопрос, не требующий глубокого погружения) — пропусти.