Yuliia Pominchuk f0b71fd1f3 feat(core): Require a declared trigger before a workflow can be scheduled ... Running a workflow now and putting it on a schedule were held to the same bar, and they should not be. Running once is bounded — the person is there, it happens once, they see the result — and anyone with execute access could have run it from the editor anyway, so a manual trigger is enough to justify it. A schedule is unattended, recurring, and acts with that person's accounts for as long as it stands. That is too large a commitment to infer from the mere presence of a start node. The Execute Workflow Trigger is the builder saying "this is meant to be called by something other than me"; a manual trigger says the opposite. Subscriptions now require the former, on create and on update — the trigger can be taken back out after someone subscribed, and changing a schedule must not quietly re-bless it. Manual-trigger workflows stay in the catalog and stay runnable. Their schedule button is disabled with the reason on it rather than hidden, so nobody is left looking for an option that silently vanished. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>		2026-08-05 14:18:19 +02:00
..
generated	feat(core): Store catalog consent and personal schedules	2026-08-05 12:14:48 +02:00
db.md	feat(core): Add auto-generated database schema documentation (no-changelog) (#32069)	2026-06-12 07:44:01 +00:00
workflow-catalog-handoff.md	feat(core): Require a declared trigger before a workflow can be scheduled	2026-08-05 14:18:19 +02:00