the drift check cannot see a requirement that no longer describes the code, whether it lost its implementation or was contradicted by its successor

[0xLeif]

Found while backfilling the 6.0 changelog, by an agent reading #665's diff rather than its title.

The stale requirement

REQ-change-055 (specs/change/requirements.md:810) is live and unsuperseded. It says:

Change sequence allocation SHALL floor on the highest sequence observed locally (active, archive, local ledger) and, when available, the remote default-branch .specsync/change-sequence.json high-water. Concurrent multi-clone fleets MAY set SPECSYNC_SEQUENCE_BASE to disjoint ranges so agents that cannot see each other do not mint the same numeric CHG prefix.

with the acceptance criterion SPECSYNC_SEQUENCE_BASE=N makes the next allocated sequence at least N.

None of that exists. The ordinal retirement (7cbe820, #665) deleted maximum_observed_sequence and remote_sequence_high_water, and change identity became a slug. Verified rather than assumed:

• SPECSYNC_SEQUENCE_BASE appears in zero .rs files. Neither does the fragment SEQUENCE_BASE or sequence_base, so it is not constructed dynamically either.
• src/change.rs:2188 says it outright, in an error message: "nothing writes this file any more, so it cannot be repaired by allocating".
• The active change workspace on this branch is backfill-the-6-0-changelog-… — a slug. Archived changes since the retirement are date+slug (2026-08-27-a-definition-approval-may-not-withdraw-…). There is no numeric CHG prefix left to collide.
• .specsync/change-sequence.json is still on disk, frozen at sequence: 163 from security(6.0): a trust anchor must be where evidence entered history, not any commit that re-introduces it #663, and still read by validation — deliberately, to enforce that nothing rewrites it downwards (bug(change): change check --commit self-commits change-sequence.json backwards, regressing the high-water mark #533). Read-only is the intended end state; the requirement describes the write side that is gone.

AGENTS.md:49 still tells agents to prefer SPECSYNC_SEQUENCE_BASE=<N> with disjoint ranges. That guidance is inert rather than dangerous — the collision it guards against cannot occur once identity is a slug — but it is instructions to do something that does nothing.

The part that is actually about the product

specsync check --spec change does not flag REQ-change-055, and by the current model it cannot.

Drift detection measures specs against the code that implements them. A requirement whose implementation was partly changed drifts and is caught. A requirement whose implementation was entirely deleted has nothing left to measure against, so it produces no finding at all — it reads as "nothing to check" rather than "orphaned requirement."

That is this release's most-repeated defect shape one level up, in the tool's own model rather than in a single function: a category empty for want of input, read as a verdict. #672 read an unparseable schema's zero tables as "every table missing"; #684 gated on advice the reader could not take; #720 read an unreadable bypass_actors as "no bypass granted"; #689's first design read absent history as absent readiness. Here, zero implementing symbols reads as zero drift.

The requirement most likely to be stale is exactly the one with no code left pointing at it, and that is precisely the one the current check is blind to.

What this needs

1. Fix REQ-change-055 — supersede or delete it, and remove the AGENTS.md:49 guidance. Small and unambiguous.
2. Decide whether the drift model should detect an orphaned requirement at all. A requirement with zero attributable implementation is not automatically a defect — aspirational, process, and policy requirements legitimately have none, and this repository has some. So the answer is probably report, never gate: a distinct unattributed requirement outcome, disclosed and not counted as drift, in the same shape bug: deps silently skips Kotlin import analysis #477 used for unresolvable imports — "owned, foreign, or unattributed and disclosed", where silence is never the default.

(2) is the real work and should not be rushed into 6.0. (1) should land before the stable tag, since a released spec that documents a removed environment variable is the drift this tool exists to catch.

Related: #665 (the retirement), #533 (why the ledger is still read), #477 (the disclosure shape), #672 / #684 / #689 / #720 (the same defect shape).

[0xLeif]

Part 1 landed in #732. Part 2 — the unattributed requirement outcome in the drift model — is untouched and is what this issue now tracks.

Part 1 was considerably larger than I filed it. I named one stale requirement; sweeping for the mechanism's vocabulary (allocate / mint / next-ID / high-water / CHG-NNNN) rather than the named ID found the ordinal retirement had left eight more pieces of spec text standing:

• change.spec.md Invariant 1 — "Change IDs are monotonically assigned as CHG-NNNN-slug"
• context.md — two paragraphs
• REQ-change-022, -026, -070 (rationale), -072 — one stale clause each
• REQ-change-055 — deleted
• REQ-change-071 — deleted, and this is the one worth noting

REQ-change-071's normative SHALL (refuse a ledger below the default branch's published mark) is flatly contradicted by REQ-change-072 ("SHALL NOT refuse a branch for trailing the default branch… consults no remote"). A live requirement the code deliberately violates, sitting next to the requirement that replaced it. A successor that contradicts its predecessor does not retire it — that is a second route to the same failure, and it is not detectable by looking for orphaned symbols, because REQ-change-071 has an implementation. It just does the opposite of what it says.

