feat: Enhance documentation with authentication details, per-device log level filtering, and routing features

Author: ndorin

docs/README.md

@@ -61,12 +61,20 @@ To understand the underlying concepts, read the **[Explanation](./explanation/)*
 
 The PepperDash Essentials Web Config App provides several key features:
 
-- **🔍 Debug Console**: Real-time log monitoring with filtering and search
-- **⚙️ Device Management**: Inspect and interact with connected devices  
+- **� Authentication**: Secure login required before accessing any app data
+- **🔍 Debug Console**: Real-time log monitoring with per-device minimum log level filtering
+- **⚙️ Device Management**: Inspect and interact with connected devices
 - **📄 Configuration Viewer**: View and analyze merged configuration files
 - **📦 Version Information**: Check loaded assemblies and versions
+- **🔀 Routing**: Visual signal routing diagram between devices and tie lines
+- **📱 Mobile Control**: Mobile control interface management
+- **🗺️ API Paths**: Browse all available REST API routes on the processor
 - **🏷️ Type Registry**: Browse supported device types and their properties
 
+## Multi-Application Support
+
+The app supports up to 10 simultaneous PepperDash Essentials program slots (`app01` through `app10`). After logging in, available program slots are automatically discovered and populated in the application selector dropdown in the top navigation bar. Navigating between app slots does not require re-authentication.
+
 ## System Requirements
 
 - Modern web browser (Chrome, Firefox, Safari, Edge)

docs/explanation/architecture.md

@@ -78,8 +78,13 @@ The web application serves several specific roles within this ecosystem:
 
 **State Management Strategy**:
 - **RTK Query**: Server state management and caching
-- **URL-based filters**: Filter state persisted in URL parameters
-- **Local component state**: UI-specific state like modals and selections
+- **Redux Toolkit**: Client state management for authentication, debug console filters, and UI state
+  - `auth` slice: global authentication state and available app slot list
+  - `debugConsole` slice: per-device minimum log level, checked device filters, and search text
+  - `websocket` slice: WebSocket connection state and received log messages
+  - `commonUi` slice: shared UI state such as the active room ID
+- **Local component state**: Transient UI state such as modals, drawer open/close, and form inputs
+- Filter state lives in Redux (not URL parameters) so selections are preserved when navigating between routes
 
 ### API Layer (RESTful Services)
 
@@ -194,10 +199,20 @@ Framework Logging ──► Message Buffer ──► WebSocket ──► Client
 
 ### Authentication Model
 
-**Processor-Based Security**:
-The web app leverages the processor's built-in security system:
+**Application-Level Authentication**:
+The web app implements its own credential-based authentication flow on top of the processor's built-in security:
 
-- **No Independent Authentication**: Web app doesn't implement its own user system
+- **Login Form**: Users provide a username and password before accessing any app data
+- **Credential Validation**: Credentials are submitted to the processor via `POST /:appId/api/loginCredentials`
+- **Server-Side Single Auth**: The backend has one shared authentication mechanism regardless of which `appId` is used in the request
+- **Global Session**: A successful login with any app slot authenticates the session for all running app slots
+- **Redux Auth State**: `isAuthenticated` boolean and `availableApps` list are stored in Redux in-memory (resets on page reload)
+- **Route Protection**: A `RequireAuth` layout route wraps all `/:appId/*` sub-routes; unauthenticated requests are redirected to `/:appId/login`
+
+**App Slot Discovery**:
+After credentials are validated, the application probes all 10 possible slots (`app01`–`app10`) in parallel using `Promise.allSettled`. Slots that respond successfully are stored as `availableApps` and populate the app selector dropdown in the top navigation bar.
+
+**No Independent Authentication**: Web app doesn't implement its own persistent user system
 - **Processor Integration**: Uses whatever authentication the processor has configured
 - **Session Management**: Relies on processor's session handling
 

docs/explanation/debug-console-design.md

