Three layers were each blind to nested composition in different ways:
- FlatteningPipeline only loaded compositions for templates in the parent's
inheritance chain, so depth-2 composed attributes (e.g.
Pump.AlarmSensor.SensorReading) never materialized. Walk composed chains
breadth-first so the flattener's nested step has the data it needs.
- InstanceConfigure's alarm trigger picker was fed only direct, non-locked
attributes, hiding inherited and composed-member paths. Feed it the full
flattened attribute list via FlatteningPipeline.
- ValidationService.ExtractAttributeNameFromTriggerConfig only recognized
"attributeName", silently passing alarms still using the legacy
"attribute" key. Accept both keys, matching FlatteningService,
AlarmActor, and AlarmTriggerConfigCodec.
Adds a new HiLo alarm trigger type with four configurable setpoints
(LoLo / Lo / Hi / HiHi). Each setpoint carries an optional priority,
deadband (for hysteresis), and operator message. The site runtime emits
AlarmStateChanged with an AlarmLevel field so consumers can differentiate
warning vs critical bands.
Plumbing:
- new AlarmLevel enum + AlarmStateChanged.Level/Message init properties
- AlarmTriggerEditor (Blazor) gets a HiLo render with severity tinting
- AlarmTriggerConfigCodec extracted from the editor for testability
- sitestream.proto carries level + message over gRPC
- SemanticValidator enforces numeric attribute, setpoint ordering,
non-negative deadband
- on-trigger scripts get an Alarm global (Name/Level/Priority/Message)
so notification routing can branch by severity
- per-instance InstanceAlarmOverride entity + EF migration + flattening
step + CLI commands; HiLo overrides merge setpoint-by-setpoint, binary
types whole-replace
- DebugView shows a Level badge + per-band message tooltip
- App.razor auto-reloads on permanent Blazor circuit failure
- docker/regen-proto.sh automates the proto regen workflow (the linux/arm64
protoc segfault means generated files are checked in for now)