Ticket board doesn't reflect Jira status or linked session for in-flight Jira tickets (read-back complement to CROW-529)

[dhilgaertner]

Summary

Crow's ticket board does not reflect Jira reality for in-flight Jira tickets: it (1) keeps them in the Backlog column even though they're In Development / In Review in Jira, and (2) doesn't recognize that a Crow session is already established for them. The Jira ticket itself shows the correct status — Crow just never reads it back. This is the read-side complement to CROW-529 (which fixed writing the status on transition).

Symptom (reported)

In-flight Jira tickets (sessions established, transitioned to In Development on start and In Review when marked) show the correct status in Jira, but in Crow's ticket board they remain under Backlog, not In Progress / In Review, and the board doesn't show them as having a linked session.

Root cause (confirmed in code)

The board's data model is GitHub/GitLab-only; there is no Jira ingestion or status read-back:

1. No Jira task backend / no .jira provider. ProviderManager.taskBackend(for:) (Packages/CrowProvider/.../ProviderManager.swift) switches over only .github / .gitlab / .corveil — there is no JiraTaskBackend in Backends/. The board is populated from taskBackend.listAssigned() → appState.assignedIssues (IssueTracker.swift:~610, :358). Nothing fetches assigned Jira issues or maps their workflow status into the board's TicketStatus.
2. Status is written but never read back. CROW-529 made Crow transition the Jira ticket (In Development / In Review) via the jira MCP at session start / mark-in-review. But the board groups cards by issue.projectStatus (TicketBoardView.swift:237 over TicketStatus.pipelineStatuses, card uses issue.projectStatus), and the only status-readback path — syncInReviewSessions (IssueTracker.swift:~1763, reads issue.projectStatus == .inReview) — is fed by the GitHub listing. With no Jira listAssigned + no Jira-status → TicketStatus mapping, Jira cards default to Backlog forever.
3. Linked-session detection is .active-only + exact-URL. AppState.activeSession(for: issue) = activeSessions.first { $0.ticketURL == issue.url } (AppState.swift:519). It only scans .active sessions (so a session already moved to In Review isn't matched), and requires an exact ticketURL == issue.url string match (brittle for Jira browse-URL forms). Either reason makes the board show "no session established."

Proposed fix

• Ingest assigned Jira issues + read their status back. Provide a Jira path that lists the operator's in-flight Jira work items and maps each Jira workflow status → Crow TicketStatus (the inverse of CROW-523's jiraStatusMap: e.g. "In Development" → inProgress, the mapped In-Review name → inReview, Done-name → done). Surface them in assignedIssues with the correct projectStatus so the board columns group them right.
  • Mechanism is the open question — surface it. In-app there is no Jira backend; the Jira integration today is the jira MCP that runs inside launched sessions, not the Crow app process. So reading Jira status into the app's board needs a deliberate path: a real JiraTaskBackend.listAssigned (app shells the jira MCP / Jira REST with the configured token), or another ingestion route. Decide + recommend; this is the core design decision.
• Fix linked-session detection independent of the above: activeSession(for:) should consider sessions in .active and .inReview (and any non-terminal state), and match Jira tickets robustly (normalize URL, or match on the Jira key / ticket number) rather than exact ticketURL string equality. So a card shows its established session even after it moves to In Review.

Acceptance criteria

• An in-flight Jira ticket that is In Development in Jira appears under In Progress on the Crow board (and In Review under In Review), via a Jira-status → TicketStatus mapping, not stuck in Backlog.
• A Jira ticket with an established Crow session shows as linked on the board (the "Start Working" affordance becomes the linked-session indicator) for both Active and In-Review sessions.
• GitHub/GitLab board behavior is unchanged.

Notes / related

• CROW-529 wrote the status to Jira (transition on start/in-review); this is the read-back so Crow's own board agrees with Jira. CROW-523 supplies the jiraStatusMap whose inverse this needs.
• Same recurring root cause as CROW-532 / the Jira-parity family: Crow's session/board model is GitHub-shaped, and the Jira task path (vs the GitHub code path) isn't wired into the in-app data model — only into the launched-session MCP.