Files

T

hamid 2f2aec61a2 backend phase 1: config, reference & platform signals

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>

2026-07-02 01:18:00 +03:30

backend-phase-0-report.md

backend phase 0: foundation, cross-cutting seams & starter cleanup

2026-06-30 22:48:41 +03:30

backend-phase-1-report.md

backend phase 1: config, reference & platform signals

2026-07-02 01:18:00 +03:30

mocks-registry.md

backend phase 1: config, reference & platform signals

2026-07-02 01:18:00 +03:30

README.md

add build development phases

2026-06-28 21:59:59 +03:30

README.md

Phase reports — template

Every phase writes a report here when it finishes (operating-rules §7, Definition of Done). The report is the durable answer to "what did this phase do, what can I test now, and what's still fake?" — saved to a file, not left in chat.

File name: backend-phase-N-report.md or frontend-phase-N-bM-report.md.

# <Backend|Frontend> Phase N — <Title> — Report (<YYYY-MM-DD>)

## What was built
- Bullet list of concrete deliverables (entities/migrations/endpoints, or screens/services/components).

## What is now testable (and exactly how)
- Step-by-step for a human: e.g. "Swagger → POST /api/v1/auth/otp/request with {phone} → 200; the OTP is
  logged to the console; POST /api/v1/auth/otp/verify with that code → returns access+refresh tokens."
- For the frontend: which screen, which route, what to click, expected result, how mock data shows up.

## What is mocked / waiting on a real service
- Each seam touched: interface + file, what's faked, and a link to its entry in `mocks-registry.md`.

## Contracts
- Produced (backend): which `contracts/domains/*.md` + openapi snapshot.
- Consumed (frontend): which contract/version; any request filed in `frontend/requests/for-backend.md`.

## Docs updated
- Which CLAUDE.md / product doc / conventions were updated and why.

## Follow-ups for later phases
- Anything intentionally deferred, with the phase that should pick it up.