48 lines
2.4 KiB
Markdown
48 lines
2.4 KiB
Markdown
# 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.
|