Add platform health dashboard

docs/frontend/audit-capability-card.md

@@ -2,120 +2,50 @@
 
 This document describes the audit capability card component, its various states, and how to test them both manually and automatically.
 
+For shared frontend mock and Vitest workflow, see `docs/frontend/testing-basics.md`.
+
 ## Overview
 
 The Audit Capability Card displays on the ServicePulse dashboard and shows the status of the auditing feature. The card's status depends on:
 
 1. Whether audit instances are configured
-2. Whether audit instances are available (online)
-3. Whether successful messages exist (endpoints configured for auditing)
+2. Whether all or only some audit instances are available
+3. Capability-specific message readiness shown by the `Messages` indicator
 4. Whether the ServiceControl version supports the "All Messages" feature (>= 6.6.0)
 
 ## Card States
 
-| Status                   | Condition                                        | Badge       | Action Button |
-|--------------------------|--------------------------------------------------|-------------|---------------|
-| Instance Not Configured  | No audit instances configured                    | -           | Get Started   |
-| Unavailable              | All audit instances offline                      | Unavailable | Learn More    |
-| Degraded                 | Some audit instances offline                     | Degraded    | -             |
-| Endpoints Not Configured | Instance available but no messages OR SC < 6.6.0 | -           | Learn More    |
-| Available                | Instance available with messages AND SC >= 6.6.0 | Available   | View Messages |
-
-## Manual Testing with Mock Scenarios
-
-### Prerequisites
-
-```bash
-cd src/Frontend
-npm install
-```
-
-### Running the Dev Server with Mocks
+| Status                  | Condition                     | Badge          | Action Button |
+|-------------------------|-------------------------------|----------------|---------------|
+| Instance Not Configured | No audit instances configured | Not configured | Get Started   |
+| Unavailable             | All audit instances offline   | Unavailable    | Learn More    |
+| Degraded                | Some audit instances offline  | Degraded       | Learn More    |
+| Available               | All audit instances available | Available      | View Messages |
 
-```bash
-npm run dev:mocks
-```
+The `Messages` indicator carries the capability-specific readiness state. If no successful messages exist yet, or if `All Messages` is not supported, the card remains `Available` while the indicator is yellow.
 
-This starts the dev server at `http://localhost:5173` with MSW (Mock Service Worker) intercepting API calls.
+An audit instance that is degraded but still responding remains available for this card. Only unavailable audit instances affect the badge state.
 
-### Switching Between Scenarios
-
-Set the `VITE_MOCK_SCENARIO` environment variable before running the dev server:
-
-```bash
-# Linux/macOS
-VITE_MOCK_SCENARIO=audit-available npm run dev:mocks
+## Manual Testing with Mock Scenarios
 
-# Windows CMD
-set VITE_MOCK_SCENARIO=audit-available && npm run dev:mocks
+Start from the shared frontend mocking workflow in `docs/frontend/testing-basics.md`, then select one of the audit scenarios below.
 
-# Windows PowerShell
-$env:VITE_MOCK_SCENARIO="audit-available"; npm run dev:mocks
-```
+For the shared meaning of audit and remote error platform instances, use `docs/frontend/platform-health-page.md` as the canonical reference. This page documents only the auditing-specific layer on top.
 
-Open the browser console to see available scenarios.
+### Available Audit Scenarios
 
