Skip to main content

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.

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: 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.