Roadmap & task list

Single source of truth for what's planned. Update this file instead of re-listing tasks in chat.

Status legend: [ ] not started · [~] in progress · [x] done

Sales positioning & unique features

Why ChalisaVibe is different — a plain-language list for pitches, grant applications, partnerships, and any page that needs to explain the app quickly.

Positioning ChalisaVibe is not trying to be the biggest or most authoritative Hindu app in the world. It is a friendly, daily-use companion for people who already want to chant, read a chalisa, or check what is auspicious today. The goal is usefulness and respectful accuracy: good English translations, clear structure, and a calm experience that works on a phone while walking, cooking, or commuting.

What makes it different from most mantra / bhakti apps

1. Hands-free recitation that actually counts for you

   • A dedicated flow builder mixes mantras and chalisas in any order, then the teleprompter paces the user one line at a time, keeps the screen awake, and logs the session.
   • Optional AI-assisted ear mode listens for Sanskrit utterances and advances the mala automatically, falling back to sound-detection when offline or on error.
   • Most apps either force manual tapping or use generic speech recognition that fails on Sanskrit; this flow is built around the rhythm of chanting.

2. Practice, not just playback

   • The mala counter, mantra builds, and hands-free flow are designed for active recitation, not passive listening. Users can create saved "mantra builds" (e.g. a study-focus build of five mantras) and start them immediately from the profile.
   • Favourites, recitation stats, streaks, and a weekly recap turn occasional use into a trackable personal practice.

3. Games that teach the content

   • The arcade levels are memorisation devices disguised as games: names, verses, and stotras ride across the screen and are learned by repetition, not by rote drilling.
   • Each deity gets a structured level spine (single mantra → 12/108 names → protective mantras → Gayatri → Chalisa + optional Aarti → endless weighted review), with line-by-line meaning support so the knowledge sticks.
   • Optional intention panels let the user set a sankalpa before playing, tying gameplay to a real spiritual purpose rather than a high score.

4. A calendar tied to real local time, not just midnight

   • Panchang calculations use the user's location and sunrise-to-sunrise boundaries, so the "today" deity, tithi, and power windows match how traditional practice counts the day.
   • Intent planner rates a specific day across eight themes (study, health, love, protection, etc.) and shows peak windows ahead, not just a generic horoscope sentence.

5. Personalisation without overwhelm

   • Favourite mantras, preferred deities, saved flows, and avatar frames adjust what the home screen, games, and calendar highlight — but the structure stays simple and step-by-step.
   • The app is deliberately modular: calendar, mala, teleprompter, games, and hands-free flow can each be used alone or combined into a longer session.

6. Respect-first content

   • Translations are reviewed to be literal and respectful rather than poetic or interpretive; the aim is faithful plain English that a newcomer can trust and a regular practitioner can recognise.
   • Fierce or frightening imagery is avoided; the visual tone is calm, devotional, and usable in public or family settings.

Honest framing for partners and investors

• The app does not claim to replace a priest, a scripture, or years of study. It is a supportive daily tool for people who already practise or want to start.
• The real moat is the combination: accurate content + voice-aware practice tools + playable memorisation + a calendar that follows sunrise. Each piece exists elsewhere; the integration of all four in one calm mobile experience is what is unusual.
• As content quality improves (translations, audio, more deity games), the app becomes more useful to more people; the platform is built so new deities, languages, and even non-Hindu remixes can be added from the same reusable builds.

Partnerships & user acquisition

• Reach out to creators, teachers, and communities with large followings in the Hindu / bhakti / yoga / wellness space for co-promotion, shout-outs, or affiliate-style referral.
• Offer partners a clear one-pager: positioning, unique features, audience fit, and a simple way to try the app.
• Consider a "partner code" or tracked link so influencers can share ChalisaVibe and see sign-ups driven by their audience.
• Keep partnerships respectful of the devotional nature of the app; avoid hype or guaranteed spiritual claims.

Open items (not built yet)

A. Hindi / Devanagari app language

• Full UI language toggle (English ⇄ हिन्दी) in Profile → Settings, stored in app prefs.
• Ship a translation dictionary (src/i18n/hi.ts) for nav, buttons, section titles, and mantra notes.
• Chalisa content already has Devanagari; the Hindi mode should default the reader to Devanagari + Hindi meaning.
• Target audience: practising Hindu users who want to read, recite and play entirely in Hindi.

B. Hands-free voice mode ("just talk to the app")