@@ -25,9 +25,9 @@ The console presents information in layers, allowing users to start broad and na
 ```
 All System Messages
     ↓ (Filter by Device)
-Device-Specific Messages  
-    ↓ (Filter by Level)
-Problem-Level Messages
+Device-Specific Messages
+    ↓ (Set Per-Device Minimum Level)
+Severity-Filtered Device Messages
     ↓ (Text Search)
 Specific Event Messages
     ↓ (Click for Details)
@@ -65,9 +65,10 @@ Complete Message Information
 
 **Why Client-Side**:
 - **Responsive Filtering**: Filter changes apply instantly to existing messages
-- **Rich Interaction**: Complex filter combinations without server round-trips
+- **Rich Interaction**: Complex filter combinations (including per-device levels) without server round-trips
 - **Historical Analysis**: Can re-filter previously received messages
 - **Reduced Server Load**: Filtering computation happens in user's browser
+- **Persistent Across Navigation**: Filter state stored in Redux survives route changes within the same session
 
 **Trade-offs Accepted**:
 - **Bandwidth Usage**: All messages transmitted even if filtered out
@@ -101,18 +102,17 @@ Messages use structured logging with both human-readable text and machine-readab
 ### Filter Interface Design
 
 **Multiple Filter Types**:
-The console provides three distinct filtering mechanisms:
-1. **Device Selection**: Who generated the message?
-2. **Log Level Selection**: How important is the message?
-3. **Text Search**: What specific content are you looking for?
-
-**Why Multiple Types**:
-- **Different Mental Models**: Users think about problems in different ways
-- **Complementary Filtering**: Different filters answer different questions
-- **Flexible Workflow**: Users can apply filters in any order that makes sense
-
-**Filter Combination Logic**:
-All filters use AND logic (all conditions must match)
+The console provides two distinct filtering mechanisms:
+1. **Device Selection with Per-Device Minimum Level**: Which devices to show, and what minimum severity to require per device
+2. **Text Search**: What specific content are you looking for?
+
+**Per-Device Minimum Log Level**:
+Each device in the filter list can have its own minimum log level threshold, independent of the server-side global minimum. When a device is checked in the Devices dropdown, it defaults to `Information`. A nested level dropdown next to each checked device allows selecting a higher threshold (e.g. `Warning` or `Error`) to reduce noise from that specific device while keeping other devices at a lower threshold.
+
+**Why Per-Device Rather Than Global-Only**:
+- **Precision**: A busy device generating many `Information` messages can be silenced at `Warning` while other devices remain visible at `Information`
+- **Context Preservation**: Keeps the context of multiple devices without overwhelming the view with one device's verbose output
+- **Flexible Workflow**: Useful when one device is suspected of issues and you want high verbosity from it, but low noise from everything else
 
 **Why AND Logic**:
 - **Intuitive**: Matches mental model of "show me messages that are X AND Y AND Z"

docs/explanation/security.md

@@ -90,34 +90,21 @@ Web interface could be overwhelmed by requests:
 
 ### Authentication Model
 
-**Certificate-Based Authentication**:
-The system relies on the processor's built-in authentication:
-- Client certificates validate user identity
-- Self-signed certificates common in internal deployments
-- Certificate trust requires explicit user acceptance
-- Certificate revocation through processor management
+**Credential-Based Authentication**:
+The web app implements a credential-based login flow that gates access to all application features:
+
+- **Login Form**: Before any processor data is accessible, users must provide a username and password
+- **API Validation**: Credentials are submitted to `POST /cws/:appId/api/loginCredentials` on the processor
+- **Shared Authentication**: The processor backend uses a single authentication mechanism for all program slots — a successful login with any `appId` authenticates the entire session
+- **Global Session State**: Authentication state (`isAuthenticated: boolean`) is stored in Redux. A `RequireAuth` layout route protects all `/:appId/*` sub-routes and redirects unauthenticated users to the login page
+- **In-Memory Only**: The authentication state is not persisted to `localStorage` or cookies. Reloading the page requires re-authentication, providing natural session expiry
+- **App Discovery at Login**: After validating credentials, all 10 possible program slots are probed in parallel. Only slots that respond successfully are shown in the application selector
 
 **Session Management**:
-Web sessions are managed securely:
-- Session tokens generated using cryptographically secure random numbers
-- Session data stored server-side, not in cookies
-- Automatic session expiration after inactivity
-- Session invalidation on logout or timeout
-
-### Authorization Framework
-
-**Role-Based Access Control**:
-Access is controlled through processor-level permissions:
-- **System Administrator**: Full access to all features and data
-- **Operator**: Read access to operational data and controls
-- **Viewer**: Read-only access to status and configuration information
-- **Guest**: Minimal access to basic system information
-
-**Permission Inheritance**:
-Permissions are inherited from the processor's user management:
-- Web app does not maintain separate user database
-- Authorization decisions delegated to Essentials framework
-- Consistent access control across all system interfaces
+Web sessions are managed through the Redux store:
+- Session exists for the lifetime of the browser tab
+- Logging out (or reloading) resets all auth state
+- No session tokens are stored client-side beyond the duration of the session
 
 ## Data Protection
 

docs/how-to/filter-debug-messages.md

@@ -8,9 +8,33 @@
 
 **For immediate results:**
 1. **Device filter**: Click "Devices" dropdown → Select specific devices
-2. **Log level filter**: Click "Log Level" dropdown → Select "Warning" and "Error" only  
+2. **Per-device level**: Once a device is checked, use its inline level dropdown to set a minimum severity
 3. **Search box**: Type keywords related to your issue
-4. **Clear all**: Click "Clear" button to reset
+4. **Clear all**: Click "Clear Filters" button to reset all filters
+
+## Understanding the Filter Controls
+
+### Device Filter and Per-Device Minimum Level
+
+The Devices dropdown combines two capabilities:
+
+- **Checkbox per device**: Check a device to include its messages in the view
+- **Level dropdown per device**: When checked, each device gets an inline level dropdown defaulting to `Information`
+
+**To show only warnings and above from a specific device**:
+1. Click the **Devices** dropdown
+2. Check the device
+3. Click its inline level dropdown and select **Warning**
+4. Messages from that device below `Warning` are now hidden
+
+Multiple devices can each have different thresholds. For example:
+- `Display-Room1` → `Error` (only show errors from this noisy device)
+- `Codec-Main` → `Information` (show all normal activity)
+- Global → `Warning` (only warnings from system-level messages)
+
+### Text Search
+
+Type keywords in the search box to find messages whose rendered text, template, timestamp, or device key contains the term(s).
 
 ## Effective Search Strategies
 

docs/reference/api-endpoints.md

@@ -2,16 +2,42 @@
 
 **Complete technical reference for all REST API endpoints used by the PepperDash Essentials Web Config App.**
 
-All API endpoints are accessed through the base path `/cws/app01/api` on the processor's HTTPS port (443).
+All API endpoints are accessed through the base path `/cws/:appId/api` where `:appId` is the program slot identifier (e.g. `app01` through `app10`).
 
 ## Base Configuration
 
-**Base URL**: `https://[processor-ip]/cws/app01/api`
+**Base URL**: `https://[processor-ip]/cws/:appId/api`
 **Protocol**: HTTPS only
-**Authentication**: None (uses processor's built-in web authentication)
+**Authentication**: Credential-based via `POST /loginCredentials` (see below)
 **Content-Type**: `application/json` for POST requests
 **Response Format**: JSON
 
+## Authentication Endpoints
+
+### Set Login Credentials
+**Purpose**: Authenticate with the processor. The backend uses a single shared authentication mechanism for all program slots.
+
+```http
+POST /loginCredentials
+```
+
+**Request Body**:
+```json
+{
+  "username": "admin",
+  "password": "yourpassword"
+}
+```
+
+**Response**: `200 OK` (empty body) on success
+
+**Notes**:
+- A successful response with any `appId` authenticates the session for all running slots
+- The app probes all 10 slots in parallel after initial auth to discover which are running
+- A `4xx` or network error indicates invalid credentials or that the slot is not running
+
+---
+
 ## System Information Endpoints
 
 ### Get Versions
@@ -46,6 +72,42 @@ GET /versions
 
 ---
 
+### Get API Paths
+**Purpose**: Retrieve all available REST API routes registered on the processor
+
+```http
+GET /apiPaths
+```
+
+**Response**:
+```json
+{
+  "url": "https://192.168.1.100/cws/app01",
+  "routes": [
+    {
+      "Name": "getDevices",
+      "Url": "app01/api/devices",
+      "DataTokens": { "Name": "getDevices" },
+      "RouteHandler": null
+    }
+  ]
+}
+```
+
+**Response Fields**:
+- `url` (string): Base URL of the processor web server for this app slot
+- `routes` (array): List of route objects
+  - `Name` (string): Route name
+  - `Url` (string): Route URL relative to the base
+  - `DataTokens.Name` (string): Data token name when present
+
+**Usage**: Displayed on the API Paths page; routes are sorted alphabetically and shown with clickable URLs
+
+**Error Conditions**:
+- `500`: Server error if route information cannot be retrieved
+
+---
+
 ### Get Device Types
 **Purpose**: Retrieve all available device types supported by current plugins
 

docs/reference/log-levels.md

@@ -37,7 +37,41 @@
 - **Filtered out**: None
 - **Use case**: Deep debugging, code-level analysis
 
-## Message Classification
+## Client-Side Filtering
+
+### Per-Device Minimum Log Level Filter
+
+Each device checked in the Debug Console Devices dropdown has its own minimum log level threshold. Messages from that device are only shown if they meet or exceed that device's threshold.
+
+**Default**: `Information` when a device is first checked
+
+**Severity comparison**: `LOG_LEVEL_ORDER[message.Level] >= LOG_LEVEL_ORDER[deviceMinLevel]`
+
+where `LOG_LEVEL_ORDER` is:
+
+| Level | Order Value |
+|-------|-------------|
+| Verbose | 0 |
+| Debug | 1 |
+| Information | 2 |
+| Warning | 3 |
+| Error | 4 |
+| Fatal | 5 |
+
+**Example**: Device set to `Warning` — shows Warning, Error, Fatal; hides Information, Debug, Verbose
+
+**State**: Stored in Redux `debugConsole.deviceLevels` as `Record<deviceId, levelName>`; persists across navigation within the session
+
+### Filter Combination Logic
+
+All client-side filters use AND logic:
+- **Device filter**: Message key must match a checked device (or `Global`)
+- **Per-device minimum level**: Message severity must meet the device's threshold
+- **Text search**: All search terms must appear somewhere in the message fields
+
+### Server-Side Minimum Log Level
+
+The **Minimum Log Level** dropdown in the Debug Console session panel sets the server-side floor for all messages the processor sends to the client. Messages below this level are never transmitted, regardless of the client-side per-device settings. This controls what the processor captures and streams, while per-device levels control what the client displays after receipt.
 
 ### System-Level Messages