What is a living design spec, and why make it the source of truth?
Most tools treat code as the source of truth and documentation as an afterthought that rots. d-bye flips this: a structured, living design spec is the single source of truth, and code is generated from it.
A design spec is structured, not prose
A traditional design document is prose: paragraphs, screenshots, and tables that humans read but machines cannot act on. The moment code changes, the document is out of date.
A design spec in d-bye is different. It is a structured representation — screens and their widgets, events, data tables, and batch flows — expressed as data. Because it is structured, the same spec can be validated, diffed, and turned into working code automatically.
Why the spec, not the code, is the source of truth
If code is the source of truth, the design is whatever the code happens to do — including its bugs and accidents. Intent and implementation blur together.
When the spec is the source of truth, intent is explicit and reviewable. You change the spec, regenerate, and the React frontend, backend, and database schema move together. There is no drift between "what we meant" and "what shipped".
One spec, many targets
Because the spec is independent of any one language, it can generate multiple targets — a React/TypeScript UI, a backend API in the language you choose, a database schema (DDL) — that are guaranteed to agree with each other, since they all derive from the same description.
This is the practical payoff of a spec-first workflow: consistency across the stack is a property of the system, not something you maintain by hand.
Generation is one-way by design
d-bye generates code from the spec; it does not reverse-sync code back into the spec. That constraint is deliberate. A one-way pipeline keeps the spec authoritative and avoids the ambiguity of trying to infer intent from arbitrary code edits.
You still own and can freely modify the generated code. But the spec remains the place where the design lives and evolves.