журнал решений: разложен по теме на файл, метки решений стали номерами

- DECISIONS.md (4040 строк, 65 тем) → decisions/, файл на тему плюс указатель;
- буквенные метки решений заменены сквозными Р1–Р234, следствия получили
  префикс С при прежних номерах: схема букв выродилась до пятибуквенных и
  сломалась — `АЕАКЛ` была занята и темой 53, и темой 65;
- 42 перекрёстные ссылки переписаны под новые номера и стали живыми; где номер
  означал тему, а слово стояло «решение», формулировка исправлена.

decisions/01-openspec-status.md

@@ -0,0 +1,86 @@
+# 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` вычищается блок «Ревью (процесс, не
+артефакт)», пересказ конвенций и инвариантов.