wmj
7ce1121b94
Two features scoped from the stickiness brainstorm, sharing one digest notification pipeline: Sadaqah tracker (new tab): a private daily giving journal, not a payment processor — the app logs, it never moves money. Streak tracking follows the proven pattern from dedicated apps (Sidq, Daily Sadaqa). Family visibility is strictly limited to streak counts via a SECURITY DEFINER RPC (nf_family_sadaqah_streaks) — amounts, causes, and notes never cross the member boundary, respecting the Islamic preference for giving privately. Entries can be dedicated 'in memory of' a deceased person from the Family Tree, with a memorial count (nf_memorial_sadaqah_count, count only) surfacing on that person's card. Family Tree social loop: a 'give sadaqah in memory of' link on every deceased person's card (cross-tab jump via a small requestedTab store in nav.js), plus completeness hints (missing birth date, missing photo, no relationships linked) feeding directly into the existing Coverage Dashboard recommendations engine rather than a new UI surface. Daily digest Edge Function + pg_cron (07:00 UTC): batches into one email per family member per day, sent only when there's real content — tree activity in the last 24h, a birthday/death-anniversary today, or a weekly sadaqah recap on Sundays. An empty day sends nothing, deliberately avoiding the notification-spam failure mode the research flagged. Protected by a shared secret header since it's cron-invoked, not user-triggered. Verified with a live manual invocation before relying on the schedule. Found and fixed two real bugs in nf_family_sadaqah_streaks during E2E testing: an ambiguous unqualified 'member_id' column reference colliding with the function's OUT parameter (42702), and a bigint/int type mismatch from count(*) (42804) — both would have 400'd on every call in production. Covered by e2e-sadaqah-tree.cjs (12/12). Full regression: 280/280 across all suites.
Nur Falah — Estate & Waqf Suite
Horizon 1 (Prevention Suite) + Horizon 2 (Unlock Programme, pre-pilot demo) from the
Nur Falah PRDs, built as a standalone Svelte 5 + Vite PWA, styled to match the visual
system of the live moslem03.falahos.my (Nur Falah Muslim Companion) app.
Modules
| Module | Horizon | Status |
|---|---|---|
| Faraid Calculator | 1 | Shared calc core, 14 classical cases passing (src/lib/calc/faraid.test.js) |
| Asset Registry | 1 | Local-first, feeds every other module's estate total |
| Wassiyah Generator | 1 | 1/3 meter, heir-exclusion block, jurisdiction-aware export |
| Hibah Tracker | 1 | Shared marad al-mawt guardrail |
| Family Waqf Designator | 1 | Built ahead of scholarly sign-off — see below |
| Digital Beneficial Claims | 2 | Pre-pilot demo only — see below |
Important: two governance gates were overridden for this build
Per explicit product direction, this build proceeded past two gates stated in the project's own PRDs and review log:
- Family Waqf Designator (Horizon 1 PRD §8.5) is gated on scholarly sign-off.
scholarly-review-log.md(in thedigital-waqifdocs repo) tracks OPEN-01 — whether a healthy-state waqf is subject to the one-third cap — as unresolved. This module ships anyway; the in-app copy states the open question rather than presenting invented certainty. - Horizon 2 (Digital Beneficial Claims) PRD states: "No engineering work begins until Phase 0 (legal opinion + signed institutional partner agreement) is complete." No confirmation of Phase 0 completion was available. The Claims module ships as a local, non-custodial demonstration of the data model and transfer restriction only — no real legal wrapper, no institutional integration, no real claims issued. It carries a persistent in-app banner saying so.
Both are flagged here, in deploy/DEPLOY.md, and in the relevant module's source
comments so this isn't silently presented as production-ready.
Development
npm install
npm run dev # http://localhost:5173
npm run test # classical faraid test suite
npm run build
Deploy
See deploy/DEPLOY.md. Target: moslem04.falahos.my.