Compare commits
No commits in common. "36bf1069620e0c28f7da00a403b2d57c33f3d0af" and "303b7f08aabbfa6f7abe2bb654f499a6e563e04d" have entirely different histories.
36bf106962
...
303b7f08aa
@ -1,104 +0,0 @@
|
|||||||
# dsh-sdd Specification
|
|
||||||
|
|
||||||
## Purpose
|
|
||||||
Исполнение плана субагентами в DeepSeek Harness (SDD). Контроллер диспатчит
|
|
||||||
implementer'а на задачу плана, получает отчёт, отправляет задачу на ревью
|
|
||||||
и ведёт fix-loop до чистоты, затем заказывает финальное ревью ветки. DSH не
|
|
||||||
имеет синхронного `Task`, поэтому протокол строится на асинхронном `subagent`
|
|
||||||
(идентификатор, уведомление, `send_message`) и на ledger как единственной
|
|
||||||
памяти между ходами.
|
|
||||||
|
|
||||||
## Requirements
|
|
||||||
|
|
||||||
### Requirement: Режим контроллера выбирается по контексту
|
|
||||||
Skill SHALL предлагать два режима и MUST выбирать между ними по числу
|
|
||||||
параллельных планов, а не по умолчанию.
|
|
||||||
|
|
||||||
- Один план в сессии — контроллер главная сессия; implementer'ы и ревьюеры
|
|
||||||
диспатчатся на глубину 1, что укладывается в `subagent.maxDepth` по
|
|
||||||
умолчанию.
|
|
||||||
- Несколько задач, каждая по SDD, — контроллер фоновый сабагент на план,
|
|
||||||
глубина 2.
|
|
||||||
|
|
||||||
Skill MUST проверить доступную глубину до первого диспатча и MUST записать
|
|
||||||
рулинг с откатом в режим главной сессии, если глубина меньше нужной.
|
|
||||||
|
|
||||||
#### Scenario: Одна сложная задача
|
|
||||||
- **WHEN** в сессии один план и он архитектурный
|
|
||||||
- **THEN** контроллером остаётся главная сессия, а субагенты вызываются с
|
|
||||||
глубины 1
|
|
||||||
|
|
||||||
#### Scenario: Глубина не поднята
|
|
||||||
- **WHEN** выбрано несколько параллельных планов, а `subagent.maxDepth` равен 1
|
|
||||||
- **THEN** skill не диспатчит контроллера, фиксирует рулинг об откате в режим
|
|
||||||
главной сессии и продолжает исполнение в нём
|
|
||||||
|
|
||||||
### Requirement: Асинхронный протокол диспатча и отчёта
|
|
||||||
Диспатч implementer'а SHALL передавать требования файлом брифа, а результат
|
|
||||||
MUST возвращаться файлом отчёта; в контекст контроллера возвращается только
|
|
||||||
статус, коммиты, одна строка сводки тестов и concerns. Контракт статусов:
|
|
||||||
`DONE`, `DONE_WITH_CONCERNS`, `NEEDS_CONTEXT`, `BLOCKED`.
|
|
||||||
|
|
||||||
#### Scenario: Отчёт файлом
|
|
||||||
- **WHEN** implementer завершил задачу
|
|
||||||
- **THEN** полный отчёт лежит в файле отчёта, а в ledger и контекст попали
|
|
||||||
только статус, коммиты и строка тестов
|
|
||||||
|
|
||||||
### Requirement: Ожидание без блокировки
|
|
||||||
Skill MUST NOT ждать ребёнка синхронно: в DSH такого средства нет. Пока
|
|
||||||
у контроллера есть локальная работа, он MUST продолжать её; когда работы нет,
|
|
||||||
он MUST закончить ход и продолжить по уведомлению о завершении. Перед каждым
|
|
||||||
следующим диспатчем контроллер MUST сверить живых детей через `list_agents`,
|
|
||||||
чтобы поймать завершившегося без отчёта.
|
|
||||||
|
|
||||||
#### Scenario: Ребёнок завершился без отчёта
|
|
||||||
- **WHEN** уведомление о завершении не пришло, а `list_agents` показывает
|
|
||||||
неактивного ребёнка
|
|
||||||
- **THEN** контроллер считает задачу завершённой по git-состоянию и ledger,
|
|
||||||
а не перезапускает её
|
|
||||||
|
|
||||||
### Requirement: Ревью задачи и fix-loop
|
|
||||||
Каждая задача MUST проходить ревью по спеке и по качеству; implementer self-review
|
|
||||||
его не заменяет. Fix-loop MUST длиться не более 5 раундов: раунды 1–3 — тот же
|
|
||||||
implementer через `send_message`, раунды 4–5 — свежий implementer на тир выше.
|
|
||||||
После пятого раунда контроллер MUST адъюдицировать каждую открытую находку.
|
|
||||||
|
|
||||||
#### Scenario: Дефект найден и закрыт
|
|
||||||
- **WHEN** ревьюер задачи вернул находку по существу
|
|
||||||
- **THEN** раунд фикса уходит тому же implementer'у, ре-ревью ограничено
|
|
||||||
исправлением, находка получает статус `fixed <commit>`
|
|
||||||
|
|
||||||
### Requirement: Ledger и маркировка находок
|
|
||||||
Своя рабочая директория плана SHALL содержать `progress.md` с первой строкой —
|
|
||||||
путём плана. Ledger MUST содержать таблицу сканирования плана, рулинги
|
|
||||||
`R-n (design #n)` и раздел `## Findings`, где у каждой находки есть маркер
|
|
||||||
источника (`T<n>.<k>`, `C-n`/`I-n`/`M-n`) и статус `fixed <commit>`,
|
|
||||||
`deferred` или `rejected <причина>`.
|
|
||||||
|
|
||||||
#### Scenario: Находка без статуса
|
|
||||||
- **WHEN** финальное ревью ветки вернуло находку, а исполнение остановлено
|
|
||||||
- **THEN** отчёт контроллера обязан показать её со статусом; находка без
|
|
||||||
статуса считается ошибкой контроллера
|
|
||||||
|
|
||||||
### Requirement: Тира моделей и деградация
|
|
||||||
Skill MUST называть маршруты моделей явно при каждом диспатче, если выбор
|
|
||||||
модели доступен, и MUST NOT выдавать это за гарантию: у `subagent` параметры
|
|
||||||
`provider`/`model` появляются только после включения выбора модели в профиле.
|
|
||||||
Без включённого выбора модели skill MUST исполнять всё на модели сессии и
|
|
||||||
указывать это в отчёте.
|
|
||||||
|
|
||||||
#### Scenario: Выбор модели выключен
|
|
||||||
- **WHEN** профиль не включает выбор модели для `subagent`
|
|
||||||
- **THEN** все implementer'ы и ревьюеры идут на модели сессии, а отчёт
|
|
||||||
фиксирует отсутствие тиров как наблюдение, а не как выполненное требование
|
|
||||||
|
|
||||||
### Requirement: Отличие от Claude-SDD зафиксировано
|
|
||||||
Skill SHALL содержать таблицу отличий от `subagent-driven-development` Claude
|
|
||||||
Code: синхронный `Task` против асинхронного `subagent`, наличие `send_message`,
|
|
||||||
глубина по умолчанию, выбор модели, отсутствие уведомления как штатного
|
|
||||||
ожидания. Skill MUST NOT утверждать паритет с Claude-SDD.
|
|
||||||
|
|
||||||
#### Scenario: Чтение skill перед первым диспатчем
|
|
||||||
- **WHEN** модель загрузила skill и читает таблицу отличий
|
|
||||||
- **THEN** из неё видно, что ожидание строится на завершении хода и
|
|
||||||
уведомлении, а не на возврате значения инструмента
|
|
||||||
Loading…
x
Reference in New Issue
Block a user