4.9 KiB
4.9 KiB
Cursor Guidelines
Cursor-specific workflow for TorbatYar implementation phases.
General prompt behavior: prompt-rules.md. Lifecycle: development-loop.md.
Enterprise defaults: enterprise-phase-discovery.md · definition-of-done.md · mandatory-phase-artifacts.md · ADR-018 · ADR-019.
Document Loading
Follow Runtime Read Policy.
Do not start coding before Enterprise Phase Discovery, Business Analysis, and Architecture Validation complete.
Discovery Order (before coding)
- Follow Runtime Read Policy
- Inventory existing codebase, APIs, domain model, events, permissions, aggregates, tests, docs
- Publish Discovery Record (baseline, target, gaps, promoted scope, exclusions)
- Only then proceed to Domain Modeling / Implementation
Implementation Order
- ADR/docs if a new decision is required
- Domain modeling notes in the phase doc (aggregates, entities, DTOs) for Discovery-promoted scope
- Models / migrations (entity-template.md)
- Repositories with tenant/soft-delete/page/filter/sort/search (repository-template.md)
- Specifications · Policies · Validators
- Commands · Queries · Services + events (service-layer-template.md, event-template.md)
- API routers + DTOs + OpenAPI (api-template.md); Health / Capabilities / Metrics / Permissions as required
- Configuration, feature flags, seeds, background jobs when required
- Provider adapters only if this service owns them
- Frontend only if the phase explicitly includes UI
- Keep diffs scoped to the phase — no drive-by refactors
- Close every Discovery Missing→Implement gap — do not stop at CRUD
Documentation Order
- Publish Discovery Record in the phase doc before claiming Implementation progress
- Draft/update phase doc (Business Analysis + Domain Model) during or immediately after implementation
- Update registries and manifests
- Update reference catalogs when public surface changed
- Update progress (completed) and next-steps (next milestone)
- Fill handover (phase-handover.md) including Discovery summary + Enterprise Completeness + DoD
- ADR index if a new ADR was added
- Follow documentation-template.md
Validation Order
- Automated tests (testing-template.md)
- Self audit (Discovery gaps closed, scope creep, unfinished claimed work, layering, tenancy, secrets, mandatory artifacts)
- Enterprise Completeness (enterprise-completeness.md)
- Quality gates (quality-gates.md) including Discovery gate
- Definition of Done (definition-of-done.md)
- Link / cross-reference / manifest checks for doc changes
- Repair loop until green — implement missing required work
Loop Behavior
- Follow development-loop.md stages strictly.
- On gate failure: fix root cause (implement missing artifact), re-validate, do not skip gates.
- On architecture conflict: stop coding; fix ADR/docs first.
- On boundary temptation (other service / future phase): stop; integrate or defer per boundary-rules.md.
- Prefer existing sibling service patterns (Accounting, CRM, Loyalty, Communication, platform services).
Completion Behavior
- Phase is complete only when Completion Rules in development-loop.md, Discovery gaps closed, and definition-of-done.md are satisfied.
- Print a concise completion summary for the user (include Discovery + completeness/DoD confirmation).
- Stop — do not begin the next phase unless the user explicitly requests it.
- Do not commit unless the user asks (project git norms).
Cursor Tooling Notes
- Use the repo’s docs and code as source of truth; do not invent registries.
- Discovery must inspect the real codebase/APIs/tests — do not Discovery from the phase brief alone.
- Run pytest for the touched service before claiming tests passed.
- For docs-only phases (like framework upgrades), run documentation/link/manifest validation instead of service pytest; still produce a Discovery Record against docs/manifests.
- Never modify unrelated completed business phases when upgrading the framework.