| name | sdd:test |
| description | Generate and run check artifacts for a spec. Self-sufficient: MCP preflight, 2-agent generation, автоматически по всем Requirements, auto state transition.
|
| workflow_step | 5 |
Шаг 0: MCP preflight
Попытайся вызвать sdd_db_init (MCP tool).
Если инструмент недоступен:
-
Прочитай .mcp.json. Если sdd-scripts отсутствует → остановись:
✗ sdd-scripts не зарегистрирован в .mcp.json. Добавьте запись вручную и перезапустите.
-
Если sdd-scripts присутствует → запусти через Bash tool:
python3 "${CLAUDE_SKILL_DIR}/../scripts/enable_mcp.py"
- Вывод
added → остановись:
Конфигурация обновлена: sdd-scripts добавлен в enabledMcpjsonServers.
Перезапустите сессию Claude Code и повторите /sdd:test.
- Вывод
already-enabled → остановись:
MCP-сервер настроен, но не загружен. Перезапустите сессию Claude Code.
- Вывод
error: → остановись с текстом ошибки.
Если инструмент доступен → перейди к шагу 0.5.
Шаг 0.5: выбор режима и start run
Спроси через AskUserQuestion:
Режим прогона:
- full — заново генерировать check-скрипты и запустить всё
- rerun — запустить существующие скрипты без регенерации
- show — показать текущее состояние БД без запуска
Определи <spec> из $ARGUMENTS или из контекста разговора.
Вызови sdd_db_run_start → получи run_id. Все дальнейшие sdd_db_step_* используют этот run_id.
Шаг 1: загрузка спеки
sdd_db_step_start run_id 1
Прочитай <spec>/spec.md. Извлеки все Requirements и Scenarios.
Если spec.md содержит test_type: в Purpose-секции → sdd_db_set_spec_meta <spec> test_type <value>.
Зарегистрируй каждый Requirement через sdd_db_add <spec> <req_id> <run_id> → получи check_id.
Если у Requirement есть явный scope: → sdd_db_set_req_meta <spec> <req_id> scope <value>.
sdd_db_step_done run_id 1
Шаг 2: чтение метаданных
sdd_db_step_start run_id 2
Для каждого Requirement прочитай check_id через sdd_db_read. Собери:
test_type спеки (из spec_meta)scope каждого Requirement (из checks)
sdd_db_step_done run_id 2
Шаг 3: wipe (только в режиме full)
sdd_db_step_start run_id 3
Если mode=full: спроси подтверждение через AskUserQuestion:
Удалить существующие check-скрипты и данные БД для <spec>?
При согласии: sdd_db_delete_spec <spec>, удали файлы <spec>/scripts/check_*.py.
sdd_db_step_done run_id 3
Шаг 4: загрузка критериев
sdd_db_step_start run_id 4
Вызови sdd_db_list_criteria → получи JSON список критериев.
Они передаются Агенту 1 на шаге 6.
sdd_db_step_done run_id 4
Шаг 5: прогон существующих скриптов (rerun / full после wipe)
sdd_db_step_start run_id 5
Для каждого check: если script_path задан и файл существует → запусти через Bash tool.
Запиши результат через sdd_db_write_manual <check_id> passed|failed.
sdd_db_step_done run_id 5
Шаг 6: генерация (только mode=full)
sdd_db_step_start run_id 6
Для каждого Requirement параллельно:
scope=workflow
Создай тест-кейс <spec>/cases/<req_slug>.md по шаблону из cases/test.md.
Запиши путь: sdd_db_write_script_path <check_id> <path>.
scope=component — два агента последовательно
Агент 1 (анализ):
Входы:
- Полный текст
spec.md
- Текст данного Requirement + его Scenarios
- Список критериев из шага 4 (
test_type, scope)
Задача: системный анализ (процесс → контекст → цель → failure mode), MVP без деталей.
Если test_type=imperative — включить precondition/operation/postcondition.
Если test_type=declarative — включить assertions по каждому полю/правилу.
Формат вывода — жёсткий YAML:
goal: <что этот requirement охраняет>
failure_mode: <что сломается если нарушен>
scenarios:
- id: <scenario-id>
description: <дословно из spec.md>
checks:
- what: <что проверить>
justification: <цитата из текста Requirement>
boundary: <граничный случай с обоснованием, если применимо>
После завершения: sdd_db_write_analysis_notes <check_id> <yaml> (ставит analysis_status=done).
Агент 2 (генерация):
Входы:
analysis_notes из БД (основной источник — sdd_db_read <check_id>)spec.md только для разрешения неоднозначностей
Правило: реализовать ровно то, что в analysis_notes. Не добавлять проверки из spec.md.
Если противоречие analysis_notes vs spec.md → флагировать в stdout, не генерировать (сигнал перезапустить Агента 1).
Контракт скрипта (D22):
- Exit 0 = pass, exit 1 = fail, exit 2 = env-error
- Первая строка stdout:
PASS или FAIL: <reason>
- Read-only, детерминированный
- Данные через CLI/API, не через прямое чтение файлов
Сохрани скрипт: <spec>/scripts/check_<req_slug>.py.
Запиши путь: sdd_db_write_script_path <check_id> <path>.
Ставит generation_status=done.
sdd_db_step_done run_id 6
Шаг 6.5: проверка покрытия Scenarios
После каждого Агента 2: sdd_db_list_gaps <check_id>.
Если непусто → вернись к Агенту 2 с запросом дописать проверки.
Максимум 2 итерации.
Шаг 7: семантическая оценка (автоматически по всем Requirements)
sdd_db_step_start run_id 7
Вызови sdd_db_start_semantic_eval <run_id> agent до запуска субагентов.
Без этого вызова sdd_db_step_done run_id 7 завершится ошибкой.
Для каждого Requirement запусти субагент-оценщик:
Входы субагента:
- Текст Requirement + Scenarios из spec.md
- Содержимое check-скрипта (если scope=component) или тест-кейса (workflow)
- Список критериев (id, name, category, признаки нарушения)
Задача субагента (Верификация — шаг 7):
Проверь что тест действительно проверяет то, что написано в требовании.
Оцени каждый критерий: passed/failed.
Запиши через sdd_db_add_criterion_result <check_id> <criterion_id> <passed> <notes>.
История накапливается — повторный вызов добавляет строку, не перезаписывает.
sdd_db_step_done run_id 7
Шаг 7.5: автоматический transition Блока 1
sdd_db_step_start run_id 7.5
Если скилл вызван в контексте change'а (известен change_id):
Прочитай агрегат через sdd_db_report <spec>.
- Все
manual_result = passed → sdd_state_transition <change_id> verify-ok
- Хотя бы один
manual_result = failed → sdd_state_transition <change_id> verify-failed
Только Skill Flow выполняет этот transition. Generation и Evaluation — запрещено.
sdd_db_step_done run_id 7.5
Шаг 8: итоговый отчёт
sdd_db_step_start run_id 8
Вызови sdd_db_report <spec> → выведи таблицу:
| Requirement | Script | Manual | Semantic | Criteria |
|-------------|--------|--------|----------|----------|
| req-name | ✓ | passed | passed | 7/7 |
Итоговая строка: N/M passed.
Orphans из report → отдельная секция если непусто.
sdd_db_step_done run_id 8
