Reviewing the branch turned up defects, several of them worse than the
problems the original commits set out to solve.
Destructive: deleting an automation removed its global triggers and only then
discovered a rundown event also referenced it. The delete failed, the user
cancelled, and their triggers were gone for good. The server reports trigger
references before event ones, so this was reachable whenever both existed.
Deleted triggers are now recreated when the delete is refused.
Silently wrong: a template read the project from disk while writes are
debounced by three seconds, so "make some automations, save them as a
template" could produce a template without them. Verified by hand: an
automation created milliseconds earlier now appears.
The demo shipped half a pair. The danger warning set a stage message visible
and nothing ever cleared it, so from the first event that hit its danger
window the message covered the countdown for the rest of the session. The
recipe library ships the clearing counterpart; the demo now does too, and the
whole cycle is verified against a running server.
Flood control undid itself. resetAutomationLogState ran on every onLoad, and
roll mode loads at every event boundary, so the "logging suppressed" notice
was re-emitted once per cue: exactly the flooding it exists to prevent. It
also wiped the throttle for onLoad and onStop immediately before writing to
it. Reset now happens on stop only, outside the early returns that made the
first attempt at this a no-op.
Trigger reconciliation diffed a mount-time selection against a live prop.
Settings are polled, so a trigger created in another tab while the form was
open would be deleted by a save that never saw it. It now diffs against the
snapshot, and says which triggers a save will remove rather than removing
several same-lifecycle triggers silently.
Also: a rundowns template no longer carries a phantom empty rundown from
makeNewProject; the partial-duplicate endpoint returns the name it actually
used, since collisions get renamed; the template flow invalidates the project
list rather than relying on a refetch on mount; the last-fired label drops to
a one minute cadence instead of holding a 1Hz timer per automation forever;
e2e cleanup moved to afterEach so a mid-test failure stops leaking state.
The e2e spec has now been run against a real server, green on both the demo
project and a blank one, leaving no residue.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
Automations were already portable, contrary to the original framing: project
download carries them and the partial load already had an "Automation
Settings" toggle. What was missing is the other half of that loop. To share a
set of automations you had to hand over an entire show.
Save as template is the inverse of partial load: it writes a new project file
holding only the sections you pick. Automations, custom fields, URL presets
and view settings all become templates, and a template is an ordinary project
file, so it downloads, uploads and partial loads with no new format and no new
concepts.
createProjectWithPatch already builds exactly the right object, but it routes
through loadProject and would switch the running project. Saving a template
must not pull an operator out of the show they are running, so this writes the
file without loading it, the way duplicateProjectFile already does.
The automations panel gets the loop as a Share menu: save these automations as
a template, or go load one. The form says plainly that applying an automation
template replaces rather than merges, since triggers and automations are
coupled and safeMerge swaps the whole block, and that a template without
rundowns does not carry the events that point at its automations.
Adds the first e2e coverage automations have had.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
The demo had automations empty and switched off, so the feature stayed
invisible to exactly the users most likely to be exploring. It was also
inconsistent with the blank project default, where automations are on.
Three automations, none of which touch the network. Two fire: an aux timer
that runs with the event, on a global trigger, and a wrap-up message on an
event level trigger, which is the only way per-event triggers get found by
browsing rather than by reading the docs. The third is a fully formed OSC
example with no trigger attached at all, so there is something realistic to
read and edit without anything being sent anywhere.
OSC input stays off: never open a listening socket the user did not ask for.
The ids are hand written literals and nothing in the type system checks that
a trigger resolves to an automation, so a test covers that, along with the
promise that nothing bound to a trigger can reach off this machine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
Deleting an automation had no confirmation at all, and when the server refused
because something still referenced it, the raw message landed in a stray row
underneath the table.
Deletion now confirms first, and names what it will take with it. Global
triggers are ours to clean up, so the dialog offers to delete them along with
the automation. A reference from a rundown event is not: editing rundown data
from a settings screen would be surprising and hard to undo, so that stays a
block, with the server's message and a pointer to the event editor.
This matters more once the demo project ships with automations, since those
are referenced by definition and every user who tries to remove one would
otherwise meet the raw error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
Every logger call in the automation module was a failure path, so a working
automation and a misconfigured one looked identical: nothing happened either
way, as far as the user could see.
Two channels, because they answer different questions. A new AUTOMATION log
origin says what happened and when. A coalesced socket message feeds a "last
fired" column in the panel, which answers whether an automation is alive at
all: one that stays blank while its neighbours tick is the clearest sign that
a filter or a trigger is wrong.
Flood control is the whole difficulty here. onClock fires every second and the
logger queue holds 100 entries, so per-fire logging on a continuous lifecycle
would evict everything else within two minutes. Those cycles log a single
notice per load explaining the silence and nothing after; the rest dedupe
inside a one second window so a rapid reload does not spam. The socket message
still goes out for continuous cycles, throttled to once a second, because the
panel needs it to show the automation is running.
Log.tsx carried six copies of the same twelve line button. Adding a seventh
origin was the moment to collapse them, so the next one is free. The client
log store was also unbounded while the server queue is capped; it now holds
500 entries.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
The panel started empty with no examples, so the first thing a new user saw
was a form that assumes they already know what OSC, a lifecycle and a template
string are. Eight recipes now cover the common integrations plus three that
need no external software at all, so the library is useful on a bare laptop.
A recipe is not a new kind of object. Installing one posts an ordinary
automation and its triggers through the same endpoints the form uses, then
opens it in the editor: seeing that it is editable is the point.
Every external target defaults to this machine, so a mis-click cannot put
traffic on a venue network, and a test asserts that along with the rest of
the server's automation contract, since recipes are constants that would
otherwise rot silently into something that 400s on install.
OSC recipes are hidden in the cloud build, where OSC output is skipped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
Getting one automation to fire took two modals and two names: create the
automation, then create a separate trigger with a title the user has no use
for. The automation form now carries a "Runs on" selection and reconciles the
global triggers on save, so a working automation is one form away.
The triggers card stays for the cases it is actually good at, naming triggers
and pointing several at one automation, and says so.
Saving now spans two requests. A create that succeeds followed by a failed
trigger sync keeps the automation id, so retrying edits the automation rather
than creating a second one, and the form stays open with the partial state
reported rather than closing on a half-applied save.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
The list showed counts rather than meaning, and one column was mislabelled
"Trigger rule" while rendering the filter rule. The form buried the test and
delete actions inside four fixed grids, and the Test buttons discarded their
result entirely, so a failing output looked identical to a working one.
- list rows now say when an automation runs, what it sends, and flag the two
silent misconfigurations: an automation with no triggers and one with no outputs
- outputs and filters render as cards with a shared header, replacing the fixed
grids and the spacer hack used to fake a label-height cell
- test results are reported inline, keyed by field array id so removing an
output cannot leave feedback on the wrong row
- filters gain a plain language summary, and the filter rule only shows when
there is more than one filter to combine
- lifecycle labels are shared with the rundown event editor, which was showing
raw enum values, and it now shows what the linked automation sends
- triggers pointing at a deleted automation say so instead of rendering an
empty tag; the duplicates warning describes what actually happens
not_contains stays out of the operator list: the type and the runtime support
it but the server validation list omits it, so it cannot be saved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LpbLJVVT26tzWkduck1M9H
* fix: issue where a count-to-end would lead to incorrect expected times
* fix: include add time in overtime when countToEnd
* fix: ui and server use same calculation for expected end
The server serves html/timer-legacy.html and html/login.html from disk
at runtime, relative to the bundled server. The Docker image copies
these files but the electron packaging did not, so the view 404ed in
all desktop distributions.
Additionally, AppImages mount at /tmp/.mount_*, a hidden directory.
Express sendFile refuses paths containing dot-segments by default
(returns 404 without touching disk), so the view failed on Linux even
with the file packaged. Allow dotfiles for this route; the request
path is fixed so no user input is affected.
The Stage Timer and PiP Timer views relied on `align-content: center` to
vertically center the timer digits inside `.timer-container`, which is a
plain block element. Aligning children of a block container via
`align-content` only works in Chromium 123+ (Firefox 125+, Safari 17.4+).
Embedded browsers such as vMix Browser Input (CEF V115) and other older
CEF/Chromium-based production tools ignore the property, so the digits
fall back to the top of the container while every other element renders
correctly.
Make `.timer-container` a real flex column and center with
`justify-content: center`, which is universally supported and matches the
centering approach used elsewhere in the codebase. The removed
`justify-self`/`align-self` were no-ops on a full-width flex item.
Fixes#2126
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T6ENZ3r6JXZb1fpYw2oNY
Surface {{groupNow.*}} template variables (title, note, colour, times,
custom fields) in the automation template autocomplete so events inside a
group can reference their group. The runtime store already carries
groupNow, so substitution and filters worked already; this makes it
discoverable.
Extend the message-secondary action with an optional text field so an
automation can set the secondary message content, not just its source.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LZYPZVdZLWowU7DyzGkWyy
Claude
Carlos Valente
Carlos Valente
Alex Christoffer Rasmussen
will@t1d.dev