Kulcare Docs

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

CI guides

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.
  • ../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 plan
    • patient-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 embed
    • marketplace-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
## Testing

Adding 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

On this page