starcoach-hackathon/zarinpal-analytics-deployment
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: remove scheduled analytics worker

Browse Source
This commit is contained in:
Amirhossein Khalili
2026-08-20 16:17:49 +03:30
parent a304977ed6
commit fd73963b20
2 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
AGENTS.md
View File

@@ -29,7 +29,7 @@ This repository owns deployment concerns only. Backend and frontend directories
- Everything runs through Docker, Docker Compose, Bash scripts, and environment files/templates.
- The CSV-to-PostgreSQL workflow is a one-time administrative bootstrap/recovery command, never a scheduled ingestion service. ZarinPal owns future production payment writes.
- The analytics refresh worker is not an ingestion service: it derives projections from normalized PostgreSQL changes, publishes within 15 minutes, and performs an idempotent nightly reconciliation. Deployment must surface failed/stale refreshes and must not advance freshness on failure.
- Analytics are calculated lazily by the API and persisted as typed PostgreSQL projections. Database-managed merchant/cohort revisions invalidate affected projections on insert; no scheduled analytics worker or Redis service is deployed for the MVP.
- Nginx is the only public entry point. PostgreSQL and internal services are not internet-exposed.
- Health checks distinguish liveness from readiness.
- Backups are encrypted where supported, validated, retention-aware, and paired with rehearsed restores.

5
CAPABILITY-MAP.md
View File

@@ -15,7 +15,7 @@ The hackathon demo will seed one account per merchant. Where merchant profile fi
|---:|---|---|---|:---:|
| 1 | Data foundation | PostgreSQL model, one-time CSV bootstrap, provenance, validation, quality reporting, synthetic merchant profiles; future source writes are owned by ZarinPal | — | Yes |
| 2 | Identity and access | Merchant credentials, sessions, tenant isolation, demo account seeding | Data foundation | Yes |
| 3 | Analytics engine | Deterministic metrics, cohorts, trends, diagnostic drill-downs, traceability, projection refresh within 15 minutes, nightly reconciliation | Data foundation | Yes |
| 3 | Analytics engine | Deterministic metrics, cohorts, trends, diagnostic drill-downs, traceability, lazy PostgreSQL-backed merchant/cohort projections with insert-triggered revision invalidation | Data foundation | Yes |
| 4 | Merchant API | Stable authenticated interfaces for dashboard data and analytics | Identity and access, analytics engine | Yes |
| 5 | Merchant dashboard | Persian RTL dashboard, responsive navigation, accessible charts/tables and explanations | Merchant API | Yes |
| 6 | AI assistance | AvalAI-backed explanation/recommendation workflow over sanitized aggregates | Analytics engine, merchant API | No |
@@ -49,7 +49,8 @@ Build sequence: data foundation → identity and analytics → API → dashboard
7. External calls have timeouts and bounded retries; jobs are idempotent and observable.
8. Production changes are reversible and backed by documented health checks and rollback steps.
9. Only `Verified` is a confirmed successful session; `Paid` remains a separately reported state until an approved metric-catalogue revision says otherwise.
10. MVP reporting periods are limited to daily, weekly, Jalali-month, and Persian-season views with consistent boundaries across database, API, and frontend.
10. MVP reporting periods are limited to daily, Saturday–Friday weekly, Jalali-month, and Persian-season views with consistent `Asia/Tehran` boundaries across database, API, and frontend.
11. Analytics are calculated on first relevant access and cached by merchant/cohort source revision and metric-definition version; the MVP deploys no scheduled analytics worker or Redis.
## Required capability specs