feat(guide): dev audience tier + GUIDE_SERVED_AUDIENCES env cap (prod = customer,internal)

4-tier ladder customer<internal<dev<bcos. Re-tagged Architect/Testing/Claude + platform/technical from internal->dev; Processes stays bcos. Backend visible() enforces a per-instance served-audiences cap at the API. bcos.dev/DLX serve all; production sets GUIDE_SERVED_AUDIENCES=customer,internal so dev/bcos never leave dev. Verified: capped instance returns only Customer+Internal, 404s dev/bcos. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-01 17:11:00 -04:00
parent e02aab4d3b
commit 930a4b968e
231 changed files with 262 additions and 233 deletions
@@ -22,6 +22,26 @@ public class MarkdownGuideService {

    private volatile List<GuideDoc> docs = List.of();

+    /** Which audience tiers this instance serves — the per-environment cap.
+     *  bcos.dev/DLX = all; production = customer,internal. */
+    @org.springframework.beans.factory.annotation.Value("${guide.served-audiences:customer,internal,dev,bcos}")
+    private String servedRaw;
+    private volatile Set<String> served;
+
+    private Set<String> served() {
+        Set<String> s = served;
+        if (s == null) {
+            s = new HashSet<>();
+            for (String x : servedRaw.split(",")) {
+                x = x.trim().toLowerCase(Locale.ROOT);
+                if (!x.isEmpty()) s.add(x);
+            }
+            served = s;
+            log.info("Guide serving audience tiers: {}", s);
+        }
+        return s;
+    }
+
    @PostConstruct
    public void load() {
        List<GuideDoc> loaded = new ArrayList<>();
@@ -79,12 +99,17 @@ public class MarkdownGuideService {
        return new GuideDoc(app, module, title, tab, order, audience, body);
    }

-    /** audience tiers: customer (all) < internal (MSP/BCOS admin) < bcos (BCOS admin only). */
+    /** Audience ladder: customer < internal < dev < bcos.
+     *  First the environment cap (served tiers), then the caller's role.
+     *  customer→all · internal/dev→MSP or BCOS admin · bcos→BCOS admin only. */
    private boolean visible(GuideDoc d, boolean includeInternal, boolean includeBcos) {
        String a = d.audience();
-        if ("bcos".equals(a)) return includeBcos;
-        if ("internal".equals(a)) return includeInternal;
-        return true;
+        if (!served().contains(a)) return false;      // environment cap (prod = customer,internal)
+        return switch (a) {
+            case "bcos" -> includeBcos;
+            case "internal", "dev" -> includeInternal;
+            default -> true;                          // customer
+        };
    }

    /** apps → modules → tabs, filtered by audience. */
@@ -23,6 +23,10 @@ internal.secret=${INTERNAL_SECRET:dev-internal-secret}

 cors.allowed-origins=${CORS_ALLOWED_ORIGINS:http://localhost:5188}

+# Audience tiers this instance serves (per-environment cap).
+# bcos.dev / DLX = all four; production = customer,internal (dev/bcos never leave dev).
+guide.served-audiences=${GUIDE_SERVED_AUDIENCES:customer,internal,dev,bcos}
+
 # In-guide feedback → Gitea issues (server-side token; reaches Gitea via public route)
 gitea.base-url=${GITEA_BASE_URL:https://hiveiq-gitea.directlx.dev}
 gitea.feedback.token=${GITEA_FEEDBACK_TOKEN:}
@@ -3,7 +3,7 @@ module: analytics.adoons
 title: Adoons Insights
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-analytics` source. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: analytics.adoons
 title: Adoons Insights
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > **Internal · agent reference.** Grounded in `hiveops-analytics` @ 2026-07-01. Only confirmed facts below.
@@ -3,7 +3,7 @@ module: analytics.adoons
 title: Adoons Insights
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Adoons Insights** (the **Fleet Insights** tab in Analytics, `analytics.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: analytics.agents
 title: Agents
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** Grounded in hiveops-analytics + hiveops-devices source (2026-07-01). Cross-link [platform.data-architecture], [platform.kafka], [platform.service-ownership], [technical.analytics].
@@ -3,7 +3,7 @@ module: analytics.agents
 title: Agents
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > **Internal · AI agent quick-ref.** Confirmed against source 2026-07-01. Act on confirmed facts only.
@@ -3,7 +3,7 @@ module: analytics.agents
 title: Agents
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Agents** tab in HiveIQ Analytics (`analytics.bcos.dev`). This tab is **view-only** — there is nothing to create, edit, or push. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: analytics.cash
 title: Cash Intelligence
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** Grounded in `hiveops-analytics` + `hiveops-recon` source, 2026-07-01. Key point: Cash Intelligence is a **synchronous fan-out**, not the usual executor→Kafka→record-store pattern. Analytics stores nothing for this feature and consumes no Kafka topic to build it.
@@ -3,7 +3,7 @@ module: analytics.cash
 title: Cash Intelligence
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Terse agent reference. Cash Intelligence = **read-only pass-through**: analytics re-shapes one recon call. Analytics owns NO cash data.
@@ -3,7 +3,7 @@ module: analytics.cash
 title: Cash Intelligence
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Cash Intelligence** tab (`analytics.bcos.dev`). Open the tab in the UI and mark each row Pass or Fail. This tab is **view-only** — there is nothing to create, edit, or delete.
@@ -3,7 +3,7 @@ module: analytics.fleet-health
 title: Fleet Health
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **How it's built.** Fleet Health is a **synchronous fan-out aggregation** — not a snapshot/Kafka read. Grounded in `FleetHealthController` + `FleetHealthService` (hiveops-analytics) and the frontend `FleetHealthTab.svelte`. Cross-link [platform.data-architecture], [platform.kafka], [platform.service-ownership].
@@ -3,7 +3,7 @@ module: analytics.fleet-health
 title: Fleet Health
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Act-without-guessing reference. All facts from `FleetHealthController`/`FleetHealthService`/`SecurityConfig` (hiveops-analytics) + `FleetHealthTab.svelte`/`api.ts`.
@@ -3,7 +3,7 @@ module: analytics.fleet-health
 title: Fleet Health
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Fleet Health** tab in **Analytics** (`analytics.bcos.dev`). Click through in the UI and mark each row Pass or Fail. This screen is **read-only** — there is nothing to create, edit, or delete.
@@ -3,7 +3,7 @@ module: analytics.incidents
 title: Incident Trends
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > How the **Incident Trends** tab is built. Grounded in `hiveops-analytics` + `hiveops-incident` source, 2026-07-01. Cross-link [platform.data-architecture], [platform.kafka], [platform.service-ownership].
@@ -3,7 +3,7 @@ module: analytics.incidents
 title: Incident Trends
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Terse agent reference. All facts confirmed in source 2026-07-01. `hiveops-ai` = "Adoons".
@@ -3,7 +3,7 @@ module: analytics.incidents
 title: Incident Trends
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Incident Trends** tab in Analytics (`analytics.bcos.dev`). This tab is **read-only** — there is nothing to create, edit, or delete, so the tests focus on the four panels rendering correctly and on role scoping. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: analytics.transactions
 title: Transactions
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > How the **Transactions** tab is built. It is a **synchronous pull-through aggregation**, not an event-driven or snapshot-backed view. Cross-link [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: analytics.transactions
 title: Transactions
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Act-without-guessing reference. Transactions tab = analytics UI tab `id: 'journal', label: 'Transactions'` → `JournalCoverageTab.svelte` → `GET /api/analytics/journal-coverage`. Data source of truth is **hiveops-journal**, not analytics.
@@ -3,7 +3,7 @@ module: analytics.transactions
 title: Transactions
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Transactions** tab in **Analytics** (`analytics.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: analytics.uptime
 title: Uptime
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **How Uptime is built.** Grounded in `hiveops-analytics` source (2026-07-01). Cross-link [platform.data-architecture], [platform.kafka], [platform.service-ownership].
@@ -3,7 +3,7 @@ module: analytics.uptime
 title: Uptime
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Terse agent reference for `analytics.uptime`. Only confirmed facts. Act, don't guess.
@@ -3,7 +3,7 @@ module: analytics.uptime
 title: Uptime
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Uptime** tab in Analytics (`analytics.bcos.dev`). This screen is **read-only** — there are no buttons, forms, or actions, so the tests are all about what you can *see*. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: aria.dashboard
 title: Threat Dashboard
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the ARIA Threat Dashboard is built. The dashboard is a **thin read-only aggregation view** — it does not own data, run detection, or consume Kafka. It renders one snapshot from `hiveops-aria`'s tables. All the interesting machinery (ingestion, IOC matching, sequence detection) runs upstream and only *populates* the tables this view reads.
@@ -3,7 +3,7 @@ module: aria.dashboard
 title: Threat Dashboard
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse act-without-guessing reference. Owner service: **`hiveops-aria`** (port **8095**, DB **`hiveiq_aria`**). Frontend: `hiveops-aria/frontend/src/components/Dashboard.svelte`.
@@ -3,7 +3,7 @@ module: aria.dashboard
 title: Threat Dashboard
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **ARIA Threat Dashboard** (`aria.bcos.dev`) — the landing screen of the ARIA SPA. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: aria.device-posture
 title: Device Posture
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **How Device Posture is built.** Grounded in `hiveops-aria` backend + `hiveops-agent/hiveops-module-aria-signals`. See also [technical.aria] for the wider ARIA service. Cross-links: [platform.data-architecture], [platform.kafka], [platform.service-ownership].
@@ -3,7 +3,7 @@ module: aria.device-posture
 title: Device Posture
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Terse agent reference. Every item below confirmed in `hiveops-aria` + `hiveops-agent/hiveops-module-aria-signals`. Act without guessing.
@@ -3,7 +3,7 @@ module: aria.device-posture
 title: Device Posture
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Device Posture** (`aria.bcos.dev`). Click through in the UI and mark each row Pass or Fail. This screen is **read-only** — there is nothing to create, edit, or delete.
@@ -3,7 +3,7 @@ module: aria.ioc-feeds
 title: IOC Feeds
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **IOC Feeds** feature is built. Everything for this feature lives inside **`hiveops-aria`** — it does not call any other HiveIQ service. Cross-link [platform.service-ownership].
@@ -3,7 +3,7 @@ module: aria.ioc-feeds
 title: IOC Feeds
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse agent reference. Everything below is confirmed in `hiveops-aria` source.
@@ -3,7 +3,7 @@ module: aria.ioc-feeds
 title: IOC Feeds
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **IOC Feeds** in ARIA (`aria.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: aria.ioc-management
 title: IOC Management
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the IOC watchlist is built and how it plugs into ARIA's threat pipeline. Cross-link [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: aria.ioc-management
 title: IOC Management
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse act-without-guessing reference. Owning service: **`hiveops-aria`** (port 8095, DB `hiveiq_aria`). Frontend: `hiveops-aria/frontend/src/components/IocManagement.svelte` via `ariaApi` → base `/api/aria`.
@@ -3,7 +3,7 @@ module: aria.ioc-management
 title: IOC Management
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **IOC Management** in ARIA (`aria.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: aria.precursor-alerts
 title: Precursor Alerts
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **Precursor Alerts** feature is built. Everything lives in **hiveops-aria** (port 8095, DB `hiveiq_aria`). ARIA owns detection end-to-end — it does not read another service's tables to build alerts. See [platform.service-ownership].
@@ -3,7 +3,7 @@ module: aria.precursor-alerts
 title: Precursor Alerts
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse agent reference. Owned by **hiveops-aria** (port 8095, DB `hiveiq_aria`). All facts below confirmed in code.
@@ -3,7 +3,7 @@ module: aria.precursor-alerts
 title: Precursor Alerts
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Precursor Alerts** (`aria.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: aria.threat-events
 title: Threat Events
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **Threat Events** feature is built. It is owned end-to-end by **`hiveops-aria`** (the threat-intelligence service, `spring.application.name=hiveops-aria`, DB `hiveiq_aria`). The screen is a thin read view; the interesting work happens in the ingest → classify → store → (optionally) publish pipeline. Cross-link [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: aria.threat-events
 title: Threat Events
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse act-without-guessing reference. Owner service: **`hiveops-aria`** (`hiveiq_aria` DB, port 8095). All facts below confirmed in `hiveops-aria` source.
@@ -3,7 +3,7 @@ module: aria.threat-events
 title: Threat Events
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Threat Events** (`aria.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: claims.claim-detail
 title: Claim Detail
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **Claim Detail** panel is built end-to-end. See [platform.service-ownership] — this feature is owned entirely by **hiveops-claims**; no other HiveOps service is called for claim, message, note, attachment, or payment data. The only external dependency is the device mirror (below).
@@ -3,7 +3,7 @@ module: claims.claim-detail
 title: Claim Detail
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse agent reference for the **Claim Detail** panel (`ClaimPanel.svelte`).
@@ -3,7 +3,7 @@ module: claims.claim-detail
 title: Claim Detail
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Claim Detail** panel (`claims.bcos.dev`). Open a claim, click through each tab, and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: claims.dashboard
 title: Claims Dashboard
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **Claims Dashboard** is built. It is a thin read view over one service — **hiveops-claims** owns all the data it shows. See [platform.service-ownership].
@@ -3,7 +3,7 @@ module: claims.dashboard
 title: Claims Dashboard
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse agent reference for the Claims Dashboard view. Owner service: **hiveops-claims** (`hiveiq-claims`, port 8092, image `hiveiq-claims`). Frontend: `Dashboard.svelte` in `hiveops-claims/frontend`.
@@ -3,7 +3,7 @@ module: claims.dashboard
 title: Claims Dashboard
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Claims Dashboard** (`claims.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: claims.settings
 title: Settings
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the Claims **Settings** (vendor email templates) feature is built. Single-service, synchronous, DB-backed — **no Kafka, no executor/record-store pattern** in this feature. See [platform.service-ownership].
@@ -3,7 +3,7 @@ module: claims.settings
 title: Settings
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse reference. Feature = **vendor email templates** shown on the Claims Settings screen (read-only display of the *effective* template).
@@ -3,7 +3,7 @@ module: claims.settings
 title: Settings
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Claims → Settings** (`claims.bcos.dev`). The Settings screen is a **read-only** view of the effective vendor-email template — there is nothing to create or edit here. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: claims.vendors
 title: Vendors
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** How the Vendor Registry feature is built. All facts grounded in hiveops-claims source (2026-07-01). See [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: claims.vendors
 title: Vendors
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Act-without-guessing reference. All items code-confirmed in hiveops-claims (2026-07-01) unless marked (unverified).
@@ -3,7 +3,7 @@ module: claims.vendors
 title: Vendors
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Vendor Registry** (`claims.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: dashboard.cash-stats
 title: Cash Stats
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **Cash Stats** page is built end-to-end. It is a thin read view over data that another service derives — the interesting work happens in `hiveops-journal`, not in the dashboard. See [platform.service-ownership].
@@ -3,7 +3,7 @@ module: dashboard.cash-stats
 title: Cash Stats
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse agent reference for `dashboard.cash-stats`. Read view over cassette bill counts.
@@ -3,7 +3,7 @@ module: dashboard.cash-stats
 title: Cash Stats
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Cash Stats** page (`dashboard.bcos.dev`). Click through in the UI and mark each row Pass or Fail. The page is **read-only** — there is nothing to create, edit, or delete, so testing is about what you can **see** and **filter**.
@@ -3,7 +3,7 @@ module: dashboard.overview
 title: Fleet Overview
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 ## Shape of the feature
@@ -3,7 +3,7 @@ module: dashboard.overview
 title: Fleet Overview
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 ## Identity
@@ -3,7 +3,7 @@ module: dashboard.overview
 title: Fleet Overview
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Fleet Overview** landing page (`dashboard.bcos.dev`). Click through in the UI and mark each row Pass or Fail. This screen is **read-only** — there is nothing to create, edit, or delete, so testing focuses on what each card shows and on role scoping.
@@ -3,7 +3,7 @@ module: devices.agent-profile
 title: Agent Profile
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **Agent Profile** feature is built end to end. Profiles are lightweight hardware-grouping records; the "which modules" logic is resolved at render time by joining profile records against a CDN-hosted module manifest. See [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: devices.agent-profile
 title: Agent Profile
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse act-without-guessing reference. Feature = hardware profiles controlling agent module provisioning.
@@ -3,7 +3,7 @@ module: devices.agent-profile
 title: Agent Profile
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Agent Profile** (Devices › Settings › Agent Profile, `devices.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: devices.agent-scripts
 title: Agent Scripts
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Architect · internal.** Written 2026-07-01 from source. Describes both what is **built** (a devices-owned CRUD store) and the **intended** signed-delivery pipeline that partly exists in hiveops-fleet + the agent but is **not yet connected** to this module's Push action.
@@ -3,7 +3,7 @@ module: devices.agent-scripts
 title: Agent Scripts
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Act-without-guessing reference. Only confirmed facts (hiveops-devices source, 2026-07-01).
@@ -3,7 +3,7 @@ module: devices.agent-scripts
 title: Agent Scripts
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Agent Scripts** (`devices.bcos.dev` → **Settings → Agent Scripts**). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: devices.config-audit
 title: Config Audit
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture view.** How Config Audit is built inside `hiveops-devices`. Grounded in source 2026-07-01.
@@ -3,7 +3,7 @@ module: devices.config-audit
 title: Config Audit
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Terse agent reference. All facts below verified in `hiveops-devices` source (2026-07-01).
@@ -3,7 +3,7 @@ module: devices.config-audit
 title: Config Audit
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Config Audit** in the Devices app (`devices.bcos.dev` → **Settings → Config Audit**, header reads **Config Change Audit**). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: devices.device-detail
 title: Device Detail
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the single-device page is built. Component `AtmDetail.svelte` (~4.2k lines) is a tabbed shell; the "Details" surface is owned by **hiveops-devices**, but the page is a **multi-service aggregator** — most tabs fan out to other backends. See [platform.service-ownership] and [technical.devices].
@@ -3,7 +3,7 @@ module: devices.device-detail
 title: Device Detail
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Act-without-guessing reference for `devices.device-detail` (`AtmDetail.svelte`).
@@ -3,7 +3,7 @@ module: devices.device-detail
 title: Device Detail
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Device Detail** page (`devices.bcos.dev`). Open a device, click through the tabs and actions, and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: devices.device-groups
 title: Device Groups
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** Grounded in `hiveops-devices` backend + `AtmGroups.svelte` + `api.ts` (2026-07-01).
@@ -3,7 +3,7 @@ module: devices.device-groups
 title: Device Groups
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 ## Owner
@@ -3,7 +3,7 @@ module: devices.device-groups
 title: Device Groups
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Device Groups** (`devices.bcos.dev` → **Device Groups**). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: devices.device-list
 title: Device List
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the Device List is built. Frontend: `hiveops-devices/frontend/src/components/AtmManagement/AtmList.svelte`. Backend of record: **hiveops-devices** (Spring Boot, port **8096**, DB `hiveiq_devices`). See [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: devices.device-list
 title: Device List
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse agent reference. Frontend: `hiveops-devices/frontend/src/components/AtmManagement/AtmList.svelte`.
@@ -3,7 +3,7 @@ module: devices.device-list
 title: Device List
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Device List** (`devices.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: devices.map
 title: Map
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** Grounded in `AtmMap.svelte`, `frontend/src/lib/{api,stores}.ts`, and the devices/incident controllers, 2026-07-01.
@@ -3,7 +3,7 @@ module: devices.map
 title: Map
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Terse agent reference. Grounded in `AtmMap.svelte`, `lib/api.ts`, `lib/stores.ts`, `AtmController`, `AtmGroupController`, `IncidentController` (2026-07-01). Read-only view — no writes, no dedicated backend.
@@ -3,7 +3,7 @@ module: devices.map
 title: Map
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Fleet Map** (`devices.bcos.dev` → **Map**). It's a read-only view — no create/edit/delete. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: devices.sw-deploy
 title: Software Deployment
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-devices/frontend` + `hiveops-fleet/backend`. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: devices.sw-deploy
 title: Software Deployment
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 **Owner service:** `hiveops-fleet` (port **8097**, DB **`hiveiq_fleet`**). Frontend `DeviceSoftwareTab.svelte` lives in `hiveops-devices` but calls fleet only. NOT owned by devices/incident.
@@ -3,7 +3,7 @@ module: devices.sw-deploy
 title: Software Deployment
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **SW Deploy** tab (`devices.bcos.dev` → open a device → **SW Deploy** tab). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: fleet.artifacts
 title: Artifact Import Guide
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > How artifact import is built inside **hiveops-fleet**. Scope: the `fleet_artifacts` lifecycle — CDN import, multipart upload, and how an agent ultimately gets the bytes. Cross-link [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: fleet.artifacts
 title: Artifact Import Guide
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > Act-without-guessing cheat-sheet. Owner service: **hiveops-fleet** (`com.hiveops.fleet`, port 8097, DB `hiveiq_fleet`). Never write artifact data anywhere else.
@@ -3,7 +3,7 @@ module: fleet.artifacts
 title: Artifact Import Guide
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Fleet → Artifacts** (`fleet.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: fleet.dashboard
 title: Fleet Dashboard
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How the **Fleet Stats** dashboard is built. It is a thin read-only view over hiveops-fleet's own database — no cross-service HTTP at request time. Cross-link [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: fleet.dashboard
 title: Fleet Dashboard
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Terse agent reference for the **Fleet Stats** dashboard (`FleetDashboard.svelte`).
@@ -3,7 +3,7 @@ module: fleet.dashboard
 title: Fleet Dashboard
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Fleet Stats** dashboard (`fleet.bcos.dev`). It is a read-only screen — no create/edit/delete. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: fleet.modules
 title: Modules
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-fleet` source. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: fleet.modules
 title: Modules
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-fleet` source 2026-07-01.
@@ -3,7 +3,7 @@ module: fleet.modules
 title: Modules
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for the **Agent Modules** screen (`fleet.bcos.dev`). This screen is a read-only reference catalog — there is nothing to create, edit, or delete. Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: fleet.patch-windows
 title: Patch Window Guide
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How HiveIQ Patch Windows are built. Everything lives inside **hiveops-fleet** (`com.hiveops.fleet`, Spring Boot 3.4, port 8097, DB `hiveiq_fleet`). Patch windows are a scheduling overlay on the existing fleet-task pipeline — no dedicated microservice. Cross-link [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: fleet.patch-windows
 title: Patch Window Guide
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Act-without-guessing cheat-sheet. Everything confirmed in `hiveops-fleet` source.
@@ -3,7 +3,7 @@ module: fleet.patch-windows
 title: Patch Window Guide
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Fleet → Patch Windows** (`fleet.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: fleet.tasks
 title: Fleet Task Workflow
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 How Fleet Task Workflow is built. Owner service: **hiveops-fleet** (`com.hiveops.fleet`, Spring Boot 3.4, port 8097, DB `hiveiq_fleet`). Frontend: `FleetManagement/FleetTasks.svelte` → `lib/api.ts` (`fleetAPI`, base `…/api/fleet`). See also [platform.data-architecture] and [platform.kafka]; service-level scope in the technical `fleet/overview` doc.
@@ -3,7 +3,7 @@ module: fleet.tasks
 title: Fleet Task Workflow
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 Act-without-guessing cheat-sheet. Owner service: **hiveops-fleet** ONLY.
@@ -3,7 +3,7 @@ module: fleet.tasks
 title: Fleet Task Workflow
 tab: Testing
 order: 35
-audience: internal
+audience: dev
 ---

 Frontend test checklist for **Fleet Tasks** (`fleet.bcos.dev`). Click through in the UI and mark each row Pass or Fail.
@@ -3,7 +3,7 @@ module: incident.dashboard
 title: Dashboard
 tab: Architect
 order: 30
-audience: internal
+audience: dev
 ---

 > **How it's built.** The Dashboard is a thin read-only aggregation view: one Svelte component, three GET endpoints, all served by **hiveops-incident**. There is no dedicated dashboard aggregation service — most of the "analytics" (trend chart, incidents-by-type, device/agent status breakdowns) is computed **client-side** in the component from two data stores. See [platform.service-ownership].
@@ -3,7 +3,7 @@ module: incident.dashboard
 title: Dashboard
 tab: Claude
 order: 40
-audience: internal
+audience: dev
 ---

 ## Owner
--- a/Show More
+++ b/Show More