One example is small, clean, intent-only — try to regenerate the code from the docs alone. One is a complete, working project — the whole chain from design to verified code, public and clonable. And one is real, long-running, and messier than any pedagogical example could honestly be. Three lenses; they answer different questions.
A deliberately small fictional project. HLD, a handful of LLDs, EARS specs — no implementation. The challenge: delete the intent tree, regenerate it; delete the code, regenerate that too. When the docs are the source of truth, either can be recreated from either.
examples/urlshort/
This example may not exist yet — check the repo tree. It ships alongside the plugins.
A real, public project built with LID end-to-end: an HLD, eleven LLDs, 350 EARS specs, and the tests and code that cite them. A CI gate makes the linkage mechanical — the build fails unless every spec is cited by at least one test and every citation resolves to a defined spec. The verification story the home page describes, enforced in public.
Start with the README's guided tour — five files, read in order, from one design doc down to the CI gate that binds it.
A working project that has used LID for months. The LLDs are striated — multiple generations, uneven coherence, the honest shape any living system acquires. Not a teaching example. A stress test for cascade discipline, and a proof that LID survives real conditions.
The live product is at threadkeeper.app. Internal design docs aren't public, but the shape of the project shows LID at work over time.