# 04 — Early Pages (Phase 1 scope)

Phase 1 is **pure internal setup** — it mirrors the brief's own "Setup phase" of the workflow
(Super Admin creates the clinic → Clinic Admin adds doctors/schedules) and deliberately has
**zero patient-facing or doctor-facing UI**. Nothing here depends on payments, chat, video, or
the mobile API — those are later phases. This is the first thing to actually build.

## Why start here

Every later phase depends on this data existing: you cannot build a booking flow without clinics,
specialties and doctor schedules to book against. It's also the lowest-risk phase — it only
touches `routes/admin.php`, adds new tables, and follows the HR module's controller/service/
request pattern almost line for line, so it's the fastest way to validate the module's plumbing
(migrations, permissions, sidebar menu, branch scoping) before building anything patient-facing.

## Screens to build, in order

### 1. Specialties (Super Admin) — build this first, nothing depends on it existing yet it's needed by everything else

- Route group: `admin.dashboard.clinic.specialties.*`
- Controller: `Admin\Clinic\SpecialtyController` (`index`, `create`, `store`, `edit`, `update`, `destroy`)
- Service: `Clinic\SpecialtyService`
- Views: `dashboard/admin/clinic/specialties/{index,create,edit}.blade.php`
- Permissions: `clinic.specialties.view|create|edit|delete`
- Fields on the form: name (translatable, matching the ERP's existing translatable-field
  convention used elsewhere, e.g. `PaymentGateway.name`), slug (auto), `is_active`.

### 2. Clinics (Super Admin)

- Route group: `admin.dashboard.clinic.clinics.*`
- Controller: `Admin\Clinic\ClinicController`
- Service: `Clinic\ClinicService` — **creates a `Branch` row and its `ClinicProfile` row in one
  form submission** (two models, one transaction — same pattern as any master-detail save
  elsewhere in the app)
- Views: `dashboard/admin/clinic/clinics/{index,create,edit}.blade.php`
- Permissions: `clinic.clinics.view|create|edit|delete`
- `store()` also creates the clinic's first `Clinic Admin` account (`Admin` model, role `Clinic
  Admin`, `branch_id` = the new branch's id) in the same transaction, per the brief ("Super Admin
  creates the clinic, links Clinic Admin to it").
- Form fields (Branch side, existing columns): name, code, email, phone, address, city.
  (ClinicProfile side, see `models/Clinic.md`): logo, working hours, description.

### 3. Doctors (Clinic Admin)

- Route group: `admin.dashboard.clinic.doctors.*`
- Controller: `Admin\Clinic\DoctorController`
- Service: `Clinic\DoctorService`
- Views: `dashboard/admin/clinic/doctors/{index,create,edit}.blade.php`
- Permissions: `clinic.doctors.view|create|edit|delete`
- `index()` is branch-scoped automatically (see `03-permissions-and-roles.md`) — a Clinic Admin
  only sees doctors linked to their own branch via `clinic_doctor_branch`; Super Admin sees all.
- `create()`/`store()` creates the `Doctor` account (or links an existing one — a doctor working
  at two branches is the *same* `Doctor` row, just a second `clinic_doctor_branch` row) plus one
  `clinic_doctor_branch` pivot row for the acting admin's branch, with visit price, consultation
  price, and slot duration.

### 4. Doctor Schedules (Clinic Admin)

- Route: `admin.dashboard.clinic.doctors.{doctor}.schedule` (nested under the doctor edit page as
  a tab, not a separate top-level menu item — matches how HR's `EmployeeController::edit()`
  loads multiple related tabs, `app/Http/Controllers/Admin/HR/Employee/EmployeeController.php:57-59`)
- Controller: `Admin\Clinic\DoctorScheduleController`
- Service: `Clinic\DoctorScheduleService`
- Fields: day of week, start time, end time (repeatable rows), scoped to the current
  `clinic_doctor_branch` pairing being edited.

## Sidebar

Add the "Clinic" section to `main-sidebar.blade.php` as described in `01-module-structure.md`,
with menu items for Clinics, Specialties and Doctors visible for Phase 1 (Bookings/Patients/
Reports/Offers menu items can be added to the same section now, pointing at routes that don't
exist yet, or deferred to Phase 2 — deferring is cleaner, avoids dead links).

## Explicitly out of scope for Phase 1

- Anything under `Site/Clinic/*` (patient-facing) — Phase 2.
- Anything under `Doctor/*` (doctor portal, new guard) — Phase 3.
- `clinic_bookings`, `clinic_payments`, `clinic_medical_records`, `clinic_reviews`,
  `clinic_chat_messages` tables/models — not created in Phase 1 (only `clinic_profiles`,
  `clinic_specialties`, `clinic_doctors`, `clinic_doctor_branch`, `clinic_doctor_schedules`, plus
  the `admins.branch_id` column).
- `clinic_offers` — Phase 4.

## Definition of done for Phase 1

A Super Admin can create a clinic (which also creates its Clinic Admin account and appears in the
branch list), log in as that Clinic Admin (scoped to only that branch), add a specialty-linked
doctor, and configure that doctor's weekly schedule and prices for that branch — with every
screen permission-gated and every list branch-scoped correctly.