Migrate to Jinja2 template system with semver string versions

src/seclab_taskflows/configs/model_config.yaml

@@ -2,7 +2,7 @@
 # SPDX-License-Identifier: MIT
 
 seclab-taskflow-agent:
-  version: 1
+  version: "1.0"
   filetype: model_config
 models:
    code_analysis: gpt-5

src/seclab_taskflows/configs/model_config_codeql_python.yaml

@@ -2,7 +2,7 @@
 # SPDX-License-Identifier: MIT
 
 seclab-taskflow-agent:
-  version: 1
+  version: "1.0"
   filetype: model_config
 models:
    code_analysis: gpt-5

src/seclab_taskflows/configs/model_config_lowercost.yaml

@@ -2,7 +2,7 @@
 # SPDX-License-Identifier: MIT
 
 seclab-taskflow-agent:
-  version: 1
+  version: "1.0"
   filetype: model_config
 models:
    code_analysis: gpt-5-mini

src/seclab_taskflows/personalities/action_expert.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: personality
-  version: 1
-
+  version: "1.0"
 personality: |
   You are an expert in GitHub actions and workflows. A GitHub workflow maybe reusuable by other workflows. 
   Here are some important facts about GitHub actions and workflows that you should know and used in your analysis.

src/seclab_taskflows/personalities/auditor.yaml

@@ -2,7 +2,7 @@
 # SPDX-License-Identifier: MIT
 
 seclab-taskflow-agent:
-  version: 1
+  version: "1.0"
   filetype: personality
 
 personality: |

src/seclab_taskflows/personalities/web_application_security_expert.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: personality
-  version: 1
-
+  version: "1.0"
 personality: |
   You are a security expert for web applications and libraries, in multiple programming languages.
   You have the ability to call tools to aid you in your security reviews. You know when libraries are used in an unsafe way.

src/seclab_taskflows/prompts/audit/audit_issue.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: prompt
-  version: 1
-
+  version: "1.0"
 prompt: |
         The issues suggested have not been properly verified and are only suggested because they are common issues in these types of 
         application. Your task is to audit the source code to check if this type of issues is present. 

src/seclab_taskflows/prompts/triage_taskflows/actions_common/check_dismiss_reason.yaml

@@ -3,21 +3,20 @@
 
 seclab-taskflow-agent:
   filetype: prompt
-  version: 1
-
+  version: "1.0"
 prompt: |
-  The key is {{ RESULT_key }}. If it is `repos` or `dismissed_alerts_summary,` then your task is done.
+  The key is {{ result.key }}. If it is `repos` or `dismissed_alerts_summary,` then your task is done.
 
-  The repo and alert id can are encoded in the key {{ RESULT_key }} as follows:
+  The repo and alert id can are encoded in the key {{ result.key }} as follows:
   ```
   <encoded_repo_name>_<alert id>
   ```
   For example, if the key is `my_org/my_repo_123`, the repo name to use is `my_org/my_repo`.
   The alert id is the number after the last `_` in the key, which is `123` in this case.
 
-  Before you start, check if an issue with the alert id already exists in {{ RESULT_repo }}.
+  Before you start, check if an issue with the alert id already exists in {{ result.repo }}.
   If it doesn't, then your task is done. 
-  Otherwise, fetch the issue from {{ RESULT_repo }} using the issue id that you found and inspect its body.
+  Otherwise, fetch the issue from {{ result.repo }} using the issue id that you found and inspect its body.
   Remember the issue id, which you'll need to add label and comment on the issue later. 
   This is usually not the same as the alert id.
 

src/seclab_taskflows/prompts/triage_taskflows/actions_common/dismiss_decision.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: prompt
-  version: 1
-
+  version: "1.0"
 prompt: |
   If you decided that the ANY dismissal reason applies then alert is invalid. In this case, add the `FP` label to the issue.
   But if the None of the dismissal reason applies, then don't add the `FP` label.

src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/check_notes.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -17,10 +16,10 @@ taskflow:
         - seclab_taskflows.personalities.web_application_security_expert
       async: true
       user_prompt: |
-        The alert_id is {{ RESULT_alert_id }} and the repo is {{ RESULT_repo }}.
+        The alert_id is {{ result.alert_id }} and the repo is {{ result.repo }}.
         The notes from the alert analysis is:        
         ```
-        {{ RESULT_result }}
+        {{ result.result }}
         ```
         Check all results whether they contain next steps that need to be taken. If they do, then take those steps.
         In case code parts (such as methods) were not found previously, look them up and change the notes accordingly.

src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/fetch_code_scanning_alerts.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -16,7 +15,7 @@ taskflow:
       agents:
         - seclab_taskflow_agent.personalities.assistant
       user_prompt: |
-        Fetch the open alerts from the {{ RESULT_repo }} repo to the sql database.
-        Use {{ RESULT_repo }} as the repo name for storing.
+        Fetch the open alerts from the {{ result.repo }} repo to the sql database.
+        Use {{ result.repo }} as the repo name for storing.
       toolboxes:
         - seclab_taskflows.toolboxes.gh_code_scanning

