# 12 — IT Ops

## AI grep hints

- Keys: `itops.*`, `settings.sectionItOps`, `watchdog.*`
- Topics: IT Ops Module, Sites, Site View, Server Room, Server Room View, Server Room floor plan, Server Room 2.5D view, Rack View, racks, Rack Device, Rack Device Type, Rack Device Properties, rack unit (U), rack shell, tree navigator, drill-down, virtual datacenter, click-to-connect, Hosts, Host inventory, host import, hostname list, connectivity scan, child hosts, VM guests, container guests, Host Connection bindings, Batch Runs, Automations, site task, run history, Run Report, transport, SSH, WinRM, PsExec, trigger, condition, action, armed, disabled, Watchdog Status Bar
- Tutorial targets: `app.activityRailItOps`, `itops.sitesTree`, `itops.siteView`
- Synonyms: "run on many hosts", "bulk command", "site", "host group" (renamed to Site), "host collection", "host inventory", "import servers", "detect ssh", "detect winrm", "scan hosts", "virtual machines on a host", "rack diagram", "rack elevation", "top-down view", "floor plan", "floor-plan view", "room footprint", "DCIM map", "2.5D view", "isometric room", "3D server room", "axonometric view", "utilization heatmap", "capacity heatmap", "rack health map", "virtual datacenter", "data center map", "open from rack", "scheduled monitor", "saved watchdog", "automation rule", "batch script", "run report"

The **IT Ops Module** is an Activity Rail destination for operating across multiple existing Connections. Its current visible surface is Sites: a left Sites navigator and a right Site topology drill-down. Batch Runs and Automations are managed per Site from Site View's `itops.sites.viewLabel` segmented control; there is no separate top-level tab chrome. Settings → General → `settings.activityRail` controls whether the Module appears; it is hidden by default.

## Sites

A **Site** is the durable top-level container for Server Rooms and Racks. It is not itself a Connection and owns no live Session or secret. When IT Ops has no Site data, KKTerm keeps an undeletable Default Site so the topology always has a safe parent container.

Open Sites from the add menu beside `itops.title` and choose `itops.racks.addSite`. The New Site dialog explains that a Site can model a region, location, customer, project, or other infrastructure grouping. Enter `itops.sites.nameLabel`; Connection binding is not part of Site creation. The header's shared icon picker customizes the Site icon. Save with `itops.actions.create`.

The left Sites column includes the `itops.title` label/icon and can be resized like the Connection Tree. Use the Sites title-bar button, placed immediately before the `app.aiAssistant` button, to hide or show the entire left Sites navigator. The right column shows the selected Site only; it does not show the old Sites / Batch Runs / Automations top bar — Site View's `itops.sites.viewLabel` segmented control covers Batch Runs and Automations per Site instead.

### Site View, Server Room View, and Rack View

The Site topology is a Connection-tree-style navigator. The left panel nests **Site → Server Room → Rack** as collapsible, searchable (`itops.racks.treeSearchPlaceholder`) rows, with `connections.collapseAll` and `connections.expandAll` controls beside `itops.sites.heading` when expandable rows exist. Clicking a **Site** opens **Site View**, a free-form placement surface for its **Server Room** cards: each card sits at its freely chosen position in normal and edit mode alike, while the dot placement grid appears only in edit mode. Site View edit mode also shows the same right-side `itops.floorPlan.pickerTitle` column used by Server Room View, with one `itops.racks.serverRoomLabel` card that opens the existing New Server Room dialog for the selected Site. When a Site has no Server Rooms, normal mode shows a compact centered `itops.racks.addServerRoom` action; edit mode keeps the empty placement grid and Server Room picker visible. Right-clicking a Site, Server Room, or Rack row opens a native command menu whose `common.properties` action reopens that entity's add dialog in edit mode; Server Room Properties also owns its durable `itops.floorPlan.floorColorLabel` finish. Site View, Server Room View, and Rack View each have an icon-only `itops.actions.viewActions` toolbar: `itops.actions.edit` / `itops.actions.editDone` toggles placement editing, and `itops.actions.export` opens export options. Site View's toolbar row also carries the icon-labelled `itops.sites.viewLabel` segmented control (the Site View counterpart of the Server Room View layout switcher): `itops.sites.viewOverview` shows the Server Room card surface described here, while `itops.tabs.hosts`, `itops.tabs.runs`, and `itops.tabs.autos` show that Site's Hosts, Batch Runs, and Automations (see their sections below). In the Overview segment, edit mode lets Server Room cards be dragged to new positions or removed with a confirmation (`itops.racks.deleteServerRoomTitle`); the toolbar's `itops.sites.autoOrganize` action snaps every card back onto the default grid arrangement; right-clicking empty surface exposes `itops.racks.changeBackground`, which opens the shared background dialog with the same image/SVG/video media support as Dashboard and persists the Site background; export offers `itops.export.pdf`. In the Hosts, Batch Runs, and Automations segments, the edit, auto-organize, and export actions hide and the plus action becomes `itops.hosts.importAction`, `itops.actions.newBatchRun`, or `itops.actions.newAutomation`.

