fix(guide): gate Architect + Claude tabs to BCOS_ADMIN only (#16)

The 162 Architect/Claude docs were tagged 'audience: dev'. The 'dev' tier resolves to isInternal() = ROLE_MSP_ADMIN || ROLE_BCOS_ADMIN, so every MSP_ADMIN could read full internal architecture: source paths, DB tables, service ports, NGINX routes. Verified live on bcos.dev as msp_a@msp1.bcos.dev. Retag them to 'audience: bcos' (isBcos, BCOS_ADMIN only). Content-only change; the 'dev' tier mapping is deliberately left alone so the 15 Internal, 35 Overview and 66 Testing docs stay MSP-visible. Also add platform.guide-access documenting the audience tiers and the per-role visibility matrix, so the access model is queryable from the Guide instead of re-derived from source each time. Verified: MSP module count unchanged (116 across 17 apps); no module loses all its tabs. Guide is bcos.dev only, not deployed to production. Closes #16 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-14 17:55:07 -04:00
parent 32bc8e7440
commit f21c783d8c
163 changed files with 259 additions and 162 deletions
@@ -3,7 +3,7 @@ module: agent.activeteller
 title: Active Teller (IAT) — teller-session, core-banking & Check21 monitoring for Nautilus Hyosung ITMs
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-module-activeteller` source. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: agent.activeteller
 title: Active Teller (IAT) — teller-session, core-banking & Check21 monitoring for Nautilus Hyosung ITMs
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-activeteller` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.aria-signals
 title: ARIA Security Signals — ATM threat-signal collector
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · how it's built.** Confirmed against `hiveops-module-aria-signals` source (`com.hiveops.aria`) 2026-07-01. See [technical.agent] for agent-wide module-system context.
@@ -3,7 +3,7 @@ module: agent.aria-signals
 title: ARIA Security Signals — ATM threat-signal collector
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-aria-signals` source (`com.hiveops.aria`) 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.atec-tcr-events
 title: ATEC TCR Events — cassette + process monitoring for LG Teller Cash Recyclers
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-module-atec-tcr-events` source. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: agent.atec-tcr-events
 title: ATEC TCR Events — cassette + process monitoring for LG Teller Cash Recyclers
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-atec-tcr-events` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.atm-config-sync
 title: ATM Config Sync — pushes ATM hardware/software/cassette config to the platform
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-module-atm-config-sync` source. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: agent.atm-config-sync
 title: ATM Config Sync — pushes ATM hardware/software/cassette config to the platform
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-atm-config-sync` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.ejournal-db-monitor
 title: EJournal DB Monitor — how it's built
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 # EJournal DB Monitor (Architecture)
@@ -3,7 +3,7 @@ module: agent.ejournal-db-monitor
 title: EJournal DB Monitor — act-without-guessing reference
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 # EJournal DB Monitor (Claude quick-reference)
@@ -3,7 +3,7 @@ module: agent.hw-inventory
 title: Hardware Inventory — ATM hardware/OS inventory sync + CDN bandwidth probe
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · architecture view.** Confirmed against `hiveops-module-hw-inventory` source 2026-07-01. See [technical.agent] for the module system as a whole.
@@ -3,7 +3,7 @@ module: agent.hw-inventory
 title: Hardware Inventory — ATM hardware/OS inventory sync + CDN bandwidth probe
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-hw-inventory` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.log-collect
 title: Log Collect Path — on-demand file/log pull from an arbitrary ATM path
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · how it's built.** Confirmed against `hiveops-module-log-collect` source (`com.hiveops.logcollect`) 2026-07-01. See [technical.agent] for agent-wide context (module system, HTTP layer, platform abstraction).
@@ -3,7 +3,7 @@ module: agent.log-collect
 title: Log Collect Path — on-demand file/log pull from an arbitrary ATM path
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-log-collect` source 2026-07-01. Every key/string below is from code; nothing invented.
@@ -3,7 +3,7 @@ module: agent.log
 title: Agent Log — self-log upload & error-to-incident monitoring
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · how it's built.** Confirmed against `hiveops-module-log` source (`com.hiveops.logs`) 2026-07-01. See [technical.agent] for agent-wide module/lifecycle context.
@@ -3,7 +3,7 @@ module: agent.log
 title: Agent Log — self-log upload & error-to-incident monitoring
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-log` source (`com.hiveops.logs`) 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.nh-tcr-events
 title: NH TCR Events — cassette + firmware monitoring for Nautilus Hyosung / Glory BRM30 recyclers
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-module-nh-tcr-events` source. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: agent.nh-tcr-events
 title: NH TCR Events — cassette + firmware monitoring for Nautilus Hyosung / Glory BRM30 recyclers
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-nh-tcr-events` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.nh-tcr-journal
 title: NH TCR Journal — transaction + fault events from Nautilus Hyosung Teller Cash Recyclers
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · architecture.** Written 2026-07-01 from `hiveops-module-nh-tcr-journal` source. Verify against code before relying on specifics.
@@ -3,7 +3,7 @@ module: agent.nh-tcr-journal
 title: NH TCR Journal — transaction + fault events from Nautilus Hyosung Teller Cash Recyclers
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-nh-tcr-journal` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.packet-capture
 title: Packet Capture — on-demand network capture for ATM diagnostics
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · how it's built.** Confirmed against `hiveops-module-packet-capture` source (`com.hiveops.packetcapture`) 2026-07-01. See [technical.agent] for agent-wide context.
@@ -3,7 +3,7 @@ module: agent.packet-capture
 title: Packet Capture — on-demand network capture for ATM diagnostics
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-packet-capture` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.remote
 title: Remote Control Module — how it's built
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Architect · dev view.** Grounded in `hiveops-module-remote` source (parent v4.4.3, module `pom` version 1.0.0) on 2026-07-01. See [technical.agent] for the shared module system this plugs into.
@@ -3,7 +3,7 @@ module: agent.remote
 title: Remote Control Module — Claude quick reference
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > Terse, act-without-guessing reference. Everything below is confirmed in `hiveops-module-remote` source (parent v4.4.3) unless marked `(unverified)`.
@@ -3,7 +3,7 @@ module: agent.srv-monitor
 title: Server Monitor — CPU/memory/disk/service health watcher for SRV devices
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · how it's built.** Confirmed against `hiveops-module-srv-monitor` source (`com.hiveops.srvmonitor`) 2026-07-01. See [technical.agent] for agent-wide module-system and event-pipeline context.
@@ -3,7 +3,7 @@ module: agent.srv-monitor
 title: Server Monitor — CPU/memory/disk/service health watcher for SRV devices
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse, act-without-guessing. Confirmed against `hiveops-module-srv-monitor` source 2026-07-01.
@@ -3,7 +3,7 @@ module: agent.tcr-events
 title: TCR Events — cassette + sensor + process monitoring for Teller Cash Recyclers
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Architect · dev.** Written 2026-07-01 from the compiled `hiveops-module-tcr-events` artifact (v4.3.5); `.java` sources are absent from the working tree, so class/method flow below is reconstructed from bytecode in `target/classes`. Cross-reference [technical.agent] for the module system and event pipeline.
@@ -3,7 +3,7 @@ module: agent.tcr-events
 title: TCR Events — cassette + sensor + process monitoring for Teller Cash Recyclers
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Claude · terse act-without-guessing reference.** From compiled `hiveops-module-tcr-events` v4.3.5 (`.java` not in tree; read from bytecode + core `IncidentEventClient`/`HttpClientHelper`).
@@ -3,7 +3,7 @@ module: agent.win-app-events
 title: Windows App Event Log Monitor — forwards Windows Application-log errors as HiveIQ incidents
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **Internal · how it's built.** Confirmed against `hiveops-module-win-app-events` source (`com.hiveops.winevents`) 2026-07-01. See [technical.agent] for agent-wide module/event context.
@@ -3,7 +3,7 @@ module: agent.win-app-events
 title: Windows App Event Log Monitor — forwards Windows Application-log errors as HiveIQ incidents
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-module-win-app-events` source (`com.hiveops.winevents`) 2026-07-01.
@@ -3,7 +3,7 @@ module: analytics.adoons
 title: Adoons Insights
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Grounded in `hiveops-analytics` @ 2026-07-01. Only confirmed facts below.
@@ -3,7 +3,7 @@ module: analytics.agents
 title: Agents
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > **Internal · AI agent quick-ref.** Confirmed against source 2026-07-01. Act on confirmed facts only.
@@ -3,7 +3,7 @@ module: analytics.cash
 title: Cash Intelligence
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > 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.fleet-health
 title: Fleet Health
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > Act-without-guessing reference. All facts from `FleetHealthController`/`FleetHealthService`/`SecurityConfig` (hiveops-analytics) + `FleetHealthTab.svelte`/`api.ts`.
@@ -3,7 +3,7 @@ module: analytics.incidents
 title: Incident Trends
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > 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: dev
+audience: bcos
 ---

 > Terse agent reference. All facts confirmed in source 2026-07-01. `hiveops-ai` = "Adoons".
@@ -3,7 +3,7 @@ module: analytics.transactions
 title: Transactions
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > 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: dev
+audience: bcos
 ---

 > 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.uptime
 title: Uptime
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > Terse agent reference for `analytics.uptime`. Only confirmed facts. Act, don't guess.
@@ -3,7 +3,7 @@ module: aria.dashboard
 title: Threat Dashboard
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 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.device-posture
 title: Device Posture
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > 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.ioc-feeds
 title: IOC Feeds
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Terse agent reference. Everything below is confirmed in `hiveops-aria` source.
@@ -3,7 +3,7 @@ module: aria.ioc-management
 title: IOC Management
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 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.precursor-alerts
 title: Precursor Alerts
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Terse agent reference. Owned by **hiveops-aria** (port 8095, DB `hiveiq_aria`). All facts below confirmed in code.
@@ -3,7 +3,7 @@ module: aria.threat-events
 title: Threat Events
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 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: claims.claim-detail
 title: Claim Detail
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Terse agent reference for the **Claim Detail** panel (`ClaimPanel.svelte`).
@@ -3,7 +3,7 @@ module: claims.dashboard
 title: Claims Dashboard
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 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.settings
 title: Settings
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 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.vendors
 title: Vendors
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > Act-without-guessing reference. All items code-confirmed in hiveops-claims (2026-07-01) unless marked (unverified).
@@ -3,7 +3,7 @@ module: dashboard.cash-stats
 title: Cash Stats
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Terse agent reference for `dashboard.cash-stats`. Read view over cassette bill counts.
@@ -3,7 +3,7 @@ module: dashboard.overview
 title: Fleet Overview
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

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

 ## Identity
@@ -3,7 +3,7 @@ module: devices.agent-profile
 title: Agent Profile
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Terse act-without-guessing reference. Feature = hardware profiles controlling agent module provisioning.
@@ -3,7 +3,7 @@ module: devices.agent-scripts
 title: Agent Scripts
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > Act-without-guessing reference. Only confirmed facts (hiveops-devices source, 2026-07-01).
@@ -3,7 +3,7 @@ module: devices.config-audit
 title: Config Audit
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > Terse agent reference. All facts below verified in `hiveops-devices` source (2026-07-01).
@@ -3,7 +3,7 @@ module: devices.device-detail
 title: Device Detail
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Act-without-guessing reference for `devices.device-detail` (`AtmDetail.svelte`).
@@ -3,7 +3,7 @@ module: devices.device-groups
 title: Device Groups
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 ## Owner
@@ -3,7 +3,7 @@ module: devices.device-list
 title: Device List
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Terse agent reference. Frontend: `hiveops-devices/frontend/src/components/AtmManagement/AtmList.svelte`.
@@ -3,7 +3,7 @@ module: devices.map
 title: Map
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > 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.sw-deploy
 title: Software Deployment
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 **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: fleet.artifacts
 title: Artifact Import Guide
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > 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: dev
+audience: bcos
 ---

 > 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.dashboard
 title: Fleet Dashboard
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Terse agent reference for the **Fleet Stats** dashboard (`FleetDashboard.svelte`).
@@ -3,7 +3,7 @@ module: fleet.modules
 title: Modules
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 > **Internal · agent reference.** Terse. Confirmed against `hiveops-fleet` source 2026-07-01.
@@ -3,7 +3,7 @@ module: fleet.patch-windows
 title: Patch Window Guide
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Act-without-guessing cheat-sheet. Everything confirmed in `hiveops-fleet` source.
@@ -3,7 +3,7 @@ module: fleet.tasks
 title: Fleet Task Workflow
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 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: dev
+audience: bcos
 ---

 Act-without-guessing cheat-sheet. Owner service: **hiveops-fleet** ONLY.
@@ -3,7 +3,7 @@ module: incident.dashboard
 title: Dashboard
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > **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: dev
+audience: bcos
 ---

 ## Owner
@@ -3,7 +3,7 @@ module: incident.incident-management
 title: Incident Management
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > How the Incident Management screen is built. Owner service: **hiveops-incident**. See [platform.service-ownership], [platform.data-architecture], [platform.kafka].
@@ -3,7 +3,7 @@ module: incident.incident-management
 title: Incident Management
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 ## Ownership
@@ -3,7 +3,7 @@ module: incident.incident-tracker
 title: Incident Tracker
 tab: Architect
 order: 30
-audience: dev
+audience: bcos
 ---

 > How the Incident Tracker is built. Grounded in `hiveops-incident` frontend + backend as of 2026-07-01. See [platform.data-architecture], [platform.kafka], [platform.service-ownership].
@@ -3,7 +3,7 @@ module: incident.incident-tracker
 title: Incident Tracker
 tab: Claude
 order: 40
-audience: dev
+audience: bcos
 ---

 > Terse act-without-guessing reference. Confirmed against `hiveops-incident` code 2026-07-01.
--- a/Show More
+++ b/Show More