DSH: SDD spike — async controller vs workflow #41

Closed
opened 2026-10-24 15:40:59 +03:00 by aep · 3 comments
Owner

Цель

Сделать DSH-native SDD: контроллер исполняет план через субагентов, собирает отчёты, делает ревью и fix-loop. Не выдавать это за паритет с Claude Task, пока не проверено живьём.

Контекст

  • Порт уже в main: #36 (guard/bootstrap//role), #38 (skills/roles в ~/.dsh), #40 (model-invocable skill role).
  • Дизайн и риски: dsh/PORT.md, раздел 8.
  • Роли: ~/.dsh/roles/dev.md; модель загружает их через skill role.
  • Claude Task синхронный; DSH subagent асинхронный (send_message, maxDepth: 2), workflow синхронный.
  • Модели sonnet/haiku/opus не DSH; нужна таблица реальных provider/model routes.

Варианты

A. Async controller: главный агент вызывает subagent, ждёт отчёт, затем reviewer, fix-loop. Гибко, но надо определить протокол ожидания/таймаутов.
B. workflow-скрипт: детерминированный fan-out implementer/reviewer. Проще для предсказуемых планов, хуже для адаптивных ревью.
C. Гибрид: workflow для независимых задач, async controller для ревью/фиксов.

Deliverables

  • design note с выбранной семантикой и model routes;
  • skill/инструкция DSH SDD (dispatch, wait, report, review, findings, ledger);
  • один план из 3 задач, прогнанный в temp-репо: implementer → reviewer → fix → final review;
  • тесты/проверки, которые можно прогнать без DSH runtime;
  • README/PORT обновлены.

Acceptance

  • 3 задачи не теряются, отчёты собираются, ревьюер находит и проверяет хотя бы один дефект, fix-loop завершается;
  • ledger содержит ## Findings со статусами;
  • итоговый прогон тестов зелёный;
  • явно указано, чем DSH-семантика отличается от Claude SDD.

Старт в новой сессии

Прочитать dsh/PORT.md, roles/dev.md (через skill role), этот issue. Не начинать с кода: сначала design spike и один пробный план.

## Цель Сделать DSH-native SDD: контроллер исполняет план через субагентов, собирает отчёты, делает ревью и fix-loop. Не выдавать это за паритет с Claude `Task`, пока не проверено живьём. ## Контекст - Порт уже в main: #36 (guard/bootstrap//role), #38 (skills/roles в ~/.dsh), #40 (model-invocable skill `role`). - Дизайн и риски: `dsh/PORT.md`, раздел 8. - Роли: `~/.dsh/roles/dev.md`; модель загружает их через `skill role`. - Claude `Task` синхронный; DSH `subagent` асинхронный (`send_message`, `maxDepth: 2`), `workflow` синхронный. - Модели `sonnet`/`haiku`/`opus` не DSH; нужна таблица реальных provider/model routes. ## Варианты A. Async controller: главный агент вызывает `subagent`, ждёт отчёт, затем reviewer, fix-loop. Гибко, но надо определить протокол ожидания/таймаутов. B. `workflow`-скрипт: детерминированный fan-out implementer/reviewer. Проще для предсказуемых планов, хуже для адаптивных ревью. C. Гибрид: workflow для независимых задач, async controller для ревью/фиксов. ## Deliverables - design note с выбранной семантикой и model routes; - skill/инструкция DSH SDD (dispatch, wait, report, review, findings, ledger); - один план из 3 задач, прогнанный в temp-репо: implementer → reviewer → fix → final review; - тесты/проверки, которые можно прогнать без DSH runtime; - README/PORT обновлены. ## Acceptance - 3 задачи не теряются, отчёты собираются, ревьюер находит и проверяет хотя бы один дефект, fix-loop завершается; - ledger содержит `## Findings` со статусами; - итоговый прогон тестов зелёный; - явно указано, чем DSH-семантика отличается от Claude SDD. ## Старт в новой сессии Прочитать `dsh/PORT.md`, `roles/dev.md` (через `skill role`), этот issue. Не начинать с кода: сначала design spike и один пробный план.
Author
Owner

Состояние: фаза начата, дизайн зафиксирован

Ветка feat/41-dsh-sdd-spike (push сделан), worktree:
/Users/andrey.epifancev/projects/cc-skills/claude-harness/.claude/worktrees/sdd-spike.

Коммит ee0d876: openspec/changes/dsh-sdd/ — proposal, design, spec delta
(openspec validate dsh-sdd — valid). Тесты на ветке зелёные:
dsh/tests/run.sh 30/30, tests/run.sh 630/630.

