End Session

---
name: end-session
description: Завершение сессии — обновление PLAN приложения, остановка таймера, коммит и retire agent-mail
allowed-tools: Bash, Read, Edit, Grep, Glob
---

Завершай сессию:

1. **Определи контекст работы** — над каким приложением/библиотекой шла сессия
2. **Обнови ПЛАН приложения** (не глобальный `PLAN.md` в корне репо):
   - Если у проекта есть `tasks/` ([tasks-per-file](/.claude/docs/tasks-per-file.md)) — итог и
     передача пишутся в файл задачи: `bun scripts/tasks.mjs note <ID> "…"` по ходу,
     `done <ID> --summary "…"` по завершении. `PLAN*.md` проекта не трогай: они заморожены.
   - Иначе: `apps/<name>/PLAN.md` — отметь выполненные задачи как `[x]`;
     `apps/<name>/PLAN_COMPLETED.md` — добавь итоги сессии с деталями реализации.
   - Если работали над несколькими приложениями — обнови каждый
3. **Глобальная очередь** (`tasks/` корня или `/PLAN.md`) — только если сессия затрагивала кросс-приложенческую работу (auth, libs, инфра, деплой)
4. **Не ретирь фиксированную identity agent-mail** (`<app>-dev`, координаторы вроде
   `deploy-agent-dev`/`forms-coordinator-dev`/`animatrona-coordinator-dev`/`repo-dev`). Она
   персистентная и переиспользуется следующей сессией того же приложения — `retire_agent` на неё
   ничего не даёт (сервер сам ретирит по простою) и только плодит orphan-состояния, из которых
   потом приходится восстанавливать identity вручную (разбор — `docs/plans/PLAN-INFRA-5.md` §93). Так уже
   устроен `/deploy-agent`: на завершении `deploy-agent-dev` не ретирится,
   только broadcast «ухожу» — бери это за образец. `retire_agent`/`expire_window` вызывай только
   для временной identity этой сессии (`<app>-dev-<задача>`, заведённая через `register_agent`
   по [agent-mail.md](/.claude/rules/agent-mail.md), раздел «Вторая сессия того же приложения»)
   — если такая была. Случайные имена вида `SunnyTower` не заводят.
5. **Если менялась `schema.zmodel` — проверь, что миграция создана.** `nx db:push` синхронизирует
   dev-БД без файла миграции — этого достаточно для локальной разработки, но не для деплоя:
   продовая БД накатывается только через файлы миграций (`prisma/migrations/`). Перед коммитом:
   - `git status apps/<name>/schema.zmodel` (или проверь, что `schema.zmodel` в списке изменённых
     файлов сессии) — если менялась;
   - убедись, что в `apps/<name>/prisma/migrations/` появилась новая папка, соответствующая
     изменению (`nx db:migrate <name>` создаёт её; голого `db:push` без последующего `db:migrate`
     недостаточно);
   - если миграции нет — создай её сейчас (`nx zenstack:generate <name>` → `nx db:migrate <name>`),
     не откладывай на следующую сессию: незакоммиченный дрейф схемы без миграции — то, что молча
     ломает деплой на этапе применения к прод-БД.
     Подробности воркфлоу — `.claude/docs/database.md`.
6. **Закоммить изменения** — добавь только файлы текущего приложения и закоммить их:
   ```bash
   git add <файлы этой сессии>
   git commit -m "<type>(<scope>): <описание>" -- <те же файлы>
   git show --stat HEAD   # убедись, что чужого WIP в коммите нет
   ```
   Следуй формату из `.claude/rules/git.md` (feat/fix/refactor/chore/style/docs).
