Stop telling the model to disable triggers

[elias-ba]

Short Description

Removes the instruction telling the model to emit triggers with enabled: false, and the same default from the prompt's templates and worked examples.

Fixes #678

Implementation Details

Lightning decides whether a trigger is on. A new workflow arrives as a draft with its triggers off, going live is what turns them on, and the provisioner lands it that way whatever the YAML says. The instruction here was repeating something Lightning does anyway, and it would disagree with the lifecycle the first time that default changed.

Changed in services/workflow_chat/gen_project_prompts.yaml:

• the instruction "The trigger should be set to enabled: false by default."
• enabled: false on the cron and webhook triggers in both YAML templates
• enabled: false on the trigger in both embedded worked examples

Edges keep their enabled, which is a different thing and one the model sets meaningfully.

No test asserts on the removed lines. tests/unit/gen_project/test_prompt_build.py checks other phrases, and the enabled: false in tests/test_pass_fail.py is input YAML representing an existing workflow, which is still valid and still has to be preserved.

Context: this came out of the Sandbox DevX work in Lightning (OpenFn/lightning#4852), where trigger enablement became a consequence of the workflow lifecycle. Filed there first as OpenFn/lightning#4899 and moved here.

AI Usage

Please disclose whether you've used AI in this work (it's cool, we just want to
know!):

• Yes, I have used AI
• No, I have not used AI

You can read more details in our
Responsible AI Policy

[hanna-paasivirta]

@elias-ba Which is the correct Lightning branch for this? Lightning complains of the missing key when generating a workflow from scratch, and also when changing the trigger type.

Are you sure we don't need to tell the assistant explicitly about what it should do in each scenario? If we don't want Apollo to touch the trigger setting at all, should Lightning stop sending it?

[elias-ba]

Sorry Hanna, I shouldn't have put this up for review. There is no Lightning branch that makes it work yet, which is why you're seeing the missing key.

This one belongs to the Sandboxes DevX work rather than the global assistant, and I filed it as a standalone prompt cleanup when it isn't one. Lightning still requires enabled on a trigger and reads an absent one as on, so dropping the instruction would leave new workflows live instead of draft. That needs fixing on the Lightning side first.

I've put it back in draft. Please don't spend any more time on it for now, and I'll pick it up again once the Lightning half is in.