Build the Podcast end-to-end slice

[alexeygrigorev]

Build the Podcast end-to-end slice

Status: pending
Tags: enhancement, portal, work-engine, assistant, podcast, process-docs, frontend, backend, data, testing, P0
Depends on: #4, #6 (closed), #7, #8, #49 (closed), #50 (closed)
Blocks: first V1 workflow acceptance, later end-to-end workflow slices, backend consolidation after the first workflow proves the model

Scope

Build the first V1 operator flow for one Podcast workflow run. Keep this as an integration slice across the existing work-engine, process-doc, and Podcast Assistant surfaces; do not redesign the workflow engine, assistant job system, or artifact storage model in this issue.

The operator should be able to:

• Start a Podcast workflow from the groomed Podcast workflow/template produced by Define the Podcast workflow #8.
• Provide the minimal launch inputs needed for V1: topic or working title, guest/speaker name, anchor date/live stream date, and optional guest email or source note.
• Open the resulting Podcast workflow from the dashboard, bundle/workflow list, or task row.
• See the Podcast workflow in context: title, stage, anchor date, progress, next due tasks, overdue tasks, waiting/follow-up tasks, required bundle links, attached files/assistant outputs, and process references.
• Execute Podcast tasks from the workflow detail without leaving the workflow context.
• Use process docs in context for Podcast tasks, preferring instructionDocId/registry resolution from Add task-to-process-doc links #6 and falling back to instructionsUrl only when no stable doc ID exists.
• Mark tasks as waiting with waitingFor, followUpAt, and a short note; due follow-ups must surface through the existing reminder behavior from Generate dashboard reminders from waiting follow-up dates #50.
• Complete tasks only when required proof exists:
  • required-link tasks need their URL saved on the task and reflected in the matching Podcast bundle link;
  • required-file tasks need an uploaded file record;
  • completion records completedAt and, where actor context is available, completedBy.
• Attach or link a Podcast Assistant output from Import Podcast Assistant into assistants/podcast #7 to the workflow as the V1 artifact/proof for the podcast document task, using the current file metadata and/or bundle-link model unless a finalized artifact API already exists by implementation time.