7. **Оглянись на системные решения в монорепо** — просмотри код, к которому прикасалась сессия (и смежный контекст), на предмет:
   - дублирования логики/компонентов/утилит, которые стоит вынести в `libs/` и зашарить через `@letar/*` (shared-first — AGENTS.md § «Методология»)
   - мест, которые пора отDRYть (повторяющиеся паттерны в 3+ местах)
   - разросшихся файлов/функций, которые стоит декомпозировать
   - паттернов, которые уже устоялись в приложении и заслуживают документации в `.claude/docs/`

   Если находки есть — не применяй изменения самостоятельно, а заведи для каждой отдельный чип
   через `spawn_task` (заголовок-глагол, самодостаточный prompt с путями файлов, короткий tldr) —
   так пользователь сможет запустить каждую находку отдельной новой сессией одним кликом. После
   этого кратко перечисли в тексте, что заведено (файл, что не так, что предлагается).
   Если находок нет — прямо напиши, что предложить нечего.

   ⚠️ **Такая находка запускается позже как отдельная новая сессия** — время её выполнения не
   входит в таймер текущей сессии (он уже остановлен к тому моменту). Поэтому в `prompt`
   `spawn_task` включай инструкцию для будущей сессии самой стартовать `time_start` в начале
   своей работы — иначе время на неё нигде не запишется.
8. **Останови фоновые процессы, запущенные этой сессией** — background Bash/PowerShell-задачи
   (`run_in_background: true`) через `TaskStop` по их id, dev-серверы/preview, поднятые через
   `preview_start`, через `preview_stop` по `serverId`. Не трогай процессы, которые не заводила
   сама эта сессия (`tsgo`, `node`, `nx`, чужие `claude`-сессии других агентов) — репозиторий
   общий, параллельно работают другие агенты (`.claude/rules/git.md`,
   `.claude/rules/agent-mail.md`), и убийство процесса по имени вместо PID снесёт их работу.
   Если не уверен, что именно висит в фоне — перечисли активные background-задачи текущей сессии
   и останови только их.
9. **Открытые вопросы** — если за сессию остались нерешённые вопросы (недосказанность с
   пользователем, развилка, требующая его решения, недостающая информация) — не оставляй их
   только в чате. Если у проекта есть `tasks/` — заведи задачу:
   `bun scripts/tasks.mjs new <проект> "<суть>" --status blocked --blocked-by "kami: <что нужно>"`
   с коротким контекстом в «Что и зачем». Иначе занеси в `apps/<name>/PLAN.md` (или в
   глобальный `PLAN.md`, если вопрос кросс-приложенческий) с пометкой
   `[ ] ⚠️ Открытый вопрос: <суть>`. Так вопрос не потеряется между сессиями.
10. **Закрой завершённые этапы (`ProjectStage`) ДО остановки таймера.** Если за сессию хоть один
    вызов `time_start`/`time_switch` передавал `stage: "<название>"` — по каждому такому названию
    задача завершена или нет, реши явно и, если завершена, вызови:
    ```
    time_stage_close({ app: "<app>", stage: "<то же название дословно>" })
    ```
    ⚠️ **Это не опция «если вспомнишь» — карточка «Этапы» на `/owner/projects/<id>` показывает
    незакрытые чекбоксы как незавершённую работу, даже если задача давно сделана и отмечена `[x]`
    в `PLAN.md`.** `PLAN.md` и `ProjectStage` — два независимых состояния, автоматической синхронизации
    между ними нет: галочка в плане не закрывает карточку, а `time_stage_close` не отмечает пункт в
    плане. Расхождение видит только владелец на дашборде, не агент — если не закрыть явно здесь,
    оно останется до следующей сессии, где про этот этап уже никто не вспомнит.
    Пройдись по задачам, закрытым в этой сессии (шаг 2): для проектов с `tasks/` название этапа
    берётся из поля `stage` (`done` напоминает про `time_stage_close`), для остальных — по пунктам
    `PLAN.md`, отмеченным `[x]`. Каждая такая задача — кандидат на `time_stage_close`.
11. **Останови таймер тайм-трекера studio** — покажи итог сессии по проектам (`time_status` перед
    остановкой). Клиентская биллируемая работа — `time_stop`; инфраструктура студии и
    некоммерческие/личные проекты — `time_discard` (биллинг считается по флагу записи, а не по
    тексту описания; [time-tracking.md](/.claude/rules/time-tracking.md)). Если за сессию был
    задет не один проект, проверь, что для каждого переключения был вызван `time_switch` —
    забытое переключение приводит к тому, что время одного проекта записывается на другой. Один
    `Stop`-хук (`.claude/hooks/time-stop-check.js`) эту роль не закрывает: он срабатывает на конец
    **ответа агента**, а не на конец рабочей сессии — нужны оба механизма.