Observed on the live store: input-request:sha256:33951365… (advisory, "residual density-flip nudge") was opened on a revision, the same session recaptured with --supersedes, and re-opened a verbatim duplicate (input-request:sha256:25511e84… — same title, track, mode, reason code) on the successor. The owner answered the duplicate (approved, input-request-response:sha256:c9e2de26…); the original stayed open and dangled in shore attention list until it was manually closed with --outcome superseded referencing the duplicate's approval.
Projection-time detection was considered and rejected: the only link between the two requests is identical prose on adjacent supersession anchors, and a fuzzy text match in a deterministic projection could false-merge and silently hide a genuinely open ask (attention's absence-must-be-derivable property, per ADR-0019's judgment-subsumption amendment — open_input_request is deliberately never auto-suppressed).
Two candidate fixes, not mutually exclusive:
- Skill guidance (cheapest): the author skills tell the agent not to re-open an ask on recapture — an open request stays answerable regardless of its anchor's freshness, and the attention item already carries a
superseded freshness badge pointing at the successors. No duplicate, no dangle.
- A typed edge (model):
shore input-request open --replaces <input-request-id> recording replaces_input_request_ids on the opened payload — the same shape as replaces_assessment_ids. With a typed edge, the projection can confidently treat a replaced request as closed once its replacement is responded (no heuristics), and the respond-with-superseded step this case needed becomes automatic.
(1) is worth doing regardless. (2) should probably wait for a second occurrence, per the defer-until-usage discipline — this issue is the record of the first.
Observed on the live store:
input-request:sha256:33951365…(advisory, "residual density-flip nudge") was opened on a revision, the same session recaptured with--supersedes, and re-opened a verbatim duplicate (input-request:sha256:25511e84…— same title, track, mode, reason code) on the successor. The owner answered the duplicate (approved,input-request-response:sha256:c9e2de26…); the original stayed open and dangled inshore attention listuntil it was manually closed with--outcome supersededreferencing the duplicate's approval.Projection-time detection was considered and rejected: the only link between the two requests is identical prose on adjacent supersession anchors, and a fuzzy text match in a deterministic projection could false-merge and silently hide a genuinely open ask (attention's absence-must-be-derivable property, per ADR-0019's judgment-subsumption amendment —
open_input_requestis deliberately never auto-suppressed).Two candidate fixes, not mutually exclusive:
supersededfreshness badge pointing at the successors. No duplicate, no dangle.shore input-request open --replaces <input-request-id>recordingreplaces_input_request_idson the opened payload — the same shape asreplaces_assessment_ids. With a typed edge, the projection can confidently treat a replaced request as closed once its replacement is responded (no heuristics), and the respond-with-supersededstep this case needed becomes automatic.(1) is worth doing regardless. (2) should probably wait for a second occurrence, per the defer-until-usage discipline — this issue is the record of the first.