[Frontend] Composer silently discards label/due metadata; board-link columnId is read by nothing (horizon doc round-2 findings)

[Chris0Jeky]

Exposed by the Codex round on PR #1980's golden-journey doc, verified against source 2026-08-22.

Realignment 2026-08-23 (main a43df082c): finding 1 is struck — superseded by #2005, which covers the same handler with live proposal evidence plus the backend half. Finding 2 stays live and is tracked nowhere else. See the reconciliation comment below.

1. Composer metadata discard: PaperInboxView.onComposerSubmit (frontend/taskdeck-web/src/views/paper/inbox/PaperInboxView.vue:118-131) explicitly drops labels and dueAt because CreateCaptureItemDto doesn't carry them — the composer UI collects metadata that never reaches the server, silently. Either carry them through the DTO→proposal chain or remove the fields from the composer (never collect-and-discard). The [Frontend][Testing] Guard against dead affordances - six enabled-but-inert controls found in one audit pass #1949 class, data-shaped.

   STRUCK 2026-08-23 — superseded by Capture due date (and labels) are silently dropped end-to-end — never reach the proposal or the card #2005. Same defect, same handler, but Capture due date (and labels) are silently dropped end-to-end — never reach the proposal or the card #2005 carries live proposal evidence and the backend half this finding could not see (CaptureTriageService.cs:626-632 never reads task.DueDateHint; the field has zero consumers). Tracked there so one handler has one owner.

   Path correction while striking it: the path cited above does not exist. frontend/taskdeck-web/src/views/paper/inbox/ holds only PaperCaptureComposer.vue, PaperCaptureNib.vue, PaperTriageRowEdit.vue and PaperTriageTable.vue. The real site is frontend/taskdeck-web/src/views/paper/PaperInboxView.vue:124-136.

2. Dead columnId parameter: the board's + capture link navigates to /workspace/inbox?boardId=…&columnId=… but useInboxOrchestrator reads only boardId — route.query.columnId has ZERO readers repo-wide, so column-scoped capture routing silently degrades to board-scoped. Either honor it through triage→proposal targeting or stop passing it.

   Re-confirmed 2026-08-23 at main a43df082c. Grepping route.query.columnId across frontend/taskdeck-web/src still returns zero matches; composables/useInboxOrchestrator.ts:42 reads only boardId. This is the surviving scope of this issue.

AC: each path either works end-to-end with a test or the affordance stops promising it. Refs: PR #1980, #2005 (owns struck finding 1), #1966 (same class, same route — fix finding 2 alongside it), #1949, tracker #1947.

[Chris0Jeky]

Realignment 2026-08-23 — narrowed to finding 2. Verified against main a43df082c.

Finding 1 struck — superseded by #2005

Same defect, same handler. #2005 (filed 2026-08-23, Priority I, milestone v0.1.2) carries live proposal evidence and the backend half this finding could not see: backend/src/Taskdeck.Application/Services/CaptureTriageService.cs:626-632 serializes only { title, description, columnId, boardId } and never reads task.DueDateHint, whose only three sites repo-wide are its own declaration, length constant and validator. So an LLM-extracted date is lost on the same path as an explicitly typed one.

Struck here rather than duplicated so one handler has one owner.

Path correction, recorded while striking it: the body cited frontend/taskdeck-web/src/views/paper/inbox/PaperInboxView.vue:118-131. No such file exists — views/paper/inbox/ holds only PaperCaptureComposer.vue, PaperCaptureNib.vue, PaperTriageRowEdit.vue and PaperTriageTable.vue. The real site is frontend/taskdeck-web/src/views/paper/PaperInboxView.vue:124-136. Worth knowing before anyone tries to open the cited path.

Finding 2 stays live and is confirmed

Grepping route.query.columnId across frontend/taskdeck-web/src returns zero matches. composables/useInboxOrchestrator.ts:42 reads only boardId. The board's + CAPTURE link passes a columnId that nothing anywhere consumes, so column-scoped capture silently degrades to board-scoped. This is tracked nowhere else — do not close this issue on the strike above.

Sequencing — rides along with #1966

Finding 2 is the same class as #1966's Inbox half: an unread query parameter on the same route, where the surface promises a narrower scope than it delivers. Both are one pass over useInboxOrchestrator. #1966 is Priority I on v0.1.2; this issue is Priority II, so the marginal cost of taking finding 2 in the same PR is near zero — recommend it rides along rather than being scheduled separately.

[Chris0Jeky]

Post-merge reconciliation from #2017/#2018: columnId is no longer a literal zero-reader field—it is now read to label the visible scope—but the capture list still sends only boardId, so the column is display/destination context rather than a real list filter. Keep this issue open and treat its reader-count wording as superseded by this evidence. Any implementation must either remove the column from filter copy or add a real column contract before claiming the list is column-filtered.

Source review: #2018 (comment)