Joseph Doherty
ce5d8ae7c2
Both questions stay open, and the reason is the finding: the dev rig's alarm UDAs reject a plain MXAccess Write with SecurityError/detail=1008 from the responding automation object, so no alarm instance can be created to follow through an acknowledge and no population can be built to overflow a capped fetch. The rig is otherwise live — objects deployed and on scan, wnwrap subscribed, GetXmlCurrentAlarms2 returning well-formed XML — which is what makes the blocker specific and the unblock (engine-side script, or AuthenticateUser + WriteSecured, or reclassifying the UDAs) actionable. Comment-only changes in WnWrapAlarmConsumer: scope the GUID-identity claim to the leg live capture actually covers, and record that ALARM_RECORDS/@COUNT exists as a candidate exact truncation signal but is deliberately not trusted because its semantics under a capped reply are unverified. No behavior change.