Files

Tom Boucher 647365faf1 fix(#4011 ): key the TDD runtime gate on TDD_MODE alone (#4180 )

* test(#4011): TDD gate keys on TDD_MODE alone, not the MVP intersection

Contract updates: no shipped line may conjoin MVP_MODE with TDD_MODE as
a gate condition, the end-of-phase escalation must not require MVP, the
executor agent's gate section triggers on TDD_MODE alone, and the gate
semantics reference loads without MVP_MODE.

* fix(#4011): key the TDD runtime gate on TDD_MODE alone

The RED-commit gate shipped as #76's MVP slice kept the paired
invocation's conjunct, so workflow.tdd_mode=true was silently inert on
every non-MVP phase, contradicting references/tdd.md's own contract.
Drops the MVP conjunct from the per-task gate and the end-of-phase
review escalation; rescopes execute-mvp-tdd.md's load condition,
gsd-executor's gate section, and mvp-concepts' intersection claim.
MVP remains free to imply TDD; the file is not renamed (stated
assumption in the PR body).

* test(#4011): scope no-conjunct detector to shell conditions; clean stale MVP+TDD phrasing

Review follow-ups: the detector now only inspects if/[ condition lines
so explanatory prose mentioning both flags cannot trip it; remaining
'under/outside MVP+TDD' phrases in execute-phase.md, the gate
reference, and docs/INVENTORY.md now describe TDD-mode semantics.

Emitted-Drift-Ack-Growth: execute-phase.md — TDD-gate decoupling comment + escalation rescoping (#4011)
Emitted-Drift-Ack-Growth: gsd-executor.md — gate section trigger rescoped to TDD_MODE alone (#4011)

* chore(#4011): backfill changeset pr number

---------

Co-authored-by: sim <sim@local>

2026-09-02 04:24:52 -04:00

4.4 KiB

Raw Blame History

Execute-Phase — TDD Gate (Runtime Enforcement)

Loaded by execute-phase workflow and gsd-executor agent when TDD_MODE=true for the phase (#4011 — the gate no longer requires MVP mode; MVP may imply TDD, but TDD never requires MVP). Defines the runtime gate that blocks behavior-adding tasks until a failing-test commit exists.

When this gate fires

TDD_MODE is true (resolved from --tdd flag → workflow.tdd_mode config). MVP mode is NOT required (#4011).
The current task being executed has tdd="true" in its <task> frontmatter (set by the planner per Phase 1).
The task's <behavior> block lists at least one expected behavior.

If any of these is false, the gate is inactive — execution proceeds normally.

What the gate checks

For each task gated by TDD, the executor MUST verify (before running the implementation step):

A failing-test commit exists. Search git log on the current branch for a commit matching test({phase}-{plan}) whose subject mentions the same plan as the current task. The commit must touch a test file (*.test.*, *.spec.*, tests/**).
The test was actually red. The commit message body or the executor's recent shell history must show the test failed when first run. Acceptable evidence:
- Commit message contains RED: prefix or (RED) tag
- Recent terminal output shows FAIL or non-zero exit on the new test before any implementation commit
No implementation commit yet. No feat({phase}-{plan}) commit may exist for the same plan ID before the failing-test commit.

If any check fails, the gate trips.

What "behavior-adding task" means

A task is behavior-adding when:

Its frontmatter has tdd="true" AND
Its <behavior> block names at least one user-visible outcome (not a config-only or doc-only task) AND
Its <files> list includes at least one source file (not exclusively docs/tests/config files such as *.md, *.json, *.test.*, *.spec.*, *.yml, *.yaml, *.toml, *.ini, .env*)

Pure documentation, configuration, or test-only tasks are skipped by this gate even when both modes are active.

What happens when the gate trips

The executor MUST:

Halt before running the task's implementation step.
Emit a structured halt report:

TDD GATE TRIPPED — Plan {plan_id}, Task {task_id}

Reason: {missing_red_commit | red_commit_not_failing | feat_before_test}

Behavior expected to be tested:

{first behavior bullet}

Required next step:

Write a failing test for the behavior above.
Commit it as: test({phase}-{plan}): {short description}
Re-run /gsd execute-phase


3. Exit the current execution wave cleanly. Do NOT roll back any prior commits in the same wave.
4. Update `STATE.md` with `last_gate_trip: {plan_id}/{task_id}` so the user can resume after writing the test.

## Escalation: end-of-phase TDD review under TDD

The existing end-of-phase TDD review (in `workflows/execute-phase.md`'s `tdd_review_checkpoint` step) is normally **advisory** — it surfaces gate violations but does not block phase completion.

Under TDD mode, escalate this to **blocking**:
- If any TDD plan is missing a RED or GREEN commit, the executor MUST refuse to mark the phase complete.
- The user is shown the same review table, but the verdict line reads:
> "Phase blocked: {N} TDD plan(s) violate the RED→GREEN gate sequence under TDD. Resolve and re-run /gsd execute-phase, or override with `/gsd execute-phase {phase} --force-mvp-gate` to ship anyway."

The `--force-mvp-gate` flag is documented but not introduced by this plan — it is the escape hatch the spec mentions; if the user later builds it, the workflow already references the contract.

## What this gate does NOT do

- It does not enforce REFACTOR commits. REFACTOR remains optional (per `gsd-core/references/tdd.md`).
- It does not check test quality (the test could be trivially passing). That's the planner's job.
- It does not run tests. The executor only inspects git log + file system. Running tests is the implementation step's job.
- It does not gate config-only or doc-only tasks (see "behavior-adding task" definition).

## Compatibility with existing TDD discipline

This gate is additive to `gsd-core/references/tdd.md`. Tasks not under TDD mode continue to use the existing advisory TDD discipline (RED/GREEN/REFACTOR commits with end-of-phase review checkpoint). Only the runtime gate and the blocking escalation are new.

4.4 KiB Raw Blame History