wmj
5b4a05afb2
Researched mosque-app and community-board best practices (MadinaAPPS,
Nextdoor) before building: the pattern that works is one-tap RSVP with
what/who/where/when up front, plus a clean separation between plain
announcements and dated events. Deliberately did NOT auto-populate a
global Islamic calendar (Eid/Ramadan dates) — those are moon-sighting-
dependent and hardcoding one as fact would be exactly the kind of
fabrication this app avoids everywhere else (real Overpass data, real
Quran API, no invented listings). The Event Board is community-submitted
only: a mosque posting its own Eid prayer time is real information: this
app guessing the date isn't.
Implementation extends the existing Neighbourhood board rather than
building a parallel system: nf_neighbourhood_posts gains is_event/
event_date/event_location, plus a new nf_event_rsvps table (RLS reuses
the existing nf_is_neighbourhood_member helper via a join, no duplicated
logic). UI adds an event toggle on the post form (reveals date/time/
location), a 📅-badged event card with one-tap 'I'm going' RSVP + live
count, and an All/Events/Announcements filter with events sorted
soonest-first.
Seeded a real demo neighbourhood, 'Masjid Al-Falah Kariah' (join code
ALFALAH), with all 5 demo family owners plus a mutawalli as members: 3
announcements and 4 dated, RSVP'd events (Jumu'ah khutbah, weekly Quran
circle, an Islamic finance/estate-planning talk tying back to the app's
own core purpose, and a Ramadan iftar potluck). Caught and fixed two
seeding bugs during verification: timestamps stored without timezone
context displayed several hours off from the intended Malaysia-local
time, and a 'Saturday' event that actually landed on a Sunday — both
fixed by computing against real weekdays/timezone rather than guessing
offsets.
Covered by e2e-event-board.cjs (14/14), including live verification that
the seeded demo neighbourhood renders its real content. Full regression:
all suites pass.
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.