"When something important is broken and you can help, you help."David Lennard, Founder
Why the database matters in this architecture
The database acts as the system-of-record for canonical identity, consent state, reset authority, ledger-backed rewards, public-intake writes, and audit evidence. That gives the application one authoritative source for critical state and makes regression analysis more reliable because routes, policies, migrations, and table state can be checked against the same model.
Why Supabase was chosen for these services
Supabase was the pragmatic fit because it combines managed Postgres, Auth, storage, row-level security, and SQL-native migrations in one stack. That matches why industry reviews tend to rate it well for product teams that need fast delivery without giving up database transparency, operational control, or a clean audit trail.
Why this Project
Why this project
A few people have asked why I'd give up what little time I had for this project. This background is only a fraction of the story, but it explains why I made that choice. I assume most people in their position would have responded the same way.
When something important is broken and you can help, you help.
The collapse
One of the first major challenges I had to overcome was the sudden loss of a large sum through a number of real estate transactions when the market was low, but my responsibilities to contractors were high. Shortly afterwards I came down with cancer, just two weeks after a health insurance policy had lapsed. That finished me off. By the time I finally got out of bed eight months later, the COVID lockdowns had begun, and I've remained largely isolated ever since - and COVID free, for what it's worth.
Other than some sales of my photography in the Web3 space and some private client work, I've had no real income since I was hospitalized in 2019. The timing could not have been worse. Rehab started under those conditions, and I made it to one physical therapy session where the provider told me I might never be able to raise my arms again and would need to begin with three months of hydrotherapy. The drive home was painful physically and emotionally, and I knew immediately I was in serious trouble.
The choice
At that point I was faced with another hard choice. One option was to take a risk on COVID, transfer my real estate license to Sedona, and use that income to try to bring my food project to market, a path that would have required a $26 million seed raise and a two-year buildout. The other was to find something less demanding that could still produce meaningful social impact. I chose the latter, and CareHub is the output.
The founder story video on the website gives you the polished side of things, but the hard truth is I've been homeless since October 2022. I've spent bitter winters and scorching summers camping in the desert, lived for three months in a shed, a year living in an insect-infested slum in Arizona's fentanyl capital, and periods where the sale of camera equipment, artwork or my vehicle kept a roof over my head for a while. In all I've moved over 35 times.
What came next
A little later I started investigating AI from every angle I could find: cancer, clinical trial databases, tokenization, sources of truth, storytelling, cinematography, mental health, and end of life. The list kept growing. When I moved out of the shed and canceled home hospice, I began using LLMs (large language models) to do the legwork, with Google NotebookLM as the organizational tool.
Key to using LLMs effectively is no different from knowing how to use a camera, drive a car, scramble eggs, or not catch COVID.
- Define the objective properly - the specification.
- Use logic with traditional research methods to understand the steps needed to achieve the objective.
- Know what questions to ask.
- RTFM. Read the manual.
After about a year of attending Twitter spaces on AI Alpha and Art, chaired by Robert (Rob) Stratton (@madbutter), I was convinced I'd found a key that could unlock real opportunity for cancer patients, caregivers, and science. The next step was to work out how to reduce government obstruction where it's doing the most harm and build something from the ground up.
Why I stayed with it
When I saw the lights in my hospital room at the beginning of this journey, I had a split-second decision to make: let go and the pain would be over, or fight back and find some purpose in life that could benefit society. I chose to fight, fully aware I had an insurance problem, a horrid cancer, and that a bad set of blood tests could change everything at any time.
A great deal of the grit behind that decision comes from seeing, at close range, patterns of malignant narcissism and predatory behavior in my family that were the exact opposite of everything my education taught me was decent or constructive. I moved to Australia in 1989 to get away from that world rather than join it.
The battle between homelessness, hunger, jawbone necrosis, no family support, a close friend dying from cancer, and my own cancer journey has been grueling. The constant daily worry about where the next meal is coming from, whether I have a bed for the night, or can pay for the project hosting, coding or my prescription costs, is exhausting.
My Prognosis
Where things stand
I'm still in remission, but I haven't focused on my health nearly enough, and that needs to change. Just over a week ago my left mandible flared up. We won't know whether necrosis has started to attack that side until I get a scan.
Covering project overhead before nutrition has also seen me lose 20 lbs since my last oncology visit. I need to take a short break, get to a dentist and the oral surgeon, put some weight back on, and get some sleep.
Get a Second Opinion
Before I was hospitalized with multiple myeloma, the bone pain was so bad that I begged my oncologist to put me on lenalidomide and prescribe something for the pain. He flatly refused. Several weeks later I was almost dead and riddled with fractures.
I spoke with an attorney friend of mine who told me I'd be wasting my time suing. Without children and at almost 60 years old at the time, it meant my life wasn't considered to have much value to society, and the other side would likely send me broke before the case was ever heard.
That same provider also put me on Zometa, a bone-strengthening drug, and never cautioned me about the side effects. This is why I have jawbone necrosis. When I saw my new oncologist in Tucson, I mentioned the pain in my left mandible, the history, and the fact that I had never been advised of the potential risks. He told me I absolutely have a case.
Over the course of treatment, the original file of roughly 1000 pages has shrunk to three as I've moved around. I have a full set of records on the way from Honor Health.
Homelessness
What's been humbling is how people have helped me. A ride to chemo, grocery store and pharmacy runs, a hot meal now and then, and some good friendships. These have all been salt of the earth people. Living at or below the poverty line. No airs or graces. Strong families, mostly, and not a nasty bone in their bodies. Three of them are featured on the website in the founder story section.
Personal Needs
The Bulk Of The Work Is Done
CareHub is a working platform, the Vitals Tracking system is up and running, and specialty areas are in beta testing right now. The documentation, business model, and technology are complete. I just need runway to get it across the finish line.
Continuation Plan
There are two viable paths from here: stabilise my health and continue building, or fund a clean handoff.
| Continuation | Best guess for a six month period is $30,000, to cover dental repairs, food and shelter and, keep core services connected, and create short recovery runway. |
|---|---|
| Handoff | $5,500 to clear back rent, purchase 3 sets of ssd's for Next.js app disaster recovery, supabase schema and adatabase. |
Continuation Plan
Where it goes
- Rent: $1,800
- Dental out-of-pocket estimate: $450
- Nutrition and supplements: $600/month
- Phone/internet: $200/month
- Platform hosting and subscriptions: $400/month
- Part-time staff hours: $600/month
- Legal/insurance: $400/month
- Development computer replacement. Current device is on loan. (one-time): $6,000
On the continuation path, the goal is straightforward: restore housing, food, communications, and enough breathing room to focus on treatment and restart income generation. The immediate priority is Alzheimer's and Medicare work, where the market is large and payments are reliable.
On the handoff path, the remaining work is operational rather than conceptual. I can populate the crowdsource page with coding jobs, let the language audit continue until the i18 system has two matching native translations, and hand over the project with the existing documentation and anti-regression protocols intact.
Social media presence and marketing still need attention a couple of days a week. That work is already accounted for in cashflow and the white paper; it simply has not yet been staffed.
| Food and shelter | Basic stability so the work does not collapse between treatment cycles and funding gaps |
|---|---|
| Emergency medical and dental costs | Shorten the gap between urgent need and actual care |
| Transport and communications | Keep treatment access, product work, and partner conversations moving |
| Recovery runway | Buy time for the founder to keep building rather than triaging crisis alone |
| Bitcoin | 333EHrn9stTF6K9wfHXsQxoiTbSx7F1TEc |
|---|---|
| Ethereum | 0xA73473137f0A40f1B90280e30999b13B7A460C66 |
| USDC (ERC-20) | 0x6DC2D4B043CE0963556cA5a44E96993a3C79aACF |
| Solana | FybJfNziQLn2GxP7Tg6G42wyVyN8y3CWAHzqF6gTKJ5a |
| Tezos | tz1TALzNAWtovfUTwQA4U6k6xzqNWuasDWY9 |
| PayPal | paypal.me/DavidLennard301 |
| GoFundMe | gofund.me/289d5f9c1 |
CareHub Needs
Simply put, if we remove David from the equation, what needs to happen for CareHub to remain stable and continue building.
Operational continuity
| Platform continuity | Hosting, storage, subscriptions, core tooling, coding support, QA, and the operational work needed to keep the site, app, and language audit moving without regression |
|---|---|
| Documentation and handoff | The documentation, packaging, and transfer work needed so the system can continue under direction or be passed on cleanly if that becomes the prudent path |
Key Personnel
| Founder tiers | CareHub uses a four-tier founder structure: Principal Founder, Core Co-Founders, Founding Council, and Honorary Founders. It is designed to balance significant commitment with accessible entry points while maintaining mission alignment. |
|---|---|
| Ambassador role and low-risk entry | The ambassador program is integral to global user and enterprise growth. Filling one role early gives us a low-risk way to refine the job specification and KPIs before rolling the program out in other regions. A sensible early candidate might be a social worker who has been pushed out of an oncology group or government agency and already understands the real-world failure points in care delivery. |
| Social Media and Web Asst. | Social media management, light web support, and regression analysis are serious ongoing responsibilities. This role may be best handled by a freelance creator or operator who knows the ropes and can follow instructions precisely. |
Where specialist attention matters most
| Engineering review | Review architecture, tighten implementation, remove friction, and catch weak points before they become production problems |
|---|---|
| UI and UX | Refine flow, hierarchy, and interaction quality so the product feels clear, calm, and dependable rather than improvised |
| Performance, QA, security | Stabilise core flows, reduce regressions, harden the product, and make sure it holds up under real use |
| Accessibility and clinical logic | Improve clarity, safety, and usability for patients, caregivers, and healthcare-facing workflows |
Where everyone can participate
| Usability feedback | Clear notes about anything confusing, slow, ugly, or unnecessary |
|---|---|
| Language and content | Language review, content checks, and straight patient or caregiver feedback on what reads clearly and what does not |
| Walkthrough testing | Walkthrough testing, bug reports, and edge-case spotting during the final build |
The standard
| Product standard | CareHub needs to feel clear, calm, fast, and trustworthy, with enough polish and stability to look and run like a Rolls-Royce rather than a prototype |
|---|
Twitter/X - the biggest issue at hand
| X account | My Twitter account was hacked on March 15. I have been a member since 2008, and it holds 108,000 posts about my cancer journey, nature therapy, purpose, photography, and the beginnings of the CareHub project. It also contains bookmarked Twitter spaces, business-related direct messages, and 238 global contacts primed for the CareApp presentation. |
|---|---|
| Support loop | I have followed the support protocol and it is just a loop. There are no humans to talk to. The last communication asked me to prove who I am by giving them my email address, which I did, and got nowhere. The account was then shut down completely, only to reappear as @Dlennard instead of @dlennard. It looks like a parked account. |
| Proof in hand | I have a piece of jawbone in a jar, a scan of my jaw, the bank statement showing they charged me again, and all the original images and video footage that have been posted, including the CareHub logo. I still believe this can be resolved if the right person sees the record. |
| What I need help with | Someone at X who can get this sorted out, or clear guidance on the next prudent step while all records are kept in place. |
Close-Out Status
Code-side hardening for the audited auth, rewards, public-intake, and analytics surfaces is complete in this repo. This handoff reflects the live code path after the canonical-login and reset-flow cleanup completed in this pass.
Scope
Current CH Next.js repo only. The core result is that canonical identity now resolves through users.id aligned to auth.users.id, the reset path is normalized, public intake writes are server-owned, and the regular-user token view is ledger-backed.
Expected residual risk
Once the remaining live deploy and SQL steps are confirmed, the expected audit outcome is a single residual warning: leaked-password protection remains disabled by operational choice for later expert review.
| Pending live verification after deployment | Why it matters |
|---|---|
Deploy the updated app so POST /api/analytics/page-visit is live |
Closes the last browser-direct analytics write path |
Ensure the updated static davidlennard-com/bug-report.html is synced |
Moves public bug intake onto the server-owned API path |
Run supabase/migrations/20260523_bug_report_policy_and_storage_listing_lockdown.sql |
Retires the broad bug-report insert path and the bucket-listing exposure |
Run supabase/migrations/20260523_public_intake_and_page_visit_rls_lockdown.sql |
Removes the remaining permissive insert warnings from the audit surface |
| Rerun the Supabase audit | Confirms the repo-side remediation matches the live system state |
Static / Public Sync
The public sync in this pass also cleaned up the live crowdsource handoff so the static site now points to the real Language Beta surface.
| Surface | Current live destination | What changed |
|---|---|---|
davidlennard-com/crowdsource-grid.html |
https://app.carehub.davidlennard.com/translate | The older static /beta-testing handoff was retired in this pass |
| Canonical new-user onboarding | /forms/early-adopters |
Unchanged. Live Language Beta and canonical onboarding remain deliberately separate |
Findings First
- Canonical app identity is now
users.id. Login authenticates against Supabase Auth first, then refuses to mint an app JWT unless the authenticated Supabase user maps to the same canonicalusers.id. - Compatibility lookups still exist, but only as decoration.
admin_access_codes,admin_source_codes, andbeta_invitesremain metadata sources only and no longer function as primary app identity. - The active regular-user onboarding flow is
forms/early-adopters. The older staged modal chain still exists in the repo, but it is now a compatibility and dead-end surface rather than the canonical registration route. - Password reset is now one flow. The live route is
/auth/reset-password, backed by/api/auth/forgot-passwordand/api/auth/reset-password, with the older token handler reduced to a re-export. - Rewards now separate regular-user ledger balance from beta/module metadata. The canonical regular-user rewards ledger lives in
user_token_accountsanduser_token_events; legacy snapshot fields remain compatibility-only. - Beta runtime APIs now enforce canonical request-user identity. The product gate is paused, but the audited beta feedback, signoff, complete, and progress routes now resolve identity server-side.
- Token-ledger DB exposure is closed at the server-only boundary. Service-role-only policy coverage now matches the current server-owned access model.
- One material security gap remains outside this pass.
src/lib/authJwt.tsstill falls back to a hardcoded default ifJWT_SECRETis unset, which leaves a deployment/configuration risk for decision-makers.
Architecture And Schema
| Layer | File(s) | Current role |
|---|---|---|
| Browser Supabase client | src/lib/supabaseClient.ts |
Browser-side Supabase access using the anon singleton |
| Server admin client | src/lib/supabase.ts |
Authoritative service-role DB access for API routes |
| App JWT layer | src/lib/authJwt.ts |
App session token used by AuthContext and custom app APIs |
| Canonical identity resolver | src/lib/authIdentity.ts |
Canonical users row resolution with compatibility metadata lookup |
| Surface | Primary tables / store | Current rule |
|---|---|---|
| Canonical user identity | users, auth.users |
users.id must match the Supabase Auth user id |
| Registration verification | verification_codes |
Used by the early-adopters verify step |
| Consent completion | consent_submissions, users.consent_accepted |
Active completion depends on consent, not NDA |
| Password reset | users.password_reset_token, users.password_reset_token_expires, auth.users |
One authoritative expiry path; older duplicate handler is now compatibility-only |
| Rewards ledger | user_token_accounts, user_token_events |
Canonical regular-user rewards data source |
Browser and static surfaces
- Login and reset surfaces
- Early-adopters onboarding
- Public beta-notify, collaborator, and bug-report intake
- Consented page analytics
Next.js API boundary
- Auth and onboarding APIs
- Rewards and account APIs
- Public intake APIs
- Analytics page-visit API
Supabase Auth and Postgres
auth.usersandusersverification_codes,consent_submissions,user_sessionsuser_token_accounts,user_token_eventspage_visits,beta_notify_submissions,collaborator_access_requests,bug_reports
Schema mind map
Security And Access Control
| Measure | Evidence | Current result |
|---|---|---|
| Supabase Auth password verification | src/pages/api/auth/login.ts |
Credentials are checked against Supabase Auth before app JWT minting |
| Canonical identity re-check on restore | src/pages/api/auth/verify.ts |
JWTs are rejected if decoded.userId no longer maps to a real canonical user row |
| One-hour reset tokens | src/pages/api/auth/forgot-password.ts, src/pages/api/auth/reset-password.ts |
Reset email and completion now share one authoritative expiry rule |
| Response security headers | src/middleware.ts |
CSP, COOP, COEP, HSTS, frame denial, referrer, and permissions policy are active in the repo |
| Service-role separation | src/lib/supabase.ts |
Sensitive DB access remains server-only behind the service-role client |
| Schedule item | Current state |
|---|---|
| Internal password screening | Now enforced consistently on the audited app paths, but still weaker than full leaked-password intelligence |
| Last three permissive insert policies | Code-complete and waiting on live deploy plus the public-intake / analytics lockdown migration |
| Bug-report closure | Prepared for closure; requires live static sync plus the matching migration rerun |
| Public bucket listing on bug screenshots | Prepared for closure; requires live SQL verification after deploy |
| Leaked-password protection | Still disabled by operational choice and remains the residual decision-maker item |
Web and App Domains
The public website and the live app are currently being hosted through the davidlennard.com domain family. In practice that means the website lives at davidlennard.com and the app lives at app.carehub.davidlennard.com. That arrangement is temporary while a final naming decision is made from the available domains.
My view is straightforward: CareHub is still CareHub. If the eventual domain is XYZ.com it will not change the underlying value equation by an iota, so I do not think it is worth spending a large sum of money chasing the perfect name. What matters more is landing on a decision, aligning the web and app surfaces behind it, and then moving on.
That said, this does need to be resolved soon. The current setup is workable, but it is still a founder-domain bridge rather than the long-term production answer. The sooner consensus is reached, the cleaner the trust, onboarding, and public handoff story becomes.
Current live addresses
- https://davidlennard.com/ for the public web experience.
- https://app.carehub.davidlennard.com/ for the live app homepage.
Modal Inventory And Flows
| Surface | Entry surface | API / data touch | Classification |
|---|---|---|---|
| Simple sign-in | Homepage derivatives, Community, Rewards, Crowdsource | POST /api/auth/login touching auth.users, users, and user_sessions |
Canonical |
| Reset request / reset completion | Direct route and emailed reset links | POST /api/auth/forgot-password and POST /api/auth/reset-password |
Canonical |
| Crowdsource waitlist chooser | Crowdsource hero CTA | Route push to /crowdsource/waitlist?category=... |
Canonical access gate |
| Beta / restricted gate | Research and other beta-flagged surfaces | POST /api/beta/notify when the notify form is submitted |
Canonical access gate |
| Onboarding teaser | Header, footer, calendar disclaimer, tracking dashboard | Delegates to the login modal or the waitlist-notify path | Canonical orchestration |
Modal_Waitlist, Modal_NDA, AuthFlow_DEPRECATED, Modal_17_admin_login |
Compatibility and disconnected surfaces only | Legacy assumptions, stubs, or parent-callback shells | Dead-end / misleading |
Flow A: canonical login and early-adopters registration
Existing users move through SimpleLoginModal to POST /api/auth/login, then restore through POST /api/auth/verify. New users go through /forms/early-adopters for start, verify, consent, completion, and only then transition into the canonical authenticated surfaces.
Flow B: restricted and beta-tinted path
Guests opening gated features are either routed into the crowdsource waitlist chooser, the restricted beta notify gate, or the broader onboarding teaser. The runtime beta APIs now derive identity server-side even while the product-level gate remains paused.
Deployment Checklist And Dead Ends
Deployment verification checklist
- App deploy live and
/api/analytics/page-visitreturns success from production - Static sync live and
davidlennard-com/bug-report.htmlposts to/api/bug-report/submit - Database migrations live for the bug-report and public-intake / page-visit lockdowns
- Supabase audit rerun confirms only the leaked-password warning remains
Dead ends, stubs, and misleading surfaces
AuthFlow_DEPRECATEDstill looks like a full auth flow but is not the canonical registration routeModal_NDAis real code but no longer part of active early-adopters onboardingModal_Waitlistremains a real component file without active current-page usageModal_17_admin_loginis an intentionally non-functional stubuseBetaProtectionsounds authoritative but is currently bypassed by a hardcoded disconnect flag
Brand and IP
The live brand and IP position is documented separately from the auth and schema work. The current handover source of truth is davidlennard-com/brand-grid.html, with a counsel-ready intake brief in davidlennard-com/legal/carehub-trademark-brief-2026-03-31.md. This section pulls the parts that matter for continuity, naming discipline, and trademark decision-making.
Current naming split
CareHub remains the umbrella / website / legal / trust layer. CareApp remains the app-facing product name. That split is already reflected in repo convention and should be preserved unless there is an explicit rebrand decision.
Protection posture
The current strategy is common law first: rely on live use, keep the mark family coherent, and escalate only where impersonation, fraud, or real patient harm appears. The intent is user safety and clarity, not aggressive brand policing.
| Mark / phrase | Current role | Handover note |
|---|---|---|
| CareHub | House mark for organization, website, trust, privacy, and mission copy | Keep as the umbrella brand across legal and public-trust surfaces |
| CareApp | Patient-facing app / product entry point | Do not collapse back into CareHub inside app-facing shell copy without a deliberate naming review |
| CareToken | Rewards / token reference | Treat as part of the active mark family if the token layer remains stable |
| Closing the Care Gap | Primary tagline | Use consistently as the signature slogan tied to the mission layer |
| Explore the Cure | Campaign / entry slogan | Still needs a decision on whether it stays campaign-only or becomes part of the protected mark set |
| ProviderConnect | Provider-side service reference | Needs an explicit decision on whether it is a real customer-facing mark or descriptive product language |
| Device / source | Current use | Why it matters in handover |
|---|---|---|
CH logo devicelegal/carehub-trademark-brief-2026-03-31.md |
Splash / flash entry experience and high-visibility hero mark | Candidate canonical device mark for counsel discussion and future registration sequencing |
Circular / command-center logo devicelegal/carehub-trademark-brief-2026-03-31.md |
Homepage sidebar / persistent shell brand lockup | Represents the live shell identity most users will actually see during navigation |
davidlennard-com/brand-grid.html |
Long-form strategy page for brand family, protection philosophy, and community rules | Best single reference for how the brand is meant to behave, not just how it looks |
CareHub device mark continuity
The CH logo device stays here at supporting scale because this handover is tracking mark continuity, not hero artwork. It remains the monogram from the trademark brief and should stay in scope for counsel review as a candidate canonical device mark.
The circular command-center logo belongs in the same review because it is the live shell lockup users see in persistent navigation. Device-mark decisions need to cover both the splash mark and the everyday shell mark.
Ask Rupert and trademark protection
Ask Rupert should be treated as the companion-facing mark inside the wider CareHub family. The avatar is the live identifier for the assistant surface and should be handled as part of that mark.
Trademark protection here is for preventing confusing or harmful imitation of the assistant lane, its identity, and its association with the wider CareHub trust surface. The handover priority is clear ownership, clear attribution, and less patient-risk confusion.
What outside parties can do
The working stance from the brand strategy page is permissive for discussion, screenshots, attribution, and genuinely helpful integrations. Official partnerships, commercial products using exact branding, or anything that risks confusion should still go through explicit permission.
What counsel still needs to settle
The open questions are filing order, whether both live logo devices should be protected now, whether ProviderConnect merits separate treatment, and whether Explore the Cure stays campaign-only or moves into the durable mark family.
i18Next translations
We chose i18Next first for strategic reasons. If translations become part of the product backbone, they need to sit on top of a stack with a credible future, a strong ecosystem, and a track record for continuity and quality. This was not just about making the current build work; it was about aligning with a translation system likely to keep delivering dependable support and good implementation standards over time.
Why we chose i18Next
That strategic choice also fit the way this product is built: static locale JSON, namespaced content loading, Next routing support, and typed translation generation all work in one stack without moving runtime copy into a separate database service. It gave us one canonical locale registry, one manifest/preload path, nested namespace support, and routing behavior that can stay explicit instead of guessing a language for the user. That kept translation work, audit tooling, and regression checks on one pipeline instead of splitting the product across multiple localization systems.
Current rollout state
The live registry currently tracks 114 known locales: 113 active runtime locales and 1 reserve locale held back until content and QA are ready. English is the baseline source lane. Active non-English locales stay amber until every word for that local has been translated. Reserve locales stay red so this handover does not overstate coverage.
The current reserve lane is Luba-Katanga (Tshiluba). It is listed below with a red status dot because it exists in the registry but is not part of the active rollout set.
| Language | Status | Language | Status |
|---|---|---|---|
| Afrikaans | In process | Amharic (አማርኛ) | In process |
| Arabic (العربية) | In process | Assamese (অসমীয়া) | In process |
| Azerbaijani (Azərbaycan) | In process | Belarusian (Беларуская) | In process |
| Bulgarian (Български) | In process | Bengali (বাংলা) | In process |
| Tibetan (བོད་སྐད་) | In process | Bosnian (Bosanski) | In process |
| Catalan (Català) | In process | Czech (Čeština) | In process |
| Welsh (Cymraeg) | In process | Danish (Dansk) | In process |
| German (Deutsch) | In process | Greek (Ελληνικά) | In process |
| English | Complete | Esperanto | In process |
| Spanish (Español) | Complete | Estonian (Eesti) | In process |
| Basque (Euskara) | In process | Persian (فارسی) | In process |
| Finnish (Suomi) | In process | Fijian (Vosa Vakaviti) | In process |
| French (Français) | Complete | Western Frisian (Frysk) | In process |
| Irish (Gaeilge) | In process | Scottish Gaelic (Gàidhlig) | In process |
| Galician (Galego) | In process | Guarani (Avañeʼẽ) | In process |
| Gujarati (ગુજરાતી) | In process | Hausa | In process |
| Hawaiian (ʻŌlelo Hawaiʻi) | In process | Hebrew (עברית) | In process |
| Hindi (हिन्दी) | In process | Croatian (Hrvatski) | In process |
| Hungarian (Magyar) | In process | Armenian (Հայերեն) | In process |
| Indonesian (Bahasa Indonesia) | In process | Igbo | In process |
| Icelandic (Íslenska) | In process | Italian (Italiano) | In process |
| Japanese (日本語) | In process | Georgian (ქართული) | In process |
| Kazakh (Қазақша) | In process | Kannada (ಕನ್ನಡ) | In process |
| Korean (한국어) | In process | Kashmiri (कॉशुर) | In process |
| Kyrgyz (Кыргызча) | In process | Latin (Latina) | In process |
| Luxembourgish (Lëtzebuergesch) | In process | Luganda | In process |
| Lingala (Lingála) | In process | Lao (ລາວ) | In process |
| Lithuanian (Lietuvių) | In process | Luba-Katanga (Tshiluba) | Not started |
| Latvian (Latviešu) | In process | Malagasy | In process |
| Māori (Te Reo Māori) | In process | Macedonian (Македонски) | In process |
| Malayalam (മലയാളം) | In process | Mongolian (Монгол) | In process |
| Marathi (मराठी) | In process | Malay (Bahasa Melayu) | In process |
| Maltese (Malti) | In process | Northern Ndebele (isiNdebele) | In process |
| Nepali (नेपाली) | In process | Dutch (Nederlands) | Complete |
| Norwegian (Norsk) | In process | Chichewa | In process |
| Occitan | In process | Oromo (Afaan Oromoo) | In process |
| Punjabi (ਪੰਜਾਬੀ) | In process | Polish (Polski) | In process |
| Pashto (پښتو) | In process | Portuguese (Português) | In process |
| Quechua (Runasimi) | In process | Kirundi (Ikirundi) | In process |
| Romanian (Română) | In process | Russian (Русский) | In process |
| Kinyarwanda (Ikinyarwanda) | In process | Sindhi (سنڌي) | In process |
| Slovak (Slovenčina) | In process | Slovenian (Slovenščina) | In process |
| Samoan (Gagana Sāmoa) | In process | Shona (chiShona) | In process |
| Somali (Soomaali) | In process | Albanian (Shqip) | In process |
| Serbian (Српски) | In process | Swati (SiSwati) | In process |
| Southern Sotho (Sesotho) | In process | Swedish (Svenska) | In process |
| Swahili (Kiswahili) | In process | Tamil (தமிழ்) | In process |
| Telugu (తెలుగు) | In process | Tajik (Тоҷикӣ) | In process |
| Thai (ไทย) | In process | Turkmen (Türkmen) | In process |
| Filipino (Tagalog) | In process | Tswana (Setswana) | In process |
| Tongan (Lea Fakatonga) | In process | Turkish (Türkçe) | In process |
| Tsonga (Xitsonga) | In process | Tahitian (Reo Tahiti) | In process |
| Ukrainian (Українська) | In process | Urdu (اردو) | In process |
| Uzbek (Oʻzbek) | In process | Venda (Tshivenḓa) | In process |
| Vietnamese (Tiếng Việt) | In process | Xhosa (isiXhosa) | In process |
| Yoruba (Yorùbá) | In process | Cantonese (粵語) | In process |
| Mandarin (中文) | In process | Zulu (isiZulu) | In process |
Screenshot Pack
Base viewport used: 1920x1080 against the live app on http://127.0.0.1:3000. The pack focuses on meaningful entry and gating states that could be captured truthfully without inventing user session data.
SimpleLoginModal
Intentionally excluded states
Authenticated rewards ledgers, token-backed snapshots, beta runtime progress states, real admin success paths, and the deprecated NDA-completion path were intentionally excluded because they either require real user data, truthful bearer context, or are no longer the canonical flow. The full exclusion list is preserved in assets/auth-handoff-2026-05-23/manifest.md.