LumisCare

LumisCare client project (beta)

Overview

Overview

Domain & Infrastructure

Deploy Method

Unknown — requires discovery

Architecture

Architecture

Technology Stack

Java Spring Boot, Mobile BFF, Web BFF

Infrastructure

To be documented: hosting environment, dependencies, integrations

Deployment Pipeline

Unknown — requires discovery

Dependencies

To be documented: external services, APIs, databases

Deploy Runbook

Deploy Runbook

Prerequisites

Deployment Steps

  1. Navigate to repo: cd ~/projects/client/lumiscare-beta
  2. Pull latest: git pull origin main
  3. Deploy: Unknown — requires discovery
  4. Verify: Check TBD

Rollback Procedure

  1. List deployments: vercel ls N/A
  2. Identify previous stable deployment ID
  3. Rollback: vercel rollback [deployment-url]

Common Issues

To be documented as issues are discovered

Current State

Current State

What Works

What Doesn't Work / Known Issues

Open Tasks

Last Verified

Date: 2026-04-15

Status: Initial documentation shell created

Changelog

Changelog

2026-04-15 — Documentation Shell Created

All significant deploys and changes should be logged here with date, description, and deploy ID.

LumisCare Privacy Terms Readiness Options — 2026-05-24

LumisCare Privacy/Terms readiness options

Date: 2026-05-24 Status: implementation drafted after CEO direction on 2026-05-24; final legal review still recommended before treating as full SaaS legal package.

Current live gap

landing/index.html footer currently renders:

Mail contact is verified separately, but Privacy/Terms remain unresolved public-readiness blockers because the public landing page promotes care-management software and repo documentation references regulated healthcare/care contexts.

Existing product/compliance context found in repo

Relevant repo context to review before approving legal pages:

These docs are product/engineering context only; they do not constitute approved public legal policy.

Decisions required before publishing final legal pages

Safe implementation options

Option A — Minimal blocker acknowledgement, no public legal pages yet

Keep Privacy/Terms as known blockers in readiness docs. Do not claim full public readiness.

Pros:

Cons:

Option B — Publish “review pending” placeholder pages

Create /privacy.html and /terms.html that clearly state legal documents are pending review and provide hello@lumiscare.com contact.

Pros:

Cons:

Option C — Publish approved marketing-site Privacy/Terms only

Legal/CEO approves narrow pages covering:

Pros:

Cons:

Option D — Publish full SaaS Privacy, Terms, DPA/BAA package

Pros:

Cons:

CEO direction received 2026-05-24

Implemented draft

Implemented narrow marketing-site pages:

The pages intentionally do not claim to be a full SaaS legal package, DPA, BAA, or customer contract. They cover the public marketing website and demo enquiries, and warn visitors not to send patient/care-recipient/PHI/sensitive care data by email.

  1. Confirm exact registered Snowit legal name, registration number, and address for formal insertion.
  2. Confirm cookie/analytics status if tracking is added later.
  3. Add full SaaS Terms, DPA, and BAA package before regulated production customer onboarding.

Deployment verification summary

LumisCare PR #2 legal pages deploy verification

Date: 2026-05-24 UTC

Merge/deploy

Evidence:

Live browser verification

Verdict: PASS

Verified on https://lumiscare.com:

Evidence:

Scope note

The published pages are narrow marketing-site Privacy Notice and Website Terms for demo/contact enquiries. They are not a full SaaS legal package, DPA, BAA, or regulated production customer contract set.

Runbook — LumisCare "Unable to load your account" (Entra B2B + JIT/DB mapping) — 2026-06-02

Runbook — LumisCare "Unable to load your account" (Entra B2B + JIT/DB user mapping)

Date: 2026-06-02 · Evidence: /tmp/evidence-session-fe5379ce/ · Env: ALAI demo (Azure tenant 3454a03f, rg-lumiscare-demo) · App: app.lumiscare.com, appId e422174a-24a6-4889-b66c-f6c483b8631f

Symptom

After login, the backoffice shows "Unable to load your account — We could not retrieve your user information." Rendered by frontend/packages/shared-ui/src/components/layout/AccountInfoLoader.tsx when the GET /users/about-me query (in useAccountStore.ts) errors.

