Lightning should decide whether a trigger is on, so the prompt should stop deciding it.
A new workflow arrives as a draft with its triggers off, and going live is what turns them on. The provisioner already lands state: draft with enabled: false on every trigger regardless of what the YAML says, so for anything deployed that way this instruction repeats something Lightning does anyway.
Blocked on OpenFn/lightning#5163. The assistant's apply does not go through the provisioner. It goes through the client's YAML conversion, which requires a trigger to carry an enabled key and reads an absent one as on. So removing the instruction today fails the apply outright, and removing it after only relaxing that requirement would land generated workflows with their triggers running. Right now this instruction is the only thing keeping them off.
That was the mistaken part of this issue as first written: it treated the provisioner's behaviour as covering every path, and the assistant's is the one that matters here.
What to remove from services/workflow_chat/gen_project_prompts.yaml, once Lightning's side is in:
- The instruction "The trigger should be set to enabled: false by default."
enabled: false on the trigger in the two YAML templates.enabled: false on the triggers inside the two embedded example responses.
Leave enabled alone on edges. That is a different thing and the AI does set it meaningfully.
#679 does this and is parked in draft until then.
Moved from OpenFn/lightning#4899, which is where it was filed. Part of the Sandbox DevX work in Lightning, OpenFn/lightning#4852, where trigger enablement became a consequence of the lifecycle.
Lightning should decide whether a trigger is on, so the prompt should stop deciding it.
A new workflow arrives as a draft with its triggers off, and going live is what turns them on. The provisioner already lands
state: draftwithenabled: falseon every trigger regardless of what the YAML says, so for anything deployed that way this instruction repeats something Lightning does anyway.Blocked on OpenFn/lightning#5163. The assistant's apply does not go through the provisioner. It goes through the client's YAML conversion, which requires a trigger to carry an
enabledkey and reads an absent one as on. So removing the instruction today fails the apply outright, and removing it after only relaxing that requirement would land generated workflows with their triggers running. Right now this instruction is the only thing keeping them off.That was the mistaken part of this issue as first written: it treated the provisioner's behaviour as covering every path, and the assistant's is the one that matters here.
What to remove from
services/workflow_chat/gen_project_prompts.yaml, once Lightning's side is in:enabled: falseon the trigger in the two YAML templates.enabled: falseon the triggers inside the two embedded example responses.Leave
enabledalone on edges. That is a different thing and the AI does set it meaningfully.#679 does this and is parked in draft until then.
Moved from OpenFn/lightning#4899, which is where it was filed. Part of the Sandbox DevX work in Lightning, OpenFn/lightning#4852, where trigger enablement became a consequence of the lifecycle.