feat: add employee API integration and request lab component

- Introduced EMPLOYEE_API endpoint in api.js for employee service.
- Added RequestLab component for testing API routes with a user-friendly interface.
- Updated monitoring_ui documentation to reflect changes in features and authentication.
- Removed unnecessary login functionality from monitoring_ui to maintain unauthenticated access.
- Enhanced styles for new components and improved overall UI consistency.

monitoring_ui/docs/MONITORING_UI.md

@@ -1,19 +1,20 @@
 # Transit Control Room
 
-`monitoring_ui` is a React + Vite operations dashboard for the XTransit service group. It gives an operator one place to answer four questions:
+`monitoring_ui` is a React + Vite operations dashboard for the XTransit service group. It gives an operator one place to answer three questions:
 
 1. Are the services reachable right now?
 2. What kind of data does each service provide?
-3. Which errors and bad requests have been recorded?
-4. Can I safely inspect a real API response without building a curl command by hand?
+3. Where is the documentation for each service?
 
-The dashboard is a browser-only application. It does not introduce a database, server-side session store, or monitoring proxy. Requests go directly from the browser to the configured services.
+The dashboard is a browser-only application. It does not introduce a database, server-side session store, or monitoring proxy. Health requests go directly from the browser to the configured services.
+
+Authenticated operations — the centralized error log, the request lab, and network management — live in the **admin console** (`admin_ui`, the Beheercentrum). This dashboard deliberately stays unauthenticated and read-only so a control-room wall display never needs a token.
 
 ## 1. What It Monitors
 
 | Surface       | Default URL                                  | Health request | Purpose                                                   |
 | ------------- | -------------------------------------------- | -------------- | --------------------------------------------------------- |
-| Auth API      | `http://localhost:5000`                      | `GET /me`      | Login, JWT sessions, and current-user information         |
+| Auth API      | `http://localhost:5000`                      | `GET /health`  | Login, JWT sessions, and current-user information         |
 | Employee API  | `https://employees.xtransit.testinstance.nl` | `GET /health`  | Employee onboarding and employee records                  |
 | Transit API   | `http://localhost:5001`                      | `GET /health`  | Schedules, routes, GPS, fleet, and administration         |
 | Error Log API | `http://localhost:5003`                      | `GET /health`  | Centralized service errors and bad requests               |
@@ -28,9 +29,7 @@ The URLs are development defaults only. For a deployed dashboard, use the Connec
 - `offline`: the browser could not establish a response, usually because the service is stopped, the URL is wrong, TLS failed, or CORS blocked the request.
 - `checking`: the first poll has not completed yet.
 
-The Auth API uses `/me` because it does not currently expose a public `/health` endpoint. Without a JWT this normally appears as `degraded`, not as a broken service. Add a token in Connections when an authenticated Auth API signal is required.
-
-Transit health includes database reachability. Employee health currently confirms process reachability only. Admin UI health is supplied by the nginx configuration in `admin_ui/nginx.conf` and returns a small JSON document.
+Transit health includes database reachability. Employee health currently confirms process reachability only. Auth health reads the public `/health` endpoint, which does not require a token. Admin UI health is supplied by the nginx configuration in `admin_ui/nginx.conf` and returns a small JSON document.
 
 ## 2. Features
 
@@ -49,42 +48,15 @@ The top-level pulse shows how many surfaces are healthy and the average latency
 
 The Service catalog is a human-readable map of the data each service serves. It is deliberately maintained as a small allowlisted catalog rather than attempting to discover every Express route at runtime. This keeps the dashboard understandable and avoids exposing internal routes or implementation details.
 
-### Errors and bad requests
+### Docs
 
-The Errors & bad requests tab reads:
-
-```text
-GET /error_log?limit=80
-Authorization: Bearer <admin-jwt>
-```
-
-The Error Log API restricts this endpoint to administrator tokens. The dashboard displays timestamp, service, route or sub-service, and normalized error text. The dashboard does not write new logs itself; the existing APIs already report their failures to `error_log_api`.
-
-If the token is missing, the dashboard explains how to configure it. If the token is expired or not an administrator token, the API response is shown as a load failure rather than silently displaying an empty incident list.
-
-### Request lab
-
-The Request lab executes only known routes listed in `testerRoutes` inside `monitoring_ui/src/App.jsx`. It supports representative calls for:
-
-- Auth API current-session inspection;
-- Employee API health;
-- Transit API health;
-- public schedule progress;
-- driver daily schedule;
-- recent Error Log API entries.
-
-The selected service, method, and path determine the destination. An optional JSON body can be entered for future write routes. Non-GET requests require a browser confirmation before execution.
-
-This is an operator diagnostic tool, not a general-purpose arbitrary URL proxy. Keep the allowlist intentionally narrow when adding routes.
+The Docs tab bundles the project documentation hub (`monitoring_ui/docs/`) into a searchable sidebar. It renders every markdown file that ships with the dashboard and resolves in-document links. This is the same documentation referenced throughout the repository.
 
 ### Connections
 
-The Connections tab edits the five service base URLs and the optional admin JWT. Values are stored in `localStorage` under:
+The Connections tab edits the service base URLs used for health polling. Values are stored in `localStorage` under `transit-monitor-urls`. This makes local experimentation convenient, but it also means the URLs are readable by JavaScript running on the same origin. Use the dashboard only in a trusted browser profile.
 
-- `transit-monitor-urls`
-- `transit-monitor-token`
-
-This makes local experimentation convenient, but it also means the token is readable by JavaScript running on the same origin. Use the dashboard only in a trusted browser profile and do not use it on a shared workstation with untrusted browser extensions.
+The Connections screen intentionally does **not** accept tokens or passwords. Authenticated reads (error log, admin endpoints) are done from the admin console.
 
 ## 3. Local Development
 
