From the pack / Product notes
Specs, types, and graphs: the Dotdog 1.0 research
Specs, types, and graphs solve different problems. The useful part is connecting them without turning partial evidence into a promise.
Start with three separate questions
| Question | Artifact | Limit |
|---|---|---|
| What should the system do? | Authored specification | A clear rule may still be wrong or unimplemented. |
| Which states and interfaces can code represent? | Types and compiler diagnostics | Only encoded constraints are checked; untrusted runtime input still needs parsing. |
| How do artifacts and observations connect? | Graphs with source/evidence identities | Missing or truncated relationships do not prove independence. |
Dotdog 1.0 keeps those roles distinct. Specs hold intent, repository extraction records a bounded view of code, and imported type/native graphs retain the evidence behind their relationships. We did not add another database or make a compiler mandatory for ordinary graph use.
New research: intent helps, but maintenance still costs
Agarwal and colleagues' October revision of Spec-Driven Development as Prescribed and as Practiced studies public artifacts, practitioner discussions and interviews. Participants reported more reliable agent behavior alongside added planning/review work; the authors also identify specification decay and differences between individual and team adoption. This is an empirical preprint, not a controlled validation of Dotdog.
Our design implication is to preserve intent and source evidence separately, make freshness inspectable, and keep checks reproducible. A completeness score is not a substitute for runtime tests or ongoing review.
New compiler APIs do not mean automatic compatibility
Microsoft's October 20 TypeScript 7.1 beta announcement introduces separate synchronous/asynchronous compiler entry points and snapshot-based updates. Its examples also make resource disposal explicit. This is relevant future adapter work, not a reason to silently replace the interface a released tool actually tested.
Dotdog 1.0 supports a trusted project-installed TypeScript 7.0.2 compiler through its version-specific unstable/sync API. It retains original project settings and diagnostics in a bounded Node worker. Other compiler versions and unsupported project configurations fail explicitly. The beta was researched separately; it is not a required dependency or a claimed supported version.
Specs remain useful outside one tool
GitHub Spec Kit's extension model allows additional commands and integrations while keeping their behavior and governance explicit. Dotdog reuses that boundary with an optional community extension for local import, inspection and stdio MCP access. It does not replace Spec Kit's workflow or require a new hosted service.
What we actually checked
The 1.0 release record links the approved source, retained npm archive, checksums and publisher. The final implementation suite passed 133 tests and 2,124 assertions. Fresh npm/Bun registry consumers exercised spec refresh, context/impact, real compiler invalid/repair behavior, evidence-tamper rejection, REA import/path and real stdio MCP.
The separate research findings preserve earlier prototype failures and historical compiler/corpus checkpoints. A broken legacy extractor was not relabeled a production success. The published adapter uses the separately tested compiler interface.
What we have not established
These checks do not measure coding-agent productivity, whole-program semantic closure or general cost savings. Authenticated model-driven Claude invocation/edit-refresh remains unverified. Type success does not prove business requirements; saved native references do not prove runtime equivalence.
That is why the old dogfood dashboard is no longer a live-status claim. Versioned inputs, exact checks and retained failure boundaries are more useful than unqualified green numbers.
Try the workflows
Further reading: technical thesis, historical thesis PDF, and measured performance scope.