Inbox: disambiguate checklist ownership and preserve Board card context within multi-task threads

Start by tracing the Inbox thread checklist and Board card navigation, including the checklist-specific Details / Board action and the Board's Open thread entry point. The issue does not name files, tests, or implementation details, so first locate those UI and data-flow entry points and determine how card context is represented. Done means the listed acceptance cases work, including explicit handling of multiple or missing card associations and preserving completed steps when switching tasks.

Problem

A single Inbox thread can be linked to several Board cards for different tasks. The thread currently presents one visible checklist, but the UI does not make its relationship to those cards clear. Navigating between the checklist/thread and Board can therefore show an unrelated task's details.

This matters in a long-running conversation where we discuss several tasks without starting a separate thread for each one.

Observed user journey

• One thread is linked to several cards, including an older “Codex Herdr visibility” card (In review) and a “Collaboration handbook update” card (Done).
• The visible checklist contains three completed steps for the handbook update: back up the handbook, update the practice chapter/diagrams, and check the page/interactions.
• The user reports that opening the Board/details entry associated with the current Plan/checklist opens the older Herdr-visibility card instead of the handbook card.
• Opening the thread from a Board card via Open thread still exposes that thread's handbook checklist, without clearly identifying which card the checklist belongs to.

The screenshots supplied by the user show both card detail pages and the thread's handbook checklist (3/3). The Board API also confirms that both distinct cards link to the same thread. We have not independently replayed the complete click sequence or established the implementation root cause. In particular, this report does not assert a specific “first card” selection algorithm or that the storage schema can only ever hold one checklist.

The Herdr wording is the title of a Board card: the reported navigation stays within Plannotator, rather than launching the Herdr application.

Expected behavior

• A checklist-specific Details / Board action should preserve the identity of the task/card represented by that checklist, rather than silently opening another card linked to the same thread.
• Show the associated card title beside the checklist, if there is an association.
• A thread-level Board action should show the linked cards or offer a choice when several are linked.
• Open thread should preserve the source-card context, ideally locating the relevant task message/checklist. If that context is not available, make the limitation explicit rather than implying that the currently visible checklist belongs to the source card.
• With no explicit association, show “Thread checklist / no linked card” or a card selector; do not silently guess a card.

Design question: one thread, multiple tasks

A thread is the conversation container; a Board card is a work item. Their relationship is not necessarily one-to-one.

One possible minimal design is to retain one visible current checklist per thread, with an explicit associated card and an action to switch/reassign it. Finished steps should not silently become another card's steps. If per-card checklist history is supported, switching the selected card could display that card's checklist while preserving other cards' steps.

Alternatively, if checklists are intentionally thread-wide and independent of cards, label that scope clearly and let the Board entry choose among the thread's cards. The essential request is an explicit, consistent relationship and context-preserving navigation, not a requirement to adopt a particular storage model.

Suggested acceptance cases

1. A thread has cards A and B; its visible checklist represents B. Its checklist-specific details action opens B.
2. Opening that thread from A does not present B's checklist as if it belonged to A.
3. A generic thread-to-Board action handles multiple cards explicitly.
4. Missing associations do not silently select an unrelated card.
5. Switching the current task does not overwrite or reassign completed steps without an explicit action.

Environment

• Plannotator: 0.28.61 (local CLI version checked)
• Inbox/Board served from macOS; reported UI interaction in Chrome on Android
• Agent: Codex

Private conversation screenshots and hostnames are omitted; task names above describe the minimal example.