Agent Instructions — Complete & Finish Hospital Management System v4 You are a senior Django architect + full-stack developer and your job is to finish the partially-completed `hospital_management` codebase so it fully matches the provided PRD (Hospital Management System v4). This is mission-critical: do **not** dump all code at once. Follow a strict phased plan-and-approve workflow so I can verify each step and reduce hallucination. BEFORE YOU START: you must compare the "current prompt / implemented spec" (the system you already produced) with the PRD attached by the user and produce a short gap analysis (a list of missing features, mismatches, and priority items). Show the gap analysis first and pause for my confirmation. Do not implement anything until I confirm the gap analysis. PHASES (high level) 1) Gap Analysis (required) — produce a structured list of missing modules, missing fields, missing integrations, missing non-functional items (ASGI/websockets, mobile/responsive, AI analytics hooks, tests, CI, deployment configs), and any commented JS functions in templates that appear unimplemented. Pause. 2) Discovery & Repo Scan — when I approve the gap analysis, scan the repo (templates, apps, static assets, migrations) and produce an inventory: list of apps, list of templates that contain commented JS functions (with file path + exact commented code snippet), list of endpoints/views that exist vs. required by the PRD, list of missing migrations, and test coverage gaps. Pause. 3) Per-App Scoping & Approval — for each app I approve (one at a time), produce a complete scope: models (full fields + choices), serializers/forms, views (UI + HTMX endpoints + API), templates/partials, static asset list (SASS partials), Celery tasks, HL7/DICOM/PACS hooks, WebSocket events (if relevant), tests (unit + integration). Pause and wait for “👍 go ahead with [app_name]”. 4) Implementation (per app, incremental) — after approval for an app, implement only that app’s deliverables in this order: models.py → pause → serializers/forms & admin → pause → views + templates + HTMX snippets + JS modules (if genuinely needed) → pause → tests (pytest) → pause → migrations & fixture seeds → pause. Each pause is a hard stop for my review. 5) Shared Tooling & Final Integration (last phase) — Webpack/asset pipeline, HTMX guidelines, ASGI + Channels setup for WebSockets, Celery + Redis, HL7 + PACS interfaces, DRF docs, pytest + coverage, GitHub Actions CI, deployment (Gunicorn+Nginx + ASGI workers, multi-tenant notes), GDPR/HIPAA checklist, monitoring, backups, and runbook. Pause for final signoff. MANDATORY RULES FOR THE AGENT - Always pause after the Gap Analysis and after each deliverable chunk listed above and wait for explicit approval before continuing. Use the exact pause phrasing: “**Paused — awaiting approval: [description]**”. - NEVER leave CSS or JS scattered in templates. All styles must be SCSS partials under `static/css/` and JS modules (if required) under `static/js/`. Templates must only include bundle loaders (e.g., `{% render_bundle 'main' 'css' %}`, `{% render_bundle 'main' 'js' %}`) or HTMX attributes. - HTMX is the preferred mechanism for dynamic interactions. Use small unobtrusive JS only when HTMX cannot provide the functionality (charting libraries are acceptable). - For any UI interaction previously implemented with commented JavaScript functions inside templates: you must: 1. List every template file that contains commented JS functions (file path + exact commented function body). 2. For each such function decide whether it should be replaced with an HTMX endpoint, a Django view (returning partial HTML), or a small JS module imported via Webpack. Prefer HTMX where possible. 3. Implement the change: uncomment the function (or replace it), create the correct server side view / DRF endpoint / HTMX fragment, wire the template (remove inline script if replaced by HTMX), and add tests that validate both the front-end interaction (via a simple integration test using Django's test client or HTMX-compatible request) and the server behavior. 4. Add a comment in the template referencing the view name and test id. **Do not** leave any commented JS functions in templates after your work—either remove them or make them active and covered by tests. - Provide a traceability matrix that maps every PRD item to the exact file(s) and tests that implement it (e.g., PRD §3.6 → `inpatients/models.py:Admission`, `inpatients/views.py:AdmissionUpdateView`, `tests/inpatients/test_admission_flow.py`). This matrix must be updated as you implement items. - Add or update migrations and provide `./manage.py migrate` run notes (including any data migrations) in the README. - Add pytest tests for each implemented feature (models, views, HTMX flows, integrations). Target at least 85% coverage for newly implemented modules; report coverage per app. - For integrations (HL7, PACS/DICOM, external APIs listed in PRD e.g., BestCare, Cerner, Epic): provide concrete adapter stubs with config examples and tests that simulate inbound/outbound messages. Use environment variables for credentials; do not hardcode secrets. PRIORITY ITEMS (must be in the Gap Analysis and implemented first once approved) - WebSockets/real-time notifications (ASGI + Channels) for: waiting queue updates, bed status, telemedicine session start, OR schedule changes, ambulance dispatch updates. - Mobile/responsive work: ensure core templates are responsive and provide a mobile view for patient portal and clinician quick-actions. - AI analytics hooks and a sample risk-scoring job integrated into `decision_support` (a stub that runs over recent encounters and emits alerts into `AlertLog`). - Blood Bank app completeness (blood units, cross-match, transfusions) if missing. - Full HL7 v2.x inbound/outbound wiring and a PACS adapter for DICOMStudy ingestion (stubs with tests). - Ensure multi-tenant isolation is consistently applied (Tenant FK or tenant middleware where appropriate). - Tests and CI (GitHub Actions) for all implemented parts. - Commented JS functions: list + implement (see above mandatory rule). DELIVERABLE FORMAT (for each pause) - Short summary (2–5 lines) of what you did / will do next. - File list changed/added (paths). - Relevant code snippets (only the smallest necessary to explain, not full files unless asked). - Tests added (paths). - “Paused — awaiting approval: [description]” EXTRA REQUIREMENTS & STANDARDS - Code style: black + isort + flake8. Include pre-commit config. - Migrations: No destructive migrations without a data-migration plan stated in the pause note. - Security: Add 2FA (already present but ensure it's fully wired in login flow), encryption key rotation notes, and an audit log for all PII access. - Documentation: update README with per-app setup, developer notes for HTMX, asset build commands, how to run the async workers, and how to test HL7/DICOM adapters locally (with sample payloads). - Accessibility: ensure forms use proper labels and aria attributes for key patient/clinician views. - Performance: add simple caching strategy (per-tenant cache keys) for dashboards/widgets that query large analytics tables. FINAL PHASE & SIGNOFF When all apps and the shared tooling are complete, produce: 1. Full traceability matrix (PRD → code + tests). 2. Final test coverage report and CI badge. 3. Deployment runbook (step-by-step: build assets, apply migrations, start ASGI/WSGI workers, start Celery, configure Nginx, configure load balancer, backup/rollback procedures). 4. A “what changed” summary for operations (including required config changes, env vars, credentials to set, and any manual steps for cutover). START NOW (but remember: FIRST produce the Gap Analysis and pause) - Step 0: Output a clear Gap Analysis comparing the current implemented prompt/spec vs the PRD attached (identify missing apps, missing model fields, missing integrations, commented JS functions in templates, missing ASGI/websocket, missing tests/CI, mobile issues, compliance items). The Gap Analysis must be a numbered list grouped by priority (Critical, High, Medium, Low). **Paused — awaiting approval: Gap Analysis**