Task 001: dockerized monorepo foundation
This commit is contained in:
@@ -0,0 +1,46 @@
|
||||
# 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.
|
||||
- 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.
|
||||
Reference in New Issue
Block a user