Delete rather than rewrite, because the surviving invariant is already stated twice: REQ-change-070 (the commit side — floor_sequence_ledger_to_committed raises a stale working-tree ledger before staging) and REQ-change-072 (the read-side gate, judged against the branch's own HEAD history). A rewrite would have been a third copy, and a restatement is exactly what goes stale next. ## REMOVED leaves a permanent tombstone, so the retirement is recorded rather than silently dropped.

Zero .rs files changed; the ledger read path and both gates are untouched. AGENTS.md now describes slug identity and says .specsync/change-sequence.json is read-only history, instead of telling agents to set an inert variable.

What this sharpens for part 2

REQ-change-055 survived an entire release because a requirement with zero implementing symbols produces no finding at all — the shape this issue is about. But REQ-change-071 shows the detector cannot be "requirements with no attributable code": it had code. The two failure modes are different and only one is an attribution question.

Also worth carrying in: the thing that actually found all nine was searching the vocabulary of the removed mechanism, not the requirement ID. Whatever part 2 builds should be reachable that way.

[0xLeif]

Correcting myself: "nothing writes this file any more" is false

Found by the audit of folded lessons (#714), which is doing exactly what this issue's part 2 is about.

In the issue text above I wrote, as evidence:

src/change.rs:2188 says it outright, in an error message: "nothing writes this file any more, so it cannot be repaired by allocating".

That error message is wrong, and I propagated it without checking the function beside it.

floor_sequence_ledger_to_committed (src/change.rs:1869) writes .specsync/change-sequence.json:

write_json(
    &root.join(SEQUENCE_PATH),
    &ChangeSequenceLedger { schema_version: 1, sequence: committed.sequence, id: committed.id, acknowledged_collisions: collisions },
)?;

and it is called on the commit path from src/commands/change.rs:2865. So every lifecycle commit can rewrite that file. That write is #533's fix: it raises a stale working-tree ledger to the committed high-water mark before staging and merges acknowledged_collisions.

The accurate statement is: nothing allocates into the ledger any more; it is still written, in one direction only, as a repair. "Read-only history" is wrong.

Where I propagated it

• this issue's body (above);
• AGENTS.md, rewritten by fix(change): a requirement describing wholly-deleted behaviour must not stay live (#728) #732 and now on main: ".specsync/change-sequence.json is read-only history. Nothing writes it." The very next clause of that same bullet then describes the write — "change check raises a stale working-tree copy to the committed mark and says so" — so the file contradicts itself inside one sentence;
• Discussion Public roadmap: SpecSync 6.0, and what adoption is deciding next #339, the public roadmap. Corrected there, with the correction stated rather than silently edited.

Why this belongs on this issue specifically

This is part 2's failure mode, committed by me, in the process of filing part 1.

A requirement or a lesson goes stale when the code moves. But an error message is prose too, and it is the most trusted prose in the codebase: it is written by the authors, printed by the running program, and read by someone who is already in trouble. I treated src/change.rs:2189 as ground truth precisely because it is emitted by the tool, and did not read the forty lines above it.

Whatever part 2 builds to detect a requirement that no longer describes the code should be pointed at diagnostic strings too. They are load-bearing claims about behaviour, they are never tested for truth, and this one has now been wrong for long enough to be quoted into a public roadmap and into the instructions agents read before doing any work.

What still needs fixing

1. src/change.rs:2189 — the error message itself. It should say the ledger cannot be repaired by allocating, which is the true and useful part, without claiming nothing writes it.
2. AGENTS.md:51 — the self-contradicting bullet.

Both are outside the #714 audit's scope (it is correcting context.md files) and outside #732's, which is merged. I will scope them separately unless someone gets there first.