Exported spec never shows that a deviation contested one of its confirmed claims

[OriNachum]

Summary

An approved devague deviate record can invalidate a confirmed claim in an
already-exported spec. The deviation ledger records this correctly. The
exported spec artifact gives the reader no signal at all — so
docs/specs/<date>-<slug>.md keeps presenting a claim that execution has
since disproved, as authoritative.

The link already exists in state: devague deviate --affects accepts and
validates claim ids. Nothing renders it back.

devague 0.19.1, hit at the end of a full
scope → think → challenge → spec-to-plan → assign-to-workforce → deviate → summarize-delivery
run.

What happened

Scope exploration surveyed the corpus this feature searches and recorded a flat
layout. That became confirmed requirement c21:

native transcripts under ~/.claude/projects/<project-dir>/<session_id>.jsonl
(1 line = 1 event; text in message.content …)

The frame converged and exported on that basis. A task agent built faithfully
to it. Then post-merge validation against the real corpus measured that 408 of
695 transcript files (59%) live one tier deeper, at
<project-dir>/<session_id>/subagents/agent-<id>.jsonl. The spec was not
imprecise — it was wrong about the world, and the exploration behind it never
saw that tier.

That was approved and recorded, naming the claim it contradicts:

devague deviate "walk transcripts recursively: subagent transcripts … are a real corpus tier the spec missed" \
  --task t8 --reason "…measured 408 of 695 files (59%) below the depth the walker searches…" \
  --affects t4 --affects c21 --affects c4 --affects h4 --classification risky
# -> recorded d8 (approved)

The code was fixed. devague summary quotes d8 under Mid-work Decisions and
Drift From Plan, and the committed delivery summary carries it.

But docs/specs/2026-07-26-<slug>.md still renders c21 under
## Requirements, unmarked. Someone who reads the spec — the artifact the
method advertises as the buildable output — inherits the wrong mental model,
with nothing pointing at d8.

Why this is not #84 (amend)

My first instinct was to fix the claim: capture a corrected requirement, reject
c21, re-export. The human owner stopped me, and I think they were right:

Don't change the spec, this is part of the ledger. Deviate is the marking of
the change.

That is a coherent and, I'd argue, correct principle — the spec is a
point-in-time record of what was believed at convergence, and rewriting it to
match what was later learned destroys exactly the audit trail that makes
convergence mean something. #84 (amend) is about textual corrections found
during review, before the frame is spent. This issue is the opposite
situation: the frame is converged, exported, and executed, the claim was
honestly held and honestly disproved, and the record of that belongs in the
ledger — not in a rewritten claim.

So this is not a request to make exported specs editable. The ask is that
the immutable spec point forward to the record that superseded it.

The gap, precisely

Artifact	Sees d8?
.devague/deliveries/<slug>.json	yes — it is the record
devague deviate --list	yes
devague summary / docs/deliveries/…	yes, quoted under Drift + Mid-work Decisions
docs/specs/<date>-<slug>.md	no
devague show / devague status	no

The asymmetry is the bug. A deviation knows which claims it contests
(--affects); a claim has no idea it has been contested.

Suggested direction (design is yours)

Cheapest version that respects immutability: at export time, derive a
back-reference read-only from existing state and render a marker on any
confirmed claim named in an approved deviation's --affects. Something like:

## Requirements

- native transcripts under `~/.claude/projects/<project-dir>/<session_id>.jsonl` …
  - ⚠ contested by `d8` (risky): measured 408 of 695 files (59%) below the depth
    the walker searches — see `docs/deliveries/2026-07-26-<slug>.md`

Properties worth keeping: no new state, no claim mutation, no id churn, no LLM
calls — a pure derivation over Frame.claims × the delivery store, in the same
spirit as the existing convergence-warning predicates.

Two wrinkles for whoever picks this up:

1. Ordering. The spec exports before execution, so the marker can only
   appear on a re-export. /challenge already documents a
   reconverge-and-re-export loop into the same dated file, so the machinery
   exists — but a spec exported once and never re-exported would stay unmarked.
   A read-only view (devague show --with-deviations, or a line in
   devague status) may matter more than the rendered artifact.
2. Frames outlive plans. The delivery store is keyed by plan slug while
   claims live on the frame, so the lookup crosses that boundary. Worth
   confirming that is a relationship devague wants to render, or whether the
   pointer belongs only in the delivery summary (Add summary skill to capture delivery, decisions, and plan drift #62).

Alternative, if the above is unwanted

If the maintainer's position is that the spec should stay entirely unaware of
downstream execution, then /summarize-delivery's template should say so
explicitly — because right now the honest thing I could put in the delivery
summary was a "spec correction owed" line, and per the principle above no
correction is owed. That instruction gap is worth closing either way.

• Claude