Clicking a **Server Room** opens **Server Room View**, showing its racks grouped under their `itops.racks.groupLabel` tag (`itops.racks.ungrouped` for untagged racks). When a Server Room has no Racks, a compact centered `itops.racks.addRack` action opens the existing Rack dialog with that Server Room selected. Server Room View has three layouts, toggled with the icon-labelled `itops.floorPlan.viewLabel` control centered in the same top toolbar row as the `itops.actions.viewActions` buttons: `itops.floorPlan.viewElevation` (the default front-elevation rows), `itops.floorPlan.viewFloor`, a blueprint-style top-down floor plan, and `itops.floorPlan.view25d`, a 2.5D axonometric room. In elevation mode, every rack reserves room above the cabinet for a rack-top 乖乖 package, edit mode enables Rack Device drag/drop and direct delete controls on Racks and Rack Devices, and normal mode does not expose drag/drop targets. The floor plan and the 2.5D view share one floor grid: each Rack stands on a grid cell with a stored facing, so moving or rotating a Rack in either view rearranges both. There is no metric toggle; every Rack footprint/cabinet is painted in the Rack's shell finish (the same colour on the whole cabinet — no status colouring; health, the worst placed-device status, reads as text — `itops.floorPlan.health.ok` / `itops.floorPlan.health.warning` / `itops.floorPlan.health.critical`, with `itops.floorPlan.health.empty` for an empty rack — in the footprint tooltip and the hover detail card both spatial layouts share) and carries compact always-on tags: the device count and summed Rack Device power draw (`itops.floorPlan.powerValue` against the Rack dialog's optional `itops.racks.powerCapacityLabel` watts, or `itops.floorPlan.powerDrawOnly` when no capacity is set; each Rack Device's optional `itops.racks.powerDrawLabel` watts sums into it). Rack heights and unit occupancy are never written on the view itself; they appear only in the hover detail card. Racks in adjacent cells connect side-to-side with no gap, like a real rack row; the facing edge on the plan (and the device-face side in 2.5D) shows which way the front points. A Rack footprint's displayed depth follows the Rack's `itops.racks.depthLabel` millimetres against the 1200 mm floor cell — 600 mm reads as half a cell, 1200 mm as the whole cell, values in between scale by ratio, and any deeper custom depth still draws as one full cell — with the front face always flush on the cell borderline the facing points at. Each 2.5D cabinet carries its Rack name as a label fixed to the cabinet top and rotated with the Rack facing; its front face renders a miniature of the 2D rack skin — the cabinet shell finish plus each placed Rack Device as a faceplate strip with its status LED — and the room can be viewed from four fixed corners with the `itops.floorPlan.viewAngleLabel` stepper (`itops.floorPlan.rotateViewLeft` / `itops.floorPlan.rotateViewRight`, curved-arrow buttons). Both spatial layouts grow their floor grid to cover the whole view, and each carries a vertical ruler-style zoom control (`itops.floorPlan.zoomLabel`) floating over the room's top-right corner: one clickable tick per fixed level between 50% and 200% (`itops.floorPlan.zoomSet`), and scrolling the mouse wheel over the room steps the active tick the same way. The 2.5D floor is a solid finish (never transparent) selected in Server Room Properties from `itops.floorPlan.floorColor.default`, `itops.floorPlan.floorColor.concrete`, `itops.floorPlan.floorColor.graphite`, `itops.floorPlan.floorColor.green`, or `itops.floorPlan.floorColor.blue`; it persists with that Server Room. Each spatial layout's zoom level persists locally and is restored the next time that layout opens. When the room is larger than the window, it pans with a held left-button drag on the floor, a middle-mouse drag from anywhere, or, after clicking the room, the arrow keys. Hovering a floor-plan footprint or a 2.5D cabinet shows the same compact detail card with health, utilisation, power, used/total rack units, device count, and status tallies; clicking a footprint or cabinet drills into that Rack outside edit mode. Right-clicking empty 2.5D space exposes `itops.racks.changeBackground`, which opens the same shared background dialog used by Dashboard and persists the selected Server Room background. Both spatial layouts also hold **room objects** — non-rack fixtures picked from the edit-mode `itops.floorPlan.pickerTitle` column, a full-height searchable (`itops.floorPlan.pickerSearchPlaceholder`) grid of preview cards on the right of the room holding a `itops.floorPlan.pickerRack` card plus `itops.floorPlan.object.camera`, `itops.floorPlan.object.aircon`, `itops.floorPlan.object.fireExtinguisher`, `itops.floorPlan.object.cableTray`, `itops.floorPlan.object.ups`, `itops.floorPlan.object.sensor`, `itops.floorPlan.object.smokeDetector`, `itops.floorPlan.object.crashCart`, and `itops.floorPlan.object.kuaikuai`. Room objects draw only their artwork; no type icon floats above the object in either mode. Clicking a card arms one item: a room fixture follows the mouse immediately, while the `itops.floorPlan.pickerRack` card first opens the New Rack dialog to collect its properties. The armed object remains visible under the mouse anywhere in the app content, snaps to the hovered floor cell, previews the drop in realtime (the highlight turns red when the cell has no free vertical span), and one successful floor-cell click places it and disarms the picker. A blocked drop stays armed for another target. Right-click anywhere, press Escape, choose the armed picker card again, exit edit mode, change layout, or navigate away to cancel; cancellation discards a configured but still-unplaced Rack. Room object footprints follow their real size against the floor cell: small fixtures (camera, fire extinguisher, sensor, smoke detector, 乖乖 pack) occupy one quarter of a cell anchored to a cell corner — on the floor plan the placement click's quadrant picks the corner — while large fixtures span several cells (the air conditioner covers a 2×1-cell span, a cable-tray section runs two cells) and block every covered cell. An object also has a vertical position in rack units, so several occupants can share one floor cell as long as their vertical spans don't intersect. A 乖乖 pack dropped on a Rack's cell lands on the cabinet top and becomes that Rack's single rack-top 乖乖 Rack Device — the same shared package Rack View and the elevation rows show centered above the cabinet — rather than a separate room object (the drop reads as blocked when the cabinet top already holds one); a pack placed on the floor stays a room object. In edit mode (`itops.floorPlan.blueprintEditHint` / `itops.floorPlan.isoEditHint`), Racks and objects are dragged between cells (dropping a Rack onto an occupied cell swaps the two); rotate, level, and remove controls appear only after the user clicks the Rack or room object to select it. Those controls rotate a facing (`itops.floorPlan.rotateTitle`), walk a quarter-block object to the next cell corner (`itops.floorPlan.cornerTitle`), move an object between vertical levels (`itops.floorPlan.raiseTitle` / `itops.floorPlan.lowerTitle`, tooltip `itops.floorPlan.objectLevel`), or remove it (`itops.floorPlan.deleteObjectTitle`); a placement with no free vertical span raises the `itops.floorPlan.objectNoSpace` Status Bar warning. In the 2.5D view an empty tile click (`itops.floorPlan.isoAddHere`) opens the New Rack dialog, and the selected Rack's delete control removes it with the usual confirmation. Unplaced cabinets default to one floor row per rack group, separated by aisles. The chosen layout, view angle, and zoom levels persist locally; the Server Room floor finish, grid placements, rack facings, and room objects are durable data stored in the app database (layouts saved before this existed are still read as a local fallback until the next edit). The Rack dialog previews the real rack elevation and stores `itops.racks.heightLabel`, `itops.racks.depthLabel` (millimetres), group, and shell properties. The Group field suggests groups already used in the selected Server Room while continuing to accept a new free-text group. Export offers `itops.export.pdf`.