Измеренные ограничения DSH 0.2.1-rc.3 (основание дизайна)

  1. subagent.maxDepth по умолчанию 1 — фоновый контроллер (глубина 1) не
    позовёт implementer'а (глубина 2).
  2. У subagent нет provider/model, пока строке tool-subagent не поставлен
    modelSelectionSettings: true; иначе ребёнок наследует модель сессии.
  3. Выбор модели работает сразу только в workflow.agent(). Маршрутов два:
    deepseek-official/deepseek-flash, deepseek-official/deepseek-v4-pro.
  4. Строка subagent-model-selection-settings есть в web/desktop-профиле и
    отсутствует в headless — флаг нельзя ставить в бандл, только в overlay профиля.

Решение владельца (24.10)

Режим контроллера зависит от контекста: одна сложная задача — контроллер
главная сессия; несколько задач параллельно — фоновый контроллер на задачу.

Действия владельца перед следующей сессией

Скопировать в ~/.dsh/profiles/desktop/cordis.patch.yml:

- id: tool-subagent
  config:
    modelSelectionSettings: true
- id: tool-subagent-fork
  config:
    modelSelectionSettings: true
- id: subagent
  config:
    maxDepth: 2

Затем рестарт приложения и на странице Plugins → Official → Subagent
включить Model selection с маршрутами deepseek-flash и deepseek-v4-pro
(и проверить Maximum recursion depth = 2). Проверка: в новой сессии у
инструмента subagent в схеме появляются provider, model,
reasoning_effort.

Что делает следующая сессия

  1. План через writing-plans → docs/superpowers/plans/ по
    openspec/changes/dsh-sdd/ (design.md — источник решений).
  2. Task 1 — dsh/subagent-models.yml (overlay, содержимое уже в design.md) +
    строка в dsh/PORT.md + dsh/tests/sdd-skill.test.mjs.
  3. Task 2 — dsh/skills/sdd/SKILL.md + установка через dsh/install.sh --skills.
  4. Task 3 — пробный прогон: план из 3 задач в temp-репозитории,
    implementer → reviewer → fix → финальное ревью; результат в design.md и сюда.
  5. PR в main, ссылка на этот issue.

Наблюдения

  • O-1. В новом worktree dsh/bundle/hooks материализуется обычным файлом,
    а не симлинком (core.symlinks=false на машине), из-за чего 5 тестов
    dsh/tests/run.sh падают на BLOCKED [guard-main]. Лечится в worktree:
    rm dsh/bundle/hooks && ln -s ../../hooks dsh/bundle/hooks. Стоит проверить
    в dsh/install.sh --check или в тестах.
## Состояние: фаза начата, дизайн зафиксирован Ветка `feat/41-dsh-sdd-spike` (push сделан), worktree: `/Users/andrey.epifancev/projects/cc-skills/claude-harness/.claude/worktrees/sdd-spike`. Коммит `ee0d876`: `openspec/changes/dsh-sdd/` — proposal, design, spec delta (`openspec validate dsh-sdd` — valid). Тесты на ветке зелёные: `dsh/tests/run.sh` 30/30, `tests/run.sh` 630/630. ### Измеренные ограничения DSH 0.2.1-rc.3 (основание дизайна) 1. `subagent.maxDepth` по умолчанию **1** — фоновый контроллер (глубина 1) не позовёт implementer'а (глубина 2). 2. У `subagent` нет `provider`/`model`, пока строке `tool-subagent` не поставлен `modelSelectionSettings: true`; иначе ребёнок наследует модель сессии. 3. Выбор модели работает сразу только в `workflow.agent()`. Маршрутов два: `deepseek-official/deepseek-flash`, `deepseek-official/deepseek-v4-pro`. 4. Строка `subagent-model-selection-settings` есть в web/desktop-профиле и отсутствует в headless — флаг нельзя ставить в бандл, только в overlay профиля. ### Решение владельца (24.10) Режим контроллера зависит от контекста: одна сложная задача — контроллер главная сессия; несколько задач параллельно — фоновый контроллер на задачу. ### Действия владельца перед следующей сессией Скопировать в `~/.dsh/profiles/desktop/cordis.patch.yml`: ```yaml - id: tool-subagent config: modelSelectionSettings: true - id: tool-subagent-fork config: modelSelectionSettings: true - id: subagent config: maxDepth: 2 ``` Затем рестарт приложения и на странице **Plugins → Official → Subagent** включить **Model selection** с маршрутами `deepseek-flash` и `deepseek-v4-pro` (и проверить **Maximum recursion depth** = 2). Проверка: в новой сессии у инструмента `subagent` в схеме появляются `provider`, `model`, `reasoning_effort`. ### Что делает следующая сессия 1. План через `writing-plans` → `docs/superpowers/plans/` по `openspec/changes/dsh-sdd/` (design.md — источник решений). 2. Task 1 — `dsh/subagent-models.yml` (overlay, содержимое уже в design.md) + строка в `dsh/PORT.md` + `dsh/tests/sdd-skill.test.mjs`. 3. Task 2 — `dsh/skills/sdd/SKILL.md` + установка через `dsh/install.sh --skills`. 4. Task 3 — пробный прогон: план из 3 задач в temp-репозитории, implementer → reviewer → fix → финальное ревью; результат в design.md и сюда. 5. PR в main, ссылка на этот issue. ### Наблюдения - **O-1.** В новом worktree `dsh/bundle/hooks` материализуется обычным файлом, а не симлинком (`core.symlinks=false` на машине), из-за чего 5 тестов `dsh/tests/run.sh` падают на `BLOCKED [guard-main]`. Лечится в worktree: `rm dsh/bundle/hooks && ln -s ../../hooks dsh/bundle/hooks`. Стоит проверить в `dsh/install.sh --check` или в тестах.
Author
Owner

