8054c1e1e4
- Environment-split settings: base/local/test/prod with django-environ - Postgres + Redis + Celery wiring (broker, beat, result backend) - All 9 domain app stubs: accounts, courses, cms, tracking, quizzes, training, certificates, reports, notifications - api app: /healthz/ endpoint, custom DRF exception handler, SecurityAuditMiddleware, permissions/throttle/upload-validation stubs - DRF global baseline: JWT+session auth, closed-by-default permissions, cursor/page pagination, drf-spectacular schema generation - Dockerfile (multi-env build arg), docker-compose.yml (local), docker-compose.test.yml (CI-friendly tmpfs Postgres) - pytest.ini with smoke + settings marker definitions - tests/test_smoke.py: startup, URL resolution, healthcheck shape - tests/test_settings_matrix.py: per-profile security assertions - .github/workflows/ci.yml: test, lint, schema CI jobs - .env.example with all required vars documented - .gitignore Co-Authored-By: Paperclip <noreply@paperclip.ing>
3.0 KiB
3.0 KiB
TRA-210 Implementation Plan (Django-First, Pending Lastenheft)
Status: partially unblocked by board stack decision (Django), still blocked on Lastenheft content. Owner: CTO
1) Confirmed Constraints
- Backend stack: Django-first (board-confirmed 2026-05-06)
- Architecture decomposition must align with:
- Django apps boundaries
- Django auth/permissions model
- Django ORM data model and migrations
- DRF API surface and serializer/validation strategy
- Celery async workload design
- Django-native security controls and hardening
2) Remaining Required Inputs
- Lastenheft source:
<repo path or URL> - Scope constraints:
<in/out of scope> - Timeline constraints:
<milestones / deadlines> - Preferred delivery phases:
<phase model> - Workspace completeness confirmation:
<yes/no + details>
3) Decomposition Workflow
- Parse Lastenheft into atomic requirement IDs (
REQ-*). - Map each requirement to Django domain app(s).
- Define MVP boundary and phase slicing.
- Convert grouped requirements into implementation epics.
- Break epics into execution-ready tickets with acceptance criteria.
- Sequence dependencies and identify critical path.
- Define QA gates and release criteria.
4) Django-Centric Backlog Structure
For each ticket:
- Title
- Requirement IDs covered
- Django app/module target
- Description
- Acceptance criteria (testable)
- Dependencies
- Estimated effort (S/M/L)
- Owner role
- Target phase
5) Provisional Epic Skeleton (to map after Lastenheft ingest)
- E1: Project bootstrap and environment foundations (Django settings, env segregation, CI)
- E2: Identity and access (custom user model, auth flows, role/permission matrix)
- E3: Core domain modeling (ORM entities, constraints, migrations, admin interfaces)
- E4: API platform (DRF viewsets/serializers, versioning, pagination, error contract)
- E5: Async processing (Celery tasks, broker/result backend, retries, monitoring)
- E6: Security and compliance controls (CSRF/CORS, secret handling, audit logs, rate limiting)
- E7: Quality system (unit/integration/API tests, fixtures, coverage gates)
- E8: Observability and operations (structured logs, health checks, metrics, deployment runbooks)
6) Phase Skeleton
- Phase 0: Lastenheft normalization + architecture mapping
- Phase 1: Foundations (E1, baseline security from E6)
- Phase 2: MVP core delivery (E2, E3, E4)
- Phase 3: Scale/reliability (E5, E7, E8)
- Phase 4: Hardening/release readiness (full E6 + non-functional closure)
7) Risks and Controls
- Missing/ambiguous requirements -> clarification register tied to
REQ-* - Scope creep -> strict requirement-to-ticket traceability
- Integration unknowns -> time-boxed technical spikes
- Security regressions -> Django security checklist as release gate
8) Definition of Ready/Done
Definition of Ready:
- Requirement mapping complete
- Acceptance criteria defined
- Dependencies identified
Definition of Done:
- Acceptance criteria verified
- Tests passing
- Documentation updated
- Traceability to Lastenheft requirement IDs recorded