TorbatYar/docs/architecture/adr/ADR-018.md
Mortezakoohjani 5c6a2e78cf feat(platform): seed service registry, deploy all modules, and fix homepage catalog.
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>
2026-07-27 12:39:51 +03:30

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

  1. 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).
  2. Every implementation phase must satisfy the mandatory Definition of Done.
  3. 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.
  4. CRUD is never sufficient for phase completion.
  5. Before Complete, verify all dimensions in Enterprise Completeness; missing required work is implemented before status change.
  6. 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.
  7. Quality gates, development loop, phase template, handover, testing/documentation templates, master prompt, and Cursor guidelines are updated to encode these rules.
  8. 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

  1. Keep restating enterprise rules in every phase prompt — rejected (drift, omission)
  2. Retroactively refactor all completed services to new package layouts — rejected (out of scope; compatibility)
  3. Treat CRUD + tests as enough for “foundation” phases — rejected (not production-ready)