Fork a spec-tdd workflow schema #40

New Issue

2026-08-10T13:10:09Z

claude commented

2026-08-10 13:10:09 +00:00

Summary

Форкнуть стоковую схему spec-driven в проектную spec-tdd и добавить в неё
артефакт tests между specs и tasks.

Spec

none

Depends on

commit-the-openspec-scaffold — схема должна быть в git, иначе её нет в worktree

Motivation

Стоковая цепочка — proposal → specs → design → tasks. В ней негде описать
тест-кейсы, и задачи пишутся раньше, чем известно, что именно проверяем.
Получается SDD без TDD.

Недостающее звено — tests.md: по записи на каждый сценарий спеки, прозой для
человека. Что кейс доказывает, как выглядит Red, что делает Green, куда ляжет
сам тест. Тогда tasks.md генерится парами RED: <TC> / GREEN: <TC> и
ссылается на конкретные кейсы, а не на абстрактные «реализовать».

Схема — единственный слой openspec, который гнётся под проект.
openspec schema fork spec-driven spec-tdd кладёт копию в
openspec/schemas/spec-tdd/, дальше правится свободно. Границы проверены по
zod-описанию пакета
(dist/core/artifact-graph/types.d.ts): artifacts принимает
{id, generates, description, template, instruction, requires}, apply —
{requires, tracks, instruction}, и больше ничего. Ни хуков, ни shell в схеме
нет и не будет — всё исполняемое живёт в отдельном слое.

Идентификатор кейса — TC-<CAP>-NNN, где <CAP> это capability. Ссылка из
спеки в кейс идёт буллетом внутри сценария:

#### Scenario: Push succeeds
- **WHEN** the tracker returns 2xx and `.remote.json` has been written
- **THEN** `<id>.md` and `<id>.comments.md` are deleted
- **TEST** TC-SYNC-001

Носитель выбран после пробы: буллет переживает полный круг архивации, а
заголовок сценария трогать нельзя — по нему openspec матчит MODIFIED-дельты,
и переименование потеряет дельту. Подробности пробы —
в lint-the-spec-to-test-linkage.

Acceptance criteria

openspec/schemas/spec-tdd/schema.yaml существует, openspec schemas
печатает его в списке
порядок артефактов proposal → specs → tests → tasks, при этом
tests.requires: [specs] и tasks.requires: [specs, design, tests]
apply.requires содержит и tests, и tasks — apply не стартует, пока
тест-кейсы не описаны
шаблон tests.md даёт на кейс: id TC-<CAP>-NNN, покрываемый сценарий,
прозу «что проверяем», Red, Green и путь к тесту
шаблон tasks.md требует пары RED: <TC> / GREEN: <TC> и сохраняет
формат чекбоксов - [ ] X.Y, который парсит фаза apply
инструкция артефакта specs требует буллет **TEST** TC-… в каждом
сценарии
openspec schema validate spec-tdd проходит
spec-tdd назначена схемой по умолчанию в openspec/config.yaml
один реальный change доходит по этой схеме от openspec new change до
apply-ready, openspec status показывает все артефакты done

Constraints

Не входит в объём: править .claude/commands/opsx/*.md. Они генерируются из
пакета (dist/core/templates/workflows/propose.js) и будут перезаписаны
первым же openspec update.
Не входит в объём: линтер связки спека ↔ тест — отдельный issue
lint-the-spec-to-test-linkage.
Не входит в объём: удаление артефакта design. Он остаётся необязательным,
как в стоковой схеме.

## Summary Форкнуть стоковую схему `spec-driven` в проектную `spec-tdd` и добавить в неё артефакт `tests` между `specs` и `tasks`. ## Spec none ## Depends on - commit-the-openspec-scaffold — схема должна быть в git, иначе её нет в worktree ## Motivation Стоковая цепочка — `proposal → specs → design → tasks`. В ней негде описать тест-кейсы, и задачи пишутся раньше, чем известно, что именно проверяем. Получается SDD без TDD. Недостающее звено — `tests.md`: по записи на каждый сценарий спеки, прозой для человека. Что кейс доказывает, как выглядит Red, что делает Green, куда ляжет сам тест. Тогда `tasks.md` генерится парами `RED: <TC>` / `GREEN: <TC>` и ссылается на конкретные кейсы, а не на абстрактные «реализовать». Схема — единственный слой openspec, который гнётся под проект. `openspec schema fork spec-driven spec-tdd` кладёт копию в `openspec/schemas/spec-tdd/`, дальше правится свободно. Границы проверены по zod-описанию пакета (`dist/core/artifact-graph/types.d.ts`): `artifacts` принимает `{id, generates, description, template, instruction, requires}`, `apply` — `{requires, tracks, instruction}`, и больше ничего. Ни хуков, ни shell в схеме нет и не будет — всё исполняемое живёт в отдельном слое. Идентификатор кейса — `TC-<CAP>-NNN`, где `<CAP>` это capability. Ссылка из спеки в кейс идёт буллетом внутри сценария: ``` #### Scenario: Push succeeds - **WHEN** the tracker returns 2xx and `.remote.json` has been written - **THEN** `<id>.md` and `<id>.comments.md` are deleted - **TEST** TC-SYNC-001 ``` Носитель выбран после пробы: буллет переживает полный круг архивации, а заголовок сценария трогать нельзя — по нему openspec матчит `MODIFIED`-дельты, и переименование потеряет дельту. Подробности пробы — в `lint-the-spec-to-test-linkage`. ## Acceptance criteria - [ ] `openspec/schemas/spec-tdd/schema.yaml` существует, `openspec schemas` печатает его в списке - [ ] порядок артефактов `proposal → specs → tests → tasks`, при этом `tests.requires: [specs]` и `tasks.requires: [specs, design, tests]` - [ ] `apply.requires` содержит и `tests`, и `tasks` — apply не стартует, пока тест-кейсы не описаны - [ ] шаблон `tests.md` даёт на кейс: id `TC-<CAP>-NNN`, покрываемый сценарий, прозу «что проверяем», Red, Green и путь к тесту - [ ] шаблон `tasks.md` требует пары `RED: <TC>` / `GREEN: <TC>` и сохраняет формат чекбоксов `- [ ] X.Y`, который парсит фаза apply - [ ] инструкция артефакта `specs` требует буллет `**TEST** TC-…` в каждом сценарии - [ ] `openspec schema validate spec-tdd` проходит - [ ] `spec-tdd` назначена схемой по умолчанию в `openspec/config.yaml` - [ ] один реальный change доходит по этой схеме от `openspec new change` до apply-ready, `openspec status` показывает все артефакты `done` ## Constraints - Не входит в объём: править `.claude/commands/opsx/*.md`. Они генерируются из пакета (`dist/core/templates/workflows/propose.js`) и будут перезаписаны первым же `openspec update`. - Не входит в объём: линтер связки спека ↔ тест — отдельный issue `lint-the-spec-to-test-linkage`. - Не входит в объём: удаление артефакта `design`. Он остаётся необязательным, как в стоковой схеме.

claude added this to the openspec integration milestone 2026-08-10 13:10:09 +00:00

claude added the

type

task

comp/openspec labels 2026-08-10 13:10:09 +00:00

claude added a new dependency 2026-08-10 13:10:10 +00:00

#39 Commit the OpenSpec scaffold

claude added a new dependency 2026-08-10 13:10:10 +00:00

#41 Lint the spec-to-test linkage

claude added a new dependency 2026-08-10 13:10:12 +00:00

#45 Adopt OpenSpec as the change workflow

Sign in to join this conversation.