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>
product/ — Balinyaar product & domain knowledge
This folder is the source of truth for Balinyaar's business rules, data model, payments design, and market/legal research. The code is young; these docs are the decisions. Read the relevant doc before designing any schema, API, or feature — don't infer business rules from code.
For humans: open
index.md(or the generatedindex.html) — it's the hub that links everything.
Layout
| Path | What's in it |
|---|---|
overview/ |
What Balinyaar is, the four cross-cutting ground truths, IRR/Toman rule, Persian glossary. Read first. |
business/ |
The 14 functional requirement areas (onboarding → admin), each with rules / Iran considerations / MVP-vs-deferred / supporting entities. |
data-model/ |
The ~54-table schema across 13 domains + diagrams, design principles, design decisions. |
payments/ |
Fintech deep-dive with sources: payment reality, escrow ledger, BNPL, cancellation/payout, integrations. |
research/ |
Market, risks, verification, legal landscape, go-to-market — adversarially fact-checked, cited. |
notes/ |
Living notes: open questions, future ideas. |
wireframes/ |
Screen wireframes (HTML). |
fa/ |
Farsi-language docs kept in parallel (research report + verification flow). |
assets/ |
Shared CSS for the generated HTML view. |
Markdown is canonical; HTML is generated
Every .md file is the editable source. The matching .html files are a generated,
brand-styled, cross-linked browsing view (sidebar nav, Mermaid diagrams, dark mode). Never edit
the .html by hand — edit the Markdown and regenerate.
Regenerating the HTML view
The generator is dependency-free — plain Node, no npm install:
cd product
node build-docs.mjs
It walks every .md file, converts it to a styled .html at the same path,
builds the sidebar from the manifest inside build-docs.mjs, and rewrites internal …/foo.md links
to …/foo.html. If you add, remove, or rename a .md file, update the NAV manifest at the top of
build-docs.mjs so it appears in the sidebar.
Conventions
- Each
.mdstarts with a single# H1(the generator uses it as the page title). - Cross-doc links are relative and use the
.mdextension (the generator rewrites them to.html); this keeps links working both in raw Markdown and in the rendered site. - Languages: English is canonical. Farsi versions live under
fa/and are linked, not inlined. - Money is IRR Rials; see the ground truths.