ревью: цикл задачи проверяет механику, метки сняты
Состав прогона постоянный: гейт, спеки, код, триаж; приёмник тем идёт, когда у проекта есть свои темы. Метка, разметка и проход review-scope упразднены, review-levels.md удалён, ось «метка» снята из axes.md. Ступень 4 ушла из цикла: review-proof упразднён через день после заведения, review-architecture переехал в code-deep-review вслед за adversary и ops. Темы security, operations и architecture закрывает review-code сверкой с записанными инвариантами, потолком 1 находка. Умолчание разметки действий перевёрнуто на инлайн; развилка осталась за необратимым, изменением дельта-спек и нарушенным инвариантом. Задачи из урожая заводятся по слову человека, а не шагом сценария. Чекпоинт назван единственным местом, где решается форма решения. Потеряны ось времени в цикле и суждение о форме после кода — обе потери названы в «Честном пределе» строкой границ покрытия. Журнал — тема 77.
This commit is contained in:
@@ -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, 4 и 7 и проход `review-specs`
|
||||
опция. На них стоят его шаги 2, 4 и 6 и проход `review-specs`
|
||||
(они завязаны на `openspec/changes/<id>/specs/*/spec.md` и на
|
||||
`openspec validate --strict`). **Проект без OpenSpec этим скиллом не ведётся** —
|
||||
подключай OpenSpec, а не вырождай цикл сценария; почему ветка деградации здесь
|
||||
@@ -284,7 +284,7 @@ flowchart TD
|
||||
скилл написал бы сам, если бы писал.
|
||||
|
||||
Причина про контекст, и она одна. Оркестратор ведёт задачу целиком: выбрал
|
||||
сценарий, собирает чекпоинт, сверяет план прогона с исходом, пишет доклад, — а
|
||||
сценарий, собирает чекпоинт, сверяет перечень тем с исходом, пишет доклад, — а
|
||||
для всего этого надо помнить постановку, критерии приёмки и то, что человек
|
||||
одобрил. Письмо тянет в контекст ровно то, чего в докладе не будет ни строкой:
|
||||
содержимое тронутых файлов, вывод линтеров и гейта, перебранные варианты правки.
|
||||
@@ -293,23 +293,23 @@ flowchart TD
|
||||
|
||||
**Разведённость тут ни при чём**, и путать два довода нельзя. Агент пишет по
|
||||
заданию оркестратора и отвечает перед ним; разведён с автором тот, кто работу
|
||||
**судит**, — разметчик и проходы ревью.
|
||||
**судит**, — проходы ревью.
|
||||
|
||||
| Работа | Где шаг |
|
||||
| --- | --- |
|
||||
| предложение и дельта-спеки — `opsx:propose` | [solve](references/solve.md), шаг 2 |
|
||||
| правки спек и дизайна по сказанному на чекпоинте | [solve](references/solve.md), шаг 3 |
|
||||
| код — `opsx:apply`, вместе с гейтом до зелёного и поведенческой верификацией | [solve](references/solve.md), шаг 4 |
|
||||
| правки по находкам триажа, помеченным `инлайн` | [solve](references/solve.md), шаг 6; [maintain](references/maintain.md), шаг 4 |
|
||||
| правки по находкам триажа, помеченным `инлайн` | [solve](references/solve.md), шаг 5; [maintain](references/maintain.md), шаг 4 |
|
||||
| правка оснастки в сценарии обслуживания | [maintain](references/maintain.md), шаг 2 |
|
||||
| архивация change и синк документации — `opsx:archive` и `av-dev:doc-sync` | [solve](references/solve.md), шаг 7; [maintain](references/maintain.md), шаг 5 |
|
||||
| архивация change и синк документации — `opsx:archive` и `av-dev:doc-sync` | [solve](references/solve.md), шаг 6; [maintain](references/maintain.md), шаг 5 |
|
||||
|
||||
**Остальное остаётся оркестратору, и перечень закрыт:** выбор сценария и стопы,
|
||||
чекпоинт, вызовы `av-dev:code-review`, `av-dev-git:commit` и `av-dev:task-track`,
|
||||
сверка плана с исходом, урожай и доклад. **Коммит и закрытие задачи агенту не
|
||||
отдаются ни в одном сценарии** — они необратимы для учёта: закрытие удаляет запись
|
||||
и правит индексы, а коммит уезжает в историю. Оркестратор делает их сам, уже
|
||||
сверив план прогона с исходом. Ни одна из этих
|
||||
сверив перечень тем с исходом. Ни одна из этих
|
||||
работ не пишет файлов проекта — они и есть та работа, ради которой контекст
|
||||
берегут.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user