by Merak
What it does
sdd-factory turns a one-page Markdown spec into a working TypeScript CLI or HTTP API with passing tests, with one command and no human in the loop. Agents first compile the spec into a typed, linted specification (agent-sdd) that a reviewer from another model vendor checks, then design modules and a task graph, build each task test-first in parallel lanes (failing tests, implementation, review), and assemble the result through npm ci, tsc, build, vitest and a spec-coverage gate before publishing it to hidden/<spec>/. Failures are routed back to the agent that owns them, mechanical breakages go to a capped repair agent, and every run leaves a trace with time and cost per stage and per task. Rehearsal runs on four specs published working products in 24 to 53 minutes for 2.4 to 4.3 USD, most with zero human steps.
How the agents run concurrently
Every role is a participant on one Mozaik runtime bus; agents never call each other, they publish typed events that are validated against a catalogue. What runs at the same time: - Design fan-out: one spec.approved event starts two Mozaik agent loops at once, the architect (module map, data shapes) and the verification-designer (input classes, negative oracles per requirement). Their active intervals must overlap; that is a tested invariant. The planner starts at a barrier when both are ready. - Build lanes: the planner cuts a dependency graph of tasks with disjoint write-sets. Every task whose dependencies are approved starts its own lane in its own git worktree: test-writer -> red check -> implementer -> green check -> reviewer. Up to 4 lanes run in parallel (configurable); reviews of finished lanes run while other lanes are still coding. Lane agents are Claude Code subprocesses wrapped as Mozaik participants, so concurrent lanes show up as concurrent participants in Mozaik Cloud. Shared state: - The event bus plus a pure transition function: each event becomes a new RunState written to state.json after every transition, so the run can be replayed from its trace and resumed after a failure. - Code is shared through git: per-task worktrees merged into an integration branch; roles exchange results through handoff files. Coordination: - The foreman reacts to events with effects: dependency barriers, disjoint write-sets checked mechanically, retry caps, rework routed to the most upstream owner (spec, architect, planner, test-writer or implementer), and a watchdog that fails a stalled run instead of hanging. - Isolation keeps judges independent: the architect never reads the verification design, the critic and reviewer run on a different vendor's model than the authors they judge, and the implementer cannot change the frozen tests.