docs(phase6): AdminUI editors, pickers, deletes, new-script

docs/Historian.md

@@ -13,9 +13,13 @@ Design reference: [docs/plans/2026-06-14-galaxy-phase-c-historian-design.md](pla
 
 ## Historized TagConfig schema
 
-A tag is historized by adding fields to its `TagConfig` blob on the `/uns` equipment page
-Tags tab (raw-JSON textarea). No separate UI control exists — Galaxy (the primary use case)
-already uses the raw-JSON editor.
+A tag is historized by setting the **Historize this tag** checkbox and optional **Historian
+tagname (override)** textbox in the Tag modal on the `/uns` equipment page Tags tab. These
+controls work for **all drivers** — typed editors (Modbus, S7, OpcUaClient, etc.) and the
+raw-JSON textarea (Galaxy) alike. The controls merge `isHistorized` / `historianTagname`
+into the existing `TagConfig` JSON blob via the `TagHistorizeConfig` helper, preserving all
+other keys byte-stable. Drivers that still use the raw-JSON editor (Galaxy) can also add the
+fields directly in the textarea.
 
 ### Fields
 
@@ -199,13 +203,36 @@ bit set at materialization. A session without sufficient permissions receives
 ## Authoring workflow
 
 1. Open the equipment's **Tags** tab on `/uns/equipment/{id}`.
-2. Create or edit the tag. Because Galaxy uses the raw-JSON editor, add `"isHistorized":true`
-   (and optionally `"historianTagname":"..."`) directly in the TagConfig textarea.
+2. Create or edit the tag.
+   - For **typed-editor drivers** (Modbus, S7, OpcUaClient, etc.): check the
+     **Historize this tag** checkbox and, if needed, fill in the **Historian tagname
+     (override)** textbox.
+   - For **raw-JSON editors** (Galaxy): you can check the same first-class checkboxes
+     (they appear below the JSON textarea), or add `"isHistorized":true` (and optionally
+     `"historianTagname":"..."`) directly in the textarea.
 3. Save and publish. The server rebuilds its address space; the node materialises with
    `Historizing=true` and the `HistoryRead` AccessLevel bit.
 4. Confirm with Client.CLI `read` that the node's `Status` is `Good` and that the value
    is updating. Then issue a `historyread` to verify the historian connection returns data.
 
+### Native-alarm historian opt-out (`alarm.historizeToAveva`)
+
+A tag carrying a native `"alarm"` object has a **separate** historian opt-out for its
+**alarm transitions** (distinct from tag-value historization). On the Tag modal, check or
+uncheck **Historize to AVEVA** in the alarm section. This maps to `alarm.historizeToAveva`
+(`bool?`) in the `TagConfig` JSON:
+
+- **Absent or `true`** (default) — the alarm's transitions are written to AVEVA Historian
+  via `HistorianAdapterActor`.
+- **`false`** — the durable AVEVA write is suppressed for this alarm's transitions. The
+  live `/alerts` feed and OPC UA condition events are unaffected.
+
+The gate is applied in `HistorianAdapterActor` using `is not false` semantics, matching the
+scripted-alarm `HistorizeToAveva` posture. See
+[ScriptedAlarms.md §Native driver alarms](ScriptedAlarms.md#native-driver-alarms-equipment-tag-path)
+and [AlarmTracking.md §Historian write-back](AlarmTracking.md#historian-write-back-non-galaxy-alarms)
+for the full alarm-historian routing.
+
 ---
 
 ## Client.CLI historyread examples