порядок проходов ревью — граф, а не номера стадий
Номер стадии не означал зависимости: между стадиями 1–4 ни один проход не читает вывод другого, и очередь между ними была платой ни за что. А правило про замеры держалось на двух именах и рассыпалось бы в день, когда мерить начнёт третий проход. Рёбер три вида, и они разной природы: зависимость (гейт → опиниативные, все проходы → триаж), конфликт за ресурс (ненаправленный) и барьер стоимости. Стадии остаются единицей состава, порядок задаёт граф: уходит всё, у чего входящие рёбра закрыты. Сериализует ресурс, а не имена: пометка «держит машину» — gate, adversary, ops, triage; остальные читают и рассуждают. Проект вправе пометить свой проход, снять пометку с перечисленных — нет. Ранний выход заменён барьером стоимости и стоит там, где выход зарабатывал: перед reimpl и architecture, то есть только в deep. Отдельным абзацем — что ребро значит порядок и никогда не данные: графовый словарь провоцирует обратное прочтение, а проход, увидевший чужие находки, соглашается с ними. Исключение одно и оно же сток. Диаграммы — mermaid, прогнаны через mermaid-cli. Режим прогона теперь «по графу» / «линейно»; task-batch и task-pipeline подтянуты под общий словарь, adversary и ops знают о пометке из своих charter'ов. DECISIONS 15. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -156,6 +156,26 @@ description: Проводит несколько задач разом — пл
|
||||
только задачи, между которыми нет ребра; замеряющие стоят отдельными волнами по
|
||||
одной.
|
||||
|
||||
Рёбра у графа двух видов, и путать их не надо: **зависимость** направлена (B без
|
||||
результата A не делается), **пересечение** — нет (кто первый, неважно, лишь бы не
|
||||
разом). Тот же словарь у графа проходов ревью — см. «Порядок прогона» в
|
||||
`av-dev-pipeline:review-pipeline`.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["A: схема хранилища<br/>(замеряющая)"]
|
||||
B["B: эндпоинт поверх A"]
|
||||
C["C: формат лога"]
|
||||
D["D: правит ту же capability, что C"]
|
||||
|
||||
A -->|зависимость| B
|
||||
C -. пересечение — одна capability .- D
|
||||
```
|
||||
|
||||
Этот граф даёт: **последовательно** — `A → B → C → D` (или `A → C → B → D`, обе
|
||||
линеаризации законны); **параллельно** — волна 1 `A` одна (замеряющая), волна 2
|
||||
`B` и `C`, волна 3 `D`.
|
||||
|
||||
Покажи план короткой репликой — режим, порядок или состав волн, какие задачи
|
||||
признаны замеряющими и по какому триггеру, — и иди дальше.
|
||||
|
||||
@@ -213,11 +233,11 @@ description: Проводит несколько задач разом — пл
|
||||
профиль: «нас много и мы спешим» — это ровно тот стимул, из-за которого
|
||||
проходы пропускают;
|
||||
- **режим прогона проходов ревью — от режима батча**, и его называет charter,
|
||||
а не сабагент: батч идёт по одной задаче → режим умолчательный,
|
||||
**параллельный** (машина свободна); батч идёт волнами → **последовательный**,
|
||||
твой worktree не один на машине, и этой причиной ты обязан объяснить режим в
|
||||
отчёте. Меряющую пару `adversary` и `ops` конвейер держит по очереди сам, в
|
||||
любом режиме;
|
||||
а не сабагент: батч идёт по одной задаче → режим умолчательный, **`по
|
||||
графу`** (машина свободна); батч идёт волнами → **`линейно`**, твой worktree
|
||||
не один на машине, и этой причиной ты обязан объяснить режим в отчёте.
|
||||
Внутренние рёбра графа — цепочку проходов, держащих машину, и барьер
|
||||
стоимости — конвейер соблюдает сам, в любом режиме;
|
||||
- **если вложенные сабагенты недоступны** (движок не даёт запускать агентов из
|
||||
агента) — не пропускай ревью и не понижай профиль: проведи его **инлайн** по
|
||||
тем же charter'ам `av-dev-pipeline`, сохранив обязательное — гейт до
|
||||
@@ -345,10 +365,10 @@ rebase в файле X», а не «нераспознанное пересеч
|
||||
находки и удорожат триаж. Здесь проверяется **только то, что появилось от
|
||||
слияния**:
|
||||
|
||||
- запусти **по одному `review-specs` на каждую затронутую capability**,
|
||||
параллельно — как велит умолчание конвейера: замеров эти проходы не делают,
|
||||
друг другу не мешают, а машина к этому моменту свободна (все сабагенты
|
||||
вернулись). По очереди — только по особой причине из раздела «Режим запуска»
|
||||
- запусти **по одному `review-specs` на каждую затронутую capability**, все
|
||||
разом — граф здесь плоский: машину эти проходы не держат, ребра между ними нет,
|
||||
а сама машина к этому моменту свободна (все сабагенты вернулись). Линейно —
|
||||
только по причине из раздела «Порядок прогона»
|
||||
`av-dev-pipeline:review-pipeline`, и причину назови;
|
||||
- **задание у этих проходов особое, и это надо сказать прямо.** Живого change
|
||||
здесь нет — все заархивированы, дельта-спек не существует. Источник требований
|
||||
@@ -365,6 +385,21 @@ rebase в файле X», а не «нераспознанное пересеч
|
||||
опирается. Прогон из двух проходов без триажа — это сырые находки, выданные за
|
||||
разобранные.
|
||||
|
||||
Граф этой сверки — веер в один сток, и он такой же, как у обычного прогона:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
merged["основная ветка после всех интеграций<br/>(финальный гейт зелёный)"]
|
||||
s1["review-specs: capability 1<br/>режим «стык после слияния»"]
|
||||
s2["review-specs: capability 2<br/>режим «стык после слияния»"]
|
||||
arch["review-architecture на интегрированном диффе<br/>(если задачи пересекались по файлам)"]
|
||||
tri["review-triage — сток"]
|
||||
|
||||
merged --> s1 --> tri
|
||||
merged --> s2 --> tri
|
||||
merged --> arch --> tri
|
||||
```
|
||||
|
||||
Замечания отрабатывай как одиночный пайплайн: `инлайн` чини сам, `развилка` —
|
||||
вопросом в запись; после правок — снова гейт.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user