From a631331e946e015793b40d9356bc5b1b13a178a2 Mon Sep 17 00:00:00 2001 From: "sas.fajri" Date: Mon, 13 Apr 2026 14:28:22 +0700 Subject: [PATCH] Add project rebuild specs --- project-specs/API_ENDPOINTS.md | 95 ++++++++++++++++++++++++++++++++++ project-specs/README.md | 53 +++++++++++++++++++ project-specs/UI_PLAN.md | 81 +++++++++++++++++++++++++++++ 3 files changed, 229 insertions(+) create mode 100644 project-specs/API_ENDPOINTS.md create mode 100644 project-specs/README.md create mode 100644 project-specs/UI_PLAN.md diff --git a/project-specs/API_ENDPOINTS.md b/project-specs/API_ENDPOINTS.md new file mode 100644 index 0000000..ca3f113 --- /dev/null +++ b/project-specs/API_ENDPOINTS.md @@ -0,0 +1,95 @@ +# API Endpoints - DocLink Web + +Source of truth for this document: +- Compiled Flutter web build in `main.dart.js` +- Sample test data in `assets/assets/fpp-example.json` + +Important note: +- This repo snapshot looks like a **compiled web build**, not the original Dart source. +- Endpoint paths and request fields below are extracted from the compiled JavaScript bundle. +- Some request methods are inferred from the shared HTTP helper used by the app. + +## Base URL + +Most endpoints point to: + +```text +https://devbandungraya.aplikasi.web.id/one-api-doctor/doctor_mitra +``` + +## HTTP pattern + +The compiled app uses a shared JSON POST helper: + +- `Content-Type: application/json` +- `Authorization: Bearer ` when token auth is available +- Many requests also include `token` in the JSON body + +## Auth + +| Endpoint | Method | Purpose | Request fields | +| --- | --- | --- | --- | +| `/auth/login` | POST | Login doctor user | `username`, `doctor_id`, `password` | +| `/auth/logout` | POST | Logout user | `M_UserID`, `M_UserUsername` | +| `/auth/change_password` | POST | Change password | `token`, `M_UserID`, `username`, `doctor_id`, `new_password`, `confirm_password` | + +## Order / Result + +| Endpoint | Method | Purpose | Request fields | +| --- | --- | --- | --- | +| `/order/home` | Referenced in app config | Home page / navigation target | Not visible as request body in the bundle snippet | +| `/order/order_list_search_for_result_v2` | Referenced in app config | Search/list result page | Not visible as request body in the bundle snippet | +| `/order/get_order_saran_by_order_patient_id` | POST | Fetch saran/recommendation by order patient ID | `token`, `order_patient_id` | +| `/order/hasil_belum_keluar_by_id` | POST | Fetch unfinished result by order ID | `token`, `order_id` | +| `/order/order_patient` | POST | Create/save order patient | `token`, `M_MouID`, `patient_name`, `patient_diagnosa`, `patient_address`, `patient_nik`, `patient_hp`, `patient_dob`, `patient_note`, `details` | +| `/order/search_order_pasien_by_doktorid` | POST | Search patient orders by doctor | `token`, `OrderPatientM_DoctorID`, `search` | + +## FPP + +| Endpoint | Method | Purpose | Request fields | +| --- | --- | --- | --- | +| `/Fpp/load/{c}/{b}` | POST | Load FPP data | Path params only in bundle snippet | +| `/Fpp/loadFPP/{a}/{b}` | POST | Load FPP detail/data | Path params only in bundle snippet | + +## Pesan Khusus + +| Endpoint | Method | Purpose | Request fields | +| --- | --- | --- | --- | +| `/Pesankhusus/add_pesan_khusus` | POST | Save special message | `token`, `order_id`, `pesan_khusus` | + +## Other API base references + +The bundle also references additional API bases for result/summary flows: + +- `.../result/getResult` +- a base path used for summary and search flows + +Those base URLs are not fully visible in the extracted snippet, so I did not guess them here. + +## Sample data + +`assets/assets/fpp-example.json` contains lab test group data, for example: + +- `HEMATOLOGI` +- `KLINIK RUTIN` + +This looks like static UI seed data, not an API endpoint. + +## Rebuild notes for a new project + +The current UI looks very mobile-first. For a new project, I would split it into: + +1. Auth screens +2. Dashboard shell +3. Order flow +4. Result/search flow +5. FPP flow +6. Password change / profile actions + +Responsive behavior should use: + +- mobile: bottom navigation or drawer +- desktop: persistent sidebar + content pane +- forms: two-column layout on desktop, single column on mobile +- tables/lists: cards on mobile, table/grid on desktop + diff --git a/project-specs/README.md b/project-specs/README.md new file mode 100644 index 0000000..6c23f07 --- /dev/null +++ b/project-specs/README.md @@ -0,0 +1,53 @@ +# Project Rebuild Spec + +Target: +- Rebuild the current app as a new project +- Keep the same API contract where needed +- Make the UI responsive for desktop and mobile + +## Current App Snapshot + +The existing repo snapshot looks like a Flutter web build output, not the original source tree. +That means the most reliable extracted data here is: + +- API endpoints from `main.dart.js` +- static sample data from `assets/assets/fpp-example.json` + +## Suggested New Structure + +1. `auth` +2. `dashboard` +3. `orders` +4. `results` +5. `fpp` +6. `settings` + +## Responsive Direction + +Mobile: +- use a compact layout +- prefer cards, drawers, and bottom navigation +- keep forms single-column + +Desktop: +- use a persistent sidebar +- show content in wider panes +- turn lists into tables when space is available +- use two-column forms where it improves readability + +## Migration Rules + +- Keep API paths consistent unless the backend changes +- Do not copy the old mobile-only layout as-is +- Split logic from presentation from the beginning +- Add a responsive shell first, then port each screen into it + +## Reference Files + +- [API_ENDPOINTS.md](./API_ENDPOINTS.md) +- [SCREEN_MAP.md](./SCREEN_MAP.md) +- [UI_PLAN.md](./UI_PLAN.md) +- [TECH_STACK.md](./TECH_STACK.md) +- [BACKEND_SPEC.md](./BACKEND_SPEC.md) +- [ROUTES.md](./ROUTES.md) +- [TEMPLATE_STRUCTURE.md](./TEMPLATE_STRUCTURE.md) diff --git a/project-specs/UI_PLAN.md b/project-specs/UI_PLAN.md new file mode 100644 index 0000000..5c549f3 --- /dev/null +++ b/project-specs/UI_PLAN.md @@ -0,0 +1,81 @@ +# UI Plan + +Goal: +- Rebuild the current app into a responsive product +- Keep the workflow familiar, but stop forcing a mobile-only layout on desktop + +## Layout Strategy + +### Mobile + +- Use a single-column layout +- Prefer bottom navigation for primary destinations +- Use drawers only for secondary navigation +- Convert dense tables into stacked cards +- Keep form controls full width + +### Desktop + +- Use a persistent sidebar +- Use a top header for page title and actions +- Split the screen into content + detail when needed +- Show lists as tables or master-detail panels +- Use two-column forms where the data density justifies it + +## Proposed Shell + +Common shell components: + +1. App header +2. Sidebar or bottom nav +3. Page title and breadcrumb area +4. Content container +5. Optional right-side detail panel + +## Screen-Level Guidance + +### Login + +- Centered card on desktop +- Full-width padded form on mobile + +### Dashboard + +- Desktop: stats row, recent activity, action shortcuts +- Mobile: stacked cards + +### Order List + +- Desktop: searchable table with filters +- Mobile: card list with summary and action button + +### Order Detail + +- Desktop: master-detail layout +- Mobile: sectioned accordion or tabs + +### Result/Historical Result + +- Desktop: chart or summary panel on top, list/table below +- Mobile: compact summary cards first, details later + +### Pendaftaran Pasien + +- Desktop: stepper or multi-column form +- Mobile: step-by-step single column flow + +### FPP + +- Desktop: filter panel + result panel +- Mobile: collapsible filter block and list cards + +### Change Password + +- Simple form in both layouts +- Keep validation inline + +### Pesan Khusus + +- Modal on desktop +- Full-screen sheet or dedicated page on mobile +