добавлен конвейер ревью и пайплайн задачи

- одиннадцать проходов ревью перенесены из jellybit и переписаны под домен:
  приём пакетов, слои, координатная идентичность, чувствительность данных
- скиллы task-pipeline и review-pipeline, контракт находок, журнал промахов

.claude/skills/task-pipeline/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: task-pipeline
+description: Автономно проводит задачу healthlog через полный цикл SDD — от выбора в беклоге до коммита (opsx explore→propose→ревью спек→apply→ревью кода→archive→чистка беклога). Использовать, когда пользователь просит взять/сделать задачу из беклога или довести идею до реализации.
+---
+
+# Пайплайн задачи (healthlog)
+
+Оркестратор одной задачи по Spec Driven Development: проводит её от беклога до
+коммита максимально автономно, привлекая пользователя **только на реальных
+развилках** (компромиссы, изменение scope, угроза инвариантам). Механику не
+согласовываем — делаем.
+
+Перед стартом прочитай `CLAUDE.md`, а также `README.md`, `docs/architecture.md`,
+`docs/conventions.md`, если ещё не в контексте. Это тонкая обёртка над
+каноническими скиллами `opsx:explore` / `opsx:propose` / `opsx:apply` /
+`opsx:archive` — вызывай их через Skill, не переизобретай их шаги.
+
+## Что нельзя сломать
+
+healthlog — хранилище данных о здоровье, у которого источник (телефон) шлёт
+непрерывно и молча. Отсюда особенности, которых нет в обычном сервисе:
+
+- **Поток не останавливается на время задачи.** Сервис поднят в контейнере
+  (`task up` / `task restart`), данные в `./data`. Перезапуск на пару секунд
+  безопасен — дыру закроют средний и глубокий проходы синхронизации; а вот
+  сломанный приём, оставленный работать, теряет данные необратимо.
+- **Потерянная точка не восстанавливается.** Сырой архив живёт 14 дней. Любая
+  правка разбора, слияния или вывода слоя — это `deep`-профиль ревью, без
+  исключений.
+- **Данные чувствительны.** Ничего из `./data` не попадает ни в git, ни в
+  логи выше `DEBUG`, ни в вывод агента. Гейт проверяет первое механически
+  (`no-health-data`), остальное — на тебе.
+- **Разведка уже проведена.** `docs/local-research.md` — 41 находка на живом
+  потоке, половина расходится с документацией HAE. Проверь там, прежде чем
+  строить догадку о формате: скорее всего вопрос уже закрыт измерением.
+
+## Принцип автономности
+
+Зови пользователя (через **AskUserQuestion**) только когда решение реально его:
+
+- **Выбор задачи**, если он не задан явно.
+- **Развилки грумминга** на explore: несколько равнозначных направлений,
+  спорный scope, продуктовый компромисс.
+- **Замечания ревью спек**, требующие выбора: смена подхода, урезание/расширение
+  scope, риск инварианту хранения данных.
+- Всё остальное — механика: делаем без спроса. Мелкие замечания ревью чиним
+  инлайн, не логируем.
+
+Стиль правок — заточка под проект и конвенции, right-size, без золочения.
+
+## Шаги
+
+### 1. Выбрать / прочитать задачу
+
+- Если задача задана (slug, файл в `docs/backlog/` или описание) — прочитай её
+  файл и связанные спеки/черновики.
+- Если не задана — покажи топ-кандидатов из `docs/backlog/README.md` (высокий
+  приоритет, не `[idea]`) через **AskUserQuestion** и дай выбрать.
+- Задача с префиксом `[idea]` (ещё без решения «делаем») — сперва обязательно
+  через explore (шаг 2), там она либо становится задачей, либо остаётся идеей.
+
+Формат файла задачи и индекса держит скилл `backlog` — здесь мы беклог только
+читаем. Если по ходу выбора вскрылось, что задача устарела, дублируется или
+разрослась в эпик, это работа для скилла `backlog`, а не для пайплайна.
+
+Оцени тривиальность (влияет на шаг 4):
+- **Тривиальная** — локальная правка без изменения поведения/спек/схемы БД,
+  очевидное решение. Explore и ревью спек пропускаем.
+- **Нетривиальная** — новое/изменённое поведение, дизайн-развилки, затрагивает
+  инварианты, схему БД или несколько capability. Полный цикл.
+
+### 2. (Опц.) Груммить идею — `opsx:explore`
+
+Только для `[idea]`-задач или когда постановка мутная. Вызови Skill
+`opsx:explore`. Развилки грумминга — на пользователя (AskUserQuestion). Выход:
+ясная постановка, готовая к propose. **В explore не пишем код.**
+
+### 3. Завести change — `opsx:propose`
+
+Вызови Skill `opsx:propose`. Получаем `proposal.md`, дизайн (для нетривиальных),
+дельта-спеки (`ADDED`/`MODIFIED`/`REMOVED Requirements`), `tasks.md`. Каждое
+`### Requirement` содержит `SHALL`/`MUST`; структурные заголовки английские,
+сценарии `GIVEN/WHEN/THEN`. Прогони `openspec validate --strict <id>`.
+
+### 4. (Нетривиальная) Ревью предложения — профиль `design`, ДО кода
+
+Первый чекпоинт ревью-процесса. Вызови Skill **`review-pipeline`** с профилем
+`design` и ссылкой на change `<id>`. Он запустит `healthlog-review-specs` (режим
+«дизайн/спеки ДО кода»), `healthlog-review-rubric` (фаза 1: приёмочные критерии
+для задуманного узла), `healthlog-review-idiom` и `healthlog-review-architecture`
+по предложению.
+
+Смысл профиля: архитектурная находка на готовом коде стоит переписывания и
+потому игнорируется — та же находка здесь стоит абзаца обсуждения. Рубрику из
+`healthlog-review-rubric` перенеси в `tasks.md` как приёмочные критерии.
+
+### 5. Отработать замечания ревью предложения
+
+- Мелочь и явные улучшения — правь сам в спеках/дизайне.
+- Развилки (компромисс, scope, инвариант) — на пользователя (AskUserQuestion).
+- После правок перепрогони `openspec validate --strict <id>`.
+
+### 6. Написать код — `opsx:apply`
+
+Вызови Skill `opsx:apply` для реализации `tasks.md`. Код по конвенциям
+`docs/conventions.md`: ошибки stdlib с `%w`/`errors.Is`, логи только `slog` без
+секретов и тел запросов, время в UTC через `store.Now()`, ULID через
+`internal/ident`, миграции goose. Меняешь схему — обнови ER-схему
+`docs/database.md` в том же change (гейт это проверяет).
+
+Прогони `task gate` и добейся зелёного — он же гейт следующего шага.
+
+**Поведенческая верификация.** Если задача меняет реальное поведение (новый
+эндпоинт, разбор входа, схема БД, форма ответа) — зелёных юнит-тестов мало.
+Подними изменение вживую: `task restart`, затем прогони сценарий по настоящим
+данным из `./data` (89+ доставок реального потока) или скриптом из
+`tmp/research/`. Пропусти только для чисто внутренних правок без наблюдаемого
+рантайма.
+
+**Сервис не оставляем лежать.** Если `task restart` упал — почини или откати
+до конца шага: телефон продолжает слать всё это время.
+
+### 7. Ревью кода — Skill `review-pipeline`
+
+Второй чекпоинт. Вызови Skill **`review-pipeline`**, дав ссылку на change
+`<id>`, базу диффа и профиль. Профиль выбирается по факту изменения, а не по
+ощущению важности (правило — в самом скилле):
+
+- миграция, новый пакет, контракт Read API или MCP, правило слияния точек или
+  вывод слоя → `deep`;
+- иначе меняется поведение, видимое снаружи → `standard`;
+- иначе (багфикс, локальная правка, доки) → `quick`.
+
+Скилл сам гоняет гейт, нужные проходы и обязательный триаж. Возвращает отчёт с
+потолком 7 пунктов, разметкой `Действие: инлайн | развилка` и секцией границ
+покрытия.
+
+Отработай так же, как шаг 5: помеченное `инлайн` чини сам и не логируй,
+`развилка` — на пользователя через AskUserQuestion (вопрос уже сформулирован
+триажем). После правок — снова `task gate`.
+
+**Границы покрытия из отчёта не выбрасывай** — они уезжают в финальный доклад
+(шаг 10) сжатой строкой. Отчёт, из которого исчезло «что проверить было
+невозможно», превращается в ложное ощущение проверенности.
+
+### 8. Архивировать — `opsx:archive`
+
+Вызови Skill `opsx:archive`: change уезжает в `openspec/changes/archive/`,
+дельты вливаются в `openspec/specs/`.
+
+### 9. Закрыть беклог и синк доков
+
+Ревью выполненного — **до** чистки. Затем:
+
+- Удали файл задачи `docs/backlog/<slug>.md` и строку в `docs/backlog/README.md`.
+  Реализованное не держим в беклоге — у него есть коммит и спека.
+- Суть переехавшего решения — в `docs/architecture.md`, если ещё не там.
+- Менялась структура БД — убедись, что `docs/database.md` обновлён в этом же
+  change.
+- Новое, узнанное о формате HAE или о данных, — в `docs/local-research.md`
+  очередной находкой. Это источник истины по формату, и он ценнее кода.
+- Проверь согласованность индекса командой `check` скилла `backlog`.
+
+### 10. Коммит
+
+Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не
+создавай и не переключай, ничего не пушь. При ручном запуске HEAD обычно на
+`master` — коммит идёт прямо в него, без feature-веток.
+
+Сообщение — по-русски, по скиллу `commit` (первая строка отвечает «что
+сделано», тело списком 1–3 пункта, без трейлеров). Одна задача — один
+осмысленный коммит.
+
+Готово — доложи пользователю кратко: что сделано, какие развилки решались,
+ссылка на архивный change. **Плюс одна строка границ покрытия** из отчёта
+ревью: какой профиль гонялся и что проверить было невозможно. Доклад без неё
+сообщает «проверено», не сообщая, что именно.
+
+## Тонкости
+
+- **Не завязывайся на master и корень репо.** Скилл работает в текущем worktree
+  и на текущей ветке: не делай `git checkout`/`switch`, не создавай веток, не
+  пушь.
+- Не пропускай `openspec validate --strict` перед архивацией.
+- Тривиальная задача: шаги 2 и 4 пропускаются; ревью кода (шаг 7) остаётся
+  всегда, но в профиле `quick`.
+- Гейт блокирует: пока `task gate` красный, опиниативные проходы не
+  запускаются. Чинить и перезапускать, а не «посмотреть заодно».
+- Если ревью предлагает крупную переработку — это развилка, не правь молча,
+  вынеси пользователю.
+- Держи пользователя в цикле короткими репликами на переходах фаз, но не проси
+  подтверждать механику.