hamid
1c266523bc
The trust engine. New `verif` schema (5 tables) + a data-driven verification pipeline: steps are rows (6 seeded step-types), not a code enum. - nurse_verifications.status is the single source of verification truth; nurse_profiles.is_verified is flipped ONLY inside the finalize transaction (VerificationAggregator: tracked verification + tracked profile -> one commit) and reversed on suspension/expiry — no in-between state. - is_automated snapshotted onto each step at submit; steps seeded from active required step-types; automated runs (identity-KYC, Shahkar, IBAN ownership) find their step by code. - users.national_id populated only on identity-KYC pass; Shahkar + IBAN owner compare against it (money-mule guard); shared-SIM -> shared_sim support alert. - Documents are metadata-only behind signed URLs; credential_number encrypted and never serialized; public trust badge exposes credential TYPES, not numbers; holder-name cross-checked against the verified identity before recording. - Admin-triggered credential-expiry scan reverts lapsed steps, re-gates bookability, raises a verification_expired alert + verification_expiry_prompt notification (scheduled cron deferred; config key verification_expiry_scan_cadence_hours). Three new mock vendor seams (IShahkarVerifier / IIdentityKycProvider / ICredentialVerifier) behind DI; reuses b3 IBankAccountOwnershipVerifier and b0 IObjectStorage/IFieldEncryptor. 15 endpoints across 4 controllers. Two migrations (tables + step-type seed). 154 tests pass, zero new warnings. Contract dev/contracts/domains/verification.md + swagger snapshot refreshed; handoff/report/mocks-registry updated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
dev/ — the Balinyaar build workspace
This folder is the plan for building Balinyaar, not application code. It takes the repo from its
current starter + auth baseline to the MVP described in product/, as a chain of
agent-runnable prompt files split into two parallel tracks.
| Folder | What it is |
|---|---|
phases/ |
The prompt chain — backend/ (b0–b15) and frontend/ (f0–f15), plus the shared rules/template in phases/_shared/. Start at phases/README.md. |
contracts/ |
The shared API/flow contract between the two independent projects. Backend writes, frontend reads. |
shared-working-context/ |
The parallel-agent handoff + per-phase reports + the mock registry. Each lane writes only its own files. |
How to use it
- Read
phases/README.md— the roadmap and dependency graph. - To run a phase, point a fresh agent at one phase file (e.g. "Execute
dev/phases/backend/backend-phase-2.md"). The phase file tells it what to read, what to build, and how to close out. - Run the two tracks in parallel with two agents if you like: a frontend phase named
frontend-phase-N-bM.mdonly needs backend phase bM merged first; everything else about the two tracks is decoupled throughcontracts/andshared-working-context/(which are designed so the two agents never touch the same files).
Non-negotiables (every phase enforces them)
- Follow the project rules in the relevant
CLAUDE.md/CONVENTIONS.mdand the shared operating rules. - Mock external services behind DI seams and record them in
shared-working-context/reports/mocks-registry.md. - Finish each phase with: updated docs, a written contract (backend), a handoff note, a phase report, and saved memory.