Implement Podcast Assistant portal UI in workflow context

Status: pending
Tags: enhancement, portal, work-engine, assistant, podcast, frontend, testing, design, P0
Depends on: None - #30 agent-verifiable assistant job lifecycle is implemented on main via 553f576; #30 remains open only for human production credential verification.
Blocks: #9 Podcast end-to-end assistant-output review/proof path

Scope

Build the operator-facing Podcast Assistant UI for DataOps V1. The UI must be centered on the operations-manager jobs-to-be-done from docs/operations-manager-platform-jtbd.md: the operator starts from a podcast workflow/task, asks for assistant help, tracks whether assistant work is queued/running/failed/waiting for approval, reviews generated output, and attaches approved output as workflow proof/artifact without switching into a disconnected assistant console.

This issue is the frontend/product layer for Podcast Assistant jobs. It should consume the durable assistant job lifecycle and API from #30 and the accepted artifact model from #29. It may add small API-client or route glue needed by the portal UI, but it must not redefine assistant job persistence, artifact storage policy, or production assistant execution.

Primary operator jobs this issue must make easy:

• From a Podcast workflow or Podcast task, request assistant help using the current task/bundle context.
• Track assistant jobs that are queued, running, failed, canceled, succeeded, or waiting for approval.
• See assistant job risk in the same places the operator checks daily work: workflow detail, task panel, and an assistant-jobs queue/panel reachable from the V1 workspace.
• Open a job detail view with linked task/bundle context, input references, bounded logs/events, output artifacts, failures, and retry/approval history.
• Review generated Podcast Assistant output, approve or reject it, retry failed/rejected output, cancel non-terminal jobs, and attach approved output as workflow proof/artifact.
• Return to the podcast workflow with the approved assistant output visible in the task/bundle proof surface.

Required UI Surfaces

Workflow/task entry points

• Add an Ask assistant or equivalent action in Podcast task panels and Podcast workflow/bundle detail.
• The action must require at least one workflow context: taskId, bundleId, or both. It must not create orphaned assistant jobs.
• The request form should prefill assistant type podcast, linked workflow/task title, and relevant context such as guest/topic/anchor date when available.
• The operator can add input references such as task notes, source URLs, existing artifacts/files, process docs, or free-form source notes.
• Submitting creates/submits a Podcast Assistant job through the Implement assistant job model and lifecycle #30 API and returns the operator to workflow context with the new job visible.

Assistant jobs queue/panel

• Add an assistant jobs queue/panel that is framed as operational work, not a separate assistant app.
• Default grouping must prioritize waiting_approval, failed, running, and queued jobs before completed history.
• Each row must show assistant type, job title, linked workflow/task, status, attempt count, last update, and the next available operator action.
• Filters should support at least status, needs approval, failed, running/queued, and Podcast jobs.
• Empty states must tell the operator what is clear, for example no jobs need approval or no failed assistant jobs.

Job detail

• Opening a job shows one primary detail view or panel with:
  • status and status history;
  • linked Podcast workflow/task and a direct return path;
  • input references;
  • output artifacts and review status;
  • bounded log/event timeline;
  • sanitized failure summary and retry policy;
  • available actions based on job status.
• Logs must be readable enough for the operator to decide whether to retry or file a follow-up issue, but full/raw transcripts should remain artifact/log links when they are too large or sensitive.
• The detail view must not expose secrets, raw tokens, signed URLs, or unbounded runner output.

Review, approval, retry, cancel, and proof attachment

• Jobs in waiting_approval expose review actions for approve and reject.
• Approval must attach or confirm the output artifact on the linked task/bundle using the Define artifact model and storage policy #29 artifact contract and make it visible as proof in the workflow context.
• Rejection requires a reason and preserves the reason in the job history.
• Failed or rejected jobs expose retry only when the retry policy allows it.
• Non-terminal jobs expose cancel when the Implement assistant job model and lifecycle #30 lifecycle allows it.
• Actions must refresh all affected surfaces: queue row, job detail, task panel, workflow detail, artifact/proof section, and relevant risk state.

V1 workflow integration

• Assistant job state must contribute to the workflow-level picture from the JTBD doc: what is at risk, what needs approval, and which proof is missing.
• A Podcast workflow with an assistant job waiting for approval should show that approval as a visible next action.
• A failed Podcast Assistant job should appear as operational risk and, where Implement assistant job model and lifecycle #30 supports it, as an automation-failure notification.
• A task that requires an approved assistant-generated artifact must remain blocked until an approved artifact is attached.
• Approved assistant output must appear in the same artifact/proof UI as manually registered artifacts; do not create a parallel assistant-only proof model.

