[Frontend][UX] Applied proposals are unreachable and "Open Proposal" renders a different proposal than it deep-links

[Chris0Jeky]

Found by the 2026-08-22 horizon-journey golden run — a 44-capability live end-to-end session against a running instance. Sibling of tracker #1947. Finding H-05.

Realignment 2026-08-23 (main a43df082c): finding (c) is refuted and struck — the link is bound and opens a Teleported drawer; what looked like a dead link is #1987's missing :metadata. (a) and (b) stand and remain this issue's scope. See the reconciliation comment below.

The defect

Three related defects around reaching a proposal from an applied card. Three Two — see the strike on (c).

(a) The deep link targets a proposal it does not show

From an applied card's CAPTURE ORIGIN block, Open Proposal navigates to:

/workspace/review?boardId=f6572b65-…#proposal-8efe8562-0b61-4dd3-a67d-6f26350a98bb

The hash names proposal 8efe8562 (the applied one), but the detail pane renders #6a8b247e — a
different, still-pending proposal. There is no error and no "not found" state; the pane simply shows
something else.

In a surface whose entire purpose is deciding, silently rendering a different, actionable proposal than
the one requested is dangerous: the next ⏎ approves the wrong thing. (The ?boardId= half of this URL
is separately broken — see the sibling finding on silent board filtering, #1966.)

(b) Applied proposals cannot be opened at all

The RECENTLY APPLIED rail lists them, but the rows are inert markup. Ancestor chain, as rendered:

span.tk-serial → div.paper-review-recent__head → div.paper-review-recent__row
              → div.paper-review-recent → aside.paper-review-rail

with no role, no onclick, no tabindex anywhere in that chain. The audit record of a decision you
already made is visible but not inspectable — which is also why (a) has no correct destination today.

(c) A second dead link in the same pane — STRUCK 2026-08-23 (refuted)

Struck by the 2026-08-23 realignment pass, verified against main a43df082c. View full read-set →
is not a dead link. frontend/taskdeck-web/src/views/paper/review/ReviewProvenance.vue:84 is
<a href="#" class="paper-review-prov__more" @click.prevent="drawerOpen = true"> — a bound handler that
opens ProvenanceDrawer. The drawer is <Teleport to="body">
(frontend/taskdeck-web/src/components/review/ProvenanceDrawer.vue:233), so it renders outside the
review pane and a pane-scoped htmlDelta reads 0 even though it opened. The binding predates this audit
(cb52b16fc) and PR #1957's repo-wide dead-anchor sweep independently verified it.

The drawer nonetheless looks empty, which is a real defect — but a different one: ReviewMain.vue:176-181
passes rows / evidence-links / proposal-id and no :metadata, so ProvenanceDrawer.vue's
<div v-if="metadata"> block never renders. That is #1987, and (c) is folded there. The cosmetic
href="#" is already covered by PR #1957's deadAnchors.spec.ts guard.

View full read-set → is href="#" and inert (urlChanged:false, htmlDelta:0, zero network requests).
It is the string at frontend/taskdeck-web/src/locales/en/review.ts (provenance.viewAll), rendered
immediately below the provenance footnote. This is the same defect class as #1941's Tune heuristics →,
but on a different link that #1941 does not mention — so fixing #1941 as written would leave this one
dead.

Why it matters

Taskdeck's pitch is an auditable decision trail: evidence in, human decision, applied change, record kept.
(b) and (c) means the record is a display artifact rather than a destination, and (a) means the one link
that does navigate lands on the wrong record without saying so. Together they break the "inspect what I
approved" path end to end — and (a) adds a real chance of approving an unintended proposal.

Acceptance criteria

• Open Proposal from an applied card opens that proposal. If it cannot be shown (applied, archived, missing), an explicit not-found / already-applied state renders — never a silent substitution of a different proposal.
• No code path renders a proposal whose id differs from the one named in the route hash without an on-screen statement that it did so.
• RECENTLY APPLIED rows are real controls (keyboard-focusable, role/semantics, activatable) that open the applied proposal in a read-only detail view.
• An applied proposal has a viewable read-only detail state (decision, actor, timestamp, operations applied) — the decision ledger is inspectable from the UI.
• View full read-set → either navigates to the full read-set or is removed. No href="#" remains in the provenance pane. — struck 2026-08-23: the link is bound and opens the Teleported drawer; the empty drawer is [Backend][Frontend] Wire the provenance triple (provider/model/promptVersion) into the deep-review payload so #1963's honest footnote can render #1987 (missing :metadata).
• Spec: mounting Review with a hash naming a non-pending proposal asserts the not-found/applied state and asserts the pane does not render a different proposal's decision buttons.
• Spec: the RECENTLY APPLIED row is reachable by keyboard and its activation is asserted against the rendered DOM.
• Spec / lint guard: no inert href="#" anchors in the Review surface (feeds the [Frontend][Testing] Guard against dead affordances - six enabled-but-inert controls found in one audit pass #1949 dead-affordance guard). — struck 2026-08-23: already delivered by PR fix(frontend): #1934 #1941 dead sidebar + provenance controls #1957's frontend/taskdeck-web/src/tests/guards/deadAnchors.spec.ts.

Refs

• Journey step 16 and matrix rows 6g, 12d; finding H-05 (a/b/c) of the 2026-08-22 horizon-journey run.
• [Frontend][Bug] Review provenance card: the Tune heuristics link is dead #1941 — same class as Tune heuristics →, different link; (c) should be fixed alongside it. — struck with (c).
• [Backend][Frontend] Wire the provenance triple (provider/model/promptVersion) into the deep-review payload so #1963's honest footnote can render #1987 — where struck finding (c) is now tracked (the provenance drawer's missing :metadata).
• [Frontend][UX] ?boardId= silently scopes Review and Inbox with no filter chip — headers report 0 AWAITING / 0 IN QUEUE while work exists #1966 — the ?boardId= half of the (a) URL.
• [Frontend][Testing] Guard against dead affordances - six enabled-but-inert controls found in one audit pass #1949 — dead-affordance guard.
• Tracker TRACKER: dogfooding UX sweep 2026-08-22 — dead affordances, core-loop legibility, board management #1947.

[Chris0Jeky]

Realignment 2026-08-23 — verified against main a43df082c. Finding (c) is refuted and struck from the body above; (a) and (b) stand.

(c) View full read-set → is not a dead link

frontend/taskdeck-web/src/views/paper/review/ReviewProvenance.vue:84:

<a href="#" class="paper-review-prov__more" @click.prevent="drawerOpen = true">{{ $t('review.provenance.viewAll') }}</a>

A bound handler, opening ProvenanceDrawer immediately below (:89-95). The binding is not new — it predates the audit (cb52b16fc) — and PR #1957's repo-wide dead-anchor sweep independently verified it while fixing #1941.

Why the journey run measured otherwise. frontend/taskdeck-web/src/components/review/ProvenanceDrawer.vue:233 is <Teleport to="body">. The drawer renders outside the review pane, so a pane-scoped htmlDelta reads 0 even though the drawer opened. A genuine measurement artefact — worth remembering for the next journey pass: a Teleported surface is invisible to a container-scoped DOM diff.

Why it nonetheless looked like nothing happened — and this is a real defect, just a different one. frontend/taskdeck-web/src/views/paper/review/ReviewMain.vue:176-181 renders:

<ReviewProvenance
  :rows="provenance"
  :evidence-links="evidenceLinks"
  :proposal-id="proposalId"
  @report="emit('report', $event)"
/>

No :metadata. ReviewProvenance passes :metadata="metadata ?? null" straight through, so ProvenanceDrawer's <div v-if="metadata"> block — provider, model, promptVersion — never renders. The link opens a drawer with nothing in it.

That is #1987, at the same root cause. Finding (c) is folded there; the cosmetic href="#" is already covered by PR #1957's frontend/taskdeck-web/src/tests/guards/deadAnchors.spec.ts. The two ACs that carried (c) are struck in the body accordingly.

(b) confirmed by source

frontend/taskdeck-web/src/views/paper/review/ReviewRecentApplied.vue renders rows as plain <div> / <span> — no role, no @click, no tabindex anywhere in the component. Exactly as reported.

(a) stands, and is the one to fix first

A hash naming one proposal while the pane renders a different, still-actionable proposal means the next ⏎ approves the wrong thing. That is the dangerous half of this issue and should lead the implementation, ahead of (b). It was not source-verified in this read-only pass — confirm the routing before scoping the fix.

Sequencing note: #1966 owns the ?boardId= half of the (a) URL and should land alongside.