Use the V1 runtime shape from docs/v1-runtime-architecture.md: work execution goes through the private work-engine behind the authenticated /work/api/* broker; Git-backed process knowledge stays under content/; private or bulky outputs are represented by metadata/links rather than moved into Git.

Acceptance Criteria

• A Podcast workflow can be started from the Podcast template/workflow definition delivered by Define the Podcast workflow #8 using topic/title, guest name, anchor date, and optional guest email/source note.
• Starting the workflow creates one active Podcast bundle/workflow with the expected title, podcast tag/type, stage, anchor date, required bundle-link slots, process references, and generated task set.
• The generated tasks preserve task definition metadata from Define the Podcast workflow #8, including offsets, milestones/stage transitions, assignees when present, required links/files, instructionDocId or instructionsUrl, phase/systems/validation fields where available, and template task refs.
• The operator can open the Podcast workflow from the dashboard/task list and from the workflow/bundle list.
• The Podcast workflow detail shows active tasks before completed tasks, progress, stage, due/overdue state, waiting/follow-up state, required bundle links, process references, and attached proof/output records relevant to the workflow.
• Completing a task with requiredLinkName is blocked until a URL is saved; saving the URL updates both the task proof link and the matching Podcast bundle link.
• Completing a task with requiresFile is blocked until at least one file is attached to that task.
• Completing a milestone task updates the Podcast workflow stage according to the workflow definition from Define the Podcast workflow #8.
• A Podcast task can be moved to waiting only with waitingFor, followUpAt, and a note/comment; when followUpAt is due, the follow-up appears on Operations Home/reminders without hiding the underlying workflow risk.
• Follow-up actions let the operator either move the task back to todo when a response arrives or record that a follow-up was sent and set the next followUpAt.
• Tasks with instructionDocId show resolved process-doc context and an action to open the doc in the portal; unresolved doc IDs show a usable fallback state; legacy instructionsUrl still appears when no doc ID exists.
• A Podcast Assistant output from Import Podcast Assistant into assistants/podcast #7 can be attached or linked to the relevant Podcast task/workflow, is visible in the workflow context, and can satisfy the podcast-document proof path for V1.
• The flow works through the authenticated V1 /work / /work/api/* surface and does not introduce a second public work-engine endpoint.
• Automated coverage includes backend/API tests for workflow start, generated task metadata, proof blocking, waiting/follow-up fields, stage transitions, and assistant-output attachment/linking.
• Playwright coverage exercises the operator path: start Podcast workflow, open it, view a process doc action, save required proof, attach/link assistant output, mark a task waiting, resolve a follow-up, and complete proof-gated tasks.

Test Scenarios

Scenario: Operator starts a Podcast workflow

Given: the Podcast workflow/template from #8 exists
When: the operator starts a Podcast workflow with a live stream date, guest name, and topic
Then: an active Podcast workflow is created with generated tasks, required bundle-link slots, stage, references, and a visible path back to the workflow detail.

Scenario: Operator uses process docs while executing a task

Given: a Podcast task has a resolvable instructionDocId
When: the operator opens the task inside the Podcast workflow
Then: the UI shows the process doc title/context and an action to open it in the portal.

Scenario: Required link blocks task completion

Given: the Podcast task Create an event in Luma requires the Luma link
When: the operator tries to complete it without a URL
Then: completion is blocked with a clear reason.
When: the operator saves the Luma URL
Then: the task can be completed and the Podcast workflow's Luma bundle link contains the same URL.

Scenario: Required file blocks task completion

Given: a Podcast task requires a file, such as the banner/proof task from the workflow definition
When: the operator tries to complete it before attaching a file
Then: completion is blocked.
When: the operator uploads or attaches a file record to that task
Then: the task can be completed.

Scenario: Waiting guest follow-up resurfaces

Given: a Podcast task is waiting for a guest with waitingFor, followUpAt, and a note
When: followUpAt is today or earlier
Then: the task appears as a due follow-up on Operations Home/reminders and still links back to the Podcast workflow.
When: the operator records Response received
Then: the task moves back to todo with an event note.
When: the operator records Follow-up sent with a new date
Then: the task remains waiting with the new followUpAt.

Scenario: Assistant output becomes workflow proof

Given: Podcast Assistant has produced a draft podcast guest/prep document from #7
When: the operator attaches or links that output to the Podcast workflow/task
Then: the output is visible in the workflow context and the podcast-document task has the proof needed for V1 completion.

Scenario: Podcast milestone advances stage

Given: a Podcast milestone task has stageOnComplete
When: the operator completes that milestone with required proof present
Then: the Podcast workflow stage updates and the active/completed task ordering remains stable.

Out of Scope

• Rebuilding the whole portal navigation or design system.
• Creating a generic workflow designer beyond what Define the Podcast workflow #8 defines for Podcast.
• Redefining the task/bundle/template data model beyond fields needed to consume Define the Podcast workflow #8.
• Importing or normalizing every Podcast SOP/template; Define the Podcast workflow #8 owns the workflow definition and priority mappings.
• Building the full assistant job lifecycle from Implement assistant job model and lifecycle #30.
• Building the final artifact model/storage policy from Define artifact model and storage policy #29.
• Adding S3-backed binary artifact storage unless it already exists by implementation time.
• Automating external systems such as Luma, Meetup, YouTube, Spotify, Airtable, Google Drive, Slack, Mailchimp, or Dropbox.
• Migrating Trello cards, spreadsheet rows, or historical Podcast runs.
• Consolidating work-engine into the Python backend.

Dependencies

Required before implementation starts:

• Import DataTasks into work-engine #4: work-engine import/tracker dependency. The current repo has work-engine/, but Import DataTasks into work-engine #4 still declares that it blocks Build the Podcast end-to-end slice #9, so the tracker should be resolved before engineering starts this slice.
• Import Podcast Assistant into assistants/podcast #7: Podcast Assistant must be imported into assistants/podcast with its local processing/tests preserved so this issue can attach/link real assistant output instead of inventing a stub assistant.
• Define the Podcast workflow #8: Podcast workflow definition must provide the executable template/task metadata, stage/milestone mapping, required proof, and priority process-doc links used by this slice.

Already satisfied or available as platform prerequisites:

• Add task-to-process-doc links #6: task-to-process-doc links are closed and should be used for docs-in-context.
• Deploy private work-engine Lambda behind portal broker #49: private work-engine Lambda behind the authenticated portal broker is closed and should remain the runtime boundary.
• Generate dashboard reminders from waiting follow-up dates #50: waiting follow-up reminders are closed and should be reused rather than rebuilt.

Not blocking unless they land first:

• Define artifact model and storage policy #29: final artifact model/storage policy. For this V1 slice, assistant output may be represented with existing file metadata and/or bundle links. If Define artifact model and storage policy #29 is complete before implementation, use its accepted model without broadening this issue.
• Implement assistant job model and lifecycle #30: assistant job model and lifecycle. This issue only needs to consume/attach a Podcast Assistant output from Import Podcast Assistant into assistants/podcast #7; it should not create a generic job dashboard.
• Define the first workflow data model #15: broader workflow data model. Do not wait on Define the first workflow data model #15 unless Define the Podcast workflow #8 concludes that the current template/bundle/task model cannot express the Podcast workflow slice.