-#### Available Audit Scenarios
-
-| Scenario                   | Status                   | Badge       | Button        | Description                                                                                          | Indicators                                |
-|----------------------------|--------------------------|-------------|---------------|------------------------------------------------------------------------------------------------------|-------------------------------------------|
-| `audit-no-instance`        | Instance Not Configured  | -           | Get Started   | "A ServiceControl Audit instance has not been configured..."                                         | None                                      |
-| `audit-unavailable`        | Unavailable              | Unavailable | Learn More    | "All ServiceControl Audit instances are configured but not responding..."                            | Instance: ❌                               |
-| `audit-degraded`           | Partially Unavailable    | Degraded    | -             | "Some ServiceControl Audit instances are not responding."                                            | Instance 1: ✅, Instance 2: ❌, Messages: ✅ |
-| `audit-available`          | Available                | Available   | View Messages | "All ServiceControl Audit instances are available and endpoints have been configured..."             | Instance: ✅, Messages: ✅                  |
-| `audit-old-sc-version`     | Endpoints Not Configured | -           | Learn More    | "A ServiceControl Audit instance is connected but no successful messages..."                         | Instance: ✅, Messages: ⚠️ (SC < 6.6.0)    |
-| `audit-no-messages`        | Endpoints Not Configured | -           | Learn More    | "A ServiceControl Audit instance is connected but no successful messages have been processed yet..." | Instance: ✅, Messages: ⚠️                 |
-| `audit-multiple-instances` | Available                | Available   | View Messages | "All ServiceControl Audit instances are available..."                                                | Instance 1: ✅, Instance 2: ✅, Messages: ✅ |
+| Scenario                   | Status                  | Badge          | Button        | Description                                                       | Indicators      |
+|----------------------------|-------------------------|----------------|---------------|-------------------------------------------------------------------|-----------------|
+| `audit-no-instance`        | Instance Not Configured | Not configured | Get Started   | "A ServiceControl Audit instance has not been configured..."     | None            |
+| `audit-unavailable`        | Unavailable             | Unavailable    | Learn More    | "All ServiceControl Audit instances are configured but not responding..." | None    |
+| `audit-degraded`           | Degraded                | Degraded       | Learn More    | "Some ServiceControl Audit instances are not responding."        | Messages: ✅     |
+| `audit-available`          | Available               | Available      | View Messages | "All ServiceControl Audit instances are available."              | Messages: ✅     |
+| `audit-old-sc-version`     | Available               | Available      | View Messages | "All ServiceControl Audit instances are available."              | Messages: ⚠️     |
+| `audit-no-messages`        | Available               | Available      | View Messages | "All ServiceControl Audit instances are available."              | Messages: ⚠️     |
+| `audit-multiple-instances` | Available               | Available      | View Messages | "All ServiceControl Audit instances are available."              | Messages: ✅     |
 
 **Indicator Legend:** ✅ = Available/Success, ❌ = Unavailable/Error, ⚠️ = Warning/Not Configured
 
-### Adding New Scenarios
-
-1. Add a scenario precondition to `src/Frontend/test/preconditions/platformCapabilities.ts`:
-
-```typescript
-export const scenarioMyScenario = async ({ driver }: SetupFactoryOptions) => {
-  await driver.setUp(precondition.serviceControlWithMonitoring);
-  // Add scenario-specific preconditions here
-};
-```
-
-2. Create a new file in `src/Frontend/test/mocks/scenarios/` (e.g., `my-scenario.ts`):
-
-```typescript
-import { setupWorker } from "msw/browser";
-import { Driver } from "../../driver";
-import { makeMockEndpoint, makeMockEndpointDynamic } from "../../mock-endpoint";
-import * as precondition from "../../preconditions";
-
-export const worker = setupWorker();
-const mockEndpoint = makeMockEndpoint({ mockServer: worker });
-const mockEndpointDynamic = makeMockEndpointDynamic({ mockServer: worker });
-
-const makeDriver = (): Driver => ({
-  goTo() { throw new Error("Not implemented"); },
-  mockEndpoint,
-  mockEndpointDynamic,
-  setUp(factory) { return factory({ driver: this }); },
-  disposeApp() { throw new Error("Not implemented"); },
-});
-
-const driver = makeDriver();
-
-export const setupComplete = (async () => {
-  await driver.setUp(precondition.scenarioMyScenario);
-})();
-```
-
-1. Register it in `src/Frontend/test/mocks/scenarios/index.ts`:
-
-```typescript
-const scenarios: Record<string, () => Promise<ScenarioModule>> = {
-  // ... existing scenarios
-  "my-scenario": () => import("./my-scenario"),
-};
-```
-
 ## Automated Tests
 
 ### Test Files
