Восстановление припаркованного контекста
Ты выполняешь протокол возврата — находишь все припаркованные задачи, показываешь пользователю, и после выбора загружаешь полный контекст проекта для продолжения работы.
Зачем это нужно
Каждая припаркованная задача — это незавершённый рабочий контекст, на создание которого были потрачены усилия. Без явного протокола восстановления эти точки теряются: пользователь забывает, что было припарковано, или тратит время на повторное погружение. Resume делает возврат дешёвым — агент сам подтягивает контекст и напоминает, на чём остановились.
Модель роутинга задач
Resume работает в рамках task-routing-модели (см. task-routing-methodology-2026-04.md и Правила 10–14 AGENTS.md). Это значит:
- Припаркованное состояние проекта может лежать в пяти разных местах, в порядке приоритета чтения:
<project>/plan.md §Blockers— первоклассные блокеры проекта (BLOCKED, DELEGATED-with-milestone-impact). Главный источник «что не даёт двигаться». Читается первым.<project>/tasks.md— шаги проекта с маркерами прерываний (NEED_INFO, STOPPED Active-step)<project>/log.md— записи PAUSED/RESUMED без активных блокеров (STOPPED)01_now/ops/<contour>/delegations/<person-slug>.md— открытые делегирования сотрудникам, из поляdue:можно вытащить статус01_now/personal/tasks.md— личные обязательства владельца (не через парковку, но могут всплыть по passive recall)
- При восстановлении контекста проекта порядок чтения служебных файлов: README → plan (включая §Blockers) → context → tasks → log (медленные слои опережают быстрые, как в write-protocol.md §5).
- Для каждого упомянутого в парковке сотрудника — passive recall по соответствующему
delegations/<slug>.md: что ещё висит на нём, нет ли related блокеров. - Маркера 💡 SPAWNED больше не ищем — новая идея не паркуется, она сразу маршрутизируется в свой целевой файл без прерывания (см. §5.4.4 методологии).
Протокол (выполняй строго по шагам)
Шаг 1. Найди все припаркованные задачи
Прочитай 01_now/README.md, чтобы получить список активных проектов. Затем для каждого проекта собери четыре класса припаркованного состояния в порядке приоритета:
Класс A — Активные блокеры (главный источник). Для каждого проекта прочитай <project>/plan.md §Blockers. Каждая карточка Bx там — активный блокер проекта. Посчитай возраст от поля Открыт: до текущей даты — пригодится на Шаге 4 для stale check. Эти блокеры — основная причина, почему работа по проекту стоит, и первое, что нужно показать владельцу.
Класс B — PAUSED в log.md. Прочитай <project>/log.md и найди записи с маркерами:
⏸️ BLOCKED PAUSED🔀 DELEGATED PAUSED🔍 NEED_INFO PAUSED⏹️ STOPPED PAUSED
Запись считается активной, если после неё в том же log.md нет соответствующей ▶️ RESUMED или ✅ RESOLVED Bx (для BLOCKED/DELEGATED). Не ищем 💡 SPAWNED PAUSED — этого маркера в новой модели нет.
Класс C — NEED_INFO в tasks.md. Прочитай <project>/tasks.md §Next и найди задачи с маркером 🔍 — это тактические шаги сбора информации, которые владелец оставил у себя (не блокер, а отложенное действие).
Класс D — Открытые делегирования. Прочитай 01_now/ops/<contour>/delegations/*.md секцию ## Active. Особое внимание: строки с прошедшим due: — это парковка, которая протухла.
Кроме того, при bootstrap проекта автоматически проверь 01_now/personal/tasks.md §Hard на обязательства, упомянутые в контексте парковки, — это passive recall, не отдельный класс.
Все четыре класса дают одну сводную картину припаркованного состояния.
Шаг 2. Покажи список пользователю
Выведи найденные парковки компактной таблицей:
Припаркованные задачи:
1. ⏸️ [2026-03-07] example-project — модель новых тарифов
Ждём: ответ от @Иванова по себестоимости
2. 🔀 [2026-03-05] personal-content — контент-план для канала
Делегировано: @Петрова, ожидаем драфт
3. ⏹️ [2026-03-06] travel-planning — бронирование жилья
Следующий шаг: сравнить 3 варианта по цене
Что продолжаем?
Если парковок нет — скажи: «Активных парковок не нашёл. Все записи PAUSED в логах имеют соответствующие RESUMED.»
Если пользователь уже указал конкретный проект или задачу в своём запросе (например, «resume click-ru» или «продолжи с unit-экономикой») — не показывай полный список, а сразу переходи к шагу 3 для этой задачи.
Шаг 3. Загрузи контекст проекта
После того как пользователь выбрал задачу (или ты определил её из запроса), загрузи контекст в порядке медленные слои → быстрые (как в write-protocol.md §5):
01_now/projects/<project>/README.md— what/why/границы01_now/projects/<project>/plan.md— медленный контракт проекта: Goal, Non-goals, Milestones, Blockers (первый проход — выполнить stale check каждой карточки Bx по полюОткрыт:и дефолтным порогам из §5.4.3 методологии), Blockers — Resolved, Drift Guard, Contingency. Это первое, что читается после README: без понимания плана и текущих блокеров нельзя разобрать шаги в tasks.md01_now/projects/<project>/context.md— устойчивые инварианты: термины, метрики, SoT, stakeholders01_now/projects/<project>/tasks.md— execution queue с маркерами прерываний01_now/projects/<project>/log.md— последние 5–10 записей для понимания хронологии- Для каждого упомянутого в парковке сотрудника — passive recall по
01_now/ops/<contour>/delegations/<person-slug>.mdсекция## Active. Покажи пользователю, что ещё висит на этом человеке, чтобы не терять смежные блокеры. Для каждого блокера вplan.md §Blockersтипаdelegated-work— убедись, что parallel-строка в delegations ещё актуальна - Если парковка относится к личному обязательству —
01_now/personal/tasks.md§Hard
Если у активного проекта нет plan.md (legacy, ещё не мигрирован) — сначала создай plan.md из шаблона, перенеси цель и текущий milestone из README.md / tasks.md, и только потом продолжай resume. После миграции добавь одну строку в log.md: «создан plan.md при resume-модернизации legacy-проекта».
Шаг 4. Восстанови контекст для пользователя
Кратко сообщи:
Загрузил контекст [проекта X]. Ты остановился на: [конкретная точка из PAUSED-записи]. Триггер возврата был: [условие]. [Статус: выполнен / не выполнен / неизвестно — уточни]. Текущий milestone по plan.md: [название + acceptance criteria]. Связанные задачи в tasks.md: [если есть]. Открытые делегирования на упомянутых людей: [если есть, из delegations/]. Продолжаем?
Если триггер возврата предполагал внешнее событие (ответ от человека, результат делегирования) — спроси, произошло ли оно: «Ответ от @Иванова получен?»
Если при чтении plan.md обнаружилось, что активный milestone уже не соответствует реальности (drift) — подсвети это отдельно: «plan.md говорит, что мы в milestone M1, но по log.md работа уже в M2 — нужно обновить plan.md перед продолжением».
Шаг 5. Запиши возврат в log.md
После подтверждения пользователя добавь запись:
- YYYY-MM-DD: ▶️ RESUMED | Задача: <исходная задача>.
Результат паузы: <что получили за время паузы — ответ, результат делегирования, найденная информация; или «без изменений»>.
Продолжаем с: <конкретная точка возобновления>.
Режим «обзор» (без выбора конкретной задачи)
Если пользователь спрашивает «что у меня подвисло» / «покажи все парковки» / «что я забыл» — выполни только шаги 1–2 (сканирование и показ списка). Не загружай контекст проекта, пока пользователь не выберет конкретную задачу.
В режиме обзора обязательно подсвети (не опционально):
- Stale блокеры в
plan.md §Blockers— если возраст карточки превышаетStale checkили дефолтные пороги (§5.4.3 методологии): >30d warn, >60d stale, >90d requires decision. Для >90d: «B1 висит 94 дня — нужно решение: снять через fallback, перевести в Contingency или закрыть milestone?» - Парковки PAUSED в log.md старше 7 дней — «Эта парковка висит уже N дней, стоит разобраться или закрыть.»
- Делегирования с прошедшим
due:— «В delegations/ivanov.md строка от 2026-03-07 имеет due: 2026-03-10 — просрочка 35 дней, нужно пнуть или снять.» - Парковки с просроченным триггером возврата — «Триггер "пнуть через 3 дня" истёк 2 дня назад.»
Быстрый resume в том же чате
Если /resume вызван в том же чате, где ранее была /parking — не нужно сканировать все проекты. Агент помнит контекст из этого чата и может восстановить точку напрямую:
Возвращаемся к [задача]. Ты остановился на [точка]. Продолжаем?