Repo

---
name: repo
description: Показать статус монорепо по очереди задач tasks/ — что в работе, что можно брать, что ждёт владельца, здоровье зависимостей
allowed-tools: Bash(git log:*), Bash(git rev-parse:*), Bash(bun scripts/tasks.mjs:*)
---

# Статус монорепо

Очередь задач корня — каталог `tasks/` (формат: [tasks-per-file](/.claude/docs/tasks-per-file.md)).
`PLAN.md` и `docs/plans/PLAN-INFRA-*.md` заморожены и остаются справкой: **целиком их не читать**
(124 КБ и 1,8 МБ). Нужная секция берётся по полю `source` задачи: `grep -n '^## §'` по файлу и
`Read` с `offset`/`limit`.

## Учёт времени

Если это начало рабочей сессии (а не разовая проверка статуса) — стартуй таймер
`time_start({ app: "letar", description: "статус монорепо и постановка задачи" })`. Когда
направление работы прояснится (выбрана конкретная задача/приложение) — обнови через
`time_switch` на это приложение. Общий шаблон и правила переключения/остановки —
`.claude/rules/app-workflow.md` и `.claude/rules/time-tracking.md`.

## 1. Очередь

1. Прочитай `tasks/README.md` (компас: текущий фокус, справка, три правила).
2. Выполни `bun scripts/tasks.mjs next letar` — в работе, можно брать, ждут, предупреждения.
3. Что ждёт владельца: `bun scripts/tasks.mjs waiting letar --on kami`.
4. Выбрали задачу — `bun scripts/tasks.mjs show <ID>`, затем `start <ID> --owner <имя>`.

## 2. Здоровье зависимостей (§25, `docs/plans/PLAN-INFRA-1.md`)

1. Выполни `git log -1 --format=%cI -- bun.lock` — дата последнего изменения lock-файла.
2. Выполни `git log -5 --format='%cI %h %s' -- bun.lock` — определи, был ли последний коммит
   реальным обновлением зависимостей или lock задело попутно (например, бампом submodule). Если
   попутно — возьми ближайший коммит, похожий на настоящее обновление, и отметь расхождение строкой.
3. Посчитай возраст в днях от даты из шага 1 и выведи строку: `Зависимости: последнее обновление
N дней назад (<коммит>, <дата>)`.
4. Условная логика по возрасту N: ≤ 7 — «в норме», ничего не предлагать; 7 < N ≤ 14 — 🟡 «пора
   запланировать проверку»; N > 14 — 🔴 баннер, предложи `bun scripts/deps-scan.ts`, затем
   `анализ результатов сканера`. **Спроси, запускать ли сканер. Не запускай без ответа.**
5. Если файл `.claude/state/deps-last-scan.json` существует — прочитай и добавь строку с датой
   скана и счётчиками (`riskScore`, `outdatedCount`, `vulnCount`); если файла нет — выведи «скан
   ни разу не запускался».

## 3. Отчёт

Коротко: фокус из компаса; задачи в работе; до 5 задач «можно брать» (id, размер, приоритет,
заголовок); что ждёт владельца; предупреждения `next`; строка о зависимостях; рекомендуемый
следующий шаг (одна задача с id).

## 4. Приватные детали — не в этом отчёте

Очередь корня — публичная. Детали конкретных коммерческих приложений и сквозной журнал сессий
лежат отдельно:

- **По одному приложению** → `apps/<app>/PLAN.md` / `PLAN_COMPLETED.md` (или его `tasks/`) внутри
  приватного submodule этого приложения.
- **Сквозные записи** (несколько приложений сразу, rollout/деплой-кампании) →
  `.claude/private/PLAN-JOURNAL.md` (submodule `letar-private-docs`).
- **Реквизиты 152-ФЗ/РКН, домены, привязка к ИП** → `.claude/private/COMPLIANCE.md`.

Нужен статус конкретного коммерческого приложения — читай эти файлы отдельно, этот отчёт их не
пересказывает. Что можно и нельзя писать в публичные файлы —
`.claude/rules/public-repo-hygiene.md`.