Design Requirements

• Follow docs/design-system.md tokens and components. Assistant jobs must reuse DataOps status, panel, artifact, task, and workflow patterns instead of introducing a second visual language.
• Follow docs/operations-manager-platform-jtbd.md: the workflow remains the primary screen, assistant output is operational output, and proof is part of task completion.
• Keep the UI calm, compact, and operationally dense. Avoid marketing-style assistant pages, decorative cards, or a standalone chat-console feel.
• Mobile must work on a Pixel 7-sized viewport with one primary state visible at a time: workflow/task, job queue, or job detail.
• Buttons/actions should be state-aware and disabled or hidden when invalid, with clear inline reasons for blocked completion or unavailable retry/approval.

Acceptance Criteria

• Podcast task panels and Podcast workflow/bundle detail provide a clear action to request Podcast Assistant help with the current task/bundle context prefilled.
• Assistant job creation/submission from the UI requires workflow context and persists assistantType=podcast, taskId and/or bundleId, input references, title, and approval requirement through the Implement assistant job model and lifecycle #30 API.
• The new assistant jobs queue/panel groups approval-needed, failed, running, queued, and completed jobs in an operator-prioritized order.
• Queue rows show job title, assistant type, linked Podcast workflow/task, status, attempt count, last update, output/proof summary, and next action.
• Queue filtering covers Podcast jobs, jobs needing approval, failed jobs, running/queued jobs, and completed/terminal history.
• Job detail shows linked workflow/task context, input refs, output artifact refs, bounded log/event timeline, status history, retry/approval history, sanitized error summary, and available state-specific actions.
• Jobs in waiting_approval can be approved or rejected from the UI; rejection requires a reason.
• Approving output attaches or confirms the generated artifact on the linked task/bundle and makes it visible in the existing artifact/proof section.
• A task requiring approved assistant output remains blocked until the approved artifact is attached; after approval, the same task can satisfy artifact proof without duplicating the proof model.
• Failed or rejected jobs can be retried only when the Implement assistant job model and lifecycle #30 retry policy allows it; exhausted retries show a clear no-retry state.
• Non-terminal jobs can be canceled only when the Implement assistant job model and lifecycle #30 lifecycle allows it; terminal jobs do not show invalid actions.
• Approval, rejection, retry, cancel, and attach actions refresh queue, job detail, task panel, workflow detail, and proof/risk state without requiring a full page reload.
• Assistant jobs waiting for approval or failed are visible as workflow risk/next action in Podcast workflow context, not only in a global assistant view.
• Logs and artifacts are displayed safely: bounded previews, links to full artifacts/logs when available, no secrets/tokens/signed URLs/raw unbounded transcripts in the UI.
• Empty, loading, error, and permission/API-failure states are implemented for the queue, request form, job detail, logs, and review actions.
• UI uses DataOps design tokens/components from docs/design-system.md, works in light/dark mode if the touched surface supports it, and remains usable on desktop and Pixel 7 mobile widths.
• Automated tests cover request-from-workflow, queue grouping/filtering, job detail rendering, approve/reject/retry/cancel state rules, artifact attachment/proof blocking, failed-job risk visibility, and API error states.
• Tester captures screenshot evidence for desktop and mobile: request from workflow/task, queue/panel, job detail with logs/artifacts, approval-needed review, failed/retry state, and approved artifact visible as workflow proof.

Test Scenarios

Scenario: Request assistant help from a Podcast task

Given: an authenticated operator viewing a Podcast task inside a Podcast workflow
When: the operator clicks the assistant action, reviews the prefilled context, adds source notes or input refs, and submits
Then: a Podcast Assistant job is created/submitted with the linked taskId and bundleId, appears in the queue, and appears on the originating task/workflow.

Scenario: Track approval-needed work from the daily queue

Given: a Podcast Assistant job has produced output and is in waiting_approval
When: the operator opens the assistant jobs queue/panel
Then: the job appears in the approval-needed group with linked workflow/task context and a review action before lower-priority completed history.

Scenario: Review and approve generated output as proof

Given: a Podcast Assistant job is waiting for approval with an output artifact
When: the operator opens job detail, reviews the artifact/log summary, and approves the output
Then: the approval event is recorded, the artifact is attached or confirmed on the linked task/bundle, the task proof section shows the approved artifact, and proof-gated completion can proceed.

Scenario: Reject and retry generated output

