57 lines
4.4 KiB
Markdown
57 lines
4.4 KiB
Markdown
# Capability Map
|
|
|
|
Status: **approved Phase 0 baseline**
|
|
Implementation authorization: **not granted**
|
|
|
|
## Product intent
|
|
|
|
Build a production-shaped, Persian-first merchant analytics panel that turns payment-attempt data into accurate, traceable, numerical, and actionable insights. Each merchant can sign in with a dedicated username and password, see only its own detailed data, and compare itself with anonymized category/cohort aggregates.
|
|
|
|
The hackathon demo will seed one account per merchant. Where merchant profile fields are absent from the source dataset, clearly synthetic display data may be generated for presentation; synthetic values must never be represented as source facts.
|
|
|
|
## Capabilities and dependency order
|
|
|
|
| Order | Capability | Responsibility | Depends on | MVP |
|
|
|---:|---|---|---|:---:|
|
|
| 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 |
|
|
| 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 |
|
|
| 7 | Platform operations | Compose, Nginx, CI/CD, observability, backup/restore, release and rollback | All deployables | Yes |
|
|
|
|
Build sequence: data foundation → identity and analytics → API → dashboard → platform operations → AI assistance.
|
|
|
|
## Repository boundaries
|
|
|
|
- `zarinpal-analytics-backend`: one Go repository containing the modular backend and independently runnable commands where needed (API, importer, migrations, jobs).
|
|
- `zarinpal-analytics-frontend`: SvelteKit 2, Svelte 5, strict TypeScript, Tailwind CSS v4.
|
|
- `zarinpal-analytics-deployment`: Compose/Nginx/scripts/configuration and orchestration only; service repositories appear as ignored nested checkouts during deployment.
|
|
|
|
## Dataset facts that constrain the design
|
|
|
|
- Source grain: one payment attempt, uniquely identified by `(session_key, try_seq)`.
|
|
- Observed volume: 2,213,289 attempts, 2,062,839 sessions, 343 merchants, 348 terminals, 5 categories.
|
|
- Observed period: 2026-01-01 through 2026-07-01.
|
|
- Nullability is material: response, PSP, issuer/card, verification timing, and settlement fields are incomplete.
|
|
- `adjusted_fee` is obfuscated and supports relative analysis only.
|
|
- Raw CSV/database state is local operational input, not versioned source.
|
|
|
|
## Cross-cutting invariants
|
|
|
|
1. Tenant isolation is enforced server-side on every merchant-scoped operation.
|
|
2. Cross-merchant output is aggregate and anonymized; no row-level peer data is exposed.
|
|
3. Every displayed metric has a definition, source fields, filters, time window, and drill-down path.
|
|
4. Dataset imports are repeatable and produce a versioned manifest with checksum, counts, timestamps, and validation results.
|
|
5. Secrets stay outside Git; examples contain names and safe placeholders only.
|
|
6. AI is post-MVP, receives only minimized/sanitized aggregates, and cannot become the source of record.
|
|
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. Iranian official holidays come from reviewed, versioned annual calendar snapshots; broader analytical event windows are explicitly labeled and versioned.
|
|
|
|
## Required capability specs
|
|
|
|
Each capability spec must define objective, scope/non-scope, actors, functional requirements, data/API contracts, security and privacy requirements, failure behavior, observability, tests, acceptance criteria, migration/rollback considerations, and unresolved decisions. A capability may enter implementation only after its spec status is marked **Approved**.
|