# Medicus PDF Generator — Documentation

This is the full technical documentation for `@medicus.ai/medicus-report-pdf-generator`, a Node.js library that turns JSON health-report data into branded PDF documents (and, for one flow, emails them out).

**Read this first:** [`08-known-issues-and-technical-debt.md`](08-known-issues-and-technical-debt.md) and the project-root [`HANDOVER.md`](../HANDOVER.md) contain the handful of facts that will save you the most debugging time (in particular: `index.js` runs `lib/pdf_generator.min.js`, not the readable `lib/pdf_generator.js`).

## Contents

1. [Architecture Overview](01-architecture-overview.md) — what this package is, module map, entry points, dependencies, data flow.
2. [Configuration & Whitelabelling](02-configuration-and-whitelabelling.md) — the `config/` system, how a `client` string selects branding/templates, per-generator inconsistencies.
3. [Templating & Rendering Pipeline](03-templating-and-rendering.md) — how HTML is built from data (no template engine — string replace + jsdom/jQuery), how it becomes a PDF (Puppeteer), charts, QR codes.
4. [Report Pipelines](04-report-pipelines.md) — the four distinct report generators (Core "Medicus", Wellbeing, Corporate, SanusX): purpose, entry points, data shape, brand support.
5. [Questions, Answers & the Data Model](05-questions-and-data-model.md) — directly answers "where do questions come from and how are they rendered."
6. [Internationalization (i18n) & RTL](06-internationalization.md) — locale system, Arabic/RTL handling, gotchas.
7. [Email Notifications](07-email-notifications.md) — `lib/sendEmail.js`, SMTP config, security notes.
8. [Known Issues & Technical Debt](08-known-issues-and-technical-debt.md) — consolidated list of bugs, dead code, and risks found while writing this documentation.

## What this project is NOT

- It is **not a web server**. There is no HTTP listener, no routes, no session handling anywhere in this repository. It is a plain npm library — `index.js` exports async functions that a **host application** (e.g. a Meteor app, per the README) calls directly in-process, or via the `run.js` child-process wrapper.
- It has **no authentication or authorization layer**. There are no auth-related dependencies in `package.json` (no JWT, no passport, no session store). Any access control, user identity, or permission checking is entirely the host application's responsibility — this package trusts whatever JSON payload it is handed.
- It has **no database**. Every function call is stateless: it receives a JSON payload (usually base64-encoded), renders it, and returns a PDF/HTML/base64 string. Nothing is persisted except transient files under `output/` or the OS temp directory.