Files
..

AI Content Pipeline Task Pool

This task pool turns IDEA.md into vertical, testable implementation slices that lead to a demo-ready Docker Compose product.

Execution Rules

  • Execute tasks in numeric order unless a later task is explicitly split or reprioritized.
  • Every task starts with a development description and contains concrete implementation details.
  • Every task has a TDD pre-requirement in acceptance criteria.
  • Use vertical red-green-refactor cycles: one public behavior test, minimal implementation, then repeat.
  • Do not write all tests first for a whole task.
  • Fill each task's Result section after execution with:
    • TDD plan.
    • Red evidence.
    • Green evidence.
    • Refactor notes.
    • Verification output.

Global Implementation Assumptions

  • v1 is internal or single-tenant.
  • Roles are only ADMIN and EDITOR.
  • Backend is FastAPI.
  • Frontend is Next.js.
  • Workflow orchestration uses LangGraph, while article/domain tables remain authoritative for product state.
  • Workflow templates, stages, and stage parts are Admin-managed product configuration, not hard-coded UI-only metadata.
  • Queue is Redis-backed Celery, Dramatiq, or RQ.
  • Postgres stores domain state and manifests, not large source snapshots.
  • Object storage stores research source-section artifacts, assets, and job artifacts.
  • Runner uses one managed Codex identity per environment, with fake-runner mode required for CI and demo.
  • Publishing target is a Git-backed Next.js content repository.
  • Publishing commits directly to the configured production branch after final approval and generic Markdown/MDX dry-run validation.
  • Target repository CI/CD owns deployment after commit.
  • Publishing validation is best-effort content-shape validation only; target-site build/runtime errors may reach production.
  • Admin-defined publishing scripts run directly on the runner host inside checked-out site repositories; Admins are trusted code operators.

Demo Definition

The pool is complete when a reviewer can:

  1. Run docker compose up --build from a clean checkout.
  2. Open the frontend.
  3. Use a demo Editor to create an article.
  4. Complete boundary questions, plan approval, research, evidence review, production, draft review, final approval, dry run, and publish commit.
  5. Inspect the final Git commit in the configured demo repository.
  6. Inspect research artifacts in object storage.
  7. Inspect workflow history and job logs in the UI.