Drop the enabled:false trigger instruction from the project-generation prompt (blocked)
Nobody has claimed this yet.
- Dominant language
- Jupyter Notebook
- Stars
- 5
- Forks
- 10
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 17
Description
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 https://github.com/OpenFn/lightning/issues/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: falseon the trigger in the two YAML templates.enabled: falseon 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.
https://github.com/OpenFn/apollo/pull/679 does this and is parked in draft until then.
Moved from https://github.com/OpenFn/lightning/issues/4899, which is where it was filed. Part of the Sandbox DevX work in Lightning, https://github.com/OpenFn/lightning/issues/4852, where trigger enablement became a consequence of the lifecycle.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by checking Lightning issue 5163 and the parked draft in OpenFn/apollo#679, since this change is blocked on the client YAML conversion. The target is services/workflow_chat/gen_project_prompts.yaml; after the dependency is resolved, verify the instruction and trigger enabled fields are removed from the templates and embedded examples while edge enabled fields remain.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- yaml
- Domain
- developer-experience
- Issue type
- Refactor
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 30/100