> ## Documentation Index > Fetch the complete documentation index at: https://docs.encoreos.io/llms.txt > Use this file to discover all available pages before exploring further. # Encore Health OS - Lovable Project Knowledge > Paste into Project Knowledge (per project). Requires LOVABLE_WORKSPACE_KNOWLEDGE.md in Workspace Knowledge for platform-wide guardrails. Paste into **Project Knowledge** (per project). Requires `LOVABLE_WORKSPACE_KNOWLEDGE.md` in Workspace Knowledge for platform-wide guardrails. This file is intentionally project-context-heavy. Workflow prompts live in `LOVABLE_PROMPTS.md`. Test credentials: `docs/testing/AI_BROWSER_TESTING.md`. Test organization: **NorthSight Recovery**. Full references: * `AGENTS.md` * `constitution.md` * `docs/tools/lovable/LOVABLE_PROMPTS.md` * `docs/tools/lovable/LOVABLE_REFERENCE_APPENDIX.md` *** ## GitHub sync branch (required setup) In **Git / GitHub** settings, set the **default sync branch** to **`feature/ehr`**. Do **not** sync to ad-hoc branches (for example: `finishtouch`, `lovable-sync-*`) because they diverge from `feature/ehr` and require manual merge work. Release to `main` is handled via PR (or explicit merge) from `feature/ehr`. *** ## 1. Project context and architecture * Product: multi-tenant healthcare ERP for behavioral health and recovery housing. * Tech stack: React 18 + TypeScript + Vite 8 + Tailwind v4 + shadcn/ui + TanStack Query + Supabase. * Architecture: Platform Foundation (`PF`) + domain cores. Cores depend on PF only; no direct core-to-core imports. * CL is downstream. Cross-core integration must use platform layers (`@/platform/*`), event contracts, or API contracts. * Canonical CL/PM link is encounter: `pm_encounters`. * Use `@/` path aliases; avoid deep relative imports. *** ## 2. Doc map ({SPEC_ID}, {core}) * Spec: `specs/{core}/specs/{SPEC_ID}-*.md` * Wizard / module UX spec (`{CORE}-UX-##`): `specs/{core}/ux/{SPEC_ID}-*.md` * Plan: `specs/{core}/plans/{SPEC_ID}-*-PLAN.md` * Tasks: `specs/{core}/tasks/{SPEC_ID}-TASKS.md` * Context: `specs/{core}/specs/{SPEC_ID}-CONTEXT.md` (or `specs/{core}/ux/{SPEC_ID}-CONTEXT.md`) * Integration doc: `docs/architecture/integrations/{SPEC_ID}-*-INTEGRATION.md` * Cross-core map: `docs/architecture/integrations/CROSS_CORE_INTEGRATIONS.md` * Events: `docs/architecture/integrations/EVENT_CONTRACTS.md` * Implementation log: `specs/{core}/IMPLEMENTATION_LOG.md` * Workflow prompts: `docs/tools/lovable/LOVABLE_PROMPTS.md` * Auto-generated walkthrough prompts: * `npm run uat:generate-lovable-prompts -- --module {core}` * Output: `docs/archive/testing/uat/lovable-prompts/{core}/` Always cross-check `CROSS_CORE_INTEGRATIONS.md` and spec-specific integration docs before implementing. *** ## 3. Key database entities (quick map) Platform Foundation: * `pf_organizations` * `pf_sites` * `pf_user_role_assignments` * `pf_module_permissions` * `pf_jurisdiction_profiles` Practice Management + Clinical: * `pm_encounters` (canonical CL/PM join point) * `pm_appointments` * `pm_charges` * `cl_clinical_notes` * `cl_treatment_plans` * `cl_sdoh_screenings` Finance + HR + RH: * `fa_journal_entries` * `fa_accounts` * `hr_employees` * `hr_positions` * `rh_properties` * `rh_resident_assignments` Rules: * Mutations must include tenant/org constraints. * RLS on all regulated data. * Use PF-70 libraries for ICD-10/CPT/HCPCS, never hard-coded code sets. *** ## 4. Domain terminology and personas Key terms: * SUD: Substance Use Disorder * MAT: Medication-Assisted Treatment * OTP: Opioid Treatment Program * LOC: Level of Care * SDOH: Social Determinants of Health * IOP/PHP: Intensive Outpatient / Partial Hospitalization Program * AHCCCS: Arizona Medicaid program (jurisdiction profile-driven, not global hardcode) Primary users: * Organization admin * Clinical staff (therapist/case manager) * Billing specialist * HR manager * Housing/property operations manager Use realistic healthcare context in generated copy and flows. Avoid generic placeholder text. *** ## 5. Security and compliance quick reference * HIPAA + tenant isolation are mandatory. * For SUD data, apply 42 CFR Part 2 handling. * No PHI/PII in prompts, logs, or synthetic examples. * Never expose raw `error.message` to users; sanitize. * Never store secrets in frontend code; use Lovable Cloud Secrets + server-side handlers. * Treat frontend as untrusted; enforce validation and auth server-side. * RLS must remain intact for all sensitive tables and tenant paths. *** ## 6. When to write a spec Spec required when work includes: * DB/schema changes * 3+ components * Cross-core touchpoints * Complex business logic Location pattern: `specs/{core}/specs/{CORE}-##-{name}.md` Standard delivery path: **Spec -> Plan -> Tasks -> 4-chat delivery -> Report** If work is genuinely small, use the quick-fix path in `LOVABLE_PROMPTS.md`. *** ## 7. Debugging guidance When stuck, inspect in this order: * Browser console (RLS denials, React warnings, runtime errors) * Network (auth token, tenant headers, query params) * `types.ts` vs migration/schema reality * Edge function logs (Lovable Cloud / Supabase) After 2-3 failed fix attempts, switch to Plan-mode investigation first, then implement. *** ## 8. Supabase and CL/PM integration anchors Supabase: * Lovable MCP is fine for read/schema exploration and `types.ts` regeneration. * Use CLI workflow for migrations. * Validate migration quality before commit. CL/PM: * `pm_encounters` is the canonical join point for scheduling, documentation, and billing. * CL encounter context comes from `@/platform/scheduling`. * Shared types from `@/platform/types` (`EncounterContext`, `ChargeContext`, `DiagnosisReference`). * CL cross-core FK exception applies only to `pm_encounters.id` with `ON DELETE RESTRICT`. *** ## 9. Platform re-export layers (required for cross-core access) Never import directly from `@/cores/{other-core}/` from unrelated cores. Route dependencies through platform layers: * `@/platform/auth` -> auth + organization context * `@/platform/permissions` -> permission checks and gates * `@/platform/forms` -> FW form surfaces * `@/platform/wizards` -> wizard shell + renderer * `@/platform/table-v2` -> table primitives * `@/platform/notifications` -> notification infrastructure * `@/platform/formatting` -> date/currency formatting * `@/platform/clinical` -> CL services/context surfaces * `@/platform/scheduling` -> PM scheduling/encounter context * `@/platform/portal` -> PM portal integrations * `@/platform/benefits` -> HR benefits helpers * `@/platform/telephony` -> CE telephony helpers If a required integration layer is missing, create it in `src/platform/{layer}/index.ts` and import through that layer. *** ## 10. Lovable platform features to leverage * Use built-in security scans before publish (RLS, DB security, dependency audit). * Trigger browser testing explicitly for user flows (for example: "verify it works"). * Use Agent mode for larger end-to-end tasks that need execution + verification. * Use frontend tests for stable UI behavior and edge function tests for backend rules. * Add this prompt tail for clearer implementations: * "Ask me any questions you need to fully understand this feature before writing code." *** ## 11. Knowledge setup and refresh * Workspace Knowledge: paste `LOVABLE_WORKSPACE_KNOWLEDGE.md` (shared rules). * Project Knowledge: paste this file (project-specific context). * Without Lovable Teams: paste both files into Project Knowledge. * Re-paste Workspace Knowledge whenever `constitution.md` or `AGENTS.md` rules change. * Re-paste Project Knowledge whenever this 4-chat workflow context or doc map changes.