[Frontend][Review] Headlines are paired to operations by index while the two arrays use different orderings

[Chris0Jeky]

What

ReviewProposalCard.vue pairs presentation headlines with operations by array index, but the two arrays are not guaranteed to be in the same order, so a multi-operation proposal can display the wrong headline against an operation.

Mechanism

• AutomationProposalService.BuildPresentation (backend/src/Taskdeck.Application/Services/AutomationProposalService.cs:1735-1737) builds presentation.operationHeadlines sorted by Sequence.
• MapToDto (same file, :1650) maps proposal.Operations in unordered EF .Include order.
• ReviewProposalCard.vue:120-126 then indexes one array with the other's position.

When EF returns operations in an order that does not match Sequence, headline n is rendered against operation n of a differently-ordered list. On a review surface whose entire purpose is that the human sees exactly what will be applied, a mispaired headline is a trust defect rather than a cosmetic one.

Why it is filed rather than fixed in PR #2541

Found during the review of #2541 (move-card headline enrichment). It is pre-existing, independent of that PR's gate fix, and fixing it there would have widened a scoped fix beyond its finding.

Suggested fix

Sort operations by sequence before indexing. PaperReviewView.vue:953-956 already does exactly this and is the reference shape.

Belt-and-braces alternative: have the backend emit operations pre-sorted by Sequence in MapToDto, so both consumers get a stable contract instead of each re-sorting. That is the better fix if the DTO order is not relied on elsewhere.

Also worth knowing (declined, recorded so it is not re-raised)

A related concern about operationColumnId falling back to sourceColumnId was raised and declined as unreachable: grep -rn "sourceColumnId" backend/src finds it only as a local variable in ProposalConflictDetector.cs:411-424. No operation parameters payload ever carries that key.

Refs #1761

[Chris0Jeky]

[Claude lane claim v2]
lane: alpha-product-trust (session taskdeck-alpha-85, Taskdeck-Alpha checkout)
issue: #2563
base: 2803355
residual acceptance: the whole issue: presentation headlines and operations are paired by a stable key, not by array index. Preferred shape (the issue's belt-and-braces alternative): AutomationProposalService.MapToDto emits Operations ordered by Sequence so every consumer gets one stable contract, with an Application test that seeds operations in reverse EF order and asserts the DTO order; and ReviewProposalCard.vue sorts by sequence before indexing headlines (the PaperReviewView.vue ~953-956 reference shape) so the Legacy card is correct even against an older backend, with a component spec that seeds operations out of sequence and asserts each headline lands on its own operation (red first). A regression in AutomationProposalsApiTests proves the wire order on a multi-operation proposal. No change to BuildPresentation's headline order, to Apply, or to the operation vocabulary.
owned paths/modules: backend/src/Taskdeck.Application/Services/AutomationProposalService.cs (MapToDto only); backend/tests/Taskdeck.Application.Tests/Services/AutomationProposalServiceTests.cs; backend/tests/Taskdeck.Api.Tests/AutomationProposalsApiTests.cs (one new test); frontend/taskdeck-web/src/components/review/ReviewProposalCard.vue; src/tests/components/review/ReviewProposalCard.diff.spec.ts (or the card's spec)
shared-path leases: AutomationProposalService.cs is also edited by open PR #2597 (#1307, the batch-approve transaction region ~724-760); this slice touches only MapToDto (~1650) and merges main once if #2597 lands first; PaperReviewView.vue is not edited (held by PR #2576)
parallel-safe work: worktree codex-2435 (board seam) is disjoint
open PRs/branches/review threads checked: PR #2541 merged 8c51120 (origin of this issue; touched ReviewProposalCard.vue, now free); PR #2597 open on the batch-approve region; PR #2576 open on PaperReviewView.vue; no claim on ReviewProposalCard.vue
human or decision gates: none
status: active (worktree codex-2563)

[Chris0Jeky]

Coordinator ruling (2026-09-05 03:05Z): two PRs address this issue. PR #2596 (branch issue-2563/sequence-pairing, opened 01:39Z, no lane claim, no review, client-side re-sort of a copied operation list) and PR #2609 (branch issue-2563/headline-operation-pairing, opened under the alpha lane's 01:47Z claim on this issue, fresh-context review SHIP, sorts operations by Sequence at the source in AutomationProposalService so both consumers get a stable contract, plus the frontend pairing regression). #2609 proceeds to merge; #2596 will be closed as superseded once #2609 lands, with a pointer here. If the author of #2596 believes it should be preferred, say so on this issue before #2609 merges.

[Chris0Jeky]

[Claude lane release v2]
lane: alpha-product-trust
issue: #2563
PR: #2609, exact head 0279d82 (the round-1 reviewed head 0800e31 plus a base-update merge after #2597 landed in the same file), merge commit e5612e8, merge commit not squash
disposition: closed by the merge. Shipped: MapToDto emits Operations ordered by Sequence on every wire path and BuildEffectiveProposalDto sorts the revision payload's operations the same way, so Presentation.OperationHeadlines (already Sequence-sorted) pairs by index with the operations it describes; the Legacy ReviewProposalCard sorts a copy by sequence before pairing so it is right even against an older backend; the #2541 enrichment gate is unchanged.
review: one fresh-context independent reviewer subagent, SHIP with three LOWs (declined: NaN-guarding the plain comparator, the codebase norm; tracked here: a test pinning tie stability for duplicate sequences; coordinator carry-forward: the ordered wire-contract invariant line in autodoc/interfaces/proposal-operation-vocabulary.md, landing with the STATUS twelfth block). Evidence: Application filter 151, Api filter 94, Architecture 28 (1 declared skip), full solution 8850 passed / 34 skipped / 0 failed at the reviewed head; frontend 12 files / 184 plus 16 files / 358; typecheck, ESLint, build, diff check; red first on the create-response order, the revision order and the component cases with mutation checks for all three sorts; re-proved at the base-updated head with the Application AutomationProposalService filter 168/168 and the Api Proposal filter 388/388; hosted CI green at the exact head.
NOT verified: browser or E2E; the GET assertion is a contract lock only because SQLite already served the Include from the (ProposalId, Sequence) index.
duplicate: PR #2596 (same issue, client-side copy sort only, no claim, no review) is closed as superseded by the coordinator.
follow-up test tracked here: duplicate Sequence values are persistable (no uniqueness check at create; the index is non-unique); a one-line test adding two operations with the same Sequence and asserting headline-to-operation pairing would lock the stable-sort guarantee the code comment asserts.
CLAUDE_SYNC_PACKET: merged=#2609e5612e8 closes=#2563 refs=none docs=STATUS twelfth block plus the vocabulary invariant line (coordinator, pending) worktree=codex-2563-headline-operation-pairing removed after this comment