src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/reachability_analysis.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -15,18 +14,18 @@ taskflow:
       model: triage
       max_steps: 40
       user_prompt: |
-        Inspect the alert location at {{ RESULT_location }} in the repo {{ RESULT_repo }}.
-        This is an alert for a {{ INPUTS_type }} vulnerability.
+        Inspect the alert location at {{ result.location }} in the repo {{ result.repo }}.
+        This is an alert for a {{ inputs.type }} vulnerability.
 
         ## Sanitizers
         For type of vulnerability, you should consider the following as sanitizer:
 
-        {{ INPUTS_sanitizer }}
+        {{ inputs.sanitizer }}
 
         ## User controlled inputs
 
         In this task. You need to determine whether data relevant to the alert can be controlled by an untrusted user.
-        {{ INPUTS_user_input }}
+        {{ inputs.user_input }}
 
         Create a call graph to understand how the code flows from the entry point to the vulnerable code. Let's think step by step and go through the call graph.
         Always try to find out whether the code is in use and reachable from the outside (e.g. via HTTP request).
@@ -36,7 +35,7 @@ taskflow:
 
         You need to record each step of your analysis in the note, stating which function is passing on the alert data and 
         note any sanitizer that is used. Update the results field of the alert result with your notes using `update_alert_result` with 
-        {{ RESULT_alert_id }} as alert_id and {{ RESULT_repo }} as repo.
+        {{ result.alert_id }} as alert_id and {{ result.repo }} as repo.
 
         ## Sanitizer found
         If at any point, you find that the data is sufficiently sanitized, you should mark the alert as invalid, and update its

src/seclab_taskflows/taskflows/alert_triage_examples/triage_common/validate_user_input.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -14,10 +13,10 @@ taskflow:
       async: true
       model: triage
       user_prompt: |
-        The alert_id is {{ RESULT_alert_id }} and the repo is {{ RESULT_repo }}.
+        The alert_id is {{ result.alert_id }} and the repo is {{ result.repo }}.
         The notes from the alert analysis is:        
         ```
-        {{ RESULT_result }}
+        {{ result.result }}
         ```
         Check that the notes contains a section call "User-Controlled input" or similar.
         If the section is missing, then mark the alert as invalid and update the alert results

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/audit_workflow_users.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -16,27 +15,27 @@ taskflow:
       agents:
         - seclab_taskflows.personalities.action_expert
       user_prompt: |
-        Fetch the file {{ RESULT_user }} from the repo {{ RESULT_repo }}.
+        Fetch the file {{ result.user }} from the repo {{ result.repo }}.
 
-        Get the high privileged triggers for the of the workflow in the file {{ RESULT_user }} and check if it is reusable. 
+        Get the high privileged triggers for the of the workflow in the file {{ result.user }} and check if it is reusable. 
         If it does not contain any high privileged trigger AND it is not a reusable action, then the task is done.
 
-        Otherwise, check that the action specified by {{ RESULT_user }} in repo {{ RESULT_repo }} is active.
-        To do so, fetch the workflow from GitHub using the `workflow_id` derived from {{ RESULT_user }}.
+        Otherwise, check that the action specified by {{ result.user }} in repo {{ result.repo }} is active.
+        To do so, fetch the workflow from GitHub using the `workflow_id` derived from {{ result.user }}.
         Then check the workflow state, if it is not `active`, then the task is done.
 
-        Otherwise, from the file {{ RESULT_user }}, take note of the following:
-        1. All the triggers of the action {{ RESULT_user }}.
-        2. All the high privileged triggers of {{ RESULT_user }}, if any. You must clearly state that these are high privileged triggers.
-        2. Any permissions granted to the {{ RESULT_user }} action.
-        3. Any secrets used in the {{ RESULT_user }} action.
+        Otherwise, from the file {{ result.user }}, take note of the following:
+        1. All the triggers of the action {{ result.user }}.
+        2. All the high privileged triggers of {{ result.user }}, if any. You must clearly state that these are high privileged triggers.
+        2. Any permissions granted to the {{ result.user }} action.
+        3. Any secrets used in the {{ result.user }} action.
 
         Update the notes and alert results as follows:
-        You must mention the fact that {{ RESULT_user }} uses {{ RESULT_action }} in lines {{ RESULT_lines }}
+        You must mention the fact that {{ result.user }} uses {{ result.action }} in lines {{ result.lines }}
         in the notes.
-        You must also include all the permissions granted to the {{ RESULT_user }} action in the notes, and all the triggers of the action.
-        Finally, update the all the alert result that has {{ RESULT_action }} with the results in your notes using `update_all_alert_results_for_flow_graph` with 
-        your notes as the `results`, {{ RESULT_action }} as the `next` and {{ RESULT_repo }} as the `repo`.
+        You must also include all the permissions granted to the {{ result.user }} action in the notes, and all the triggers of the action.
+        Finally, update the all the alert result that has {{ result.action }} with the results in your notes using `update_all_alert_results_for_flow_graph` with 
+        your notes as the `results`, {{ result.action }} as the `next` and {{ result.repo }} as the `repo`.
       toolboxes:
         - seclab_taskflows.toolboxes.gh_file_viewer
         - seclab_taskflows.toolboxes.report_alert_state

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/check_report.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -18,9 +17,9 @@ taskflow:
       user_prompt: |
         The bug report is as follows:
         ```
-        {{ RESULT_value }}
+        {{ result.value }}
         ```
