So is the user expected to pass through an absolute path here?

Also, where is the simulate-verify-task TASK="": just command expected to be executed from?

The user can enter a relative or absolute path to the task. If it is relative it is converted to absolute.

I added comments about when the command is supposed to be used, and what the parameter is

We want to be simulating non-terminal tasks from the networks directories and not the example directory.

simulate-non-terminal-tasks:
    #!/usr/bin/env bash
    set -euo pipefail
    root_dir=$(git rev-parse --show-toplevel)
    forge build

    # Later this networks list should be dynamically generated from the src/improvements/tasks directory.
    networks=("eth" "sep")
    for network in ${networks[@]}; do
        if [ "$network" != "src/improvements/tasks/example" ]; then # skip example tasks
            for task in ${root_dir}/src/improvements/tasks/${network}/*; do
               ${root_dir}/src/improvements/script/simulate-verify-task.sh $task $nested_safe_name
            done
        fi
        echo "Done simulating non-terminal tasks for network: $network"
    done
    ```

I think this should be put this in a separate PR. The feature being added here is simulating non-terminal tasks in CI for the new superchain-ops repo.

The thing is that I don't have any tasks outside examples to test the functionality with, so if I exclude it now it does nothing.

I suggest that we don't put this into CI, and leave it as a developer tool, until we have one or more tasks outside examples, then we can exclude it from simulate-non-terminal-tasks and put it on CI.

Who calls this? What's the TENDERLY_PAYLOAD? I know its mentioned in the simulate-verify-task.sh file below but more information in this file as to what it's purpose is would be helpful.

Good point, I added a detailed comments about that.

Do we need all the file i/o here with local/remote/forge_output_file? When it fails for whatever reason before cleanup we leave these files lying around for devs to delete manually.

We are scraping the output of other scripts to capture the payload and the hashes.

I tried to capture the output in a variable and scrape that, but we also want the output on console for debugging. It then becomes really hard to capture the output from both stdout, stderr in the variable and always show it regardless of the underlying script exit code.

The current system is more robust, as you always get all the output on the console for debugging. However, I've move the commands to remove files so that they are removed as soon as possible. If a script fails, only one file would remain, which also would have the relevant output if needed. The file would be removed in the next successful execution.

I hope that's a reasonable compromise.