Root cause (NOT a password problem)

A Microsoft Entra B2B / admin-consent / backend user-mapping problem. A logged-in guest (alem@alai.no, Entra OID f9275cf4-…) authenticated, but was not correctly provisioned/mapped to a LumisCare DB user + org, so /users/about-me could not return a usable account.

What is NOT the cause (verified, do not chase again)

Fix (live, in order)

  1. Entra B2B invite (re)issued for alem@alai.no — lumiscare-b2b-invite.json / alem-fresh-invite.txt.
  2. MSAL config confirmed correct for app.lumiscare.com — uat-login-diagnosis.md.
  3. Admin consent grant repaired for the LumisCare app:
    • scope: api openid profile offline_access, consentType=AllPrincipals
    • Grant ID: Tucgg8C0XUKt_DONAFF0Tk7nIIPAtF1CrfwzjQBRdE4
  4. Backend BFF/JIT + DB user mapping (the decisive step — frontend deploy/JIT merge alone was NOT enough):
    • alem@alai.no promoted directly in Postgres: DB id eccfeb0c-0b12-4439-9b99-33a12f9110c5, status ACTIVE, org f714cc2f-a0fc-4e47-9164-baa540fd820f (Sunshine Home Care LLC), role system_admin.
    • JWT linkage: Entra OID f9275cf4-… → DB user UUID (via JIT).
    • Backend revs: identity --0000008 (issuer URI + audience GUID match), web-bff --0000032 (audience-permissive + /users alias), Hibernate ddl-auto=update for schema drift.

Proof

Key lesson

For a new Entra guest, a frontend deploy / JIT merge is not sufficient. A working login requires the backend chain: Entra B2B membership + admin consent + identity-service JIT + an ACTIVE DB user mapped to an org. When "Unable to load account" recurs for a new user → check the DB user + org mapping and admin consent, not the password or the frontend.

LumisCare CI — Snyk + Lighthouse for deployed packages (MC #102842) — 2026-06-03

Summary

MC #102842 re-adds Snyk (dependency scan) and Lighthouse (performance) CI jobs to .github/workflows/ci.yml for the deployed pnpm packages, replacing the placeholder TODOs left by MC #102817 (which removed the old jobs that scanned the dead frontend/web/ tree).

What was added

security job (Snyk)

lighthouse job

Defect caught + fixed before close

First CI run (26888003662) the Snyk job died at pnpm install --frozen-lockfile with ERR_PNPM_IGNORED_BUILDS (exit 1) — pnpm/action-setup@v4 version: latest resolved to pnpm v10, which treats ignored build scripts as a hard error. deploy.yml pins PNPM_VERSION: "9" (warn only). Fix: pin pnpm 9 + add pnpm cache, mirroring deploy.yml.

Verification

Standing CEO action

Add SNYK_TOKEN to the johnatbasicas/vivacare repo secrets (Settings → Secrets → Actions) to activate real Snyk scanning. Until then the job skips cleanly with a warning. (John's PAT lacks secrets:write — HTTP 403.)

LumisCare Wave-1 Durability Redeploy & Validation — 2026-06-11

LumisCare Wave-1 Durability Redeploy & Validation — 2026-06-11

Scope

MC #103376 / parent #103260: prove Wave-1 live artifacts are durable after merge to dev, rebuilt and redeployed from merged dev, then independently validated.

Source and live artifacts

Validation verdict

Independent Proveo validation: PASS 8/8, regressions: [], apiOk: 6.

Validated live areas:

  1. Backoffice smoke / deployed bundle confirmation.
  2. Dashboard real data, no mock/hardcoded numbers, no crash.
  3. EVV no regression.
  4. Scheduling opens for care-manager, no access denied.
  5. Admin loads / AD-001 behavior intact.
  6. Audit logs page uses honest real/empty data and no fabricated rows.
  7. Compliance page has no fake 95% and no fake PHI rows.
  8. Family portal smoke/no white screen.

Evidence paths

Decision

Wave-1 durability gate is cleared. Wave-2 can proceed when ready, with separate gates for ADO org creation and leaked credential rotation (#103380). Do not activate unsafe pipeline paths that touch old leaked secrets.