resolve: письмо вынесено агентам, журнал — тема 72
Спеки, код и правки по находкам ревью пишет отдельный агент: оркестратору оставлены задание, возврат, чекпоинт, сверка плана с исходом и доклад. Заведён раздел «Кто пишет» в SKILL.md, переписаны шаги 2, 4, 6, 7 решения и шаги 2, 4 обслуживания, у разведки названо, почему исполнителей нет.
This commit is contained in:
@@ -170,7 +170,7 @@
|
||||
flowchart TD
|
||||
in["сценарий выбран: обслуживание"]
|
||||
s1["1. прочитать задачу<br/>критерии приёмки и границы"]
|
||||
s2["2. сделать правку<br/>гейт тронут — сверить состав, не цвет"]
|
||||
s2["2. правка агентом<br/>гейт тронут — состав снять до правки"]
|
||||
s3["3. гейт проекта до зелёного"]
|
||||
s4["4. ревью фиксированным планом<br/>av-dev:code-review, без change"]
|
||||
s5["5. синк документации — av-dev:doc-sync"]
|
||||
@@ -259,8 +259,11 @@ ADR: список источников канон закрыл двумя — а
|
||||
|
||||
### 2. Сделать правку
|
||||
|
||||
Код и конфиги — по конвенциям проекта. Правка по размеру задачи: чинится названное в записи, соседнее не улучшается
|
||||
заодно.
|
||||
**Правку делает агент** (SKILL.md, «Кто пишет: письмо уходит агентам»): задание
|
||||
несёт постановку, конвенции проекта, границы правки и требование довести гейт до
|
||||
зелёного; возврат — адреса тронутого и исход гейта. Код и конфиги — по конвенциям
|
||||
проекта. Правка по размеру задачи: чинится названное в записи, соседнее не
|
||||
улучшается заодно.
|
||||
|
||||
**Гейта ещё нет — сказать это, а не изображать сверку.** Первые шаги плана
|
||||
стройки заводят гейт, сборку и хуки: у них нет ни «до», ни «прежнего», и
|
||||
@@ -277,6 +280,11 @@ ADR: список источников канон закрыл двумя — а
|
||||
их семантикой гейта в `CLAUDE.md`. Снимай исходное состояние **до** правки, по
|
||||
тому, как проект это описал.
|
||||
|
||||
**Исходный состав снимаешь ты, а не агент, и это не мелочь.** Сверка «до и
|
||||
после» уезжает в твой доклад, а снятое тем же, кто правил, сверкой не является:
|
||||
агент вернёт состав, который получился, и назовёт его исходным. Снимок делается
|
||||
до того, как задание ушло.
|
||||
|
||||
**Проект состав не описал — скажи строкой доклада, что сверен только цвет.**
|
||||
Обходного пути не выдумывай: угаданный состав хуже отсутствующего, потому что
|
||||
читается как сверенный. Это же строка и повод — предложить проекту дописать слот
|
||||
@@ -353,8 +361,9 @@ Change ты не передаёшь — его нет.
|
||||
Отчёт, из которого исчезло «что не смотрел никто», сообщает «проверено», не
|
||||
сообщая, что именно.
|
||||
|
||||
Отработка — как в решении: помеченное `инлайн` чини сам и не логируй, `развилка`
|
||||
— вопросом в запись. После правок снова гейт. Отложенные находки собери в секцию
|
||||
Отработка — как в решении: помеченное `инлайн` чинит **агент** (SKILL.md, «Кто
|
||||
пишет»), находки уходят ему дословно с оракулом, гейт после правок гоняет он же,
|
||||
логировать их не надо; `развилка` — вопросом в запись, и агенту она не отдаётся. Отложенные находки собери в секцию
|
||||
доклада `Урожай`; задачи из него заводит `av-dev:task-track`, не ты.
|
||||
|
||||
### 5. Синк документации — главный шаг этого сценария
|
||||
|
||||
@@ -30,6 +30,13 @@
|
||||
(задачи заводятся и уточняются), `av-dev-git:commit`. Правило обращения к соседям
|
||||
и правило «чего может не быть» — общие, они в [SKILL.md](../SKILL.md).
|
||||
|
||||
**Агентов-исполнителей у разведки нет** (SKILL.md, «Кто пишет: письмо уходит
|
||||
агентам»), и это не пропуск. Её письмо — записка в документы канона и записи
|
||||
задач, то есть тот самый текст, из которого собираются чекпоинт вариантов и
|
||||
доклад: отданный агенту, он вернулся бы пересказом. Вычитку разведка всё же
|
||||
отдаёт — `doc-wording`, `task-form`, `task-wording`: там судят написанное, а не
|
||||
пишут.
|
||||
|
||||
**Отсутствие канона бьёт по разведке сильнее, чем по решению**, и сказать об этом
|
||||
строкой мало: без документов у ответа нет дома, и знание осядет в переписке.
|
||||
Назови исход и предложи `av-dev:canon`; работу не останавливай, но адрес
|
||||
|
||||
@@ -15,7 +15,8 @@
|
||||
дизайна.
|
||||
|
||||
Тонкая обёртка над каноническими скиллами `opsx:propose` / `opsx:apply` /
|
||||
`opsx:archive` — зови их через Skill, не переизобретай их шаги. Ревью — скилл
|
||||
`opsx:archive` — их шаги не переизобретаются, а **зовёт их агент**, не ты
|
||||
(SKILL.md, «Кто пишет: письмо уходит агентам»). Ревью — скилл
|
||||
`av-dev:code-review`; он же держит правило выбора метки, а называет её агент
|
||||
`review-scope` — один раз на задачу, для обеих стадий ревью.
|
||||
|
||||
@@ -25,12 +26,12 @@
|
||||
flowchart TD
|
||||
in["сценарий выбран: решение"]
|
||||
s1["1. прочитать задачу<br/>критерии приёмки выписать сразу"]
|
||||
s2["2. opsx:propose — change, дельта-спеки, tasks.md"]
|
||||
s2["2. opsx:propose — change, дельта-спеки,<br/>tasks.md — агентом"]
|
||||
s3["3. разметка — review-scope:<br/>размер, сложность, метка, план тем"]
|
||||
s4["4. ревью дизайна, состав по метке<br/>+ отработка замечаний"]
|
||||
s4["4. ревью дизайна, состав по метке<br/>+ отработка замечаний агентом"]
|
||||
s5(["5. ЧЕКПОИНТ: объяснение<br/>в чём проблема, как решаем,<br/>чем рискуем"])
|
||||
s6["6. opsx:apply — код, гейт,<br/>поведенческая верификация"]
|
||||
s7["7. ревью кода, та же метка<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"]
|
||||
@@ -103,17 +104,28 @@ flowchart TD
|
||||
|
||||
### 2. Завести change — `opsx:propose`
|
||||
|
||||
Вызови Skill `opsx:propose`. Получаем `proposal.md`, дизайн, дельта-спеки
|
||||
(`ADDED`/`MODIFIED`/`REMOVED Requirements`), `tasks.md`. Каждое `### Requirement`
|
||||
содержит `SHALL`/`MUST`; структурные заголовки английские, сценарии
|
||||
`GIVEN/WHEN/THEN`. Прогони `openspec validate --strict <id>`.
|
||||
**Скилл `opsx:propose` зовёт агент** (SKILL.md, «Кто пишет»). В задании:
|
||||
постановка — файл задачи либо её текст дословно, — критерии приёмки, если они
|
||||
были, и требование прогнать `openspec validate --strict <id>`. Возврат:
|
||||
идентификатор change, дельты адресами и исход валидации.
|
||||
|
||||
Критерии приёмки задачи, если они были, копируются в `tasks.md` отдельным блоком.
|
||||
Задаче предшествовала разведка — её записка и отвергнутые варианты **уже
|
||||
записаны** в документах канона (`docs/research/`, `docs/adr/`): сошлись на них из
|
||||
`design.md`, а не переписывай второй раз. Варианты, разобранные без разведки
|
||||
(способ был очевиден, но у него оказались оттенки), — в `design.md`, с причиной
|
||||
отказа по каждому отвергнутому.
|
||||
Шаг оставляет `proposal.md`, дизайн, дельта-спеки
|
||||
(`ADDED`/`MODIFIED`/`REMOVED Requirements`) и `tasks.md`. Форму держит сам
|
||||
`opsx:propose`, и требования к ней идут агенту заданием: каждое
|
||||
`### Requirement` содержит `SHALL`/`MUST`, структурные заголовки английские,
|
||||
сценарии — `GIVEN/WHEN/THEN`.
|
||||
|
||||
**`proposal.md` и `design.md` после возврата читаешь сам** — из них собирается
|
||||
чекпоинт шага 5, и держать их в контексте это твоя работа, а не переполнение.
|
||||
Кода нет, читать нечего сверх них.
|
||||
|
||||
Ещё две вещи задание называет прямо, иначе их не сделает никто. **Критерии
|
||||
приёмки задачи, если они были, копируются в `tasks.md` отдельным блоком.**
|
||||
И **записанное разведкой не переписывается второй раз**: задаче предшествовала
|
||||
разведка — её записка и отвергнутые варианты уже лежат в документах канона
|
||||
(`docs/research/`, `docs/adr/`), и `design.md` на них ссылается. Варианты,
|
||||
разобранные без разведки (способ был очевиден, но у него оказались оттенки), — в
|
||||
`design.md`, с причиной отказа по каждому отвергнутому.
|
||||
|
||||
**`proposal.md` пишется так, чтобы его понял человек, не читавший спек.** Это не
|
||||
стилистическое пожелание: из него собирается чекпоинт шага 5, и переписывать его
|
||||
@@ -175,10 +187,15 @@ flowchart TD
|
||||
|
||||
**Отработка замечаний, и она идёт до чекпоинта, а не после:**
|
||||
|
||||
- мелочь и явные улучшения — правь сам в спеках и дизайне;
|
||||
- мелочь и явные улучшения — правкой спек и дизайна, и её делает **агент**
|
||||
(SKILL.md, «Кто пишет»): находки уходят ему дословно, вместе с
|
||||
идентификатором change и требованием перепрогнать
|
||||
`openspec validate --strict <id>`;
|
||||
- развилки (компромисс, scope, инвариант) — **не в запись, а в чекпоинт**: он
|
||||
следующим шагом, и это ровно то, ради чего он поставлен здесь;
|
||||
- после правок перепрогони `openspec validate --strict <id>`.
|
||||
следующим шагом, и это ровно то, ради чего он поставлен здесь. Агенту развилка
|
||||
не отдаётся вовсе: решает её человек, а не тот, кто правит спеку;
|
||||
- возврат агента — адреса тронутых дельт и исход валидации; правленые спеки
|
||||
перечитываешь по адресам, если чекпоинт опирается на изменившееся.
|
||||
|
||||
### 5. Чекпоинт: объяснение
|
||||
|
||||
@@ -234,7 +251,12 @@ flowchart TD
|
||||
|
||||
### 6. Написать код — `opsx:apply`
|
||||
|
||||
Вызови Skill `opsx:apply` для реализации `tasks.md`. Код — по конвенциям проекта
|
||||
**Код пишет агент, и в его же задании лежит весь этот раздел** (SKILL.md, «Кто
|
||||
пишет»): вызов `opsx:apply` для реализации `tasks.md`, гейт до зелёного,
|
||||
поведенческая верификация. Возврат — адреса тронутого, исход гейта и строка
|
||||
верификации; диффа в нём нет.
|
||||
|
||||
Код — по конвенциям проекта
|
||||
(каталог `docs/conventions/`). Меняешь схему — обнови её описание в документации
|
||||
тем же change, если проект этого требует: гейт обычно это проверяет.
|
||||
|
||||
@@ -245,8 +267,8 @@ flowchart TD
|
||||
изменение вживую командой из раздела команд `CLAUDE.md` и прогони сценарий.
|
||||
Пропусти только для чисто внутренних правок без наблюдаемого рантайма.
|
||||
|
||||
**Сервис не оставляем лежать.** Если запуск упал — почини или откати до конца
|
||||
шага.
|
||||
**Сервис не оставляем лежать.** Если запуск упал — агент чинит или откатывает до
|
||||
конца шага; возврат с лежащим сервисом — незакрытый шаг, а не исход.
|
||||
|
||||
### 7. Ревью кода — та же метка
|
||||
|
||||
@@ -294,8 +316,11 @@ flowchart TD
|
||||
|
||||
#### Отработка, и здесь появляется одно новое правило
|
||||
|
||||
Помеченное `инлайн` чини сам и не логируй. `развилка` — вопросом в запись (он уже
|
||||
сформулирован триажем, его остаётся перенести). После правок — снова гейт.
|
||||
Помеченное `инлайн` чинит **агент** (SKILL.md, «Кто пишет»): находки уходят ему
|
||||
**дословно, вместе с оракулом**, одним заданием на весь урожай инлайна, и гейт
|
||||
после правок гоняет он же. Логировать их по-прежнему не надо. `развилка` —
|
||||
вопросом в запись (он уже сформулирован триажем, его остаётся перенести), и
|
||||
агенту она не отдаётся.
|
||||
|
||||
**Находка, отменяющая одобренный дизайн, отменяет и одобрение.** Признак
|
||||
проверяемый: **меняются ли дельта-спеки**.
|
||||
@@ -303,7 +328,8 @@ flowchart TD
|
||||
- не меняются — находка внутри дизайна, дожимай сам, это обычная отработка;
|
||||
- меняются — решение стало другим, а одобрено было прежнее. Повтори шаг 3
|
||||
(разметка выведена из дельта-спек) и **вернись на чекпоинт шага 5** с тем, что
|
||||
изменилось и почему.
|
||||
изменилось и почему. Такая находка агенту не отдаётся ни при каких условиях:
|
||||
она отменяет одобрение, а это разговор с человеком.
|
||||
|
||||
**Это правило старше правила о развилке.** Находка класса `развилка`, чьё
|
||||
основание — «надо менять спеку», подпадает под оба; побеждает возврат на
|
||||
|
||||
Reference in New Issue
Block a user