The current 2.5D placement surface treats every rendered floor cell as a real target, including the extra cells that fill a large viewport. Its snapped preview is the same CSS-3D model that remains after placement. Fixture face geometry and animation follow `Server Room Objects.dc.html`; its current one-cell footprint proportions supersede the earlier multi-cell examples above: CRAC is 0.94×0.62, UPS is 0.6×0.6, crash cart is 0.56×0.44, and cable tray is 1.0×0.3.

Room object gravity applies to resting objects: they land on the lowest fitting floor, cabinet, or object surface when placed or dragged. Top-hung fixtures such as cameras and detectors keep their overhead placement rules instead of falling to the floor.

Clicking a **Rack** opens **Rack View**, centered on a stage with per-device "balloon" callouts pointing to each U slot. The Rack name and compact height/depth/device specifications sit in the top-middle toolbar, while the stage keeps only a small bottom inset and reserves visual room above the cabinet for a rack-top 乖乖 package. Rack View reduces the cabinet's per-U display height when the available window height is too short for the normal elevation, down to a legible floor, so common rack sizes avoid vertical scrolling whenever the screen permits. A breadcrumb climbs back up. Rack View edit mode enables Rack Device drag/drop, empty-U drop targets, and a confirmation-backed delete control (`itops.racks.deleteItemTitle`) on each Rack Device. It also shows the shared right-side `itops.floorPlan.pickerTitle` column with searchable previews for every `itops.racks.kindLabel`; each card uses its faceplate text as the only visible type name and limits decorative ports or drive bays so that name has more room. Choosing one opens `itops.racks.addItemTitle` showing only that device's properties (no type switcher and no position field — placement happens next). Confirming with `itops.racks.placeAction` arms placement: the configured device remains visible under the mouse anywhere in the app content, then magnetically snaps to the nearest valid U as the pointer approaches the cabinet. The snapped preview turns red where its span would overlap a placed device, and the next valid left click places it. Right-click anywhere, press Escape, choose the armed picker card again, or navigate away to cancel. The picker column is Rack View's only add path: outside an armed placement, empty U slots are drag/drop targets only and clicking one does not open the add dialog (the `itops.racks.addDeviceCallout` empty-slot flow remains in the Server Room elevation layout). Choose `itops.racks.addServerRoom` to create an empty Server Room in a selected Site; creating a Server Room does not create a Rack. Choose `itops.racks.addRack` to add a Rack: `itops.racks.serverRoomSelectLabel` is required, so every Rack belongs to a Server Room in the selected Site.