• Voice command layer: "bring forth the Lakshmi Chalisa", "start 108 of the Gayatri mantra", "what is good today?" → resolve intent → navigate + start the right screen.
• Implementation sketch: Web Speech API (or a short audio clip → speech-to-text via the AI gateway) → intent parsing with a small model (reuse intent-parser.functions.ts pattern) → router action.
• Optional spoken intro of the chalisa's benefits before recitation begins.

C. Voice-followed auto-scroll (revisit)

• The previous attempt scrolled jerkily and was removed. Rebuild only when it can be smooth: continuous speech recognition → fuzzy-match the spoken line against the verse list → advance the reading line with an eased, calm scroll; never jump backwards on a mis-hear.
• Acceptance bar: the user should be able to recite a full chalisa without touching the screen.

D. Deeper mantra statistics (partially done)

• Done: japa totals, malas completed, 7-day bars, most-recited mantras, top deity (Profile → Mantras).
• Later: per-mantra streaks, intention tags on lists, month view, export.

E. Badge achievement dates

• Store awarded_at timestamp when a badge is earned.
• Show the date on each badge card / detail view, e.g. "108 Hanuman recitations — achieved 14 Aug 2026".
• Keep a per-user badge history so the user can look back at when milestones were reached.

F. Game completeness & "flow vibes"

• Many deity arcade games are still stubs or not built at all; finish the missing games so every deity has a playable experience.
• Audit existing games for smoothness: consistent spawn cadence, no jitter, no early despawn, fair difficulty curves, and a calm "flow" feel rather than chaotic mechanics.
• Make sure each game teaches its content (mantra/chalisa lines) without frustrating the player.
• Learn-it-for-life pass (all 19 games + chalisa game): every mantra/name/verse riding a drop should carry a short plain-English meaning (line-by-line glossary like Shani L2/L4/L5 now has), so the knowledge is retained outside the app.
• Adaptive catch zones: make the catch/patience band breathe with combo, boons and lives in every game (done for Shani) so flow is rewarded and pressure is felt without chaos.
• Level-6 chalisa audit: verify every deity game keeps spawning verses across rounds 2 and 3 (Ganesha bug: caught verses were permanently removed from the queue — fixed).
• Completion gating audit: no level should complete before its artifact minimums are met (Shani L3 fixed); re-check the other games' queue levels.
  • Match Hanuman's depth everywhere: Hanuman now has bonus levels (Bhimrupi Maruti Stotra, Panchmukhi Hanuman Kavach, Hanuman Bahuk) and an optional Aarti after the Chalisa. Bring the same pattern to every other deity game: bonus stotras/kavachs/stutis where they exist, an Aarti toggle on the Chalisa level, and line-by-line meaning support for the extra content.
  • BUG — mantra bars don't fill on hold (Hanuman, likely all games): holding a finger on/over a falling mantra does not load its progress bar, and hands-free/no-touch proximity loading also misses often. Only tapping works reliably. Needs a proper rework of the hold/proximity capture: continuous pointer tracking (pointermove + pointer stays down), hit box from the real rendered pill width and wrapped height, tolerance for the avatar lagging behind the finger, and a fill that keeps progressing while the pointer stays within the band. Fix once, roll out to all 19 games + the chalisa game.
  • Recitation flow is the core quality bar: how a mantra rides in, is held, fills, and resolves must feel meditative and smooth — steady cadence, eased motion, no jumping/snapping, no abrupt freezes, forgiving capture. This applies to every game; the exact tuning differs per game because each has its own mechanic (catch, glide, queue, endless), but the felt rhythm must be the same: calm, unhurried, and supportive of actual recitation rather than reflex play.
  • Sound mode is not working well in any game: audio cues, background beats, and recitation feedback are either missing, out of sync, or unreliable across the arcade. Define a single audio layer (Web Audio API + preloaded loops/samples) that every game shares: consistent background beat, mantra-spawn chime, successful-capture tone, level-complete/transition sound, and optional voice hint. Make it easy to mute, adjust volume, and pick a beat per game. This is part of the calm recitation flow — sound should support meditation, not add stress.

F2. Build library — reusable level & tool modules

Catalogue now written up in docs/level-blueprints.md (ids 1–7 core spine, 31+ bonus, 51+ business). Per-deity content schema, offline prompt and the 19-deity checklist live in docs/deity-content-template.md. Exact per-level content amounts (how many names, lines, mantras each level needs) live in docs/game-content-spec.md. Build the engine against those docs.

