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>
78 lines
3.0 KiB
Markdown
78 lines
3.0 KiB
Markdown
# 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
|
|
1. Parse Lastenheft into atomic requirement IDs (`REQ-*`).
|
|
2. Map each requirement to Django domain app(s).
|
|
3. Define MVP boundary and phase slicing.
|
|
4. Convert grouped requirements into implementation epics.
|
|
5. Break epics into execution-ready tickets with acceptance criteria.
|
|
6. Sequence dependencies and identify critical path.
|
|
7. 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
|