docs: limit analytics reporting periods

docs/DATA-FOUNDATION-SPEC.md

@@ -14,7 +14,7 @@ Perform a one-time, repeatable bootstrap of the supplied payment-attempt archive
 - One-time administrative bootstrap/recovery execution; no ingestion scheduler or file watcher
 - Import runs, checksums, schema version, row counts, rejection/error reporting
 - Normalized merchant, category, terminal, payment-session, payment-attempt, and account/profile concepts
-- Versioned Gregorian/Jalali calendar dates and curated Iranian event/holiday periods
+- Gregorian/Jalali reporting dates with day, week, month, and Persian-season attributes
 - Rebuildable daily base summaries and metric-specific period projections for approved analytics
 - Synthetic merchant display profiles and one demo account per merchant
 - Idempotent re-runs and explicit import lifecycle
@@ -40,8 +40,6 @@ erDiagram
     MERCHANT ||--o{ PAYMENT_SESSION : receives
     TERMINAL ||--o{ PAYMENT_SESSION : handles
     PAYMENT_SESSION ||--|{ PAYMENT_ATTEMPT : contains
-    CALENDAR_DATE ||--o{ CALENDAR_DATE_EVENT : includes
-    CALENDAR_EVENT ||--o{ CALENDAR_DATE_EVENT : occurs_on
     CALENDAR_DATE ||--o{ MERCHANT_DAY_SUMMARY : groups
     MERCHANT ||--o{ MERCHANT_DAY_SUMMARY : summarizes
     IMPORT_RUN ||--o{ PAYMENT_SESSION : introduced_by
@@ -126,17 +124,7 @@ erDiagram
       int jalali_day
       text persian_season
       int iso_weekday
-    }
-    CALENDAR_EVENT {
-      bigint id PK
-      text code UK
-      text title_fa
-      text event_type
-      text source_version
-    }
-    CALENDAR_DATE_EVENT {
-      date date FK
-      bigint calendar_event_id FK
+      date reporting_week_start
     }
     MERCHANT_DAY_SUMMARY {
       bigint merchant_id FK
@@ -192,11 +180,11 @@ This contract applies only to the one-time challenge-data bootstrap and explicit
 - Missing values remain missing rather than being silently replaced with factual-looking defaults.
 - The import report captures checksum, importer revision, timings, counts, validation failures, and quality metrics.
 - Raw data and database state remain ignored by Git; code, schema, rules, docs, and safe templates are tracked.
-- Daily, Jalali-month, Persian-season, and approved calendar-event analytics reconcile to deterministic source queries for additive metrics.
+- Daily, weekly, Jalali-month, and Persian-season analytics reconcile to deterministic source queries for additive metrics.
 - Rates are recomputed from their numerator and denominator over the requested period rather than averaged from daily percentages.
 - Non-additive metrics such as unique payer-token counts are never produced by summing daily distinct counts.
 - Incremental projections become queryable within 15 minutes of eligible live writes, and nightly reconciliation detects/corrects drift without double counting.
-- Calendar rows covering the reporting period reconcile with reviewed official snapshots and record provenance/checksums.
+- Reporting-date rows covering the dataset range reconcile deterministically between Gregorian and Jalali day, week, month, and season attributes.
 
 ## Approval gates / unresolved decisions
 
@@ -212,12 +200,12 @@ Resolved: retain `payer_card_key` unchanged as a restricted, merchant-scoped opa
 
 Resolved: peer benchmarks exclude the active merchant and require at least 10 other merchants plus 1,000 combined peer sessions in the approved cohort/window. Otherwise the benchmark is suppressed as insufficient data; the merchant's own analytics remain available. See ADR 0006.
 
-Resolved: use normalized source-of-truth entities plus versioned calendar/event dimensions, rebuildable daily base summaries, and metric-specific projections for non-additive or measured high-cost period analytics. Monthly, Persian-season, and holiday results use explicit calendar definitions. Keep fact tables unpartitioned initially and introduce partitioning only from measured need. See ADR 0007.
+Resolved: use normalized source-of-truth entities plus a reporting-date dimension, rebuildable daily base summaries, and metric-specific projections for non-additive or measured high-cost period analytics. Daily, weekly, Jalali-month, and Persian-season results use explicit date boundaries. Keep fact tables unpartitioned initially and introduce partitioning only from measured need. See ADR 0007.
 
 Resolved: ZarinPal writes future production rows directly to the normalized tables. Our backend owns schema/read/analytics contracts, refreshes projections within 15 minutes, and performs nightly reconciliation. CSV ingestion remains one-time only. See ADR 0008.
 
-Resolved: commit reviewed yearly Iranian calendar snapshots sourced from the University of Tehran Institute of Geophysics Calendar Center; do not call a calendar API at runtime. Official holidays and analytical campaign/event windows remain distinguishable and versioned. See ADR 0009.
+Resolved: holiday and named-event reporting are removed from scope. MVP reporting periods are limited to daily, weekly, Jalali-month, and Persian-season views. See ADR 0010.
 
 Resolved: only source session status `Verified` is a definitely successful payment. Keep `Paid` separate until an authoritative ZarinPal definition changes the metric catalogue. See `METRIC-CATALOGUE.md`.
 
-No broad architecture approval gates remain for this capability. Physical columns, indexes, constraints, calendar source, projection shapes, and migration details still require profiling evidence and acceptance in the implementation-ready revision of this spec.
+No broad architecture approval gates remain for this capability. Physical columns, indexes, constraints, reporting-period boundaries, projection shapes, and migration details still require profiling evidence and acceptance in the implementation-ready revision of this spec.