docs(probe): ack-leg third attempt — unavailable by configuration, GUID leg still assumed

docs/AlarmProbeFindings.md

@@ -24,13 +24,13 @@ the blocker rather than rediscovering it.
 |---|---|
 | GUID stable across polls and `ALM → RTN` | Answered — yes (2026-05-01 capture in `AlarmClientDiscovery.md`, reconfirmed 2026-08-18) |
 | GUID stable across clear-then-re-raise | Answered 2026-08-18 — **no**, a re-raise mints a new GUID |
-| GUID stable across `UNACK → ACK` | **Open** — the rig cannot be driven into an acknowledged state at all |
+| GUID stable across `UNACK → ACK` | **Open** — the rig cannot be driven into an acknowledged state; 2026-08-18 (third attempt) identifies the reason as the test attribute's `MxSecurityOperate` classification, which no non-interactive ack surface on the rig can satisfy |
 | `COUNT` = total active vs records-in-reply under a capped fetch | Answered 2026-08-18 — **records in the reply** |
 
 The 2026-08-17 run below is kept because it is the record of the wrong-verb blocker. The
 2026-08-18 run cleared that blocker with `AuthenticateUser` + `WriteSecured` and answered
 two of the three questions; the acknowledge leg is now blocked on something narrower and
-different, described in "Second attempt".
+different, described in "Second attempt" and diagnosed in "Third attempt".
 
 ## First attempt (2026-08-17): plain `Write`
 
@@ -264,8 +264,147 @@ MXAccess-side entry point and the wnwrap-side entry point is inert.
   spurious Clear plus a spurious Raise, which is the same shape the now-observed re-raise
   behaviour produces and which `ComputeTransitions` already handles as two instances.
 