Фаза выполнена, PR #50

Ветка feat/41-dsh-sdd-spike, PR: #50

Что в PR

  • dsh/skills/sdd/SKILL.md — DSH-семантика исполнения плана;
  • dsh/subagent-models.yml — opt-in overlay (model selection + maxDepth: 2), install.sh --check его проверяет;
  • тесты dsh/tests/sdd-skill.test.mjs, dsh/tests/subagent-models.test.mjs (38/38 в dsh/tests/run.sh, 630/630 в tests/run.sh);
  • артефакты пробного прогона — openspec/changes/dsh-sdd/trial/, результаты — design.md.

Пробный прогон (главная сессия контроллер, Режим 1)

Шаг Модель Результат
Task 1 implementer flash DONE dc1670f, 2 теста
Task 1 review v4-pro APPROVED
Task 2 implementer flash DONE 836a730, 4 теста
Task 2 review v4-pro CHANGES_REQUESTED: T2.1, T2.2
fix-раунд 1 (send_message тому же implementer'у) flash 186575c, 6 тестов
ре-ревью (скоуп) v4-pro APPROVED: T2.1 fixed 186575c, T2.2 fixed 186575c
Task 3 implementer flash DONE 7cb0383, 7 тестов
Task 3 review v4-pro APPROVED
финальное ревью ветки v4-pro APPROVED

Ревьюер нашёл дефект независимо: median([1,2]) == 2.0 вместо 1.5 по спеке; implementer тоже заметил расхождение, но поставил DONE — в skill добавлено правило «замеченное расхождение — DONE_WITH_CONCERNS».

Режим 2 (фоновый контроллер, глубина 2)

Проверен отдельной пробой: контроллер (flash) вызвал subagent (flash), ход закончился, уведомление пришло отдельным сообщением, после него контроллер проверил отчёт, коммит 0601d6e и тесты. Глубина 2 работает с overlay.

Наблюдения

  • O-2/O-3: первый вызов subagent с переданными provider/model вернул «child LLM provider and model must be supplied together» (2 раза за прогон); повтор тем же вызовом проходит. deferred.
  • O-4: число тестов в плане устаревает после fix-раунда (5 → 7); fixed — правило в skill.
  • O-5: describe([1,2,3]) на симметричном входе не отличил бы перестановку mean/median; deferred, код верен.
  • O-1: «Interfaces» плана обещают аннотации, «Exact code» их не содержит; rejected (дефект плана прогона, не кода).

Что осталось человеку

  • ревью и merge PR #50;
  • после merge — openspec archive dsh-sdd отдельным PR и закрытие issue по чеклисту;
  • решить открытый вопрос из design.md: добавить ли в ~/.dsh/roles/dev.md строку «в DSH исполнение плана — skill sdd».
## Фаза выполнена, PR #50 Ветка `feat/41-dsh-sdd-spike`, PR: https://git.aepif.ru/aep/claude-harness/pulls/50 ### Что в PR - `dsh/skills/sdd/SKILL.md` — DSH-семантика исполнения плана; - `dsh/subagent-models.yml` — opt-in overlay (model selection + `maxDepth: 2`), `install.sh --check` его проверяет; - тесты `dsh/tests/sdd-skill.test.mjs`, `dsh/tests/subagent-models.test.mjs` (38/38 в `dsh/tests/run.sh`, 630/630 в `tests/run.sh`); - артефакты пробного прогона — `openspec/changes/dsh-sdd/trial/`, результаты — `design.md`. ### Пробный прогон (главная сессия контроллер, Режим 1) | Шаг | Модель | Результат | |---|---|---| | Task 1 implementer | flash | `DONE` `dc1670f`, 2 теста | | Task 1 review | v4-pro | `APPROVED` | | Task 2 implementer | flash | `DONE` `836a730`, 4 теста | | Task 2 review | v4-pro | `CHANGES_REQUESTED`: `T2.1`, `T2.2` | | fix-раунд 1 (`send_message` тому же implementer'у) | flash | `186575c`, 6 тестов | | ре-ревью (скоуп) | v4-pro | `APPROVED`: `T2.1 fixed 186575c`, `T2.2 fixed 186575c` | | Task 3 implementer | flash | `DONE` `7cb0383`, 7 тестов | | Task 3 review | v4-pro | `APPROVED` | | финальное ревью ветки | v4-pro | `APPROVED` | Ревьюер нашёл дефект **независимо**: `median([1,2]) == 2.0` вместо `1.5` по спеке; implementer тоже заметил расхождение, но поставил `DONE` — в skill добавлено правило «замеченное расхождение — `DONE_WITH_CONCERNS`». ### Режим 2 (фоновый контроллер, глубина 2) Проверен отдельной пробой: контроллер (flash) вызвал `subagent` (flash), ход закончился, уведомление пришло отдельным сообщением, после него контроллер проверил отчёт, коммит `0601d6e` и тесты. Глубина 2 работает с overlay. ### Наблюдения - `O-2`/`O-3`: первый вызов `subagent` с переданными `provider`/`model` вернул «child LLM provider and model must be supplied together» (2 раза за прогон); повтор тем же вызовом проходит. `deferred`. - `O-4`: число тестов в плане устаревает после fix-раунда (5 → 7); `fixed` — правило в skill. - `O-5`: `describe([1,2,3])` на симметричном входе не отличил бы перестановку `mean`/`median`; `deferred`, код верен. - `O-1`: «Interfaces» плана обещают аннотации, «Exact code» их не содержит; `rejected` (дефект плана прогона, не кода). ### Что осталось человеку - ревью и merge PR #50; - после merge — `openspec archive dsh-sdd` отдельным PR и закрытие issue по чеклисту; - решить открытый вопрос из `design.md`: добавить ли в `~/.dsh/roles/dev.md` строку «в DSH исполнение плана — skill `sdd`».
Author
Owner

Закрыто

  • PR #50 — skill sdd, overlay dsh/subagent-models.yml, тесты, пробный прогон (merge 303b7f0).
  • PR #51 — openspec archive dsh-sdd (merge 36bf106): change в openspec/changes/archive/2026-10-24-dsh-sdd/, спека в openspec/specs/dsh-sdd/spec.md.

Приёмка #41 — все пункты выполнены

Пункт Доказательство
3 задачи не теряются ledger Task 1..3: complete, 4 коммита прогона
отчёты собираются 9 отчётов в trial/reports/
ревьюер находит и проверяет дефект T2.1, T2.2 → fixed 186575c, ре-ревью APPROVED
fix-loop завершается раунд 1 из 5, ре-ревью чистое
ledger с ## Findings и статусами trial/ledger.md
прогон тестов зелёный 38/38, 630/630, 7/7, openspec validate valid
отличие от Claude-SDD указано таблица в dsh/skills/sdd/SKILL.md

Отложенные находки

O-2/O-3 (нестабильная валидация provider/model) и O-5 (симметричный вход в тесте прогона) вынесены в follow-up issue.

Чего в репозитории нет

Skill sdd не установлен в ~/.dsh из сессии (запись вне workspace): развернуть — bash dsh/install.sh --skills из терминала.

## Закрыто - PR #50 — skill `sdd`, overlay `dsh/subagent-models.yml`, тесты, пробный прогон (merge `303b7f0`). - PR #51 — `openspec archive dsh-sdd` (merge `36bf106`): change в `openspec/changes/archive/2026-10-24-dsh-sdd/`, спека в `openspec/specs/dsh-sdd/spec.md`. ### Приёмка #41 — все пункты выполнены | Пункт | Доказательство | |---|---| | 3 задачи не теряются | ledger `Task 1..3: complete`, 4 коммита прогона | | отчёты собираются | 9 отчётов в `trial/reports/` | | ревьюер находит и проверяет дефект | `T2.1`, `T2.2` → `fixed 186575c`, ре-ревью APPROVED | | fix-loop завершается | раунд 1 из 5, ре-ревью чистое | | ledger с `## Findings` и статусами | `trial/ledger.md` | | прогон тестов зелёный | 38/38, 630/630, 7/7, `openspec validate` valid | | отличие от Claude-SDD указано | таблица в `dsh/skills/sdd/SKILL.md` | ### Отложенные находки `O-2`/`O-3` (нестабильная валидация `provider`/`model`) и `O-5` (симметричный вход в тесте прогона) вынесены в follow-up issue. ### Чего в репозитории нет Skill `sdd` не установлен в `~/.dsh` из сессии (запись вне workspace): развернуть — `bash dsh/install.sh --skills` из терминала.
aep closed this issue 2026-10-24 16:57:57 +03:00
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: aep/claude-harness#41
No description provided.