Bdd

BDD Orchestrator

Behavior-first development for features. Discovery → Scenarios → Implementation.

Define the behavior before implementing it. When unsure whether work is a feature, default to a task (TDD directly) — the user can $safeword:bdd to override.

Phase Tracking

Features progress through phases. Track in ticket frontmatter:

---
type: feature
phase: implement # intake | define-behavior | scenario-gate | plan-implementation | implement | verify | done
---

Phase meanings:

Update phase when:

• Completing a BDD phase → set next phase
• Scenario-gate complete → offer the optional $safeword:spike checkpoint only for an eligible build-only kill-risk, then set plan-implementation (impl-plan authoring, proof plan + sequencing live there)
• Plan reviewed (impl-plan.md valid, status planned) → set implement
• All scenarios pass → set verify
• $safeword:verify + $safeword:audit complete (verify.md exists) → set done

Phase-exit review (Tier 2)

The scenario-gate exit requires review-spec in Review mode. That skill owns the scenario targets, project context, coordinator protocol, verdict, and review stamp. This orchestrator owns only routing and the phase transition; do not restate or independently invoke the scenario-review protocol here.

All BDD review exits share one lifecycle rule: REVIEW_PENDING is a live review, not a verdict. Keep its review_id, collect it through the returned typed nextActions until terminal, and never start a replacement review or advance/stamp while it is pending. REVIEW_STALE means rerun against the current artifacts. Only a terminal verdict may advance the phase.

The plan-implementation exit applies the same discipline to the implementation plan (see PLAN_IMPLEMENTATION.md's exit). Other phase exits don't need an independent review by default — they carry their own guards (intake's user sub-phase gates, implement's tests, the done-gate's evidence checks). When the review gate is enabled (reviewGate in .safeword/config.json — e.g. autonomous runs where user gates auto-confirm, ticket 2VCSZY), every phase advance requires a stamp, or a logged skip reason (… --phase <phase> --skip "<why no independent review is needed>").

Resume Logic

Resuming means reconstruct where the ticket left off and continue. The ticket's phase: and the first unchecked ledger item tell you where; the last work-log entry tells you what. Announce where you're resuming, then continue.

Resume by phase:

Current Behavior

Understand first and size internally (see SAFEWORD.md "Understanding" and "Sizing") — state the scope read inside your proposal, not as a separate announcement. If the user references an iteration/story/phase from a spec, resume its child ticket at the current phase, or create one and run full BDD if none exists; if a ticket already exists, read its phase and resume there.

Artifact-first: before doing a phase's work, create or verify its artifact — intake → <namespace-root>/tickets/{ID}-{slug}/ticket.md; define-behavior → the feature source at features/<slug>.feature (or the configured paths.features directory) plus the R/G/R ledger at <namespace-root>/tickets/{ID}-{slug}/test-definitions.md. Then execute the phase using its phase file, and update phase: on transition.

Phase Files

Load the appropriate file based on current phase:

For splitting large features, see SPLITTING.md.