+## Third attempt (2026-08-18): why the acknowledge is refused
+
+The second attempt left two candidate explanations for `AlarmAckByName` returning `rc=0`
+and changing nothing: the rig enforces an acknowledgement security requirement the wnwrap
+consumer cannot meet, or wnwrap's ack is simply broken here. This attempt was read-only —
+no writes, no alarms raised, no configuration touched — and settles the first question:
+the requirement is **enforced**, and the alarm attribute's security classification is what
+enforces it.
+
+### Method
+
+Read-only inspection of the `ZB` Galaxy Repository over `sqlcmd -S localhost -d ZB -E`,
+plus the already-built `mxa` CLI (`C:\Users\dohertj2\Desktop\wwtools\mxaccesscli\src\MxAccess.Cli\bin\x86\Release\net48\mxa.exe`)
+for runtime reads. Nothing was written and nothing was installed. The `lmxopcua\gr` schema
+notes referenced elsewhere in this repo are **not present on this box** (`Test-Path` is
+`False`), so the schema was located by querying `sys.tables` / `sys.columns` directly.
+
+### The test attribute is classified `MxSecurityOperate`
+
+UDA security classification lives in `dynamic_attribute.security_classification`, keyed by
+`gobject_id` — for the `$TestMachine` template that is `1055`:
+
+```
+attribute_name  | security_classification | mx_attribute_category
+ProtectedValue  | 2                       | 10
+ProtectedValue1 | 3                       | 10
+TestAlarm001    | 1                       | 10
+TestAlarm002    | 1                       | 10
+TestAlarm003    | 1                       | 10
+TestChangingInt | 1                       | 10
+```
+
+The enum is pinned by two independent sources rather than assumed. `ProtectedValue` and
+`ProtectedValue1` are the mxaccess analysis project's documented *secured-write* and
+*verified-write* fixtures (`C:\Users\dohertj2\Desktop\mxaccess\docs\galaxy-test-fixtures.md`),
+and `docs/NMX-COM-Contracts.md` in the same project records "Galaxy security classification
+(`2` for `SecuredWrite`, `3` for VerifiedWrite)" — so `2` and `3` land on exactly the two
+attributes that are supposed to carry them. `galaxy-test-fixtures.md` also records the
+provisioning verb used for every UDA in that inventory: `--security MxSecurityOperate`.
+`TestAlarm001` therefore reads `1` = **`MxSecurityOperate`**.
+
+That is the missing piece from 2026-08-17. `Operate` is not free access: it requires an
+authenticated galaxy identity holding Operate permission on the object's security group.
+An unauthenticated `Write` is refused with `SecurityError` `1008`, and the same write after
+`AuthenticateUser` succeeds — which is precisely the pair of results both prior attempts
+recorded. Galaxy security is live on this rig, not disabled.
+
+`wwAlarmConsumerClass.AlarmAckByName` carries an operator *name* string and a comment. It
+carries no authenticated user id, no credential, and no token — there is no parameter on
+either the 6-arg or the 8-arg overload that could convey one. A consumer calling it cannot
+satisfy an `Operate` classification, and `rc=0` followed by no state change is what an ack
+dropped downstream of an accepted call looks like.
+
+The one step this stops short of is a direct experiment: the rig's security configuration
+is out of scope for a read-only probe, so "an `Operate` alarm cannot be acknowledged
+without an authenticated identity" is inferred from the classification plus the observed
+`1008`/`rc=0` pattern rather than observed by relaxing the classification and watching the
+ack start working. The human step below is exactly that experiment.
+
+### There is no writeable `.Ack` attribute — the second attempt targeted the only one there is
+
+A plausible reading of the second attempt was that it wrote the wrong sub-attribute:
+ArchestrA alarm extensions are commonly described as exposing a writeable `.Ack` alongside
+the read-only `.Acked`. On this galaxy they do not. Every `Ack`-named attribute the alarm
+primitives define:
+
+```
+attribute_name        | security_classification | mx_attribute_category
+Acked                 | -1                      | 2
+AckMsg                | 0                       | 6
+Bad.Acked             | -1                      | 2
+Bad.AckMsg            | 0                       | 6
+TimeAlarmAcked        | -1                      | 2
+AlarmAckCnt           | -1                      | 2
+AlarmAckErrorsCnt     | -1                      | 2
+AlarmMostUrgentAcked  | -1                      | 2
+AlarmUnAckedCnt       | -1                      | 2
+```
+
+No `Ack`. `Acked` carries `security_classification = -1` — no classification at all, which
+is what a non-writeable attribute carries, as distinct from the `1` on the writeable
+`TestAlarm001`. That is the configuration-side counterpart of the `detail=1007`
+operational refusal the second attempt got when it wrote `.Acked`: not a permission
+refusal, but an attribute that has no write path to refuse. The second attempt had already
+found the only MXAccess-side candidate, and it is read-only by definition.
+
+### No non-interactive acknowledge surface is installed
+
+The `wwtools` collection on the box (`aalogcli`, `aot`, `graccesscli`, `grdb`, `histdb`,
+`mbproxy`, `mxaccesscli`, `secrets`) is the most likely home for a scriptable ack. There
+isn't one. `mxa --help` lists `diag`, `info`, `read`, `read-batch`, `subscribe`,
+`subscribe-batch`, `write`, `write-batch` — a tag data-plane only, with no alarm surface.
+`graccesscli` is a Galaxy Repository configuration tool (`object uda add`, `instance
+deploy`), which acts at configure/deploy time and not on live alarm state. Reading the
+galaxy's own authentication mode at runtime is also unavailable: `Galaxy.AuthenticationMode`
+does not resolve over MXAccess (`Category=4 Detail=6`), and the value is not in
+`dynamic_attribute` — only the attribute *definition* names `AuthenticationMode` and
+`_AuthenticationModeEnum` exist in `attribute_definition`.
+
+So every remaining acknowledge surface on this rig is interactive: the IDE's alarm client,
+InTouch, or an ArchestrA graphic bound to the alarm. Driving those is out of scope.
+
+### Status of the acknowledge leg
+
+**Unavailable by configuration, and the GUID question stays assumed.** The two are separate
+statements and both matter:
+
+- The wnwrap ack path is unavailable on this rig as configured, for an identified reason
+  rather than an unknown one. This is a real finding for the gateway: `AcknowledgeByName`
+  will behave the same way — accepted, inert — on any customer galaxy whose alarmed
+  attributes carry a non-free-access security classification. It is worth noting in the
+  alarm client's documentation that a silent `rc=0` is not proof of acknowledgement.
+- Whether wnwrap re-mints the record GUID on `UNACK_ALM → ACK_ALM` is still unobserved, and
+  after three attempts it stays assumed. As the second attempt already noted, this remains
+  a documentation gap rather than a correctness one: a re-minted GUID produces a spurious
+  Clear plus a spurious Raise, the same shape the observed re-raise behaviour produces, and
+  `ComputeTransitions` already handles that correctly as two instances.
+
+#### What a human would need to do
+
+Either of these answers it; the second is cheaper and also confirms or refutes the
+classification hypothesis above, which the read-only probe could only infer.
+
+1. Acknowledge `TestMachine_001.TestAlarm001` from an interactive System Platform client
+   (IDE alarm client, InTouch, or an ArchestrA graphic) while a wnwrap probe polls
+   `GetXmlCurrentAlarms2` against `\\DESKTOP-6JL3KKO\Galaxy!TestArea`, and record whether
+   `STATE` reaches `ACK_ALM` and whether `GUID` survives the transition. Raise the alarm
+   first with `AuthenticateUser` + `WriteSecured` as the second attempt did.
+2. Reclassify `TestAlarm001` on the `$TestMachine` template to free access and redeploy —
+   `graccesscli object uda ... --security MxSecurityFreeAccess` against `$TestMachine`,
+   then `instance deploy TestMachine_001` — and re-run the second attempt's ack probe
+   unchanged. If `AlarmAckByName` then moves `STATE` to `ACK_ALM`, the classification is
+   confirmed as the blocker and the GUID question is answered in the same run. Restore the
+   classification to `MxSecurityOperate` afterwards, since the secured-write fixtures in
+   `WorkerLiveMxAccessSmokeTests` depend on the alarm UDAs being secured.
+
 ### Rig state left behind
 
+The third attempt changed nothing. `TestMachine_001.TestAlarm001` and its `.Acked` subtag
+both read `false` at the end of the session, matching the state the second attempt left.
+
 The three `TestMachine_00{1,2,3}.TestAlarm001` UDAs are back to `false` and their
 `.InAlarm` subtags read `false`, but each leaves a `UNACK_RTN` record in the wnwrap
 snapshot, since nothing can acknowledge them away. `SnapshotActiveAlarms` counts only