# 1. Статус OpenSpec (2026-08-03)

## Что было

OpenSpec несёт оба проекта: healthlog — 5 capability, 3530 строк спек, 9
архивных change за две недели; jellybit — 11 capability, 3895 строк, 43 архивных
change. При этом в трёх местах плагина написана ветка «проект без OpenSpec»
(`task-pipeline` предпосылки, `review-pipeline` предпосылки, `task-batch`
предпосылки) — и **не исполнялась ни разу**.

Проектные факты живут в пяти домах: `CLAUDE.md`, `docs/architecture.md`,
`openspec/specs/`, `openspec/config.yaml` → `context`, и планируется шестой —
`docs/review-brief.md`.

Расхождение измерено: у healthlog раздел «Хранилище» в `docs/architecture.md` —
950 строк (377–1328) против `openspec/specs/storage/spec.md` на 1337 строк. Два
описания одного поведения, никем не сверяемые. У jellybit того же нет:
`docs/specs/architecture.md` — 300 строк обзора, детали в 11 спеках. **Проект с
43 изменениями держит архитектуру втрое короче проекта с 9.**

## Решено

**Р1. OpenSpec — жёсткая предпосылка `av-dev-pipeline`.** Ветки деградации
удаляются, вместо них объявленная зависимость и проверка на старте. Зависимость
на уровне **плагина, а не процесса**: `av-dev-tasks`, `av-dev-git` и будущий
плагин документов от OpenSpec не зависят и работают на python/ansible-проектах.

*Причина:* непроверенная ветка деградации хуже честной строки «требуется
OpenSpec» — она даёт ложную уверенность, что проект без спек поедет.

**Р2. Нормативный дом поведения — `openspec/specs/`.** `architecture.md`
переопределяется как **обзор**: принципы, компоненты со ссылками на capability,
внешние форматы данных, раскладка, деплой, открытые вопросы. Поведения он не
описывает.

*Причина:* `opsx:archive` вливает дельты именно в `openspec/specs/` — любой
другой нормативный дом обязан синхронизироваться руками и разойдётся. Форма
jellybit это уже подтвердила на 43 изменениях.

**Р3. `openspec/config.yaml` → `context` держит только нужды генерации.** Язык,
правила именования capability, придирки валидатора RFC 2119 — и ссылки. Правило
ревью, пересказ конвенций и инварианты оттуда вычищаются: у них есть свои дома.

*Причина:* блок «Ревью (процесс, не артефакт)» в обоих `config.yaml` дословно
повторяет шаги 4 и 7 `task-pipeline`. Это второй дом для правила, которым владеет
плагин, и он разойдётся на первой же правке.

## Что из этого следует

Из Р1:

**С1.** Три места с веткой деградации переписываются на объявленную предпосылку
плюс проверку на старте (есть `openspec/`, разрешаются `opsx:*`) и внятный
отказ: `task-pipeline` предпосылки, `review-pipeline` предпосылки, `task-batch`
предпосылки.

**С2.** Описание `av-dev-pipeline` в маркетплейсе получает строку «требует
OpenSpec».

**С3. Факт для темы «объединять ли tasks и pipeline»:** объединение потянуло бы
зависимость от OpenSpec на управление задачами, которой там сейчас нет.

Из Р2:

**С4.** Правило «поведение — в спеку, устройство и границы — в архитектуру»
становится контрактом плагина документов и правилом шага «синк документации» в
`task-pipeline`.

**С5.** healthlog чистится **не разом**: раздел вычищается той задачей, которая
его касается. Нужен способ не потерять остаток — иначе 950 строк «Хранилища»
останутся навсегда.

**С6. Дыра, которую решение открывает:** «почему» после архивации. Сегодня
`CLAUDE.md` healthlog велит писать причину решения в `architecture.md` — а мы её
оттуда выселяем. Спеки нормативны и «почему» не держат; `design.md` живёт внутри
change и уезжает в архив. Либо ADR (как у jellybit), либо явное правило «почему
живёт в архивных change». **Первый вопрос следующей темы.**

Из Р3:

**С7.** `av-dev-pipeline` даёт образец `openspec/config.yaml` отдельным
reference — он владеет связью с OpenSpec. Заполняется при старте проекта и при
`adopt`.

**С8.** У обоих проектов из `config.yaml` вычищается блок «Ревью (процесс, не
артефакт)», пересказ конвенций и инвариантов.