Each Rack is drawn as an animated metal elevation: rail caps, a U-number gutter, and every device painted as its own faceplate that animates to match its kind and status (server fan spin and drive-bay LEDs, switch/router port blink, firewall throughput bars, disk-array grid, PDU load meter, UPS battery cells, KVM channels, and patch-panel ports). The Rack header shows online / warning / offline tallies, and devices slide in on load.

A **Rack Device** is added through the `itops.racks.addItemTitle` dialog: in Rack View edit mode it opens from the picker column's armed flow described above, and in the Server Room elevation layout's edit mode it opens by clicking an empty U slot's `itops.racks.addDeviceCallout` callout. The compact two-column editor keeps identity and longer text in the first column — a live rack preview followed by label, model when applicable, notes, tags, and Host fields, plus a four-across `itops.racks.kindPreviewLabel` picker built from the shipped device faceplates when adding into an empty U slot — and gathers appearance, capacity, and placement properties with graphical shell-finish choices in the second. Capacity such as drive bays or ports shares one two-column row with device height; Start U follows as a separate placement control when that flow exposes it. When opened from the Rack View picker column, the type picker and position field are omitted — the type is already chosen and the position comes from the placement click; editing an existing device also hides the type picker, since a placed device keeps its type. A Server also offers `itops.racks.formFactorLabel`: `itops.racks.formFactor.rack` uses the normal full rack width, while `itops.racks.formFactor.tower` draws a centered half-width tower chassis. Beside it, `itops.racks.serverPanelStyleLabel` selects independently scalable artwork: `itops.racks.serverPanelStyle.default` keeps the original generic drive/fan face, `itops.racks.serverPanelStyle.style1` uses a dark drive wall with a silver hexagonal lattice, and `itops.racks.serverPanelStyle.style2` uses silver end bezels with converging grille rails and a green center indicator. Style 1 is height-aware rather than stretched: 3–4U uses a two-row lattice over a deeper drive wall; at 5U and taller, the lattice remains only on the upper faceplate and a separate lower expansion-card/grille chassis fills the remaining height. The live properties preview shows this transition through 5U. Required fields show `*`; unmarked fields are optional. Connection associations are managed separately through `itops.racks.bindingsAction`. When the Site has Hosts, an `itops.racks.hostLabel` select binds the device to its IT Ops Host (see the Hosts section) so the Rack View callout lists the Host and its child Hosts. The **Rack Device Type** (`itops.racks.kindLabel`) choice covers `itops.racks.kind.server`, `itops.racks.kind.storage`, `itops.racks.kind.switch`, `itops.racks.kind.router`, `itops.racks.kind.firewall`, `itops.racks.kind.pdu`, `itops.racks.kind.ups`, `itops.racks.kind.kvm`, `itops.racks.kind.patchPanel`, `itops.racks.kind.equipment`, `itops.racks.kind.general`, and `itops.racks.kind.kuaiguai`.

