5c6a2e78cf
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>
2.3 KiB
2.3 KiB
ADR-013: Permanent AI Development Framework
| Field | Value |
|---|---|
| Status | Accepted |
| Date | 2026-07-24 |
| Deciders | Platform Architecture |
| Supersedes | — |
| Superseded by | — |
Context
TorbatYar is implemented across many phases and services. AI-assisted implementation without a permanent process framework risks recreating completed work, violating module boundaries, skipping documentation gates, and drifting from ADRs.
Product AI (ai_assistant) is a business capability. Implementation process for any module must be governed separately.
Decision
- Adopt a permanent AI Development Framework under
docs/ai-framework/. - Every future implementation phase must follow the framework reading order, development loop, prompt rules, Cursor guidelines, templates, manifests, and quality gates.
- Phase prompts describe only the current phase; permanent rules live in the framework.
- No phase is complete until quality gates pass and phase-handover deliverables are filled.
- Machine-readable registration uses
phase-manifest.yamlandservice-manifest.yaml. - This ADR does not implement product AI features.
Consequences
Positive
- Consistent AI/human implementation lifecycle
- Clear separation between process framework and product AI
- Enforceable completion gates and handover continuity
Negative
- Additional documentation discipline required before coding
Neutral
- Existing architecture ADRs remain authoritative for technical decisions
Alternatives Considered
- Per-phase duplicated rules in every prompt — rejected (drift, inconsistency)
- Relying only on agent memory — rejected (not auditable)
- Treating product AI architecture as the implementation process — rejected (different concern)