bdd-feedback-loop

What problem does it solve?

BDD spec-to-test work often stalls because teams lack a repeatable, safe procedure for converting a behavioral spec into executable tests that are type-checker-clean and self-audited.

Core Features & Use Cases

• Per-module feedback loop: Turns each BDD spec module into a bounded iteration that reads the spec, discovers the public API, implements tests, validates types, self-audits against BDD principles, logs deviations, and performs a coverage check.
• Strict spec immutability: Treats the spec as the authoritative input and requires human resolution for genuine spec errors or unresolved deviations.
• Tautology and boundary discipline: Enforces that “When” invokes production code, that mocks match the declared boundaries, and that assertions reflect SUT behavior rather than hand-constructed expectations.

Use case: You are implementing a new BDD test module for a service and want to ensure the resulting tests follow the spec precisely, fail meaningfully when behavior diverges, and remain aligned with language/toolchain validation rules.

Quick Start

Ask an AI agent to apply the bdd-feedback-loop workflow to implement the next BDD test module from the current spec doc, including type-check validation, self-audit, deviation logging, and a coverage disposition review.