Optional metadata includes notes, tags, typed network-port speeds, SNMP target/OID hints with user-triggered manual refresh, and hardware model details. None of these fields stores credentials or live Session state.

乖乖 is the only Rack Device that can be placed either inside the cabinet or on its top, and its editor shows only package properties — no status, shell finish, accent, or power draw. Its single `itops.racks.kuaiguaiStyleLabel` choice combines the package pose — `itops.racks.kuaiguaiStyle.full` (standing, 4U) or `itops.racks.kuaiguaiStyle.laidDown` (package face upward, 1U) — with the package size (`itops.racks.kuaiguaiSize.small` / `itops.racks.kuaiguaiSize.regular` / `itops.racks.kuaiguaiSize.large`). Moving its placement preview above the cabinet selects the rack-top position; one package may occupy that position, and the floor plan / 2.5D picker's 乖乖 dropped onto a cabinet top places this same rack-top package, so every view shows one shared object. Server Room floor views do not reveal 乖乖 packages stored inside cabinets, while a rack-top package remains visible on the cabinet footprint/top. When a package carries an `itops.racks.expiryLabel` date, its colors drain gradually over the final 30 days before that date, and on and after the date it renders fully black and white in every view that shows it.

Clicking a Rack Device that has bound Connections (its placed host and/or the `itops.racks.bindingsAction` bindings) opens a **connect popover** anchored to the faceplate. Each row shows the Connection's icon, name, and host with a `itops.racks.connectAction` action: terminals and file browsers connect in the background — a Status Bar notice (`itops.racks.connectOpenedNotice`) confirms the Session opened in the Workspace Module while IT Ops stays visible — and URL/RDP/VNC Connections switch to the Workspace Module, where those Sessions must be visible to start. A row whose Session is already open shows `itops.racks.goToSessionAction` with a live dot and jumps to its Workspace tab; the Activity Rail's IT Ops button returns to the same Rack View drill-down. A hover pencil edits a bound device; devices without bound Connections open the edit dialog on click. A placed Connection that no longer resolves to a Site member is shown dimmed with a `itops.racks.ghostBadge` badge — it cannot be opened but can still be edited or removed, and a deleted bound Connection renders as a `itops.racks.ghostBadge` row in the popover. Placement is a visual arrangement only; it does not modify the referenced Connections. The notes and additional bindings are inventory metadata that can support random Rack View callouts and multi-Connection device lookup without creating live Session state.

## Hosts

A **Host** is a durable inventory entry for one device or guest in a Site, addressed by hostname. The device itself can be a Host, and a Host can carry **child Hosts** — its virtual machines or containers (`itops.hosts.kind.physical`, `itops.hosts.kind.vm`, `itops.hosts.kind.container`, `itops.hosts.kind.other`). Site View's `itops.tabs.hosts` segment lists the selected Site's Hosts as a parent/child tree with a count roll-up (`itops.hosts.hostCount`), and the segment's toolbar plus opens the import dialog.

**Import.** `itops.hosts.importAction` opens a dialog (`itops.hosts.importTitle`) that accepts a pasted hostname list — one hostname per line, commas also separate, and `#` starts a comment (`itops.hosts.importHint`). Blank lines and duplicates are skipped; the Status Bar reports the outcome (`itops.hosts.importedNotice`). Imported Hosts are created as physical devices at the top level and are **scanned automatically** for remote-orchestration endpoints.

