# W1-BE-B — managed catalog: seeds, in-place management API, permissions, ICD favourites (BE)

Read _COMMON.md first. Review rows: C-picker #6, #12, #13, #30, Bugs 1-3; owner wants adding/editing values easy and in place (inside the picker), for doctors.

## Goal
Make the one `clinical_lookups` catalog usable out of the box for general visits and manageable from inside the picker by doctors.

## Tasks
1. **Seed general complaint + exam catalogs (Bug 1).** Find how `LookupCatalogService.php:~41-44` filters specialty (what does the complaint card's `specialty='general'` match — NULL/core rows?). Create an idempotent seeder (by `code`) `GeneralClinicalCatalogSeeder` in Modules/Clinic:
   - `complaint`: category rows (e.g. عام/General, تنفسي, هضمي, ألم, جلدية, مسالك, أعصاب, أطفال) with ~40 common Egyptian outpatient complaints (Arabic value_ar + English value_en, codes like `cc_fever`, `cc_cough`…). Specialty = what the general card queries.
   - `exam.finding`: REGION category rows with stable codes `exam_general, exam_head_neck, exam_chest, exam_heart, exam_abdomen, exam_neuro, exam_limbs, exam_skin` (Arabic labels المظهر العام، الرأس والرقبة، الصدر، القلب، البطن، الأعصاب، الأطراف، الجلد) and under each 5-10 findings incl. a «طبيعي» normal first (codes `ef_<region>_<x>`). Check `EncounterFindingService` LOOKUP_KEY and how the exam card groups by region (parent rows) so the seed fits the card.
   - Register it: installer seeder list, `config('moonstack.updater.seeders')`, and a company-created hook like `TeamLookupSeed` so new companies get it. Run it on dev for every company. Test (idempotent, counts).
2. **Validate inline add (Bug 3).** `Http/Requests/StoreLookupRequest.php:~95`: `parent_id` must exist in clinical_lookups with the same company, same lookup_key, and be a category row; `specialty` must be null or a known clinical type (ClinicalTypeRegistry keys). Test.
3. **In-place management API (#30).** Add:
   - `PATCH clinic/lookups/{id}` — `value_ar`, `value_en`, `is_active`, `display_order`, `parent_id` (same rules), `is_alert`? (only if the column exists and is already exposed). Company-scoped (404 cross-tenant).
   - `POST clinic/lookups/reorder` — `{lookup_key, parent_id|null, ids:[…]}` sets display_order in that order.
   - `DELETE clinic/lookups/{id}` — soft delete if never used, else set is_active=false (say which in the response).
   - `GET clinic/lookups` gains `include_inactive=1` for users who can manage (inactive rows flagged `is_active:false`).
   Inactive values stay readable for existing answers/links (don't break history rendering). Tests.
4. **Permissions.** New `clinic.lookups.add` (add a value from a picker) and `clinic.lookups.manage` (rename/hide/reorder/delete). Grant BOTH to every clinical doctor role (doctor, gyn_doctor, gyn_consultant, dentist, dietitian… — list what exists in StandardRolesSeeder / Gyn / Dental / Nutrition role seeders) and to the clinic admin/owner; nurse gets `add` only. Not medical data, so admin may have them. Route middleware: store = `clinic.history.manage|clinic.lookups.add`; patch/reorder/delete = `clinic.history.manage|clinic.lookups.manage`. Catalogue + labels (ar/en) + ClinicPermissionDependencies (anchor = clinic.history.view or whatever list needs) + role seeders + a bridge migration for existing installs (run on dev). Expose `can_add_values` / `can_manage_values` where the FE gets abilities today (find how `canAddValues` is computed in FE clinical-picker-box — likely from the permission list, then nothing to do BE-side). Test routes.
5. **ICD favourites + browse (for the diagnosis picker).** `FavoriteController` / clinic_favorites: allow type `icd10` (store icd10 code id). Make sure the ICD search endpoint can list by chapter/group (e.g. `GET clinic/icd10?chapter=J` or `?group=`) and returns chapter list (`GET clinic/icd10/chapters`) — reuse existing ICD tables; add only what's missing. Tests.

## Out of scope
HistoryService (another WP), FE files, PatientReadService, VisitLayoutController, Hospital.
