itd-114's maintainer reads capture list newest-first; the capture chapter orders the list by derived priority, unblocked first and then by severity.

itd-114's maintainer reads capture list newest-first; the capture chapter orders the list by derived priority, unblocked first and then by severity.

A premise contradiction (severity nitpick) found by the cross-document consistency pass.

• End A: .abcd/development/intents/shipped/itd-114-abcd-mints-collision-proof-record-ids.md:32 — "I still read capture list newest-first at a glance"
• End B: .abcd/development/brief/04-surfaces/06-capture.md:588 — "in derived-priority order: unblocked first, then severity"

itd-114's press release has the maintainer say they still read capture list newest-first at a glance after the id change. 06-capture's acceptance states the listing comes in derived-priority order: unblocked first, then severity, with blocked rows demoted and annotated. A list ordered by priority is not read newest-first, so the intent claims an ordering the surface does not give.

Evidence: .abcd/work/reviews/2026-10-26-consistency/00-summary.md, finding 524.

Grounds

• declined: Closed in the 2026-10-27 triage (dcn-2610271112330536): the two ends do not conflict when read in full. itd-114's acceptance criteria concern minting collision-proof ids and say nothing about list order; the quote is flavour, and the shipped ordering is the derived-priority view.