hamid
2f2aec61a2
Lay the cross-cutting platform backbone every later phase reads from. Adds the first marketplace EF migration baseline (new `ops` schema) and the mechanisms b2..b15 reuse: typed runtime config, an append-only audit trail, an analytics event log, the holiday/bank-closure calendar, in-app notifications, and the internal support-alert worklist. Schema & migration - New `ops` schema + migration InitialMarketplaceBaseline with 6 tables: PlatformConfigs (IAuditable), AuditLogs (append-only), SystemEvents, IranianHolidays, Notifications, SupportAlerts — with indexes/uniques and FKs to usr.Users. Seeded 12 config keys + 7 sample holidays via HasData. Domain / Application - IAuditable marker + [AuditRedacted] attribute; entities + string-code constant holders (config data_type, holiday type, alert type/severity/status). - Facade contracts: IPlatformConfig, IHolidayCalendar, IAnalyticsSink, IAuditLogger, INotificationService, ISupportAlertService; DTOs + PagedResult<T>; evolved the INotificationDispatcher.Notification record to carry Type + DataJson; Pagination helper. - 14 CQRS commands/queries (+ validators) wiring the endpoints to the facades. Infrastructure - DB-backed facade implementations in Persistence/Services/; real in-app INotificationDispatcher (removes the b0 log stub); notification-retention hosted service (purge is_read=1 AND age>90d). - Extended AuditFieldInterceptor to also append an old/new-diff audit_logs row for every IAuditable change in the same transaction (PII redacted). - Registered all facades + hosted service in AddPersistenceServices; removed the dispatcher registration from AddCrossCuttingSeams. API - 5 controllers: admin PlatformConfig/Holidays/Audit/SupportAlerts ([Authorize(DynamicPermission)]) + current-user Notifications ([Authorize]), all tenant-scoped and paginated. 16 Swagger paths total. Money-correctness & safety rules honoured - Config read at compute time (cached, parsed by data_type), never hardcoded; every config change is audited in the same transaction; audit_logs is append-only (no update/delete path); support alerts are admin-only; notifications are tenant-scoped; analytics is fire-and-forget. Tests & docs - 18 new foundation tests over in-memory SQLite (config typing + audit, holidays, notifications + tenancy + retention, support alerts, analytics); build clean (0 new code warnings), 22 tests green; migration applied to the dev DB and swagger.v1.json refreshed. - Updated server Project map + CONVENTIONS, product data-model doc 12 (seeded config defaults), config-reference contract, mock registry, backend handoff/ STATUS/report. Follow-ups: add FK constraints for SupportAlerts.BookingId (b9) and ReviewId (b14) when those tables land. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
dev/ — the Balinyaar build workspace
This folder is the plan for building Balinyaar, not application code. It takes the repo from its
current starter + auth baseline to the MVP described in product/, as a chain of
agent-runnable prompt files split into two parallel tracks.
| Folder | What it is |
|---|---|
phases/ |
The prompt chain — backend/ (b0–b15) and frontend/ (f0–f15), plus the shared rules/template in phases/_shared/. Start at phases/README.md. |
contracts/ |
The shared API/flow contract between the two independent projects. Backend writes, frontend reads. |
shared-working-context/ |
The parallel-agent handoff + per-phase reports + the mock registry. Each lane writes only its own files. |
How to use it
- Read
phases/README.md— the roadmap and dependency graph. - To run a phase, point a fresh agent at one phase file (e.g. "Execute
dev/phases/backend/backend-phase-2.md"). The phase file tells it what to read, what to build, and how to close out. - Run the two tracks in parallel with two agents if you like: a frontend phase named
frontend-phase-N-bM.mdonly needs backend phase bM merged first; everything else about the two tracks is decoupled throughcontracts/andshared-working-context/(which are designed so the two agents never touch the same files).
Non-negotiables (every phase enforces them)
- Follow the project rules in the relevant
CLAUDE.md/CONVENTIONS.mdand the shared operating rules. - Mock external services behind DI seams and record them in
shared-working-context/reports/mocks-registry.md. - Finish each phase with: updated docs, a written contract (backend), a handoff note, a phase report, and saved memory.