Goal: stop hand-coding each level or screen. Turn the proven ChalisaVibe modules into a numbered catalogue of reusable "builds" that any remix — deity game, Brand Arcade, martial-arts course, etc. — can pick from by id.

• Concept: each build is a small config object describing how a module works, not what content it shows. Content is injected separately. A finished app becomes a checklist of build ids.
• Game level blueprints (the original focus):
  • id, name, kind (single-mantra / name-list / ordered-verses / picker-rounds / kavach-short-loop / chalisa+aarti / endless-weighted), roundsPicker (e.g. 3/11/21/108 or 1×/2×/3×), completionRule (artifact minimums, full-cycle bead award), spawnCadence + speed curve, catchBandRule (adaptive zone), hazardProfile, meaningSupport (line-by-line glossary on/off), weighting (for endless pools).
  • Catalogue seeded from Hanuman: L1 single core mantra, L2 12-names with 3/11/21/108 picker, L3 108 names, L4 multi-select protective-mantra picker with full 108-bead rounds, L5 Gāyatrī, L6 Chalisa + optional Aarti (1×/2×/3×), L7 endless weighted pool, Bonus A short kavach loop (3×/11×/21×), Bonus B long stotra, Bonus C bahuk.
• Practice / recitation builds (not games, but equally reusable):
  • Mala counter with preset beads + manual/advance modes.
  • Teleprompter / chalisa reader with language toggle and auto-scroll.
  • Hands-free flow builder (mantras + chalisas + intention).
  • Audio listen mode (when J lands).
• Calendar / wisdom builds:
  • Panchang + sunrise boundary.
  • Daily deity focus.
  • Intent planner / "rate a specific day".
  • Transit highlights.
