# UX Reference: Task Logging System (Separated Per-Task Logs)

**Feature Branch**: `018-task-logging-v2`
**Created**: 2026-02-07
**Status**: Draft

## 1. User Persona & Context

*   **Who is the user?**: System Administrator / DevOps Engineer / Developer.
*   **What is their goal?**: Monitor task execution in real-time, debug failures by isolating logs from specific components (e.g., Superset API vs. Git operations), and review historical logs of completed tasks.
*   **Context**: Using the web dashboard to run migrations, backups, or LLM analysis.

## 2. The "Happy Path" Narrative

The user starts a migration task and immediately sees the log panel. As the task progresses, logs appear with clear color-coded tags indicating their source (e.g., `[superset_api]`, `[git]`). The user notices a warning from the `superset_api` source, clicks the "Source" filter, and selects "superset_api" to isolate those messages. The view instantly updates to show only API-related logs, allowing the user to quickly identify a rate-limiting warning. Once the task finishes, the user refreshes the page, and the logs are still there, fully searchable and filterable.

## 3. Interface Mockups

### UI Layout & Flow

**Screen/Component**: TaskLogPanel (within Task Details)

*   **Layout**: A header with filter controls, followed by a scrollable log area.
*   **Key Elements**:
    *   **Level Filter**: Dropdown (All, Info, Warning, Error, Debug).
    *   **Source Filter**: Dropdown (All, plugin, superset_api, storage, etc.).
    *   **Search Input**: Text field with "Search logs..." placeholder.
    *   **Log Area**: Monospace font, alternating row backgrounds.
    *   **Progress Bar**: Inline bar appearing within a log row when a component reports progress.
*   **States**:
    *   **Default**: Shows all logs for the current task.
    *   **Filtering**: Log list updates as filters are changed (live for running tasks via WS).
    *   **Auto-scroll**: Enabled by default; a "Jump to Bottom" button appears if the user scrolls up.

## 4. The "Error" Experience

### Scenario A: Log Loading Failure

*   **User Action**: Opens a historical task with thousands of logs.
*   **System Response**: A small inline notification: "Failed to load full log history. [Retry]".
*   **Recovery**: Clicking "Retry" re-triggers the REST API call.

### Scenario B: WebSocket Disconnect

*   **System Response**: The log panel shows a "Reconnecting..." status indicator.
*   **Recovery**: System automatically reconnects; once back, it fetches missing logs since the last received timestamp.

## 5. Tone & Voice

*   **Style**: Technical, precise, and informative.
*   **Terminology**: Use "Source" for component identification, "Level" for severity, and "Persistence" for saved logs.
