Seven kinds of spec ↔ test ↔ code ↔ doc drift — and why naming them makes them checkable

Spec-driven development has a quiet failure mode: your specs, tests, .feature files, source, and user docs all start aligned — and then drift apart. A test loses its spec. An acceptance criterion never gets a test. A spec is marked done but was never implemented. Nobody notices until it surfaces in review or production.

The problem with "are the artifacts still consistent?" is that it isn't one question. It's several, and each has a different mechanical answer. Naming them separately is what makes the check automatable instead of a review-time judgement call.

Seven kinds of cross-artifact drift

1. Orphan test — a test with no spec behind it. Either the spec was deleted, or the test is guarding something nobody agreed to.
2. Uncovered AC — an acceptance criterion with no test. The requirement exists on paper and nowhere else.
3. not_implemented — a spec marked done but absent in code. The dangerous one, because the status field asserts the opposite of the truth.
4. Cross-spec conflict — two specs that contradict each other. Whichever one you read last wins.
5. Orphan .feature — a feature file with no owning spec. BDD scenarios that outlived their requirement.
6. AC-without-scenario — an acceptance criterion that no BDD scenario exercises. Possibly covered by unit tests, but never described as behaviour.
7. user-guide ↔ E2E drift — docs and end-to-end tests out of sync. Two artifacts that both claim to describe what the user sees, disagreeing.

Why the enumeration is the point

Each of the seven is a link that should resolve and doesn't: spec→test, AC→test, spec→code, spec→spec, feature→spec, AC→scenario, doc→E2E. Once you state them that way, checking is a graph walk and a report of the edges that dangle — not a reading exercise.

That difference matters because a consistency check performed by reading only happens when someone remembers to read. A check expressed as dangling edges can run on every commit, and the version that runs on every commit is the only one that stays true.

The list is not exhaustive. It's the set that is cheap enough to check mechanically, which is exactly what makes it worth automating rather than intending.

---

AI disclosure: I wrote this with AI assistance for English phrasing and structure. The drift taxonomy and the decision about which links are worth checking are my own — the AI did not supply the technical judgement.