Kulcare Platform Guides
This directory contains developer-focused documentation for the Kulcare healthcare platform.
Structure
Developer Documentation (Feature-Based)
Documentation is organized by feature/domain, NOT by technology layer (frontend/backend):
- developer/queue/ - Patient queue management
- developer/patients/ - Patient management
- developer/appointments/ - Appointment scheduling
- developer/encounters/ - Clinical encounters
- developer/clinical/lhr/ - Longitudinal Health Record (CMS surface + same-tenant view endpoints + cross-tenant timeline)
- developer/care-plans/ - Care plan management
- developer/billing/ - Billing & payments
- developer/marketplace/ - Vendor marketplace payments (multi-processor: Razorpay IN, Stripe US)
- developer/subscriptions/ - Subscription management. Start with
tenant-subscriptions.md: one subscription per tenant, items, changes, Keep, history, admin prices, jobs and seeds. - developer/identity/ - User identity & auth
roles-and-permissions.md— Roles and permissions (RBAC): the model, who becomes the owner at sign-up, the resolver, the my-permissions endpoint, how to add a key or change a default, the grant ceiling, the tests, and the deploy step. Pundit rules:authorization-pundit.md.
- developer/growth/ - Marketing & growth
- developer/connect/ - Professional networking
inbox/README.md— The Connect Inbox: why these tables carry no RLS and whatvisible_totherefore has to do, the block model, where messages are produced, the action dispatcher, the cross-tenant referral accept and its second database role, attachments without ActiveStorage, and the three test traps this suite has already fallen into.
- developer/reports/ - Analytics & reports
- developer/teleconsultation/ - Video consultations
- developer/patient/ - Patient-facing app (in-monorepo at
patient/, Vite + React) - developer/patient-domain/ -
Patient::backend module (patient-owned health data + cross-tenant clinical reads) - developer/health-diary/ - Health Diary: the chat pipeline and its failure states, idempotent retry and reply fencing, voice notes and their spend budget, rate limits, caregivers, and the web app's per-diary send state. Mobile contract: mobile integration.
- developer/api-client/ - API client package
- developer/ui-kit/ - UI kit package
CI guides
- developer/backend-ci-local.md - Backend
bin/ci, including the sharded domains suite for macOS (CI_DOMAINS_SHARDS=8) - developer/frontend-ci-local.md - Frontend
bin/ciand its ratchet - developer/admin-ci-local.md - Admin
bin/ci, lockfiles and package links
End-User Documentation
Written for the people who operate the product, not for engineers. HTML, so it can be opened directly or handed to a clinic.
- user/reports-app-build-status.html — Where the Reports MFE port stands: every tier and screen needed to ship in dependency order, what is done, what is awaiting QA, what is unbuilt, and the open bugs. Epic #2102.
- user/billing-and-subscription.html — Billing and your subscription: how the bill is made, adding and removing facilities, modules and specialities, Keep, plan changes, invoices, past subscriptions, statuses, "not billed" lines, and the Kulcare admin Prices page.
- user/roles-and-permissions.html — Roles and permissions for owners and admins: the four roles, the Roles & Permissions screen, search, Reset, the "changed from the default" dot, the save bar, the owner-only edit rule, invite limits, sign-in email and phone changes, when other people see a change, and the "Could not check your permissions" notice, and what a sign-up owner does when every column is locked.
- user/health-diary.html — Your Health Diary, for patients and caregivers: writing and speaking a note, reading the answer, folders, history, the visit summary, acting for a family member, what each error means, languages, privacy, and what to do in an emergency.
- user/connect-inbox.html — Your Connect Inbox, for practitioners: how it groups by person across every facility, accepting a referral including one from a practice you have no account at, writing to a colleague and who you may write to, sending a file and why patient records do not belong there, blocking without losing a clinical message, reporting, what each error means, and what is not built yet.
- user/revenue-sharing-payouts.html — Closing a payout month in the Reports app: entering facility costs, calculating, reading the P&L, and clearing every "cannot approve" message. Companion to
developer/billing/stakeholder-payout-calculation.md.
Other Guides
- ../adrs/ - Architecture Decision Records (canonical location)
- 001 — Patient photos via Active Storage
- 002 — Patient domain architecture
- 003 — JWT-implicit tenancy + Connect cross-tenant exception
- 004 — Polymorphic-owner models skip
Shared::Concerns::TenantScoped - 005 — Parallel focused services for vendor surfaces
- general/ - Cross-cutting documentation
- testing/ - Testing guides
onboarding-qa.md— End-to-end onboarding test plan for every role (practitioner / vendor / sales-led / existing-tenant owner). Covers V1 Phases 1 + 2 (vendor wizard + profile + packages).patient-domain-qa.md—Patient::backend module test planpatient-cross-tenant-qa.md— Cross-tenant patient appointments (Workstreams A/B/C)../testing/2026-09-19-health-diary-qa.html— Health Diary test pass: 38 cases across sending, failures, folders, history, the dashboard card, voice, caregivers, access and limits, and developer-only surfaces.../testing/2026-09-21-connect-inbox-qa.html— Connect Inbox test pass: 45 cases across reading, the Accept action on a referral, writing, attachments, block and report, and four checks that must not fail (#2449, PR #2463).lhr-qa.md— Longitudinal Health Record: same-tenant LHR view endpoints, cross-tenant timeline + consent, link mutations, CMS Sheet embedmarketplace-multi-processor-qa.md— Vendor marketplace payments end-to-end: backend (#1364, #1369), connect onboarding UI (#1376), Stripe return + refresh pages (#1377), patient checkout (#1378). Backend sections run against mocks; frontend sections gate on ops (#1374).ai-scribe-qa.md— AI Scribe access gating: facility-level enablement, per-capability toggles, practitioner-override smoke tests, and the staging-bug repro recipe (#1388).rbac-qa.md— Roles and permissions: sign-in, profile switch with a network failure, a revoke in the middle of a session, logout, two tabs, owner-only matrix edits, the invite limit, cross-tenant user updates, verified identifier changes, and one gated screen for each domain.
Important Documentation
- STYLE-GUIDE.md - ✅ Consolidated Style Guide (Tailwind CSS v4, design tokens, component usage)
- tailwind-v4-setup.md - ✅ Tailwind CSS v4 setup & workflow
- lhr-overview.md - Longitudinal Health Record product overview (what users see, design principles, scope)
Documentation Template
Each feature folder should have a README.md with these sections:
# [Feature Name]
## Overview
## Technical Architecture
## API Reference
## Dependencies
## Configuration
## Common Tasks
## TestingAdding Documentation
For New Features
Create a new folder in /docs/guides/developer/[feature-name]/ with a README.md following the template above.
For Architecture Decisions
Add ADRs to /docs/guides/adrs/ following the ADR format.
Maintenance
- Review documentation quarterly for accuracy
- Update when code paths change
- Delete or archive when features are deprecated