@@ -127,34 +57,26 @@ const scenarios: Record<string, () => Promise<ScenarioModule>> = {
 
 ### Running Automated Tests
 
-From the `src/Frontend` directory:
+Use the shared commands in `docs/frontend/testing-basics.md`, then run these audit-specific specs:
 
 ```bash
-# Run all audit capability tests
 npx vitest run test/specs/platformcapabilities/audit-capability-card.spec.ts
-
-# Run helper function unit tests
 npx vitest run test/specs/platformcapabilities/auditing-capability-helpers.spec.ts
-
-# Run all platform capability tests
-npx vitest run test/specs/platformcapabilities/
 ```
 
 ### Test Coverage
 
 #### Application Tests (`audit-capability-card.spec.ts`)
 
-| Rule                            | Test Case                                                     |
-|---------------------------------|---------------------------------------------------------------|
-| No audit instance configured    | Shows "Get Started" button                                    |
-| Audit instance unavailable      | Shows "Unavailable" status                                    |
-| Partially unavailable instances | Shows "Degraded" status                                       |
-| Available but no messages       | Shows "Endpoints Not Configured" status                       |
-| Available with messages         | Shows "Available" status + "View Messages" button             |
-| ServiceControl < 6.6.0          | Shows "Endpoints Not Configured" (All Messages not supported) |
-| Single instance indicator       | Shows "Instance" label                                        |
-| Messages indicator              | Shows "Messages" label when messages exist                    |
-| Multiple instances              | Shows numbered "Instance 1", "Instance 2" labels              |
+| Rule                            | Test Case                                                         |
+|---------------------------------|-------------------------------------------------------------------|
+| No audit instance configured    | Shows "Get Started" button                                      |
+| Audit instance unavailable      | Shows "Unavailable" status                                      |
+| Partially unavailable instances | Shows "Degraded" status                                         |
+| Available but no messages       | Keeps card available and shows a warning `Messages` indicator     |
+| Available with messages         | Shows "Available" status + "View Messages" button               |
+| ServiceControl < 6.6.0          | Keeps card available and shows warning `Messages` indicator       |
+| Shared card signals             | Shows only the shared `Messages` indicator, not per-instance ones |
 
 #### Unit Tests (`auditing-capability-helpers.spec.ts`)
 
@@ -173,23 +95,27 @@ npx vitest run test/specs/platformcapabilities/
 |---------------------------------------------------------------------------------------|----------------------------------------|
 | `src/Frontend/src/components/platformcapabilities/capabilities/AuditingCapability.ts` | Main composable and helper functions   |
 | `src/Frontend/src/components/audit/isAllMessagesSupported.ts`                         | Version check for All Messages feature |
+| `src/Frontend/src/stores/PlatformModelStore.ts`                                       | Shared platform model for audit instances |
 | `src/Frontend/test/preconditions/platformCapabilities.ts`                             | Test preconditions and fixtures        |
 | `src/Frontend/test/mocks/scenarios/`                                                  | Manual testing scenarios               |
 
-## Troubleshooting
+## Status Indicators
 
-### Scenario not loading
+The auditing card no longer renders per-instance widgets.
 
-1. Check the browser console for errors
-2. Verify the scenario name matches exactly (case-sensitive)
-3. Ensure MSW is enabled (look for "[MSW] Mocking enabled" in console)
+It shows a single `Messages` indicator when at least one audit instance is available:
+
+- green when `All Messages` is supported and successful messages exist
+- yellow when no successful messages exist yet
+- yellow when the current ServiceControl version does not support `All Messages`
+
+Instance-level audit visibility lives on the `Platform health` page.
+
+## Troubleshooting
 
-### Tests failing
+Use `docs/frontend/testing-basics.md` for shared troubleshooting.
 
-1. Run `npm run type-check` to verify TypeScript compilation
-2. Check if preconditions are properly set up
-3. Use `--reporter=verbose` for detailed test output:
+Audit-specific checks:
 
-   ```bash
-   npx vitest run test/specs/platformcapabilities/ --reporter=verbose
-   ```
+1. If the card badge is wrong, inspect whether the scenario is changing instance availability or only message readiness.
+2. If the `Messages` indicator is wrong, check both successful-message mocks and the ServiceControl version used by the scenario.

docs/frontend/custom-checks-page.md

@@ -0,0 +1,109 @@
+# Custom Checks Page Testing Guide
+
+This document describes the frontend Custom Checks page behavior, with a focus on internal platform custom checks and how they relate to other frontend views.
+
+For shared frontend mock and Vitest workflow, see `docs/frontend/testing-basics.md`.
+
+## Overview
+
+The Custom Checks page shows failing custom checks reported to ServiceControl.
+
+Internal platform custom checks are handled differently from user-defined custom checks:
+
+- they are hidden by default from the Custom Checks page
+- they are hidden by default from the Custom Checks dashboard tile and menu badge
+- operators can reveal them with `Show platform custom checks` when internal checks are present
+- Platform health consumes those internal checks as secondary platform signals
+
+## Internal Platform Custom Checks
+
+ServiceControl now marks internal custom checks with `internal: true`.
+
+The frontend uses that flag for two different purposes:
+
+1. filtering internal platform checks out of the Custom Checks UI by default
+2. recognizing internal platform checks that Platform health can use as secondary instance signals
+
+Older ServiceControl versions may omit the flag. In that case, the check is treated as non-internal.
+
+## Page Behavior
+
+The Custom Checks page:
+
+- fetches failed custom checks from `customchecks?status=fail&page=<n>`
+- shows only non-internal custom checks by default
+- exposes `Show platform custom checks` to reveal internal platform checks when any are present
+- keeps pagination tied to the visible filtered list
+
+Relevant frontend pieces:
+
+- `src/Frontend/src/views/CustomChecksView.vue`
+- `src/Frontend/src/stores/CustomChecksStore.ts`
+- `src/Frontend/src/components/customchecks/CustomCheckView.vue`
+
+## Platform Health Relationship
+
+Platform health uses internal platform checks even when the Custom Checks page hides them.
+
+Platform health also refreshes those custom checks directly, so this behavior does not depend on visiting the Custom Checks page first.
+
+That logic is documented in:
+
+- `docs/frontend/platform-health-page.md`
+
+When Platform health assigns an internal custom check to a specific platform instance, it uses:
+
+- instance assignment by `originating_endpoint.name`
+
+The Custom Checks page itself does not perform that instance correlation. It only exposes the raw custom check data and the show/hide toggle.
+
+## Manual Testing with Mock Scenarios
+
+Start from the shared frontend mocking workflow in `docs/frontend/testing-basics.md`.
+
+For internal platform custom check behavior, the most useful mock setup is:
+
+- `VITE_MOCK_SCENARIO=platform-health npm run dev:mocks`
+
+Then use:
+
+- `window.__platformHealth.setCustomCheckPreset("none")`
+- `window.__platformHealth.setCustomCheckPreset("user-only")`
+- `window.__platformHealth.setCustomCheckPreset("platform-only-primary-degraded")`
+- `window.__platformHealth.setCustomCheckPreset("platform-only-audit")`
+- `window.__platformHealth.setCustomCheckPreset("mixed-primary-and-user")`
+
+### Manual Checks
+
+| Behavior | How to exercise it |
+|----------|--------------------|
+| Internal platform checks hidden by default | Apply `platform-only-primary-degraded` or `platform-only-audit`, then open Custom Checks page |
+| Internal platform checks shown when toggled on | Apply a platform-only preset, enable `Show platform custom checks` |
+| User-defined checks visible by default | Apply `user-only` or `mixed-primary-and-user` |
+| Platform health reacts to hidden internal checks | Apply `platform-only-primary-degraded` or `platform-only-audit`, then compare Platform health with Custom Checks page |
+
+## Automated Tests
+
+### Test Files
+
+| File | Type | Description |
+|------|------|-------------|
+| `src/Frontend/src/stores/CustomChecksStore.spec.ts` | Unit | internal check filtering and toggle behavior |
+
+### Running Automated Tests
+
+Use the shared commands in `docs/frontend/testing-basics.md`, then run:
+
+```bash
+npx vitest run src/stores/CustomChecksStore.spec.ts
+```
+
+## Troubleshooting
+
+Use `docs/frontend/testing-basics.md` for shared troubleshooting.
+
+Custom Checks-specific checks:
+
+1. If an internal platform check is visible unexpectedly, confirm `showPlatformCustomChecks` is off.
+2. If Platform health reacts to a check that the page is hiding, that is expected behavior.
+3. If an internal check is classified incorrectly, inspect the `internal` flag in the ServiceControl response.