The assistant's apply decides trigger enablement, and reads a missing key as on

Applying a workflow from the assistant goes through the client's YAML conversion rather than the provisioner, and that conversion still owns whether a trigger runs. It requires a trigger to carry an enabled key, and when the key is absent it reads that as on. Both are wrong now the lifecycle decides this.

The first shows up as a plain failure. A reply whose trigger has no enabled key fails validation, so the whole apply is abandoned and the user is told a property is missing instead of getting their workflow. Hanna hit this while reviewing https://github.com/OpenFn/apollo/pull/679.

The second is quieter and worse. If we only allowed the key to be absent, a generated workflow would arrive with its trigger on, which is the opposite of a new workflow arriving as a draft. The provisioner lands triggers off whatever the YAML says. The assistant's path does not, and that difference is easy to miss because both are described as "applying a workflow".

So the work is to make the assistant's apply take trigger enablement from the workflow's state the way the provisioner does, and stop requiring the key on the way in. Lightning should keep sending it, since the current setting is useful context for the model, and stop reading it back.

https://github.com/OpenFn/apollo/issues/678 is blocked on this. It removes the instruction telling the assistant to emit enabled: false, and until this lands that instruction is the only thing keeping generated workflows off.

Part of https://github.com/OpenFn/lightning/issues/4852.

Start by locating the assistant apply path and its YAML conversion, then compare its trigger handling with the provisioner. Verify that a missing enabled key is accepted, that Lightning still sends the setting as context, and that the workflow state determines whether the trigger is enabled; check the apply path and relevant validation tests.