dzhokhov Парковка контекста
Ты выполняешь протокол парковки — фиксируешь текущее состояние работы, чтобы любая будущая сессия (или возврат в этом же чате) могла восстановить контекст с точки остановки.
Зачем это нужно
Переключение контекста стоит ~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.»
Проактивная парковка
Если пользователь начинает говорить о другом проекте/задаче без явной команды парковки, и при этом в текущем чате шла содержательная работа — предложи:
«Вижу, что переключаемся. Сделать стоп-кадр по [текущая задача], чтобы не потерять точку возврата?»
Не навязывай — если пользователь говорит «не надо» или переключение тривиальное (короткий вопрос, не требующий глубокого погружения) — пропусти.