Register all active platform services and base features in core DB so admin can manage them, add delivery/hospitality/sports-center backend phases, update apps catalog and production deploy tooling. Co-authored-by: Cursor <cursoragent@cursor.com>
3.8 KiB
3.8 KiB
ADR-018: Enterprise Completeness Mandate for the AI Development Framework
| Field | Value |
|---|---|
| Status | Accepted |
| Date | 2026-07-25 |
| Deciders | Platform Architecture |
| Supersedes | — |
| Superseded by | — |
| Extends | ADR-013 |
Context
ADR-013 established the permanent AI Development Framework under docs/ai-framework/. Subsequent service phases still risked shipping CRUD-shaped slices without full production readiness (commands/queries, policies, specifications, OpenAPI, metrics, enterprise completeness verification) unless each phase prompt restated those expectations.
The framework must become the single source of truth so every future phase of every future service is production-ready by default, without additional prompting.
This ADR does not change completed business phases or modify business implementations. It upgrades process documentation and execution rules only.
Decision
- Elevate the AI Development Framework into an Enterprise Development Framework (same folder
docs/ai-framework/for backward compatibility; “AI Development Framework” remains the historical name). - Every implementation phase must satisfy the mandatory Definition of Done.
- Every implementation phase automatically includes the Mandatory Phase Artifacts (Business Analysis through Self Audit), deriving missing technical components from high-level roadmap text while remaining inside the current phase.
- CRUD is never sufficient for phase completion.
- Before Complete, verify all dimensions in Enterprise Completeness; missing required work is implemented before status change.
- Enforce Boundary Rules: no foreign service ownership, no logic duplication, no cross-DB access, integrate only via APIs/Events/Providers, never pull future-phase features forward.
- Quality gates, development loop, phase template, handover, testing/documentation templates, master prompt, and Cursor guidelines are updated to encode these rules.
- Completed business phases and existing business code are not retroactively rewritten by this ADR.
Consequences
Positive
- Production readiness becomes the default outcome of every phase
- Phase prompts stay thin; permanent rules live once in the framework
- Clear Completeness / DoD / Boundary vocabulary for agents and reviewers
Negative
- Higher documentation and verification effort per phase (intentional)
Neutral
- Path
docs/ai-framework/retained for compatibility; enterprise docs added alongside - ADR-013 remains Accepted; this ADR extends it
Alternatives Considered
- Keep restating enterprise rules in every phase prompt — rejected (drift, omission)
- Retroactively refactor all completed services to new package layouts — rejected (out of scope; compatibility)
- Treat CRUD + tests as enough for “foundation” phases — rejected (not production-ready)