• Files (when built): src/builds/*.ts (the catalogue), src/builds/build-level.ts / src/builds/build-practice.ts / src/builds/build-calendar.ts (blueprint + content → runtime module), and each remix route reduced to a content file + a list of build ids.
• Future builder tool: a config UI (or JSON/YAML manifest) where the owner ticks which builds to include, e.g. builds: ["daily-deity", "mala", "teleprompter", "game-l1", "game-l2", "game-l6"]. New apps = pick builds + provide content, no gameplay code.
• Business reuse: Brand Arcade brand configs pick the same blueprint ids; products/phrases replace mantras/verses. A new client game = one content file
  • levels: [ids], no gameplay code.

F3. Doing this cheaply (token/credit strategy)

How to roll the Hanuman structure out to the other 18 games without burning credits.

1. Extract once, reuse forever. One paid refactor turns Hanuman's level logic into the blueprint engine above. After that each new game is a data file, which is cheap to generate and cheap to review.
2. Content written outside Lovable. Use Gemini Advanced / ChatGPT to produce the per-deity content files (names, verses, stotras, meanings) against a fixed schema, then paste them in. Same approach as docs/brand-arcade-playbook.md.
3. A content template doc: docs/deity-content-template.md with the exact TS shape
   • the prompt to fill it, so no back-and-forth is needed in chat.
4. Batch by two or three deities per message, never "do all 19" in one go — smaller diffs, fewer retries.
5. Never re-explain gameplay rules in chat — they live in docs/game-rules.md and the blueprint catalogue; reference them by id.

F4. Bonus-level content audit (research task — do NOT run in Lovable)

• Produce, offline, a table of all 19 deities × available authentic extra texts: stotra / kavach / stuti / ashtakam / bahuk-equivalent / aarti, with source and a note on length (short loop vs long verse set).
• Mark which deities genuinely have such texts and which should instead get an extra names-level or a second chalisa/aarti build.
• Result feeds straight into F2 as levels: [ids] per deity — no exploration cost inside the app.

F5. Game flow / playlist — play several games & levels in a row

Same idea as the hands-free chalisa+mantra flow builder, but for games. Long-term: build it AFTER the F2 blueprint engine lands, otherwise every one of the 19 games has its own bespoke level state and the flow runner would have to be hand-wired per game (expensive, fragile, and it would have to be rewritten anyway once F2 exists).

• User story: pick a list like Ganesha L2 ×11 · Hanuman L3 ×2 · Bhairav L4 ×21, press play, and move from one entry to the next without leaving the arcade.
• Builder UI: a "Quick build game flow" section on the games hub — a single checklist across all deities and levels, each row with its rounds picker (3 / 11 / 21 / 108 or 1× / 2× / 3×), reorderable, savable as a named flow (mirrors mantra builds in the profile).
• Runner: one GameFlowSession component holding the queue, mounting each level via the blueprint engine, showing step x/y, and handing over on level completion — the game equivalent of FlowSession in src/components/chants/flow-session.tsx.
• Requirements from F2: every level must be declarable as { deity, levelId, rounds } and every level must report a clean "completed" event; no game may own its own navigation on completion.
• Persistence: resume an unfinished game flow (24h TTL) exactly like the gathered practice flow; saved flows live with the user's builds so they are ready at login.
• Reuse: Brand Arcade campaigns get the same runner — a client campaign becomes a saved flow of blueprint ids with reward ladders attached.
• Decision: do not attempt a partial version now; a half-working flow that drops progress mid-session would feel worse than stopping between games.

G. Mini-app / white-label template (point 8 — after core features)

• Keep the idea of reusing this app's engine for small devotional apps (e.g. Yakushi Nyorai, Guru Senge Dradok) and non-devotional remixes (e.g. martial-arts course).
• Defer until auto-scroll, voice navigation, and mini-games are polished and feel reliable.
• Goal: a config-driven shell where only content (deity info, core mantras, game asset) changes.
• Uses the F2 build library: a new remix is a JSON/YAML manifest that selects which builds (calendar, mala, teleprompter, game levels, etc.) to include and swaps in its own content file.

H. Chalisa quality & multi-language support (point 9)

• Continuously review all chalisa translations so they are literal, respectful, and free of interpretive fluff.
• Fix reported verses first (Durga v3, Shiva v4/v27, Radha v8, Annapurna, Dhanvantari v5, etc.), then do a full pass.
• Structure the text data so adding more languages (Hindi, Sanskrit transliterations, regional languages) is straightforward later.

I. User-friendliness & hands-free practice

• Auto-scroll and voice-followed recitation so the user never has to touch the screen while chanting.
• Voice navigation throughout the app: "bring forth the Lakshmi Chalisa", "start 108 Gayatri", "what is good today?".
• Hands-free mala counting: the mala counter advances automatically as the user recites each mantra (mic or speech-to-text), useful while cooking, walking, etc.
• Simplify the Calendar / Intent Planner further so the many variables feel structured and not overwhelming.

J. Audio: chalisa & mantra recitations + practice beats (long-term)

• Listen mode for every chalisa: ~3 audio variations per chalisa so the user can choose a voice/style — e.g. (1) slow learning pace with clear articulation, (2) traditional devotional rendition, (3) fast/flow pace for daily japa. Player sits in the chalisa reader next to the manual scroll.
• Mantra audio: each core mantra (Gayatri, Mahamrityunjaya, bija mantras, intent mantras) gets at least one clean loopable recitation, ideally 2–3 tempos so users can chant along at their own speed.
• Practice beats / background music: a small library of high-quality loops to recite over — tanpura drone, soft mridangam/tabla cycles, ambient temple bells, silence-friendly low drone. Independent volume slider so voice + beat can be mixed; beat keeps playing across screens (mala counter, games).
• Integration points:
  • Chalisa reader: play / pause / speed, optional loop count tied to the recitation logger.
  • Mala counter: beat plays in the background; long-press to switch loop.
  • Profile → Settings: default beat, default recitation voice, autoplay on/off.
• Sourcing: prefer licensed/original recordings by a real reciter for the chalisas (authenticity matters); instrumental beats can be generated or licensed. Store as audio assets + a metadata table (deity slug, variant, tempo, duration, reciter, license).
• Acceptance bar: audio must never feel synthetic or disrespectful; wrong pronunciation is worse than no audio.

K. Brand Arcade — business templates program (deferred until a client is paying)

Paused for cost reasons. The Aqwa showcase proves the concept; everything below is commercialisation work, to be built when a real business signs up. Design notes live in docs/brand-arcade.md.

• Playbook + config tool (next concrete step): docs/brand-arcade-playbook.md holds the intake form, the Gemini Advanced prompts for all copy/config writing (so no credits are spent here), the single-game decision (Hanuman-style catch, levels 1–3 + endless), and the two remix paths. First build: a /brands/new client-side form (products → give-away value → theme → export config file) on top of the existing buildLadder() maths.

• Finished vertical templates: polish ready-to-sell templates per vertical (CBD/cosmetics, water/home, sports nutrition) so onboarding a new business = copy template + fill one config file. Each brand keeps a design.prompt mirroring the client's real website so the game feels native to their brand, with buffs = their products and hazards = the problems they solve.

• Campaign cycles tied to discount periods: a campaign layer on top of a brand config — Black Friday, Christmas, birthday sale, summer sale. Each campaign has start/end dates, its own reward ladder + giveaway pool, themed visuals, and a leaderboard reset. The game auto-switches by date, so a new sales period needs no code change or deploy.

• Giveaway engine: each campaign cycle ends with a draw where top-leaderboard players and/or code holders win free products (all pre-checked against the CAC guardrail). The draw is the retention hook that brings customers back for the next cycle.

• Subscription pricing model: one-time setup fee per brand (template + design + products)

  • monthly subscription (hosting, leaderboard, N campaigns/year, N content updates, analytics).

• Deployment architecture options (choose per client):

  1. Standalone white-label app + custom domain — e.g. play.aqwa.dk or aqwa-game.com. Fully branded, no code on the client's site, best as a premium tier. Higher setup fee because it needs DNS, SSL and a per-client deploy (or multi-tenant routing).
  2. Embeddable SaaS widget — a <script> / iframe the client drops on their existing site. Quickest to sell, one engine serves many brands, campaign updates happen centrally. Best for first pilots and low-friction onboarding.
  3. Platform / marketplace integration — Shopify app, WooCommerce plugin, or similar. Lives inside the merchant's admin and auto-syncs products + discount codes. Most engineering work; build only when several clients on the same platform demand it. Recommended go-to-market order: widget first (fastest proof), then standalone (premium clients), then platform integrations (scale).

• Maintenance model — three stages, build only as revenue justifies:

  1. Prompt library (start): brand intake questionnaire + ready-made update prompts, so any client change ("new product", "new sale dates", "new offer") is a 5-minute AI-assisted edit of one config file. No client tooling; the owner needs no coding skill.
  2. Self-serve admin (once subscribed clients ask): products, phrases and campaign dates move to database tables + a validated brand-admin form with preview. Clients update their own content; the engine stays under our control.
  3. Multi-tenant SaaS (only at scale): per-brand logins, RLS, billing, Shopify/WooCommerce sync so new products and sales import automatically.

L. India customer-retention subscription (ChalisaVibe × Brand Arcade)

• Idea: once both ChalisaVibe and Brand Arcade are running, offer a subscription plan to Indian businesses so they can use devotional daily practice as a customer-retention channel.
• Why it works in India: the deities stay relevant because most Indians already know them and practise on specific days anyway; the app becomes a familiar, culturally native engagement surface rather than a foreign-looking loyalty gimmick.
• Core value prop: merchants get a white-label or co-branded daily engagement tool — daily deity focus, recommended chalisas/mantras, mini-games, and a sacred-calendar feed — that brings customers back every day without discounting.
• Retention mechanics to include: daily deity check-ins, streaks, 108-recitation milestones, avatar frames, weekly practice recap, festival/special-day notifications tied to the business's own campaigns.
• Business model options to explore:
  1. SaaS monthly per location/store — e.g. gyms, yoga studios, ayurveda clinics, temples, spiritual shops.
  2. Per-customer active-user fee — lower entry cost, scales with real engagement.
  3. Bundled with Brand Arcade campaigns — the devotional layer becomes the "off-season" retention engine between sales campaigns.
• First validation step: identify 3–5 Indian business verticals where daily spiritual engagement fits naturally (wellness, food/grocery, fitness, education/coaching, retail) and draft a one-page offer before building any tooling.
• Open question: should the Indian version be a separate app/brand, or a configurable skin of ChalisaVibe with business-specific rewards?

M. Deity roster expansion & inclusion criteria

• Maintain a running list of deities to add beyond the current 19, with a short note on why each is relevant and what content already exists (e.g. chalisa, stotra, kavach, aarti, 108 names).
• Candidates to evaluate (not all will be included):
  • Venkateshwara / Balaji — very popular daily deity, widely chanted.
  • Sai Baba — universal devotion, many chants available.
  • Khatu Shyam — rising popularity, especially in North India.
  • Vishnu / Narayana — broad Vaishnava base, overlaps with Rama/Krishna but distinct.
  • Narasimha — protective avatar, strong protective-mantra slot.
  • Vamana / Varaha / Kurma / Matsya — avatars; only include if distinct chalisa/stotra exists.
  • Tulsi — plant deity, daily worship, fits wellness/herb angle.
  • Bajrangbali — essentially Hanuman, already covered.
  • Santoshi Mata — popular Friday fast/deity.
  • Chamunda / Bagalamukhi / Dhumavati — fierce forms; evaluate carefully against the app's calm, respectful tone (Kali was removed for this reason).
  • Mahalakshmi / Ashta-Lakshmi — distinct from Lakshmi, wealth/abundance focus.
  • Kaal Bhairav — overlaps with Bhairav; decide if separate or merged.
  • Vastu Purusha / Vishwakarma — home/craft deities, possible business angle.
• Inclusion rules:
  1. Must have authentic, respectful source material (chalisa, stotra, or well-known names).
  2. Must fit the app's calm, devotional tone — no frightening or aggressive imagery.
  3. Must have enough content for at least the core spine (L1, L2, L6) or a clear reason to be a single-practice deity.
  4. Prefer deities with existing daily practice (e.g. Tuesday Hanuman, Saturday Shani) so the calendar integration makes sense.
• Output: a short docs/deity-roster.md with the evaluated list, final yes/no/maybe, and the content needed for each "yes".

Recently completed

Car-screen mode (investigation, not yet built)

Goal: passengers recite chalisas/mantras and play ChalisaVibe games together on a car's centre screen (Tesla, Skoda/VW, etc.), with or against each other.

What is actually possible today:

• Tesla (best target). Chromium-based built-in browser; ChalisaVibe already loads as a normal website. Games and teleprompter run only while parked (Tesla blocks browser/ Theater content in drive). No app store needed — a QR code or short URL is enough.
• Android Automotive OS (Volvo, Polestar, Renault, GM, some VW group): real Play Store, and Google now allows a "parked games" category. Would need a packaged app (TWA/WebView wrapper) plus car-app policy review. Realistic phase 2.
• Skoda/VW MIB3 "In-Car Apps": closed catalogue, no open browser or third-party games. Not viable without a VW partnership.
• CarPlay / Android Auto (phone-projected): template-restricted to media, navigation and messaging. Custom UI and games are not permitted. A ChalisaVibe audio-only experience (chalisa/mantra playback as a media app) is the only route here — and is a good idea on its own.

Proposed build order:

1. /car route — landscape-first, huge type, minimum taps, only three actions: Recite (teleprompter), Chant (auto-mala), Play. Parked-use disclaimer on entry.
2. Local multiplayer on one screen: 2–4 player hot-seat / split-screen scoring for the arcade games, plus a shared "family session" recitation counter.
3. Audio-first media mode for CarPlay/Android Auto (chalisa audio + mantra loops).
4. Android Automotive packaged build once the /car experience proves itself.

Safety rule for all of the above: driver-facing interaction stays audio-only; visual game and verse UI requires the vehicle to be parked.

• [x] Intentions (sankalpa): chart/transit-derived + classic + personal, saved library, shown in the chalisa page and hands-free mode
• [x] Session plan screen before a hands-free flow starts (exact order preserved, intention shown)
• [x] Hands-free teleprompter recitation (one verse at a time, paced, wake-lock, auto-logs) + favourites chain + in-mode voice commands
• [x] Badge achievement dates + "Recently achieved" list (Profile → Badges)
• [x] 6-month practice heatmap in recitation history
• [x] Calendar reorganised into Today / Month / Plan / Cosmos tabs
• [x] Mala counter persistence + 108 preset fix
• [x] Recitation totals beyond 1000 rows

Queued (waiting on credits)

• [ ] Show per-name English meanings in Level 2 (name list) and Level 3 (108 names) of every deity game — Shani's level 2 already does this and it should be the standard. Needs: meaning strings alongside each name in the src/data/*-names.ts files (and the level-2 short-name pools), plus the falling-pill / lesson UI showing the meaning under the transliteration.

Live transit alerts (queued)

Goal: hourly-precision phone notifications when the sky touches the user's natal chart, with a one-tap "recite now" deep link.

• Scan engine: extend src/lib/transit-events.ts with a transitPeaksForWindow(from, to, birth) that samples every ~10 min (Moon needs it) and returns exact-orb peaks, not just day snapshots.
• Alert rules: fire ~15 min before peak; filter by strength (reuse the existing min-strength slider); cap to N/day; respect quiet hours in use-notifications.ts.
• Deity routing: peak planet → DEITY_PLANET → chalisa; multi-planet peaks → Navagraha.
• Delivery: phase 1 = local scheduling in the existing notification service worker while the app has been opened that day; phase 2 = real push (Web Push subscription stored in Cloud + a cron /api/public/* route that computes peaks server-side per subscriber).
• Prefs: new toggles — "Moon aspects (hourly)", "Slow-planet peaks", "Lead time 5/15/30 min", "Min strength".