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. - 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 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. - Nginx is the only public entry point. PostgreSQL and internal services are not internet-exposed.
- Health checks distinguish liveness from readiness. - Health checks distinguish liveness from readiness.
- Backups are encrypted where supported, validated, retention-aware, and paired with rehearsed restores. - 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 | | 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 | | 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 | | 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 | | 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 | | 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. 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. 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. 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 ## Required capability specs