Seed production-safe recurring operations for daily V1 work

[alexeygrigorev]

Seed production-safe recurring operations for daily V1 work

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

Scope

Add a production-safe seed path for baseline recurring operational tasks so a fresh V1 deployment has real daily work for the operations manager as soon as the scheduled EventBridge cron runs.

The work lives in work-engine/ and the deploy workflow:

• add an idempotent recurring-config seed script or equivalent seed module under work-engine/scripts/;
• seed recurring configs into the existing recurring config storage used by work-engine/src/db/recurring.ts, which currently stores configs in the tasks table with RECURRING#... keys;
• wire the production deploy workflow .github/workflows/deploy-dataops-v1.yml to run the recurring seed after users and workflow templates, with the required DynamoDB table outputs exported;
• keep cron generation in work-engine/src/cron/runner.ts as the path that turns recurring configs into actionable tasks and notifications;
• cover duplicate prevention so the seed can run on every deploy without creating duplicate recurring configs or duplicate generated tasks.

Seed real documented V1 baseline recurring configs from work-engine/docs/data.md / the imported spreadsheet patterns, not demo data. The minimum V1 baseline is:

• Invite people to Slack from Airtable on 0 9 * * *;
• Create new Trello cards and review existing ones on 0 9 * * *.

Also seed the documented non-daily recurring operations that are already recognized by the migration code when they can be represented as standalone recurring tasks without external credentials:

• Ensure newsletter for next week is prepared on 0 9 * * 2;
• Prepare newsletter for the week after next on 0 9 * * 3;
• Backup MailChimp mailing list to Google Drive on 0 9 * * 4;
• Create Slack dump on 0 9 1 * *;
• Check bookkeeping, invoices, and receipts on 0 9 * * 1.

Use the seeded Grace user (00000000-0000-0000-0000-000000000001) as the default assignee for these operator-owned recurring configs unless the implementation finds a stronger existing ownership convention in the seed data.

Acceptance Criteria

• A recurring seed path exists and can run locally and in production without requiring manual DynamoDB writes.
• The seed path creates the baseline recurring configs listed in Scope with enabled: true, the specified cronExpression, the expected description, and an operator assignee.
• The seed path is idempotent: running it twice leaves exactly one recurring config per baseline description plus cron expression and reports created/skipped/updated counts clearly in logs.
• The production deploy workflow runs the recurring seed after seed-users.ts and seed-templates.ts, exporting the DynamoDB table environment needed by the recurring data layer.
• A fresh seeded database followed by a cron run on any normal day creates at least the two daily actionable recurring tasks, with source: recurring, status: todo, recurringConfigId, due date equal to the cron run date, and assignee populated.
• Re-running cron for the same date after recurring tasks have already been generated does not create duplicate tasks and reports skipped recurring work through the existing cron result shape.
• Recurring generation still creates recurring-due notifications for newly generated recurring tasks and does not create notifications for duplicate skips.
• The implementation does not create demo bundles, fake workflow instances, or synthetic production data unrelated to the documented recurring operations.
• Existing manual/automatic workflow-template seeding continues to work; automatic template bundle creation remains separate from standalone recurring task generation.
• Tests cover the new seed path, deploy wiring where practical, and the cron behavior that proves fresh seeded recurring configs produce actionable work.

Test Scenarios

Scenario: Seed baseline recurring configs locally

Given: An empty local work-engine DynamoDB database with seeded users
When: The recurring seed path runs
Then: The listed baseline recurring configs exist, are enabled, have the expected cron expressions, and are assigned to the operator user.

Scenario: Seed can be safely re-run

Given: The baseline recurring configs already exist
When: The recurring seed path runs again
Then: No duplicate recurring configs are created, the logs show skipped or updated records, and each baseline description plus cron expression has exactly one config.

Scenario: Daily cron creates actionable V1 work after seed

Given: A freshly seeded database with users, templates, and recurring configs but no tasks
When: runCron executes for a date that matches the daily recurring configs
Then: At least the Slack invite intake task and the Trello/card review task are created as todo recurring tasks assigned to the operator, and matching recurring-due notifications are created.

Scenario: Cron re-run avoids duplicate recurring tasks

Given: runCron already generated recurring tasks for a date
When: runCron runs again for the same date
Then: No second task is created for any same recurring config/date pair and the cron result reports recurring skips.

Scenario: Production deploy seeds recurring configs

Given: The GitHub Actions deploy workflow completes the SAM deploy and resolves the work-engine table outputs
When: The seed step runs after users and templates
Then: Users, templates, and recurring configs are all seeded before deployed smoke checks, without requiring a manual app deploy or direct production DynamoDB mutation outside CI/OIDC.

Out of Scope

• Changing recurring cron semantics or replacing the existing EventBridge scheduled-event path.
• Building a new recurring-task UI or redesigning the dashboard.
• Importing historical spreadsheet rows or Trello cards as runtime tasks.
• Creating demo workflows, demo bundles, or fake production events just to make the dashboard non-empty.
• Modifying source repos such as ../dtc-operations, ../datatasks, or ../podcast-assistant.
• Manual production deploys outside the existing GitHub Actions OIDC deployment path.

Dependencies

• The seeded users from work-engine/scripts/seed-users.ts must exist before assigning recurring configs.
• The deploy workflow must expose the work-engine tasks table name to the recurring seed because recurring configs are stored in the tasks table.
• Tester should run the relevant work-engine verification workflow: npm --prefix work-engine test, npm --prefix work-engine run typecheck, npm --prefix work-engine run build, and focused or full Playwright E2E only if the implementation changes operator UI or route behavior.
• Infrastructure/deploy changes require SAM/workflow validation and On-Call CI/CD monitoring after merge and push.