I was reading about an open-source tool @Dusk_Foundation built to catch documentation that has quietly stopped agreeing with the code. So naturally I tested the idea on the most convenient target available: Dusk's own docs.
The tool is Pituitary. MIT licensed, a single binary, no Docker and no API keys. It indexes your specs, docs and decision records, then flags overlapping decisions, stale docs, code that contradicts the spec, terminology drift, and the impact chain when one spec changes. It also ships an MCP server, so an AI coding agent gets spec awareness mid-session instead of confidently building on a decision that was reversed months ago. A blockchain team building general developer infrastructure and giving it away under MIT is not something I see often. Credit where it's due.
Then I read the docs. Dusk's Network Updates record states plainly that new Phoenix transactions are rejected on mainnet after the Boreas restart, and that Moonlight is the supported transaction model going forward. The Transaction Models learn page still describes Phoenix in the present tense, as one of two native ways value moves on DuskDS, and closes by telling you that you are free to choose between them. No mention of the disablement on the page.
Textbook spec drift, sitting in the documentation of the team that shipped the drift detector.
In fairness, docs lag reality on every chain. What makes Dusk unusual is that it publishes a precise, sourced hard-fork record at all, which is the only reason the gap is visible to me. The point is not that they failed. It is that even a team that built the detector cannot fully outrun the problem.
So which documentation do you actually trust for a chain: the learn pages, the changelog, or the source code? And what do you do when the three disagree?
#dusk $DUSK
The tool is Pituitary. MIT licensed, a single binary, no Docker and no API keys. It indexes your specs, docs and decision records, then flags overlapping decisions, stale docs, code that contradicts the spec, terminology drift, and the impact chain when one spec changes. It also ships an MCP server, so an AI coding agent gets spec awareness mid-session instead of confidently building on a decision that was reversed months ago. A blockchain team building general developer infrastructure and giving it away under MIT is not something I see often. Credit where it's due.
Then I read the docs. Dusk's Network Updates record states plainly that new Phoenix transactions are rejected on mainnet after the Boreas restart, and that Moonlight is the supported transaction model going forward. The Transaction Models learn page still describes Phoenix in the present tense, as one of two native ways value moves on DuskDS, and closes by telling you that you are free to choose between them. No mention of the disablement on the page.
Textbook spec drift, sitting in the documentation of the team that shipped the drift detector.
In fairness, docs lag reality on every chain. What makes Dusk unusual is that it publishes a precise, sourced hard-fork record at all, which is the only reason the gap is visible to me. The point is not that they failed. It is that even a team that built the detector cannot fully outrun the problem.
So which documentation do you actually trust for a chain: the learn pages, the changelog, or the source code? And what do you do when the three disagree?
#dusk $DUSK