TASK-004C: Alarm Acknowledgment and Recovery Flow Hardening
AI Execution Profile
- Model class:
Balanced or High-Capability - Reasoning effort:
Medium to High
Scope
- separate alarm acknowledgment from condition clearance and recovery or reset
- harden workflow and command guards around critical faults
- preserve active run summaries when faulted work is interrupted
- emit diagnostics entries for acknowledgment, clearance, recovery, and blocked-command behavior where useful
Copy/Paste Prompt
text
Implement only TASK-004C: Alarm Acknowledgment and Recovery Flow Hardening.
Read first:
- docs/specs/SLICE-004-operational-maturity.md
- docs/adrs/ADR-001-use-central-app-state-store.md
- docs/adrs/ADR-004-use-one-operational-maturity-slice-before-specialized-modules.md
- docs/tasks/slice-004/TASK-004C-alarm-acknowledgment-and-recovery-flow-hardening.md
Goal:
- Make alarm lifecycle behavior explicit: seen, cleared, and recovered must no longer blur together.
Scope:
- Separate acknowledgment from clearance and recovery or reset.
- Keep critical faults blocking Start, Home, and motion until the condition is cleared and explicit recovery occurs.
- Preserve faulted run summaries and add diagnostics for key lifecycle events.
- Harden the workflow behavior without inventing a brand-new runtime vocabulary.
Do not:
- Add new persistence stores
- Redesign the UI
- Replace the current architecture with a state machine library
Important:
- Acknowledgment alone must not re-enable blocked commands
- Recovery must be explicit and observable