Fix(frontend): prevent triggers reset upon deploy & stay here

[Guilhem-lm]

Important

Renamed triggersState.setTriggers([]) to setDraftTriggers([]) in FlowBuilder.svelte and ScriptBuilder.svelte to clarify function purpose.

• Function Rename:
  • In FlowBuilder.svelte, replace triggersState.setTriggers([]) with setDraftTriggers([]) to set draft triggers.
  • In ScriptBuilder.svelte, replace triggersState.setTriggers([]) with setDraftTriggers([]) to set draft triggers.

^{This description was created by for 8e9364d. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 8e9364d in 1 minute and 53 seconds. Click for details.

• Reviewed 26 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. frontend/src/lib/components/FlowBuilder.svelte:464

• Draft comment:
  Use of setDraftTriggers([]) now preserves non‐draft triggers. Consider adding a brief comment explaining that this clears only draft triggers (keeping committed ones) to avoid confusion.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% While the comment is technically correct about the behavior change, it's suggesting adding a documentation comment which violates our rules. The rules state we should not make purely informative comments or ask for documentation changes. The code behavior is clear from reading the setDraftTriggers implementation. The comment is accurate about the technical behavior change. Am I being too strict in applying the "no documentation requests" rule? No - the rules are clear that we should not request documentation changes or make purely informative comments. The code behavior is clear from reading the implementation. Delete the comment. While technically accurate, it violates our rules by requesting documentation changes and making purely informative comments about code that is already clear.

2. frontend/src/lib/components/ScriptBuilder.svelte:558

• Draft comment:
  Switching from triggersState.setTriggers([]) to setDraftTriggers([]) ensures only draft triggers are reset while keeping non‐draft triggers. A short comment clarifying this behavior would improve clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the comment is technically correct about the behavior difference, adding inline comments explaining implementation details is generally not a good practice. The function name setDraftTriggers() is already clear about its purpose. The implementation details can be seen by looking at the function definition. Additionally, this is a pure refactoring change to use a more appropriately named function. The comment points out a real behavioral difference between the old and new code that could be worth documenting. Future maintainers may wonder why one function was chosen over another. The function name setDraftTriggers() is self-documenting and its implementation is clear in the code. Adding an inline comment would be redundant and could become outdated. Code should be written to be self-documenting through good naming rather than relying on comments. The comment should be deleted. The code change is a straightforward refactor to use a more appropriately named function, and the function name itself adequately documents its purpose.

Workflow ID: wflow_cIGMjoDzhB4AjflG

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}