Keep documentation in sync with code — drift, flagged
Documentation has a failure mode no test catches: it doesn't break, it just quietly stops being true. The setup guide names a config flag that was renamed in March. The architecture doc describes a service that was merged into another one. Nothing errors — until a new teammate follows the doc, loses an afternoon, and learns to stop trusting the docs entirely. That last part is the real cost.
prism0x2A's AMBER layer reads your code and your documentation side by side and flags every place they disagree — the claim in the doc, the line in the code, next to each other. It runs on your machine; what the check sends to your own LLM key is bounded excerpts of the files under review, spelled out on the local-first page.
Why drift is invisible in review
A pull request shows the files that changed — and documentation drifts precisely because the doc is notin the diff. The rename is reviewed, approved, merged; the sentence describing the old name lives three directories away and nobody's eyes ever cross it. Catching that requires a tool that holds both sides at once, which is exactly the shape of the AMBER check.
What a finding looks like
- The statement in the documentation that no longer matches.
- The place in the code that contradicts it.
- A drafted correction you can apply — the edit stays a human decision.
The honest part
prism0x2A flags disagreements and drafts the fix — it does not merge anything on its own, and it cannot know which side is wrong: sometimes the doc is stale, sometimes the doc is the spec and the code drifted. That call is yours. And a docs check is only as good as its method — ours is published, not asserted.