feat: Mission Control Strip — "offen" total count per column #247

New Issue

marcel · 2026-04-16T10:04:51+02:00

marcel commented

2026-04-16 10:04:51 +02:00

Goal

Show a small "N offen" (N open) badge below each Mission Control Strip column heading so users know the total backlog size, not just the 5 items visible in the queue. This sets expectations ("there are 47 documents waiting to be segmented") and motivates sustained contribution.

Problem

The current backend returns at most 5 documents per column (hard-coded DEFAULT_QUEUE_SIZE = 5 in TranscriptionQueueService). The frontend shows these 5 items but has no way to display total queue depth because the total count is never fetched.

The weekly pulse TranscriptionWeeklyStatsDTO tracks activity during the past 7 days, which is unrelated to queue depth. There is currently no query that counts all qualifying documents in each queue regardless of the display limit.

What is missing

Backend

Three new count queries in DocumentRepository:
- countSegmentationQueue() — total documents with status NOT IN ('PLACEHOLDER') and no annotations
- countTranscriptionQueue() — total documents with annotations but reviewed_pct < 90 %
- countReadyToReadQueue() — total documents with reviewed_pct >= 90 %

DTO change — Either extend TranscriptionWeeklyStatsDTO with openCounts, or introduce a new TranscriptionQueueStatsDTO record:

public record TranscriptionQueueStatsDTO(
    long segmentationOpen,
    long transcriptionOpen,
    long readyOpen,
    // existing weekly pulse fields stay here or in a separate DTO
    long segmentationWeekly,
    long transcriptionWeekly,
    long readyWeekly
) {}

Service change — TranscriptionQueueService.getWeeklyStats() (or a new method) executes the three count queries and populates the new DTO fields.
Controller — Either extend the existing /api/transcription/weekly-stats response shape or add a new endpoint /api/transcription/queue-stats.

Frontend

+page.server.ts — Update the weeklyStatsResult fetch (or add a new fetch) to load the open counts.
MissionControlStrip.svelte / column components — Render the "N offen" badge. Suggested placement: directly under the column heading, styled as a subdued label (e.g. text-xs text-gray-400), e.g. 47 offen · ↑ +3 diese Woche.
i18n — Add keys mission_control_open_count ("{count} offen") in de.json, en.json, and es.json.
API types — After the backend DTO changes, regenerate src/lib/generated/api.ts.

Notes

The "offen" count for the Lesefertig column may be confusing (documents are ready, not "open work"). Consider a different label there, e.g. "N bereit" / "N ready".
Counts should be cheap native SQL COUNT(*) queries; no need to fetch full rows.

## Goal Show a small "N offen" (N open) badge below each Mission Control Strip column heading so users know the total backlog size, not just the 5 items visible in the queue. This sets expectations ("there are 47 documents waiting to be segmented") and motivates sustained contribution. ## Problem The current backend returns at most 5 documents per column (hard-coded `DEFAULT_QUEUE_SIZE = 5` in `TranscriptionQueueService`). The frontend shows these 5 items but has no way to display total queue depth because the total count is never fetched. The weekly pulse `TranscriptionWeeklyStatsDTO` tracks activity *during the past 7 days*, which is unrelated to queue depth. There is currently no query that counts all qualifying documents in each queue regardless of the display limit. ## What is missing ### Backend 1. **Three new count queries** in `DocumentRepository`: - `countSegmentationQueue()` — total documents with `status NOT IN ('PLACEHOLDER')` and no annotations - `countTranscriptionQueue()` — total documents with annotations but reviewed_pct < 90 % - `countReadyToReadQueue()` — total documents with reviewed_pct >= 90 % 2. **DTO change** — Either extend `TranscriptionWeeklyStatsDTO` with `openCounts`, or introduce a new `TranscriptionQueueStatsDTO` record: ```java public record TranscriptionQueueStatsDTO( long segmentationOpen, long transcriptionOpen, long readyOpen, // existing weekly pulse fields stay here or in a separate DTO long segmentationWeekly, long transcriptionWeekly, long readyWeekly ) {} ``` 3. **Service change** — `TranscriptionQueueService.getWeeklyStats()` (or a new method) executes the three count queries and populates the new DTO fields. 4. **Controller** — Either extend the existing `/api/transcription/weekly-stats` response shape or add a new endpoint `/api/transcription/queue-stats`. ### Frontend 5. **`+page.server.ts`** — Update the `weeklyStatsResult` fetch (or add a new fetch) to load the open counts. 6. **`MissionControlStrip.svelte`** / column components — Render the "N offen" badge. Suggested placement: directly under the column heading, styled as a subdued label (e.g. `text-xs text-gray-400`), e.g. `47 offen · ↑ +3 diese Woche`. 7. **i18n** — Add keys `mission_control_open_count` (`"{count} offen"`) in `de.json`, `en.json`, and `es.json`. 8. **API types** — After the backend DTO changes, regenerate `src/lib/generated/api.ts`. ## Notes - The "offen" count for the Lesefertig column may be confusing (documents are *ready*, not "open work"). Consider a different label there, e.g. `"N bereit"` / `"N ready"`. - Counts should be cheap native SQL `COUNT(*)` queries; no need to fetch full rows.

marcel added the collaboration feature ui labels 2026-04-16 10:04:56 +02:00

marcel closed this issue

2026-04-19 16:16:20 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#247