**Connectivity scan.** The scan probes each Host for SSH (port 22), WinRM (5985/5986), and HTTPS (443, a management-interface hint) and stores the snapshot on the Host — never live Session state and never a secret. Each row shows the detected endpoints as chips, `itops.hosts.scanning` while a probe runs, `itops.hosts.scanPending` for a never-scanned Host, or `itops.hosts.scanNone` when nothing answered. `itops.hosts.rescanAllAction` rescans the whole Site; each row's `itops.hosts.rescanAction` rescans one Host.

**Editing.** `itops.hosts.addAction` and each row's `itops.hosts.editAction` open the Host dialog (`itops.hosts.dialogTitleAdd` / `itops.hosts.dialogTitleEdit`) with `itops.hosts.hostnameLabel`, `itops.hosts.labelLabel`, `itops.hosts.kindLabel`, the `itops.hosts.parentLabel` select (`itops.hosts.parentNone` keeps it top level; a Host can never be its own ancestor), and `itops.hosts.notesLabel`. A row's `itops.hosts.addChildAction` pre-selects that Host as the parent. Deleting a Host asks for confirmation (`itops.hosts.deleteConfirmTitle`); its child Hosts are kept and move up one level, and no Connection is affected.

**Connection bindings.** Each row's link chip opens `itops.hosts.bindingsTitle`, where one Host binds any number of existing Connections — for example its SSH terminal Connection plus an HTTPS URL Connection to its management interface (`itops.hosts.bindingsHint`). Bindings are ordered soft references; deleting a Connection never deletes the Host.

**Rack View callouts.** The Rack Device editor's `itops.racks.hostLabel` select binds a placed device to the Host it *is*; that device's balloon callout in Rack View then lists the Host's hostname and its child Hosts (`itops.hosts.childOverflow` summarizes the rest), so a rack slot reads as "this machine, and the guests running on it".

## Batch Runs

A **Batch Run** sends one script to every resolved host in a selected Site. Site View's `itops.tabs.runs` segment shows the selected Site's Batch Runs only: its live run, its recent runs, and a start affordance — the toolbar plus (`itops.actions.newBatchRun`) and the empty state's `itops.actions.startBatchRun` open the launcher preselected to that Site. In the launcher, select `itops.batchRuns.siteLabel`, enter the script under `itops.batchRuns.scriptLabel`, and choose `itops.actions.run`.

Execution fans out with bounded concurrency. The live view shows queued, running, successful, and failed hosts and streams each host's combined output. `itops.actions.cancel` stops an active run. A completed run is written to Recent runs; select an entry to open its read-only Run Report and inspect the saved per-host output. `itops.actions.rerun` opens a new launcher preselected to the same Site.

The script is state-changing operator input. Review it and the target Site before starting. Authentication secrets remain in the OS keychain and are not copied into the Site or report.

## Automations

An **Automation** is a durable trigger → optional condition → ordered actions rule. Its saved definition persists and enabled rules re-arm when KKTerm launches; the live **Watchdog** runtime performs sampling and execution in memory.

Each Automation carries a durable Site binding, chosen with the `itops.editor.siteLabel` select in the editor header (`itops.editor.siteNone` leaves it unbound). Site View's `itops.tabs.autos` segment lists the Automations bound to the selected Site; an Automation created from that segment is bound to it by default. Rules saved before the binding existed show where they can be inferred: a Batch Run action targeting that Site, or a host-addressed trigger (ping / TCP reachable) watching one of the Site's resolved member hosts. The segment's toolbar plus (`itops.actions.newAutomation`) opens the editor. In the editor, name the rule, configure its trigger and condition, then add typed actions with `itops.actions.addAction`. Available actions include notify, popup, email, webhook, and running a Batch Run. The editor's Test action samples/evaluates the rule and previews actions without sending email, calling a webhook, or starting a Batch Run. Save with `itops.actions.create` or `itops.actions.save`.

The Automations list shows `itops.automations.armed` or `itops.automations.disabled`. Use its toggle to arm or disarm a rule, or use the edit and delete actions. Triggered in-app notifications use the Status Bar; popup actions use an app-owned dialog. The Watchdog Status Bar indicator provides app-wide live runtime visibility.

## AI Assistant

The shared AI Assistant receives compact IT Ops page context: Site names/member counts/transports, loaded rack-topology counts, Automation names and armed state, recent-run count, and a live-run summary. It does not receive scripts, host output, secrets, Rack Device details, or full trigger/action bodies through page context. Ask it operational questions normally; for UI guidance it searches this chapter and can navigate to the IT Ops Module or highlight one of the tutorial targets above after you ask to be shown.