-        The alert_id and repo are encoded in the key {{ RESULT_key }} as
+        The alert_id and repo are encoded in the key {{ result.key }} as
         `<repo_name>_<alert_id>`. Use this to extract the alert_id and repo_name from the key. 
 
         If the alert has a high privileged trigger, then the alert is valid and your task is done. Do nothing and DO NOT continue with the task and
@@ -38,23 +37,23 @@ taskflow:
           In this case, check that the report contains a section that lists the vulnerable action users. 
           If there isn't any vulnerable action users and there is no high privileged trigger, 
           then mark the alert as invalid and 
-          using the alert_id and repo, then remove the memcache entry with the key {{ RESULT_key }}.
+          using the alert_id and repo, then remove the memcache entry with the key {{ result.key }}.
         - If it is a reusable action and contains a section that lists the vulnerable action users, then check 
           if any of the action user is a high privileged workflow. If none of the the action users is a high privileged workflow, 
-          then mark the alert as invalid and remove the memcache entry with the key {{ RESULT_key }}.
+          then mark the alert as invalid and remove the memcache entry with the key {{ result.key }}.
         - Is there any mentioning of `write` permissions or secrets used by the action? If neither are mentioned, and none of the triggers is 
-          a high privileged trigger, then mark the alert as invalid and remove the memcache entry with the key {{ RESULT_key }}.
+          a high privileged trigger, then mark the alert as invalid and remove the memcache entry with the key {{ result.key }}.
         - Is the only trigger of the alert `workflow_call` or `pull_request`? If so, and there is no mentioning of any 
-          `write` permission granted, then mark the alert as invalid and remove the memcache entry with the key {{ RESULT_key }}.
+          `write` permission granted, then mark the alert as invalid and remove the memcache entry with the key {{ result.key }}.
 
-        {{ INPUTS_vuln_specifics }}
+        {{ inputs.vuln_specifics }}
 
         IMPORTANT:
         If any of the above indicates that the alert is invalid,
-        then you MUST mark the alert as invalid and remove the memcache entry with the key {{ RESULT_key }}, even if you believe 
+        then you MUST mark the alert as invalid and remove the memcache entry with the key {{ result.key }}, even if you believe 
         the vulnerability still poses a risk. You MUST follow the instructions. You can then finish the task.
         You should then also update the alert result with the reason why the alert is invalid, using the alert_id and repo_name extracted 
-        from the key {{ RESULT_key }}.
+        from the key {{ result.key }}.
 
       toolboxes:
         - seclab_taskflow_agent.toolboxes.memcache

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/cleanup_results.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -16,7 +15,7 @@ taskflow:
       name: set up taskflow
       description: Clearing previous results.
       user_prompt: |
-        Clear the alert results from with the rule `{{ GLOBALS_rule }}` and all the alert flows.
+        Clear the alert results from with the rule `{{ globals.rule }}` and all the alert flows.
         Then clear the memcache.
       toolboxes:
         - seclab_taskflows.toolboxes.report_alert_state

src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/collect_dismiss_reasons.yaml

@@ -3,8 +3,7 @@
 
 seclab-taskflow-agent:
   filetype: taskflow
-  version: 1
-
+  version: "1.0"
 model_config: seclab_taskflows.configs.model_config
 
 taskflow:
@@ -14,17 +13,17 @@ taskflow:
       agents:
         - seclab_taskflows.personalities.action_expert
       user_prompt: |
-        Fetch the dismissed alerts from the {{ INPUTS_repos }} and use {{ INPUTS_rule }}.
+        Fetch the dismissed alerts from the {{ inputs.repos }} and use {{ inputs.rule }}.
 
-        Look through the dismissal comments and only consider comments that starts with {{ INPUTS_label }}.
+        Look through the dismissal comments and only consider comments that starts with {{ inputs.label }}.
 
         Additionally, include the following dismissal reasons:
         1. There is a check to ensure that vulnerable code only runs when a label is present on the PR.
         2. There is a check to ensure that the workflow is run by a trusted user, such as a member of the org or repo.
         3. There is a check to ensure that the vulnerable code is run in an environment that requires extra approval, such as a production environment.
         4. There is a check to ensure that vulnerable code only runs when the workflow is triggered by an event that is not controlled by the user, 
            such as a push event or a merge event.
-        {{ INPUTS_vuln_specifics }}
+        {{ inputs.vuln_specifics }}
 
         Summarize the reasons for dismissal in a single markdown formatted text block, without mentioning the alert id, rule or the repo name.
         Store the summary in the memcache with the key `dismissed_alerts_summary`.