Given: a Podcast Assistant job is waiting for approval
When: the operator rejects it with a reason and retries it
Then: the rejection reason remains visible in history, the retry follows the #30 lifecycle/attempt policy, the queue and job detail show the new attempt state, and the original output is not silently treated as approved proof.

Scenario: Failed job surfaces workflow risk

Given: a Podcast Assistant job linked to a Podcast workflow has failed
When: the operator opens the workflow detail or assistant jobs queue
Then: the failed job is visible as a workflow risk/next action with sanitized error context and retry/cancel/follow-up options allowed by lifecycle state.

Scenario: Invalid actions are not available

Given: jobs in terminal states, non-approval states, and exhausted-retry states
When: the operator views the queue or detail
Then: approve/reject/retry/cancel actions are disabled or absent according to lifecycle rules, and direct API failures are handled with clear error feedback.

Scenario: Logs and artifacts stay bounded and safe

Given: a job has multiple log events and artifact/log references
When: the operator opens job detail
Then: the UI shows a bounded event/log preview, links to full artifacts/logs where available, and does not render secrets, signed URLs, or raw unbounded transcripts inline.

Scenario: Mobile workflow remains usable

Given: a Pixel 7-sized viewport
When: the operator requests assistant help, opens the queue, reviews a job, and returns to the workflow
Then: only one primary state is visible at a time, controls are touch-sized, text does not overlap, and the workflow remains the main context.

Out of Scope

• Implementing the durable assistant job model, lifecycle validation, DynamoDB/SAM tables, export behavior, or worker-runner API; Implement assistant job model and lifecycle #30 owns that.
• Redefining artifact storage, artifact status semantics, portable export, or artifact proof policy; Define artifact model and storage policy #29 owns that and is the source of truth.
• Building raw Telegram/email intake triage or an assistant inbox; that belongs to the raw intake/inbox work tracked separately.
• Requiring live Telegram, Groq, Heru, Codex, Claude, Google Drive, Dropbox, Slack, email, or S3 credentials for normal automated tests.
• Creating a disconnected assistant console, chatbot surface, or assistant-only proof model outside task/bundle workflow context.
• Automatically publishing, emailing, pushing to GitHub, or sending assistant output to external systems.
• Moving generated documents from local assistant folders into Git as durable production storage.
• Redesigning the whole portal shell, replacing the frontend framework, or rebuilding unrelated task/bundle/artifact UI.
• Modifying ../podcast-assistant, ../dtc-operations, ../datatasks, or other source repos.

Dependencies

• Implement assistant job model and lifecycle #30 is the implementation dependency for durable assistant job APIs, lifecycle state, job events/logs, retries, approvals, cancellation, and artifact attachment behavior. Its agent-verifiable work is implemented on main via 553f576; the remaining Implement assistant job model and lifecycle #30 human check for real Telegram/Heru/Codex/Claude production execution does not block this UI issue because live external execution remains out of scope here.
• Define artifact model and storage policy #29 is closed and provides the artifact/proof contract this UI must reuse for approved Podcast Assistant outputs.
• Import Podcast Assistant into assistants/podcast #7 imported assistants/podcast/ as the canonical in-repo assistant module. Its remaining human Telegram smoke is not required for this UI unless implementation intentionally enables live Telegram/Heru execution in this issue.
• Build the Podcast end-to-end slice #9 should consume this UI path for the full Podcast end-to-end slice: assistant draft -> review -> approved artifact proof -> workflow task completion.
• docs/operations-manager-platform-jtbd.md, .goal-v1.md, and docs/design-system.md are the product/design references for acceptance.

Verification Commands

Expected minimum verification from repo root:

npm --prefix work-engine test
npm --prefix work-engine run typecheck
npm --prefix work-engine run build
npm --prefix work-engine run test:e2e
uv run --project lambda-functions --extra search --with pytest python -m pytest tests/docs_app

If implementation touches assistants/podcast/**, also run:

uv run --project assistants/podcast pytest

If implementation touches docs/content metadata or search-facing references, also run:

cd lambda-functions
uv run --extra search python -m lambda_functions.build_search_index \
  --docs-dir ../content \
  --output ../.tmp/dataops-content-search.index

Tester must capture and inspect screenshots under .tmp/screenshots/ for:

• Podcast workflow/task assistant request entry point.
• Assistant jobs queue/panel with approval-needed, running/queued, and failed states.
• Job detail with logs/events and output artifacts.
• Approval review and approved artifact visible as workflow proof.
• Failed/retry/cancel state.
• Pixel 7-sized mobile views for request, queue/detail, and return-to-workflow.