Make first-run V1 production land on actionable workflow work

[alexeygrigorev]

Make first-run V1 production land on actionable workflow work

Status: pending
Tags: enhancement, portal, work-engine, frontend, backend, data, infra, testing, P0
Depends on: None
Blocks: None

Scope

Make a clean DataOps V1 runtime useful to the operations manager immediately after production seeding.

Today production can have seeded runtime users and workflow templates but still have zero active bundles, zero tasks, and zero notifications until an automatic weekly/monthly schedule happens to match or the operator manually discovers how to create work. That misses the V1 goal in .goal-v1.md and docs/operations-manager-platform-jtbd.md: the operator should land in a workflow-first daily operations workspace, not an empty dashboard with templates hidden elsewhere.

This issue should improve the first-run path across the surfaces needed to make that true:

• work-engine/src/public/app.js: dashboard empty states and first-run workflow start affordance.
• Work-engine template/bundle APIs as needed so starting real work from seeded templates is direct and reliable.
• work-engine/src/cron/runner.ts, recurring generation, scripts, or deploy smoke checks as needed for a safe catch-up/generation path after seeding.
• .github/workflows/deploy-dataops-v1.yml only if deployment should run or verify a guarded, idempotent first-run/catch-up step after seeding templates.

The intended behavior is not to create fake demo production data. The intended behavior is that, when seeded templates exist but runtime work is empty, the operator can immediately start a real workflow from a seeded template, and any automated catch-up/generation path only creates real scheduled work according to configured templates/recurring configs.

Acceptance Criteria

• In a clean seeded runtime with users and seeded templates present but no active bundles, tasks, or notifications, the dashboard no longer feels like a dead end. It shows a workflow-first first-run state that explains there is no active work yet and offers clear actions to start real work from seeded templates.
• The dashboard first-run state surfaces seeded workflow templates directly enough that the operator can start at least podcast and newsletter workflows without first navigating through template editing. The flow must collect or preserve an anchor date and create a real active bundle from the selected template.
• Starting a workflow from the first-run path uses the existing runtime model: it creates an active bundle, instantiates template tasks, copies relevant template metadata such as tags, references, bundle link definitions, default assignee behavior, proof requirements, and instruction doc context, then navigates to the created workflow or updates the dashboard so the active workflow is visible.
• The daily queue and active workflow dashboard remain truthful after first-run creation: due, overdue, waiting, follow-up, missing-evidence, recurring, and template-generated labels continue to be driven by real task/bundle state, not by placeholder UI rows.
• If a catch-up/generation step is added or changed, it is guarded and idempotent. Re-running it for the same date/date range must not duplicate bundles or recurring tasks; it must report template-created, template-skipped, template-recovered, recurring-generated, recurring-skipped, and failures distinctly; it must respect disabled triggers and manual templates; and it must have a bounded date range or explicit single-date mode.
• If deployment automation is changed, it keeps the existing GitHub Actions OIDC deployment model. The deploy workflow may seed and verify work-engine state, but it must not introduce a normal manual app deploy or require changes to ../aws-infra unless the issue explicitly documents that a credentialed AWS operator must apply the related CloudFormation stack.
• Production/test seed behavior remains idempotent. Seeding users/templates repeatedly does not delete operator-created production work and does not create fake/demo bundles, tasks, or notifications.
• The empty dashboard copy distinguishes between “no active production work yet” and “no templates are available.” If templates are unavailable, the operator gets a useful error/next step; if templates are available, the operator gets start-workflow actions.
• Regression tests cover the first-run dashboard state, starting a workflow from a seeded template, idempotent generation/catch-up behavior if touched, and deploy/script smoke checks if touched.
• Tester evidence includes a screenshot or Playwright artifact for the clean seeded dashboard first-run state and a second screenshot or artifact after starting a workflow, showing the created active workflow/tasks.

Test Scenarios

Scenario: Clean seeded runtime shows first-run workflow actions

Given: Runtime users and seeded templates exist, and bundles, tasks, recurring-generated tasks, and notifications are empty.
When: The operations manager opens the V1 dashboard.
Then: The dashboard shows no fake work, but it presents clear start-workflow actions backed by seeded templates and does not require the operator to discover the template editor first.

Scenario: Operator starts a real workflow from a seeded template

Given: The clean seeded runtime first-run state is visible.
When: The operator selects a seeded podcast or newsletter template, enters/selects an anchor date, and starts the workflow.
Then: A real active bundle is created, template tasks are instantiated with expected dates and metadata, required bundle links/proof requirements are preserved, and the operator lands in the workflow context or sees it immediately on the dashboard.

Scenario: First-run creation is not demo data

Given: A workflow has been started from a seeded template.
When: The operator opens the bundle detail and task rows.
Then: The records are normal production runtime records with source: template tasks, real template references, required evidence gates, and no demo/sample-only markers.

Scenario: Catch-up/generation is idempotent if implemented or modified

Given: Automatic templates or recurring configs match a selected generation date/date range.
When: The safe generation/catch-up command, route, or deploy step runs twice with the same inputs.
Then: The first run creates or recovers eligible work, the second run reports skipped existing work, and the total number of matching bundles/tasks does not increase on the second run.

Scenario: Non-matching schedules remain truthful

Given: Seeded automatic templates are weekly/monthly and the selected date does not match their schedules.
When: cron or catch-up generation runs for that date.
Then: It reports no generated work without errors, and the dashboard still provides manual start-from-template actions rather than pretending work exists.

Scenario: Deploy smoke preserves first-run readiness

Given: The deploy workflow has completed seeding users and templates.
When: deploy smoke checks or equivalent local tests inspect the work-engine runtime.
Then: They verify templates are present and either actionable generated work exists because schedules matched or the first-run dashboard/start-workflow affordance is available for a clean runtime.

Out of Scope

• Importing real historical Trello/Google Sheets production work.
• Creating fake/demo production bundles, tasks, or notifications just to make the dashboard non-empty.
• Replacing the current Lambda/SAM/GitHub Actions OIDC deployment architecture.
• Changing source repos such as ../dtc-operations, ../datatasks, or ../podcast-assistant.
• Building a full onboarding wizard, CRM, calendar integration, or external account OAuth flow.
• Redesigning the whole dashboard beyond the first-run/actionable-work path needed here.

Dependencies

• Seeded users and templates from work-engine/scripts/seed-users.ts and work-engine/scripts/seed-templates.ts must remain available and idempotent.
• Existing bundle creation with templateId must continue to instantiate template tasks through instantiateTemplate.
• Existing cron semantics in work-engine/src/cron/runner.ts and recurring generation must remain duplicate-safe.
• If production deployment behavior changes, the existing DataOps GitHub Actions OIDC role must already permit the required Lambda/DynamoDB/API operations. Changes to ../aws-infra/sandbox/dataops/template.github-actions.yaml would require a credentialed AWS operator to apply the dataops-github-actions CloudFormation stack and should be called out explicitly.