av/dev-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

resolve: ревью дизайна снято, разметка переехала за код

Browse Source 
Сценарий решения идёт от предложения сразу к чекпоинту и коду: стадия ревью
дизайна упразднена целиком, review-scope запускается после apply и меряет
размер по диффу, сложность — сверкой обещанных границ с тронутыми. Чекпоинт
остался единственным плановым стопом и стоит теперь до кода. review-rubric
конвейером не зовётся, слот рубрики в скелете config.yaml снят. Журнал —
тема 74.
This commit is contained in:
av
2026-08-23 15:08:17 +03:00
parent 17be316634
commit 72d9aa8034
19 changed files with 356 additions and 417 deletions
Download Patch File Download Diff File Expand all files Collapse all files
av-dev/skills/code-resolve/SKILL.md
+10 -10
View File
@@ -1,6 +1,6 @@
---
name: code-resolve
description: "Взять одну задачу и довести её до закрытия. Одна точка входа, три сценария, и выбирает сценарий сам скилл, прочитав постановку. Способ известен и меняется поведение — сценарий решения: цикл Spec Driven Development (opsx propose → разметка → ревью дизайна → чекпоинт с объяснением человеческим языком → opsx apply → ревью кода → archive → синк документации → коммит → закрытие). Способ известен, а спека не меняется (тип chore: тулчейн, зависимости, сборка, гит-хуки, перенос, чистка) — сценарий обслуживания: правка → гейт со сверкой состава проверок → ревью фиксированным планом без change (autotests, operations, плюс conventions, если тронут код) → синк документации → коммит → закрытие; планового стопа нет, change не заводится. Нашлась дельта-спека — задача оказалась шире своего типа: стоп с объяснением простым языком и двумя решениями человека, переформулировать запись в fix или feature и решать её процессом того типа следующим прогоном либо прекратить работу. Способа нет, постановка мутная, тип research — сценарий разведки: вопрос и рамки → чтение документов, кода и внешних источников (можно opsx:explore) → чекпоинт вариантов: 2–4 способа решить, цена каждого, что становится невозможным, рекомендация → ответ уезжает в документы канона, исход — в задачи → вычитка написанного → коммит → закрытие. Разведка кода не пишет и change не заводит, а выбранный способ реализуется следующим прогоном. На входе путь к файлу задачи, её слаг или просто текст постановки: размеченная запись не обязательна — текст берётся так же, как его берёт opsx:propose, и текстом идут все три сценария. Использовать, когда просят взять, сделать или решить задачу — хоть записью из каталога, хоть описанием прямо в разговоре, — обновить зависимости или сборку, разобраться, изучить, сравнить подходы, проработать сырую идею, ответить на вопрос из беклога."
description: "Взять одну задачу и довести её до закрытия. Одна точка входа, три сценария, и выбирает сценарий сам скилл, прочитав постановку. Способ известен и меняется поведение — сценарий решения: цикл Spec Driven Development (opsx propose → чекпоинт с объяснением человеческим языком → opsx apply → разметка по диффу → ревью кода → archive → синк документации → коммит → закрытие). Способ известен, а спека не меняется (тип chore: тулчейн, зависимости, сборка, гит-хуки, перенос, чистка) — сценарий обслуживания: правка → гейт со сверкой состава проверок → ревью фиксированным планом без change (autotests, operations, плюс conventions, если тронут код) → синк документации → коммит → закрытие; планового стопа нет, change не заводится. Нашлась дельта-спека — задача оказалась шире своего типа: стоп с объяснением простым языком и двумя решениями человека, переформулировать запись в fix или feature и решать её процессом того типа следующим прогоном либо прекратить работу. Способа нет, постановка мутная, тип research — сценарий разведки: вопрос и рамки → чтение документов, кода и внешних источников (можно opsx:explore) → чекпоинт вариантов: 2–4 способа решить, цена каждого, что становится невозможным, рекомендация → ответ уезжает в документы канона, исход — в задачи → вычитка написанного → коммит → закрытие. Разведка кода не пишет и change не заводит, а выбранный способ реализуется следующим прогоном. На входе путь к файлу задачи, её слаг или просто текст постановки: размеченная запись не обязательна — текст берётся так же, как его берёт opsx:propose, и текстом идут все три сценария. Использовать, когда просят взять, сделать или решить задачу — хоть записью из каталога, хоть описанием прямо в разговоре, — обновить зависимости или сборку, разобраться, изучить, сравнить подходы, проработать сырую идею, ответить на вопрос из беклога."
---
# Работа над одной задачей
@@ -31,7 +31,7 @@ description: "Взять одну задачу и довести её до за
## Предпосылки
- **OpenSpec и скиллы `opsx:*` — жёсткая предпосылка сценария решения**, а не
опция. На них стоят его шаги 2, 6 и 8, проход `review-specs` и ревью дизайна
опция. На них стоят его шаги 2, 4 и 7 и проход `review-specs`
(они завязаны на `openspec/changes/<id>/specs/*/spec.md` и на
`openspec validate --strict`). **Проект без OpenSpec этим скиллом не ведётся** —
подключай OpenSpec, а не вырождай цикл сценария; почему ветка деградации здесь
@@ -239,8 +239,8 @@ description: "Взять одну задачу и довести её до за
человек.
Обратной смены «решение → обслуживание» нет: задача, заведшая change, доводится
циклом решения. Дельта-спеки, оказавшиеся пустыми, — находка ревью дизайна о
самой постановке, а не повод свернуть на короткий путь из середины длинного.
циклом решения. Дельта-спеки, оказавшиеся пустыми, — повод назвать это на
чекпоинте, а не свернуть на короткий путь из середины длинного.
**Соблазн «разведаю по ходу» живёт именно здесь**, и он дорог тем, что выглядит
экономией одного прогона. Разведка внутри решения не имеет своего чекпоинта:
@@ -298,9 +298,9 @@ flowchart TD
| Работа | Где шаг |
| --- | --- |
| предложение и дельта-спеки — `opsx:propose` | [solve](references/solve.md), шаг 2 |
| правки спек и дизайна по находкам ревью дизайна | [solve](references/solve.md), шаг 4 |
| код — `opsx:apply`, вместе с гейтом до зелёного и поведенческой верификацией | [solve](references/solve.md), шаг 6 |
| правки по находкам триажа, помеченным `инлайн` | [solve](references/solve.md), шаг 7; [maintain](references/maintain.md), шаг 4 |
| правки спек и дизайна по сказанному на чекпоинте | [solve](references/solve.md), шаг 3 |
| код — `opsx:apply`, вместе с гейтом до зелёного и поведенческой верификацией | [solve](references/solve.md), шаг 4 |
| правки по находкам триажа, помеченным `инлайн` | [solve](references/solve.md), шаг 6; [maintain](references/maintain.md), шаг 4 |
| правка оснастки в сценарии обслуживания | [maintain](references/maintain.md), шаг 2 |
**Остальное остаётся оркестратору, и перечень закрыт:** выбор сценария и стопы,
@@ -334,7 +334,7 @@ flowchart TD
- **что делать**: файл задачи либо её текст дословно, критерии приёмки,
идентификатор change;
- **что читать**: `CLAUDE.md`, конвенции проекта, дельта-спеки change;
- **находки — дословно**, как их вернул триаж или ревью дизайна, вместе с
- **находки — дословно**, как их вернул триаж, вместе с
оракулом;
- **границы**: правится названное, соседнее не улучшается заодно; развилок агент
не решает, задач не заводит, ничего не коммитит и наружу не ходит — правило
@@ -380,8 +380,8 @@ flowchart TD
## Автономность и плановый стоп
**У двух сценариев ровно один плановый стоп**, и стоят они в разных местах:
у решения — объяснение после ревью дизайна, у разведки — варианты до первого
написанного требования. Правило вокруг них общее.
у решения — объяснение сразу после предложения и до кода, у разведки — варианты
до первого написанного требования. Правило вокруг них общее.
**У обслуживания планового стопа нет вовсе, и это следствие, а не поблажка.**
Один стоп с ожиданием ответа у него всё же есть — по найденной дельта-спеке, — но
av-dev/skills/code-resolve/references/maintain.md
+2 -2
View File
@@ -125,8 +125,8 @@
**Третьего решения — «доделать как обслуживание» — нет.** Оно и есть то самое
молчаливое изменение поведения, против которого стоит весь разрез: под коммитом,
заявляющим «поменяли оснастку», уехала бы правка, не прошедшая ни ревью дизайна,
ни чекпоинта, и не оставившая следа в спеках.
заявляющим «поменяли оснастку», уехала бы правка, не прошедшая ни чекпоинта, ни
ревью по метке, и не оставившая следа в спеках.
**Сделанное не выбрасывается ни при каком из двух решений.** Оно остаётся в
рабочем дереве незакоммиченным: при переформулировке уезжает в change следующим
av-dev/skills/code-resolve/references/solve.md
+85 -119
View File
@@ -2,7 +2,7 @@
Способ решения известен, спорно только как. Проводит задачу от постановки до
закрытия и **пишет код**: цикл Spec Driven Development с одним плановым стопом —
объяснением после ревью дизайна.
объяснением сразу после предложения.
Сценарий выбирается развилкой на входе скилла ([SKILL.md](../SKILL.md), раздел
«Развилка: какой сценарий») и называется вслух первой репликой. Здесь только его
@@ -11,14 +11,13 @@
пересказывается.
**OpenSpec — жёсткая предпосылка именно этого сценария** (SKILL.md,
«Предпосылки»): на нём стоят шаги 2, 6 и 8, проход `review-specs` и ревью
дизайна.
«Предпосылки»): на нём стоят шаги 2, 4 и 7 и проход `review-specs`.
Тонкая обёртка над каноническими скиллами `opsx:propose` / `opsx:apply` /
`opsx:archive` — их шаги не переизобретаются, а **зовёт их агент**, не ты
(SKILL.md, «Кто пишет: письмо уходит агентам»). Ревью — скилл
`av-dev:code-review`; он же держит правило выбора метки, а называет её агент
`review-scope` — один раз на задачу, для обеих стадий ревью.
`review-scope` — один раз на задачу, **после того как код написан**.
## Ход работы
@@ -27,21 +26,20 @@ flowchart TD
in["сценарий выбран: решение"]
s1["1. прочитать задачу<br/>критерии приёмки выписать сразу"]
s2["2. opsx:propose — change, дельта-спеки,<br/>tasks.md — агентом"]
s3["3. разметка — review-scope:<br/>размер, сложность, метка, план тем"]
s4["4. ревью дизайна, состав по метке<br/>+ отработка замечаний агентом"]
s5(["5. ЧЕКПОИНТ: объяснение<br/>в чём проблема, как решаем,<br/>чем рискуем"])
s6["6. opsx:apply — код, гейт,<br/>поведенческая верификация — агентом"]
s7["7. ревью кода, та же метка<br/>+ отработка замечаний агентом"]
s8["8. opsx:archive"]
s9["9. синк документации — av-dev:doc-sync"]
s10["10. коммит работы — av-dev-git:commit"]
s11["11. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
s3(["3. ЧЕКПОИНТ: объяснение<br/>в чём проблема, как решаем,<br/>чем рискуем"])
s4["4. opsx:apply — код, гейт,<br/>поведенческая верификация — агентом"]
s5["5. разметка — review-scope по диффу:<br/>размер, сложность, метка, план тем"]
s6["6. ревью кода по метке<br/>+ отработка замечаний агентом"]
s7["7. opsx:archive"]
s8["8. синк документации — av-dev:doc-sync"]
s9["9. коммит работы — av-dev-git:commit"]
s10["10. закрыть задачу — av-dev:task-track,<br/>вторым коммитом учёта"]
in --> s1
s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10 --> s11
s3 -.->|"план задачи: та же метка"| s7
s5 -.->|"скорректировать:<br/>меняются дельта-спеки"| s3
s7 -.->|"находка отменяет дизайн:<br/>меняются дельта-спеки"| s3
s1 --> s2 --> s3 --> s4 --> s5 --> s6 --> s7 --> s8 --> s9 --> s10
s5 -.->|"план задачи: темы и глубины"| s6
s3 -.->|"скорректировать:<br/>правка спек и дизайна"| s3
s6 -.->|"находка отменяет дизайн:<br/>меняются дельта-спеки"| s3
```
Схема — **сводка**: содержание каждого шага в его разделе ниже, и при
@@ -93,7 +91,7 @@ flowchart TD
**Постановка пришла текстом** (SKILL.md, «Постановка текстом») — записи нет,
читаешь сам текст. Критерии в нём бывают редко: выпиши то, что там есть, а
недостающие **предложи на чекпоинте шага 5** и считай их данными только после
недостающие **предложи на чекпоинте шага 3** и считай их данными только после
ответа человека. Сам себе критерии не проставляешь — правило то же, что и с
записью: они приходят снаружи, и подсунуть их себе значит назначить себе приёмку.
Человек критериев не назвал — скажи строкой, что задача идёт без них и приёмка
@@ -116,7 +114,7 @@ flowchart TD
сценарии — `GIVEN/WHEN/THEN`.
**`proposal.md` и `design.md` после возврата читаешь сам** — из них собирается
чекпоинт шага 5, и держать их в контексте это твоя работа, а не переполнение.
чекпоинт шага 3, и держать их в контексте это твоя работа, а не переполнение.
Кода нет, читать нечего сверх них.
Ещё две вещи задание называет прямо, иначе их не сделает никто. **Критерии
@@ -128,84 +126,21 @@ flowchart TD
`design.md`, с причиной отказа по каждому отвергнутому.
**`proposal.md` пишется так, чтобы его понял человек, не читавший спек.** Это не
стилистическое пожелание: из него собирается чекпоинт шага 5, и переписывать его
стилистическое пожелание: из него собирается чекпоинт шага 3, и переписывать его
там заново значит завести второй дом для одного объяснения. Требование стоит в
`openspec/config.yaml`, `rules.proposal` — то есть применяется в момент
порождения артефакта, а не вспоминается после.
### 3. Разметка задачи — агент `review-scope`
**Один запуск на всю задачу, и он обслуживает обе стадии ревью.** Запусти
агента `review-scope`, дав ему корень проекта, идентификатор change, базу диффа и
запись задачи. Кода на этот момент нет, и это условие его работы, а не помеха.
Он возвращает **план задачи**:
- **размер** (малое / среднее / крупное) и **сложность** (знакомое /
незнакомое), каждое с обоснованием по факту;
- **метку** как максимум по двум осям: `small`, `medium` или `large`;
- **состав ревью дизайна** — что звать на шаге 4;
- **таблицу тем** «тема → дом → глубина → кто закрывает» — для шага 7;
- разнесение документов проекта по трём категориям и строку про директивы.
**Метку выбираешь не ты.** Раньше состав ревью дизайна называл сам оркестратор —
то есть тот, кто только что довёл предложение до `propose`. Разведённости с
автором в этой точке не было вовсе; теперь есть.
**План держи в контексте до конца задачи.** На диск он не пишется: файл-план стал
бы четвёртым артефактом рядом с `proposal.md`, `tasks.md` и `design.md`, пережил
бы задачу и разошёлся бы с ней молча. Прервался прогон — повтори шаг 3, это самый
дешёвый его проход.
**Разметка повторяется ровно в одном случае** — если правки изменили сами
**дельта-спеки**: план выведен из них, и план по отменённым требованиям назовёт
не те темы. Во всех прочих случаях, включая переделку формы кода на шаге 7,
метка остаётся прежней.
### 4. Ревью дизайна — ДО кода, состав по метке
Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`,
**план разметки с шага 3** и указание, что это ревью дизайна.
Состав приходит планом, а не решается здесь:
| Метка | Проходы на предложении |
|---|---|
| `small` | `specs` |
| `medium` | `specs`, `rubric` |
| `large` | `specs`, `rubric`, `architecture` + вопрос автору о трёх формах решения |
`review-specs` в режиме «дизайн ДО кода» идёт **на каждой задаче**: это самый
дешёвый проход конвейера, и он ловит то, что на готовом коде уже не чинят.
Остальные включаются меткой, потому что стадия стоит на каждой задаче и каждый
лишний проход здесь умножается на число задач.
Смысл стадии: архитектурная находка на готовом коде стоит переписывания и потому
игнорируется — та же находка здесь стоит абзаца обсуждения. Если `review-rubric`
запускался, перенеси его рубрику в `tasks.md` как приёмочные критерии; там же уже
лежат критерии от постановки, если они были.
**Отработка замечаний, и она идёт до чекпоинта, а не после:**
- мелочь и явные улучшения — правкой спек и дизайна, и её делает **агент**
(SKILL.md, «Кто пишет»): находки уходят ему дословно, вместе с
идентификатором change и требованием перепрогнать
`openspec validate --strict <id>`;
- развилки (компромисс, scope, инвариант) — **не в запись, а в чекпоинт**: он
следующим шагом, и это ровно то, ради чего он поставлен здесь. Агенту развилка
не отдаётся вовсе: решает её человек, а не тот, кто правит спеку;
- возврат агента — адреса тронутых дельт и исход валидации; правленые спеки
перечитываешь по адресам, если чекпоинт опирается на изменившееся.
### 5. Чекпоинт: объяснение
### 3. Чекпоинт: объяснение
**Остановись и объясни человеку, что происходит.** Единственный плановый стоп
этого сценария, и он обязателен для всякой задачи.
Он стоит **после** ревью дизайна намеренно. Человек читает объяснение, уже
просеянное машиной: то, что поймал бы `review-specs`, до него не доходит, а
внимание — самый дорогой ресурс процесса, и тратить его на выловимое машиной
нельзя.
Он стоит **сразу после предложения и до кода** — намеренно. Раньше между
`propose` и чекпоинтом стояла стадия ревью дизайна, и человек читал объяснение,
уже просеянное машиной. Стадию сняли ради времени прогона, и просеивать теперь
нечем: человек читает предложение как оно есть. Взамен стоп пришёл **раньше** —
коррекция здесь стоит правки спеки, а не переписывания готового кода.
**Объяснение не сочиняется заново — оно собирается из артефактов**, `proposal.md`
и `design.md`. Третий пересказ был бы третьим домом одного и того же и разошёлся
@@ -217,7 +152,7 @@ flowchart TD
- **что человек увидит иначе**, когда это будет сделано;
- **чего мы намеренно не делаем** и почему — граница scope ловится хуже всего;
- **чем рискуем и что осталось нерешённым** — сюда съезжаются развилки,
накопленные до этого места, и находки ревью с пометкой `развилка`;
накопленные до этого места;
- **что дальше**, если возражений нет;
- **критерии приёмки, если постановка пришла текстом и не назвала их** —
предложенными, а не принятыми: человек их подтверждает или правит здесь же.
@@ -241,22 +176,24 @@ flowchart TD
Три исхода:
- **согласен** — идёшь на шаг 6;
- **скорректировать** — правишь спеки и дизайн по сказанному. Изменились
**дельта-спеки** — повтори шаг 3 (разметка выведена из них) и ту часть ревью
дизайна, которой касается правка; затем чекпоинт **заново**. Правка внутри
дизайна без спек — повтори только чекпоинт;
- **согласен** — идёшь на шаг 4;
- **скорректировать** — правку спек и дизайна по сказанному делает **агент**
(SKILL.md, «Кто пишет»): сказанное человеком уходит ему дословно, вместе с
идентификатором change и требованием перепрогнать
`openspec validate --strict <id>`. Затем чекпоинт **заново** — правленое
объяснение читает тот же человек. Разметки на этот момент ещё нет, и повторять
здесь нечего: она идёт после кода;
- **не одобрено** — исход «не доведена» с причиной. Change остаётся
незаархивированным, задача не закрывается, ничего не коммитится наполовину.
### 6. Написать код — `opsx:apply`
### 4. Написать код — `opsx:apply`
**Код пишет агент, и в его же задании лежит весь этот раздел** (SKILL.md, «Кто
пишет»): вызов `opsx:apply` для реализации `tasks.md`, гейт до зелёного,
поведенческая верификация. Возврат — адреса тронутого, исход гейта и строка
верификации; диффа в нём нет. **Исход гейта возвращается сводкой, путём к логам
шагов и отпечатком дерева** (SKILL.md, «Возврат — не длиннее экрана»): его
передача на шаг 7 избавляет ревью от второго прогона того же гейта.
передача на шаг 6 избавляет ревью от второго прогона того же гейта.
Код — по конвенциям проекта
(каталог `docs/conventions/`). Меняешь схему — обнови её описание в документации
@@ -272,23 +209,52 @@ flowchart TD
**Сервис не оставляем лежать.** Если запуск упал — агент чинит или откатывает до
конца шага; возврат с лежащим сервисом — незакрытый шаг, а не исход.
### 7. Ревью кода — та же метка
### 5. Разметка задачи — агент `review-scope`
**Один запуск на всю задачу, и он идёт после кода.** Запусти агента
`review-scope`, дав ему корень проекта, идентификатор change, базу диффа и запись
задачи. Код уже написан, и **дифф — его источник размера**: он видит, сколько
мест тронуто на самом деле, а не сколько обещала постановка.
Он возвращает **план задачи**:
- **размер** (малое / среднее / крупное) и **сложность** (знакомое /
незнакомое), каждое с обоснованием по факту;
- **метку** как максимум по двум осям: `small`, `medium` или `large`;
- **таблицу тем** «тема → дом → глубина → кто закрывает» — для шага 6;
- разнесение документов проекта по трём категориям и строку про директивы.
**Метку выбираешь не ты, и это правило держится разведённостью.** Код только что
написан по твоему заданию, и решать, насколько глубоко его проверять, тебе нельзя:
под давлением «я почти закончил» решение известно заранее. Разметчик работу не
писал, а обе оси выводит из фактов — из диффа и из постановки, — и обязан назвать
признак по каждой.
**План держи в контексте до конца задачи.** На диск он не пишется: файл-план стал
бы четвёртым артефактом рядом с `proposal.md`, `tasks.md` и `design.md`, пережил
бы задачу и разошёлся бы с ней молча. Прервался прогон — повтори шаг 5, это самый
дешёвый его проход.
**Разметка повторяется ровно в одном случае** — если правки изменили сами
**дельта-спеки**: план выведен из задачи, и план по отменённым требованиям назовёт
не те темы. Во всех прочих случаях, включая отработку находок инлайна на шаге 6,
метка остаётся прежней: дифф от правок по находкам растёт, а задача — нет.
### 6. Ревью кода — по метке разметки
Вызови Skill **`av-dev:code-review`**, дав ссылку на change `<id>`,
базу диффа, **план разметки с шага 3**, режим запуска и **исход гейта с шага 6** —
базу диффа, **план разметки с шага 5**, режим запуска и **исход гейта с шага 4** —
сводку, путь к логам шагов и отпечаток дерева.
**Метку ты не выбираешь, и это правило, а не упрощение.** Её назвал
`review-scope` ещё на шаге 3 — по размеру и сложности, с обоснованием по каждой
оси. Причина в разведённости: ты только что написал этот код, и решать, насколько
глубоко его проверять, тебе нельзя — под давлением «я почти закончил» решение
известно заранее. Правило выбора живёт в скилле конвейера —
`av-dev:code-review`, `references/review-levels.md`; проектные
`review-scope` шагом раньше — по размеру и сложности, с обоснованием по каждой
оси; причина в разведённости, и она разобрана там же. Правило выбора живёт в
скилле конвейера — `av-dev:code-review`, `references/review-levels.md`; проектные
триггеры — в `docs/review.*`, подраздел «Триггеры метки».
**Метка не пересматривается по факту диффа.** Дифф может выйти крупнее, чем
ожидалось при разметке, — это не повод её поднимать: пересмотр означал бы второй
запуск разметчика, ровно то, ради устранения чего он и переехал на шаг 3.
**Метка, названная по диффу, внутри прогона больше не пересматривается.**
Разметчик видел дифф целиком и посчитал по нему обе оси; второй запуск на том же
дереве вернул бы то же самое.
**Считаешь метку заниженной — скажи это в докладе строкой, а не переспорь.**
Разметчик вправе и поднять, и понизить; твоё несогласие это факт для человека, а
@@ -298,7 +264,7 @@ flowchart TD
**Плана нет — ревью кода не запускается.** Триаж требует план обязательным
входом: без него он не может сверить, все ли размеченные темы вернули отчёт, а
эта сверка — единственная защита от молчащего пропуска. Потерял план (прервалась
сессия, ушёл контекст) — повтори шаг 3, а не гони прогон без него.
сессия, ушёл контекст) — повтори шаг 5, а не гони прогон без него.
**Режим по умолчанию — `по графу`, и обосновывать его не надо.** Конвейер сам
знает свои рёбра: гейт открывает проходы с мнением, проходы с пометкой «держит
@@ -329,9 +295,9 @@ flowchart TD
проверяемый: **меняются ли дельта-спеки**.
- не меняются — находка внутри дизайна, дожимай сам, это обычная отработка;
- меняются — решение стало другим, а одобрено было прежнее. Повтори шаг 3
(разметка выведена из дельта-спек) и **вернись на чекпоинт шага 5** с тем, что
изменилось и почему. Такая находка агенту не отдаётся ни при каких условиях:
- меняются — решение стало другим, а одобрено было прежнее. **Вернись на чекпоинт
шага 3** с тем, что изменилось и почему; дальше задача идёт своим ходом заново —
код, разметка, ревью. Такая находка агенту не отдаётся ни при каких условиях:
она отменяет одобрение, а это разговор с человеком.
**Это правило старше правила о развилке.** Находка класса `развилка`, чьё
@@ -354,18 +320,18 @@ flowchart TD
сжатой строкой. Отчёт, из которого исчезло «что проверить было невозможно»,
превращается в ложное ощущение проверенности.
**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 8
**Отчёт триажа сохрани вместе с change (`openspec/changes/<id>/review/`; шаг 7
унесёт его в архив вместе с change) — это обязательно, а не «если удобно».** По
нему потом видно, что было найдено и что из этого осталось в урожае. И это
единственный **независимый** артефакт о составе прогона: своей прозе здесь верить
нельзя — она написана тем же, кто мог проход и пропустить.
### 8. Архивировать — `opsx:archive`
### 7. Архивировать — `opsx:archive`
Вызови Skill `opsx:archive`: change уезжает в архив, дельты вливаются в
актуальные спеки. Не пропускай `openspec validate --strict` перед этим.
### 9. Синк документации
### 8. Синк документации
**Вызови Skill `av-dev:doc-sync`**: он владеет содержимым документов канона и
ведёт чек-лист синка.
@@ -385,7 +351,7 @@ flowchart TD
задачу нельзя: документ, заведённый мимо канона, окажется вторым домом ровно
тому, что канон потом заведёт своим.
### 10. Коммит
### 9. Коммит
Коммить **в текущую ветку** (`git rev-parse --abbrev-ref HEAD`), сам ветку не
создавай и не переключай, ничего не пушь.
@@ -395,14 +361,14 @@ flowchart TD
напиши сообщение сам и скажи строкой доклада, что форму коммита не сверял никто.
Одна задача — один осмысленный коммит.
### 11. Закрыть задачу — **после коммита, не раньше**
### 10. Закрыть задачу — **после коммита, не раньше**
**Вызови Skill `av-dev:task-track`** и попроси закрыть задачу как реализованную —
он владеет форматом и двигает строку индекса сам. Путь к его скрипту не выясняй и
индексы руками не правь: мост между плагинами — вызов скилла, а не путь.
**Порядок обязателен.** Закрытие удаляет файл задачи; сделанное до коммита оно
оставило бы задачу закрытой без единого следа работы, если шаг 10 упадёт.
оставило бы задачу закрытой без единого следа работы, если шаг 9 упадёт.
**Закрытие тоже коммитится — вторым коммитом, тут же.** Удаление файла задачи и
правка индексов (их имена знает `av-dev:task-track`, не ты) — это правки в рабочем
@@ -443,8 +409,8 @@ change. Заводить запись задним числом, чтобы её
улучшений заодно.
- **Занизить метку ревью, пропустить тему или проскочить чекпоинт — самый дешёвый
способ «ускориться», и он же самый дорогой по последствиям.** Защита устроена
так, что регулятора у тебя нет: метку выбирает разметчик **до того**, как ты
написал код, план сверяется по темам, непокрытое называется строкой, а
так, что регулятора у тебя нет: метку выбирает **не ты, а разметчик, и выводит
её из диффа**, план сверяется по темам, непокрытое называется строкой, а
расхождение с одобренным — отдельным пунктом доклада.
- **Заведение задач из урожая ревью — не твоя работа.** Отложенные находки
отдаются **списком**; превращает их в задачи `av-dev:task-track`, у него на