av
bf6a173115
- DECISIONS.md (4040 строк, 65 тем) → decisions/, файл на тему плюс указатель; - буквенные метки решений заменены сквозными Р1–Р234, следствия получили префикс С при прежних номерах: схема букв выродилась до пятибуквенных и сломалась — `АЕАКЛ` была занята и темой 53, и темой 65; - 42 перекрёстные ссылки переписаны под новые номера и стали живыми; где номер означал тему, а слово стояло «решение», формулировка исправлена.
4.5 KiB
11. Зависимости между плагинами (2026-08-03)
Целевая картина, которую проверяли
av-dev-git ни от чего не зависит. av-dev-pipeline сам по себе: задача
приходит и обычным текстом, и из tasks. av-dev-pm оперирует абстрактным
«сделать задачу» и не знает, чем она выполняется.
Что показала проверка
Р38. Первые две цели выполняются, третья в исходной формулировке недостижима —
и формулировку надо поправить, а не картину. av-dev-pm владеет
конфигурационным файлом конвейера: docs/review.md держит «Вопросы к
проходам» и «Триггеры профиля», то есть перечисляет проходы поимённо, а скелет
review.md несёт форму журнала дефектов. Кто-то этим словарём владеть обязан —
канон и есть схема данных, которую конвейер читает. Честная формулировка цели:
av-dev-pm не зовёт пайплайн и не требует его наличия. Она выполняется.
Р39. Настоящая протечка была одна — необъявленная деградация опор приёмки.
«Стимулы» в session и приёмка в sprint.md держались на «сохранённом отчёте
триажа» по конкретному OpenSpec-пути. В проекте без конвейера ревью защита от
занижения урожая исчезала молча: сверять не с чем, а текст об этом не
говорил. Теперь опора названа абстрактно («независимый отчёт ревью»), путь
av-dev-pipeline дан как частный случай, а отсутствие конвейера обязано
попадать строкой в доклад спринта.
Р40. Ветка деградации шага 9 была неисполнима — ровно в том случае, ради
которого написана. «Плагина нет — открой
av-dev-pm/skills/canon/references/canon.md»: путь в дерево маркетплейса, из
проекта без установленного плагина не разрешается ниоткуда. Кросс-плагинные пути
в дерево маркетплейса теперь не используются вообще: пайплайн ходит в свой
references/project-facts.md, а ссылки в чужой плагин даются через Skill <плагин>:<скилл>.
Что из этого следует
С47. Знаниевый цикл есть и он законен, но каждый его контракт обязан иметь
единственный дом. Пайплайн описывает раскладку pm, pm описывает артефакты
пайплайна — пять симметричных контрактов, из них два уже разошлись: форма
журнала дефектов (шесть полей против пяти, «Причина» потеряна) и список
читателей docs/research/ (specs выпал). Дома назначены: форма журнала — у
конвейера, список читателей — у канона; в обеих копиях стоит явное указание на
дом.
С48. Пайплайн больше не называет внутренние имена файлов pm.
items/<slug>.md и SPRINT.md в его тексте были вторым домом для раскладки,
которую проект вправе переименовать через docs/.pm.json.
С49. Описания плагинов в манифестах врали умолчанием. Ни marketplace.json,
ни plugin.json не говорили, что av-dev-pm для конвейера опционален, а
задача принимается текстом. Теперь говорят — это первое, что читает человек,
выбирая, что подключать.