sdd-kit-2

Programs can emit their own state. Each event carries a category (audio, transport, layout), an uppercase tag (RECORD_START, FACE_TRAVERSE, EDGE_GRAB), and a typed payload. A model reads that stream directly and knows what the program did — the sample position, the beat position, whether quantization applied. Words are a poor medium for a frame that hitches at the end, a loop that starts on the wrong beat, a component that sits one pixel off. Signal-Driven Development is the discipline of designing that stream before the code that emits it.

sdd-kit-2 is that discipline written down. The vocabulary lives on the same design plane as the data model — named subsystems, typed payloads, a stability contract. The instrumentation ships with the code and refactors like a public API when the vocabulary changes. A person and a capable LLM read the same set of files and run the loop together.

The unit of work is a sprint: a small, bounded pass whose contract is declared before the code and whose outcome is graded against the signals it was supposed to produce. Cards declare intent; reports confirm evidence; a shared board carries the audit trail forward. Hypothesis, execute, observe, integrate, next sprint.

Two roles run the loop. The human is the Architect — owner of the vocabulary, the working agreement, the decisions ledger, the build gate. The model plays three roles inside a single session: partner to the Architect on shaping the sprint, supervisor of its own execution, worker on the actual write. Session-start reading, contract grading, and the self-review are protocol encoded in files that the human and the model read the same way.