@@ -112,7 +84,7 @@ monitoring_ui/
 ├── vite.config.mjs     Vite React configuration
 ├── src/
 │   ├── main.jsx        React bootstrap
-│   ├── App.jsx         service model, polling, tabs, request lab
+│   ├── App.jsx         service model, polling, tabs, docs viewer
 │   └── styles.css      responsive control-room styling
 └── README.md           short navigation pointer
 ```
@@ -139,30 +111,20 @@ The Connections screen is useful when the same build needs to point at different
 
 Because the dashboard calls services directly, every monitored API must allow the dashboard origin. The existing Auth, Transit, and Error Log services already expose permissive CORS middleware. Employee API has matching browser CORS middleware in `employee_api/index.js`.
 
-For production, replace wildcard CORS with an explicit dashboard origin where practical. At minimum, allow:
-
-- `GET`, `POST`, `OPTIONS`, and any methods used by approved tester routes;
-- `Content-Type`;
-- `Authorization`.
+For production, replace wildcard CORS with an explicit dashboard origin where practical. At minimum, allow `GET` and `OPTIONS`.
 
 If the browser console reports a refused connection but direct `curl` succeeds, check CORS before changing the dashboard code.
 
 ## 5. Authentication and Security
 
-The dashboard does not implement a second login system. It accepts a JWT created by the existing Auth API. Obtain a token through the normal admin login flow, then paste it into Connections.
-
-The Error Log API verifies both JWT validity and the `isAdmin` claim. A valid non-admin token is not sufficient to read centralized errors.
+The dashboard is deliberately unauthenticated. It never stores or sends bearer tokens. All protected operations are handled by the admin console (`admin_ui`), which obtains a JWT through the normal Auth API login flow.
 
 Operational safeguards:
 
-- never commit `.env.local` or copied tokens;
-- avoid putting production JWTs in screenshots, issue reports, or browser history;
-- keep the request lab allowlist small;
-- require confirmation for all mutating requests;
-- prefer read-only routes for routine diagnostics;
+- never commit `.env.local`;
+- avoid putting production URLs, screenshots, or issue reports in public channels;
 - use HTTPS for deployed APIs and dashboard access;
-- restrict CORS to known origins in production;
-- consider moving token handling to an authenticated same-origin backend if the dashboard becomes a multi-user production console.
+- restrict CORS to known origins in production.
 
 ## 6. Deployment Options
 
@@ -208,11 +170,7 @@ A reverse proxy can place the dashboard and service domains behind one TLS bound
 
 ### Auth API shows degraded
 
-`GET /me` requires a bearer token. Paste a current admin JWT into Connections. A `401` means the API answered and is reachable, but the supplied token is absent or invalid.
-
-### Error list is empty
-
-An empty list can mean either that no errors were returned or that the request was not authorized. Check the Errors tab status text and verify that the token has `isAdmin: true`. The Error Log API also requires its database table `data.errors` to exist.
+`GET /health` should answer without a token. If it returns degraded, the API is reachable but responding with a non-success status. Note that `/me` requires a bearer token; that endpoint is only exercised from the admin console.
 
 ### Employee API cannot be called from the dashboard
 
@@ -243,21 +201,18 @@ To add a service:
 1. Add its base URL to `configured`.
 2. Add its metadata to `serviceMeta`.
 3. Add a health path to `healthPaths`.
-4. Add representative safe routes to `testerRoutes`.
-5. Add its environment variable to this document and `.env.local` examples.
-6. Confirm the service has CORS headers and an appropriate health endpoint.
-7. Run `npm run build` and perform a browser smoke test.
+4. Add its environment variable to this document and `.env.local` examples.
+5. Confirm the service has CORS headers and an appropriate health endpoint.
+6. Run `npm run build` and perform a browser smoke test.
 
-To add a request route, include a short label and keep the route literal. Avoid user-entered arbitrary URLs, unrestricted HTTP methods, or unrestricted request headers.
+Authenticated tooling belongs in `admin_ui`, not in this dashboard. If an admin-facing request lab or error viewer is needed, extend the admin console instead so this control-room surface stays unauthenticated.
 
 Useful future extensions include:
 
 - a time-window chart backed by a real metrics store;
 - service version/build information in health payloads;
 - threshold-based alerts for latency and repeated failures;
-- export of incident rows for an operator handoff;
-- a same-origin authenticated backend if the tool becomes a shared production console;
-- a dedicated `/health` endpoint for Auth API so authentication status and process health are separate signals.
+- an Admin UI card in the overview that includes deployment/build metadata.
 
 ## 9. Validation Checklist
 
@@ -275,7 +230,5 @@ Then verify in a browser:
 - one healthy local service shows a payload and latency;
 - an unavailable service is clearly marked offline;
 - Connections persists URL changes after reload;
-- an admin JWT loads Error Log API data;
-- an invalid token produces a visible error state;
-- each Request lab route targets the expected service;
-- the layout remains usable at a narrow mobile width.
+- no tab, control, or prompt requires a token or password;
+- the layout remains usable at a narrow mobile width.

monitoring_ui/docs/PROJECT_GUIDE.md

@@ -161,7 +161,8 @@ The GitHub Actions workflow builds service images and pushes them to the configu
 - use least-privilege database users;
 - restrict CORS origins for production deployments;
 - keep admin JWTs out of logs and screenshots;
-- review allowlisted routes before expanding the monitoring request lab;
+- review allowlisted routes before expanding the admin console request lab;
+- keep the monitoring control room unauthenticated and read-only;
 - treat `DEV_MOCK=1` as a local development setting only.
 
 ## Documentation Policy