The server refused to delete an automation while any global trigger pointed
at it, so removing one meant finding its triggers in a second list and
deleting each by hand first.
The refusal was protecting against dead data, but a trigger pointing at a
deleted automation is the dead data. Both are now written in a single patch,
so there is no window where one outlives the other and nothing to roll back.
An automation attached to an event is still refused: that reference lives in
the rundown, and removing it is an edit to the show rather than to the
automation settings.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AfDKsy6PE3Rbyt32Fg4YKf
A lifecycle was written three ways depending on where you were standing:
"On Start" in the automation settings, the raw "onStart" in the event editor,
and again as a literal in the trigger list. Anyone attaching an automation to
an event had to work out that the two lists were the same list.
One label map now owns the user facing names, and one helper summarises what
an automation sends. Both are shared, so the event editor gains the labels and
a Sends column for free: the trigger row says which automation runs and what
it will do, instead of only its title.
Two things the panel could not say before, now that it can look them up:
- A trigger can outlive the automation it points at, say after a partial
project import. It rendered as an empty tag; it now says so.
- not_contains is in the type and the runtime, but the server validation list
omits it, so an automation using it cannot be saved. The operator list moves
out of the form and drops it, with a test to stop it coming back.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AfDKsy6PE3Rbyt32Fg4YKf
Search every text field with optional filters, keep result selection stable, and expose clearer match context and counts. Cover query parsing, matching, mixed-entry indexing, and the reveal flow.