Found while fixing #491, reproduced live against the running dev console (2026-07-28).
case_escalation (src/flows/case-escalation.flow.ts) triggers on record-after-update with:
record.priority == "critical" && record.status != "escalated"
Closing a critical case is itself an afterUpdate that sets status: 'closed' — which passes this guard. Observed sequence:
close_case writes is_closed: true, status: 'closed' (Done toast, write confirmed).
- The write triggers
case_escalation; its condition matches (critical + status closed ≠ escalated).
- The flow rewrites the case to
status: 'escalated', stamps escalation_reason: 'Auto-escalated: critical priority', and notifies the owner — the case the agent just closed is open again.
Note the guard cannot use is_closed != true instead: the file's own header comment documents the SQLite trap where a persisted boolean 1 makes 1 != true evaluate true (that is exactly why the guard is status-based).
Fix: extend the condition with && record.status != "closed" && record.status != "resolved" (the on-create twin inherits it via the shared nodes). Included in the #491 fix branch claude/views-pages-dashboards-refs-850098, with a regression test in test/actions-flows-integrity.test.ts ("case escalation trigger does not fight the close action").
Found while fixing #491, reproduced live against the running dev console (2026-07-28).
case_escalation(src/flows/case-escalation.flow.ts) triggers onrecord-after-updatewith:Closing a critical case is itself an afterUpdate that sets
status: 'closed'— which passes this guard. Observed sequence:close_casewritesis_closed: true, status: 'closed'(Done toast, write confirmed).case_escalation; its condition matches (critical+ statusclosed≠escalated).status: 'escalated', stampsescalation_reason: 'Auto-escalated: critical priority', and notifies the owner — the case the agent just closed is open again.Note the guard cannot use
is_closed != trueinstead: the file's own header comment documents the SQLite trap where a persisted boolean1makes1 != trueevaluate true (that is exactly why the guard is status-based).Fix: extend the condition with
&& record.status != "closed" && record.status != "resolved"(the on-create twin inherits it via the shared nodes). Included in the #491 fix branchclaude/views-pages-dashboards-refs-850098, with a regression test intest/actions-flows-integrity.test.ts("case escalation trigger does not fight the close action").