chore: deploy Set it Free Loop (review tier, v2.0.0) - #222
Conversation
Source: HemSoft/set-it-free-loop@380fe0e Version: 2.0.0 Tier: review Components: labels, governance, sfl-pr-review Engine policy: codex-gpt-55-high See https://github.com/HemSoft/set-it-free-loop for full documentation.
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
📝 WalkthroughSummary by CodeRabbit
WalkthroughAdds SFL configuration and review instructions plus a generated GitHub Actions workflow. The workflow gates labeled pull requests, runs a Copilot review, processes artifacts, and publishes bounded review and check results. ChangesSFL pull request review automation
Estimated code review effort: 4 (Complex) | ~45 minutes Suggested labels: Poem Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.gitattributes:
- Line 1: Configure the repository-local Git merge driver before relying on the
merge=ours attribute for workflow lock files, using merge.ours.driver=true, and
document the required setup step; otherwise replace merge=ours with an approach
that preserves the intended lock-file merge behavior. Leave
linguist-generated=true unchanged.
In @.github/workflows/sfl-pr-review.md:
- Around line 51-52: Convert the two provenance lines at the top of the workflow
Markdown file from Markdown headings into HTML comments, matching the existing
`<!-- sfl: ... -->` convention, while preserving their text and placement before
the intended `# SFL Review` heading.
- Around line 116-126: Update the finding policy in the review instructions so
inline comments are capped at 20 total, prioritizing findings by severity from
Critical through Low. Ensure the consolidated review body reports how many
findings were omitted when the cap is exceeded, while preserving the exact
severity prefixes and one-thread-per-posted-finding behavior.
In `@sfl.json`:
- Around line 15-23: Add SFL_APP_PRIVATE_KEY to the requiredSecretsAnyOf array
for the sfl-pr-review configuration, keeping the existing profile, provider,
model, and effort settings unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: a7470c55-a025-4e3d-81d5-c5452bea9d65
📒 Files selected for processing (6)
.gitattributes.github/aw/actions-lock.json.github/workflows/sfl-pr-review.lock.yml.github/workflows/sfl-pr-review.mdREADME.mdsfl.json
| @@ -0,0 +1 @@ | |||
| .github/workflows/*.lock.yml linguist-generated=true merge=ours No newline at end of file | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
gitattributes merge=ours requires configuring merge driver git config merge.ours.driver true
💡 Result:
Yes, using the merge=ours attribute in a.gitattributes file requires you to define a custom merge driver in your Git configuration [1][2][3]. Git does not have a built-in merge driver named "ours" that can be automatically triggered by the merge attribute, so you must define one yourself [2][3]. To set this up: 1. Define the custom driver in your git configuration: git config merge.ours.driver true This command configures a driver named "ours" that runs the shell command true [1][4]. Since the true command always exits with a success status (0) and does not modify the file, Git treats the current file version in your working tree as the successfully merged result [1][3][4]. 2. Assign the attribute to your files in.gitattributes: filename.ext merge=ours Technical Caveats and Limitations: - Driver Invocation: The custom merge driver is only invoked when Git identifies a merge conflict (a "non-trivial" merge) for that specific file [2][3][5]. If a file has not been modified on the other branch, or if Git can perform the merge automatically without conflicts, the driver will not be called [2][3][6]. - High-level Conflicts: This method addresses low-level content conflicts [5]. It will not resolve "tree" or "high-level" conflicts, such as when one branch deletes a file while the other branch modifies it [5]. - Configuration Scope: You can use --global to apply this to all your repositories, or omit it to restrict the configuration to the current repository [1][2][3]. Some users prefer to define the driver explicitly in their.git/config using a section like [merge "ours"] driver = true to ensure consistent behavior [3][7].
Citations:
- 1: https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attributes
- 2: https://stackoverflow.com/questions/14093540/tell-git-to-use-ours-merge-strategy-on-specific-files
- 3: https://stackoverflow.com/questions/5465122/gitattributes-individual-merge-strategy-for-a-file
- 4: https://stackoverflow.com/questions/928646/have-git-select-local-version-on-merge-conflict-on-a-specific-file
- 5: https://stackoverflow.com/questions/64610363/unable-to-configure-the-gitattributes-to-have-any-effect-for-merges
- 6: https://stackoverflow.com/questions/51881132/git-using-merge-ours-strategy-from-command-line
- 7: https://stackoverflow.com/questions/62385612/git-attributes-for-merge-ours-doesnt-work
🌐 Web query:
Git documentation merge attributes merge-driver merge.x.driver not built-in
💡 Result:
Git does not include a built-in merge driver named "merge.x.driver". The configuration merge.<name>.driver is a template used to define custom merge drivers in your Git configuration files (such as .git/config or ~/.gitconfig) [1][2][3]. The <name> placeholder should be replaced by a unique identifier of your choosing [4][3]. To set up a custom merge driver, follow these two steps: 1. Define the driver in your Git configuration: Use the git config command or manually edit your configuration file to define the driver's name, command, and optional recursive behavior [1][5][3]. Replace my-custom-driver with your chosen identifier: git config merge.my-custom-driver.name "A custom merge driver" git config merge.my-custom-driver.driver "path/to/your-script.sh %O %A %B" The %O, %A, and %B tokens are automatically replaced by Git with the temporary file paths for the ancestor, current, and incoming versions of the file, respectively [1][2][3]. 2. Assign the driver to specific files via.gitattributes: Tell Git which files should use your custom driver by adding an entry to your .gitattributes file [1][4][5]: *.ext merge=my-custom-driver When a merge occurs, Git will invoke the command specified in your configuration for any files matching the pattern in .gitattributes [1][4]. The script is expected to overwrite the file at %A with the merge result and exit with a status of 0 for a clean merge, or non-zero if conflicts remain [1][2].
Citations:
- 1: https://git-scm.com/docs/gitattributes
- 2: https://linuxman7.org/linux/man-pages/man5/gitattributes.5.html
- 3: https://github.com/Praqma/git-merge-driver
- 4: https://graphite.com/guides/git-merge-driver
- 5: https://monzool.net/blog/2026/03/24/custom-git-merge-driver/
🌐 Web query:
"built-in merge strategy" "built-in merge driver" git-mergeours.gitattributes
💡 Result:
In Git, merge strategies and merge drivers serve distinct roles, and the merge=ours attribute relies on a custom driver configuration rather than a built-in strategy [1][2]. Merge Strategies vs. Merge Drivers A merge strategy (e.g., recursive, octopus, ours) operates at the commit level to determine how to combine entire branches [3][4]. It is responsible for selecting the base commit and the parent commits [1][2]. A merge driver (also called a low-level merge driver) operates at the file level [1]. It is only invoked during a merge when Git determines that a specific file has been modified in both branches relative to the common ancestor [5][6]. If a file is unchanged in one branch, or if Git can perform a fast-forward, the merge driver is typically not invoked at all [5][6][4]. Merge=ours in.gitattributes The merge=ours attribute is not a built-in feature of Git by default [6][7]. To use it, you must define a custom merge driver named ours in your Git configuration [8][9]. This is typically done by running: git config --global merge.ours.driver true Once configured, assigning merge=ours to files in a.gitattributes file tells Git to use this driver when a file-level conflict occurs [8]. The driver simply does nothing (the true command returns a zero exit status), effectively leaving the file in your current branch ("ours") as it is [6][8]. Important Limitations 1. Triggering: The driver is only triggered when both branches have modified the file [5][9]. If only one branch modified the file, Git may simply accept that change, bypassing your merge driver entirely [5][6]. 2. Not a Strategy: This is a driver, not a merge strategy [5]. It cannot be used with the git merge -s command. The git merge -s ours strategy is an entirely different mechanism that merges entire branches by completely ignoring all changes from the incoming branch [7]. Summary of Key Terms * Merge Strategy: Chosen via git merge -s; determines how to reconcile commit history [3]. * Merge Driver: Triggered by.gitattributes when a file has content conflicts; handles the resolution of those specific files [1][2]. * git-merge-ours: This refers to the implementation of the -s ours strategy, which is distinct from the user-defined merge driver named "ours" used in.gitattributes [4][7].
Citations:
- 1: https://stackoverflow.com/questions/78245481/git-merge-strategies-vs-merge-drivers-vs-mergetools
- 2: https://gregmicek.com/software-coding/2020/01/13/how-to-write-a-custom-git-merge-driver/
- 3: https://git-scm.com/docs/git-merge
- 4: https://stackoverflow.com/questions/42997079/gitattributes-merge-ours-strategy-vs-fast-forward-merging
- 5: https://stackoverflow.com/questions/41640602/gitattributes-merge-strategy-not-working
- 6: https://stackoverflow.com/questions/14093540/tell-git-to-use-ours-merge-strategy-on-specific-files
- 7: https://stackoverflow.com/questions/65423043/git-merge-apply-incoming-changes-only-for-unmodified-files
- 8: https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attributes
- 9: https://stackoverflow.com/questions/27134100/whats-the-proper-usage-of-gitattributes-with-merge-ours
Configure the ours merge driver before using merge=ours.
merge=ours in .gitattributes does not invoke the branch-level git merge -s ours strategy. Git must find a configured low-level merge driver named ours; otherwise it ignores the attribute and falls back to normal three-way merge behavior. Add the repository-local config:
git config merge.ours.driver true
Document this setup step, or avoid merge=ours and regenerate the lock files after merges. linguist-generated=true needs no change.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.gitattributes at line 1, Configure the repository-local Git merge driver
before relying on the merge=ours attribute for workflow lock files, using
merge.ours.driver=true, and document the required setup step; otherwise replace
merge=ours with an approach that preserves the intended lock-file merge
behavior. Leave linguist-generated=true unchanged.
| # Deployed from: HemSoft/set-it-free-loop/deployment/workflows/sfl-pr-review.md@380fe0edc7a87cfc7b31233a955b37df0223a3a8 | ||
| # To upgrade: re-run deploy-workflow.ps1 at the desired SHA |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Lines 51-52 render as Markdown headings, not comments.
A leading # in Markdown creates an H1 heading. These two provenance lines therefore become headings. The lock file imports this file into the agent prompt at runtime (.github/workflows/sfl-pr-review.lock.yml line 317), so the agent receives a spurious H1 before the intended # SFL Review heading at line 75. markdownlint also reports MD022 on both lines.
Use HTML comments, consistent with the <!-- sfl: ... --> block below.
📝 Proposed fix
-# Deployed from: HemSoft/set-it-free-loop/deployment/workflows/sfl-pr-review.md@380fe0edc7a87cfc7b31233a955b37df0223a3a8
-# To upgrade: re-run deploy-workflow.ps1 at the desired SHA
+<!-- Deployed from: HemSoft/set-it-free-loop/deployment/workflows/sfl-pr-review.md@380fe0edc7a87cfc7b31233a955b37df0223a3a8 -->
+<!-- To upgrade: re-run deploy-workflow.ps1 at the desired SHA -->📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Deployed from: HemSoft/set-it-free-loop/deployment/workflows/sfl-pr-review.md@380fe0edc7a87cfc7b31233a955b37df0223a3a8 | |
| # To upgrade: re-run deploy-workflow.ps1 at the desired SHA | |
| <!-- Deployed from: HemSoft/set-it-free-loop/deployment/workflows/sfl-pr-review.md@380fe0edc7a87cfc7b31233a955b37df0223a3a8 --> | |
| <!-- To upgrade: re-run deploy-workflow.ps1 at the desired SHA --> |
🧰 Tools
🪛 markdownlint-cli2 (0.23.1)
[warning] 51-51: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 52-52: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Above
(MD022, blanks-around-headings)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/sfl-pr-review.md around lines 51 - 52, Convert the two
provenance lines at the top of the workflow Markdown file from Markdown headings
into HTML comments, matching the existing `<!-- sfl: ... -->` convention, while
preserving their text and placement before the intended `# SFL Review` heading.
Source: Linters/SAST tools
| For each finding, call `create-pull-request-review-comment` on the most precise | ||
| changed line. The comment body must begin with one of these exact prefixes: | ||
|
|
||
| - `**CRITICAL Finding**` | ||
| - `**HIGH Finding**` | ||
| - `**MEDIUM Finding**` | ||
| - `**LOW Finding**` | ||
|
|
||
| After the prefix, state the defect, impact, evidence, and a concrete fix. | ||
| Create exactly one inline thread per finding. If there are no findings, create | ||
| no inline comments. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
The finding policy does not account for the 20-comment cap.
create-pull-request-review-comment allows a maximum of 20 comments (line 38, and .github/workflows/sfl-pr-review.lock.yml line 545). The prompt instructs the agent to create exactly one inline thread per finding, with no upper bound. If the agent produces more than 20 findings, the safe-output handler drops the excess. The severity counts in the consolidated review body then disagree with the posted inline threads, and a dropped Critical finding is invisible to the author.
Instruct the agent to post at most 20 inline threads, to prioritize by severity, and to state any dropped-finding count in the review body.
📝 Proposed prompt addition
After the prefix, state the defect, impact, evidence, and a concrete fix.
Create exactly one inline thread per finding. If there are no findings, create
no inline comments.
+
+Post at most 20 inline threads. If the findings exceed 20, post the 20 highest
+severity findings and report the number of omitted findings in the review body.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| For each finding, call `create-pull-request-review-comment` on the most precise | |
| changed line. The comment body must begin with one of these exact prefixes: | |
| - `**CRITICAL Finding**` | |
| - `**HIGH Finding**` | |
| - `**MEDIUM Finding**` | |
| - `**LOW Finding**` | |
| After the prefix, state the defect, impact, evidence, and a concrete fix. | |
| Create exactly one inline thread per finding. If there are no findings, create | |
| no inline comments. | |
| For each finding, call `create-pull-request-review-comment` on the most precise | |
| changed line. The comment body must begin with one of these exact prefixes: | |
| - `**CRITICAL Finding**` | |
| - `**HIGH Finding**` | |
| - `**MEDIUM Finding**` | |
| - `**LOW Finding**` | |
| After the prefix, state the defect, impact, evidence, and a concrete fix. | |
| Create exactly one inline thread per finding. If there are no findings, create | |
| no inline comments. | |
| Post at most 20 inline threads. If the findings exceed 20, post the 20 highest | |
| severity findings and report the number of omitted findings in the review body. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/sfl-pr-review.md around lines 116 - 126, Update the
finding policy in the review instructions so inline comments are capped at 20
total, prioritizing findings by severity from Critical through Low. Ensure the
consolidated review body reports how many findings were omitted when the cap is
exceeded, while preserving the exact severity prefixes and
one-thread-per-posted-finding behavior.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 670a58612f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Standalone full-spectrum pull request review triggered by the sfl-review | ||
| label. Performs security, correctness and reliability, and quality and | ||
| maintainability passes, posts one inline thread per finding, submits a | ||
| consolidated review, and publishes the SFL Reviewer Approval check. |
There was a problem hiding this comment.
This introduces a repository-wide development and review process but leaves the current Unreleased changelog unchanged, so the documented development history no longer reflects the deployed automation. Add an entry under the Unreleased Developer Experience subsection describing the label-triggered reviewer.
AGENTS.md reference: AGENTS.md:L54-L55
Useful? React with 👍 / 👎.
| @@ -0,0 +1 @@ | |||
| .github/workflows/*.lock.yml linguist-generated=true merge=ours No newline at end of file | |||
There was a problem hiding this comment.
When two branches both regenerate a workflow lock file, ours is interpreted as a custom low-level merge driver, but this repository neither defines merge.ours.driver nor documents the required Git configuration. With the repository as committed, Git performs its normal merge and still reports conflicts instead of retaining the generated lock file; configure the driver for contributors or remove the ineffective attribute.
Useful? React with 👍 / 👎.
Source: HemSoft/set-it-free-loop@358e255 Version: 2.0.0 Tier: review Components: labels, governance, sfl-pr-review Engine policy: codex-gpt-55-high See https://github.com/HemSoft/set-it-free-loop for full documentation.
Source: HemSoft/set-it-free-loop@235a0df Version: 2.0.0 Tier: review Components: labels, governance, sfl-pr-review Engine policy: codex-gpt-55-high See https://github.com/HemSoft/set-it-free-loop for full documentation.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/sfl-pr-review.lock.yml (1)
61-75: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winWorkflow
nameandrun-namecarry a deployment provenance string.The value
"Deployed from: HemSoft/set-it-free-loop/deployment/workflows/sfl-pr-review.md@358e25578515d4b1ed46cacb686624897720cdab"becomes the display name in the Actions UI. The same value propagates toGH_AW_WORKFLOW_NAMEin the conclusion job (Lines 1248, 1269, 1287, 1302, 1317) and the safe-outputs job (Line 1725). Handlers such ashandle_noop_message.cjs,missing_tool.cjs, andhandle_agent_failure.cjsuse that value in issue titles and report bodies. Users will see the commit SHA and source path in issue titles.Set a readable
namein the source workflow.github/workflows/sfl-pr-review.mdand keep the provenance in the description or a comment. Recompile the lock file afterwards; do not edit the lock file directly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/sfl-pr-review.lock.yml around lines 61 - 75, Update the source workflow’s name in .github/workflows/sfl-pr-review.md to a readable user-facing title, while preserving the deployment provenance string in the description or a comment. Then recompile the generated sfl-pr-review.lock.yml through the project’s workflow generation process; do not modify the lock file directly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/sfl-pr-review.lock.yml:
- Line 356: Align the MCP tool configuration with the generated agent prompt:
update the GH_AW_MCP_CLI_SERVERS_LIST value to include the declared github MCP
tools (pull_requests and repos), or remove the github toolset from the
workflow/source if those tools should not be available. Keep the workflow’s
declared tools and prompt-listed tools consistent.
---
Outside diff comments:
In @.github/workflows/sfl-pr-review.lock.yml:
- Around line 61-75: Update the source workflow’s name in
.github/workflows/sfl-pr-review.md to a readable user-facing title, while
preserving the deployment provenance string in the description or a comment.
Then recompile the generated sfl-pr-review.lock.yml through the project’s
workflow generation process; do not modify the lock file directly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: f24f8795-b562-4ffa-b32c-41e774890e58
📒 Files selected for processing (3)
.github/workflows/sfl-pr-review.lock.yml.github/workflows/sfl-pr-review.mdsfl.json
| GH_AW_GITHUB_REPOSITORY: ${{ github.repository }} | ||
| GH_AW_GITHUB_RUN_ID: ${{ github.run_id }} | ||
| GH_AW_GITHUB_WORKSPACE: ${{ github.workspace }} | ||
| GH_AW_MCP_CLI_SERVERS_LIST: '- `safeoutputs` — run `safeoutputs --help` to see available tools' |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Trace how the GitHub MCP server token is supplied to the Codex agent.
set -euo pipefail
rg -n 'GH_AW_GITHUB_TOKEN|GITHUB_MCP_SERVER_TOKEN|GH_AW_MCP_CLI_SERVERS_LIST|mcp_servers.github' .github/workflows/sfl-pr-review.lock.yml
fd -H 'sfl-pr-review.md' -t f -p '.github' --exec rg -n -A6 'tools:|github:|toolsets' {}Repository: HemSoft/codexbar-ios
Length of output: 8499
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow relevant sections =="
sed -n '32,40p;180,215p;340,385p;485,535p;730,815p;905,980p' .github/workflows/sfl-pr-review.lock.yml
echo "== source workflow relevant sections =="
sed -n '24,36p' .github/workflows/sfl-pr-review.md 2>/dev/null || true
echo "== references to safeoutputs/github prompts =="
rg -n 'github_mcp_tools_with_safeoutputs_prompt|safeoutputs --help|pull_requests|toolsets' .github/workflows/sfl-pr-review.lock.yml .github/workflows/sfl-pr-review.md 2>/dev/null || trueRepository: HemSoft/codexbar-ios
Length of output: 22697
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate substitute placeholder action =="
fd -H 'substitute' -t f -p '.github'
for f in $(fd 'substitute.*\.(cjs|js|ts)$' .github); do
echo "== $f =="
sed -n '1,220p' "$f"
done
echo "== locate config generation action =="
fd 'generate.*config|generate_mcp|start_mcp_gateway|substitute' .github/actions -t f | sed -n '1,120p'
for f in $(fd 'generate.*config|generate_mcp|start_mcp_gateway|interpolate_prompt|substitute' .github/actions -t f); do
echo "== $f =="
sed -n '1,240p' "$f"
doneRepository: HemSoft/codexbar-ios
Length of output: 342
🏁 Script executed:
#!/bin/bash
set -euo pipefail
git ls-files .github | sed -n '1,160p'
echo "== all placeholder/config/token env references =="
rg -n 'GH_AW_PROMPT|GH_AW_MCP_CONFIG|substitutePlaceholders|GITHUB_MCP_SERVER_TOKEN|GITHUB_PERSONAL_ACCESS_TOKEN|GH_AW_GITHUB_TOKEN' .github -g '*.*' || trueRepository: HemSoft/codexbar-ios
Length of output: 13063
🌐 Web query:
gh-aw-actions setup substitute_placeholders GH_AW_PROMPT replace tokens
💡 Result:
In the context of the gh-aw project, substitute_placeholders.cjs is an internal JavaScript utility used within GitHub Actions workflows to replace specific placeholder patterns in prompt files with environment variable values at runtime [1][2]. The substitution process typically works as follows: 1. Placeholder Pattern: The system uses the pattern GH_AW_* (e.g., GH_AW_GITHUB_WORKSPACE) to represent placeholders within prompt templates [1][2]. 2. Runtime Replacement: The substitute_placeholders.cjs script is executed within a GitHub Actions step (often using actions/github-script) to scan a specified file and replace these placeholders with the values mapped from the provided environment variables [3][1][2][4]. 3. Workflow Implementation: Workflows configure this step by setting the GH_AW_PROMPT environment variable to the path of the prompt file, and providing a mapping of substitutions (variable names to their actual runtime values) when calling the substitutePlaceholders function [5][4]. Key technical details include: - Global Initialization: It is critical that setupGlobals is called before requiring substitute_placeholders.cjs to ensure GitHub Actions APIs (like core, github, context) are available to the script [3][4]. - Validation: The system includes validation steps (such as validate_prompt_placeholders.sh) to ensure that all GH_AW_* placeholders are successfully replaced before the prompt is used by the agent [5][2]. - Not to be confused with the popular community action cschleiden/replace-tokens, which is a general-purpose GitHub Action used for replacing tokens (often with prefixes like #{) in generic files [6][7]. The gh-aw implementation is a specialized, internal component of the gh-aw workflow pipeline [8].
Citations:
- 1: Fix: Use placeholder syntax for GITHUB_WORKSPACE in temp_folder_prompt github/gh-aw#15370
- 2: Prepend built-in prompts to user prompt in unified creation step with system tags and validation github/gh-aw#10469
- 3: Add logging to template/substitution pipeline and fix setupGlobals initialization github/gh-aw#16180
- 4: https://github.com/github/gh-aw/blob/main/.github/workflows/test-workflow.lock.yml
- 5: https://github.com/github/gh-aw/blob/main/.github/workflows/dev.lock.yml
- 6: https://github.com/cschleiden/replace-tokens
- 7: https://josh-ops.com/posts/github-actions-tokenization/
- 8: https://github.com/github/gh-aw/tree/main/actions
🌐 Web query:
site:github.com github gh-aw-actions substitute_placeholders.cjs
💡 Result:
substitute_placeholders.cjs is a utility script used within the GitHub Agentic Workflows (gh-aw) project to perform safe, in-place string substitution within files [1][2]. Key details regarding this script include: Purpose and Security: It was implemented to replace the use of the shell utility envsubst in GitHub Actions workflows [2]. By performing substitution via a JavaScript function (typically executed within an actions/github-script step), the project avoids common vulnerabilities associated with shell expansion and template injection when processing untrusted data [2]. Functionality: The script takes a file path and an object of substitutions as input [1]. It reads the target file, replaces occurrences of placeholders (formatted as KEY) with the corresponding values from the substitutions object, and writes the updated content back to the file [1]. It includes logic to handle null or undefined values safely, preventing them from being rendered as strings like "null" or "undefined" [1][3]. Integration in gh-aw: - Location: The script is part of the internal logic for compiled Agentic Workflows [1][4]. While it may appear in source paths like pkg/workflow/js/ or actions/setup/js/, it is ultimately utilized by GitHub Actions generated by the gh-aw compiler [2][5]. - Initialization: It relies on proper initialization of GitHub Actions globals (such as core) to function correctly, often requiring a setupGlobals call before it is invoked [5]. - Maintenance: It is actively maintained as part of the gh-aw infrastructure, undergoing periodic refactoring (such as the addition of JSDoc annotations, TypeScript checks, and improved diagnostic logging) to enhance maintainability and debugging [3][5]. Users of the gh-aw CLI should not modify these generated files manually; instead, the lifecycle of these scripts is managed automatically by the gh-aw compiler [6][7]. Reference to this script within a GitHub Actions workflow is typically handled by the underlying gh-aw-actions repository [8][6].
Citations:
- 1: https://github.com/githubnext/gh-aw/blob/e97f4432/actions/setup/js/substitute_placeholders.cjs
- 2: Replace envsubst with JavaScript-based substitution to prevent template injection github/gh-aw#5773
- 3: [jsweep] Clean substitute_placeholders.cjs github/gh-aw#19315
- 4: https://github.com/github/gh-aw/tree/main/actions
- 5: Add logging to template/substitution pipeline and fix setupGlobals initialization github/gh-aw#16180
- 6: https://github.github.com/gh-aw/reference/faq/
- 7: https://github.github.com/gh-aw/reference/compilation-process/
- 8: https://github.com/github/gh-aw-actions
🌐 Web query:
github gh-aw-actions setup substitute_placeholders.cjs process.env include only substitutions null undefined
💡 Result:
The substitute_placeholders.cjs script, used in the github/gh-aw repository, is a utility designed to safely perform template substitution within GitHub Actions, replacing unsafe shell-based envsubst to prevent template injection [1]. Regarding the handling of null and undefined values during substitution, the script explicitly ensures these values do not result in literal "null" or "undefined" strings in the output [2][3]. Key technical details include: - Behavior: When processing the substitutions object, the script iterates through each entry and converts null or undefined values into an empty string ("") before performing the replacement [2][3]. - Implementation: This is achieved via a null check (idiomatically implemented in recent versions as value == null ? "" : value) [3]. - Context: It is commonly used within actions/github-script steps in workflow files, where specific environment variables (retrieved via process.env) are passed into the substitutions object to populate placeholders (e.g., GH_AW_VARIABLE) defined in markdown templates [4][5]. By design, this pattern ensures that even if an environment variable is unset (undefined) or explicitly set to null, the resulting template maintains clean output rather than corrupted text [2].
Citations:
- 1: Replace envsubst with JavaScript-based substitution to prevent template injection github/gh-aw#5773
- 2: https://github.com/githubnext/gh-aw/blob/e97f4432/actions/setup/js/substitute_placeholders.cjs
- 3: [jsweep] Clean substitute_placeholders.cjs github/gh-aw#19315
- 4: Refactor cache memory prompt to markdown template with placeholder interpolation github/gh-aw#11705
- 5: https://github.com/github/gh-aw/blob/main/.github/workflows/ci-doctor.lock.yml
🌐 Web query:
github gh-aw-actions setup substitute_placeholders.cjs raw
💡 Result:
The file substitute_placeholders.cjs is a JavaScript utility script used within the github/gh-aw repository to safely perform string interpolation in workflow files [1][2]. It was introduced to replace unsafe shell-based substitutions (like envsubst) and prevent template injection vulnerabilities [2]. Key details about the script: - Purpose: It reads a file, searches for placeholders defined in the format KEY, replaces them with provided values, and writes the updated content back to the file [1]. - Implementation: The script exports a function that accepts an object containing the file path and a dictionary of substitutions [1]. Recent improvements include adding JSDoc type annotations, TS checks, and better integration with GitHub Actions globals via a shim [3][4]. - Usage in Workflows: It is typically invoked within a GitHub Actions workflow using actions/github-script [4][5]. Workflows often prepare a template file (e.g., a markdown prompt) containing PLACEHOLDER tokens and then use this script to inject environment variables or other dynamic data safely [6][5]. - Lifecycle: The file is managed in the actions/setup/js/ directory and is copied by setup.sh to the runner's temporary directory ($RUNNER_TEMP/gh-aw/actions/) at runtime, making it accessible for subsequent steps in a workflow [7].
Citations:
- 1: https://github.com/githubnext/gh-aw/blob/e97f4432/actions/setup/js/substitute_placeholders.cjs
- 2: Replace envsubst with JavaScript-based substitution to prevent template injection github/gh-aw#5773
- 3: [jsweep] Clean substitute_placeholders.cjs github/gh-aw#19315
- 4: Add logging to template/substitution pipeline and fix setupGlobals initialization github/gh-aw#16180
- 5: Refactor cache memory prompt to markdown template with placeholder interpolation github/gh-aw#11705
- 6: Fix: Use placeholder syntax for GITHUB_WORKSPACE in temp_folder_prompt github/gh-aw#15370
- 7: https://github.com/github/gh-aw/blob/main/actions/setup/setup.sh
Align the GitHub MCP tool supply with the agent prompt.
The workflow declares github with pull_requests, repos, while the generated prompt only lists safeoutputs MCP CLIs. Either expose the GitHub MCP tools in the listed MCP CLIs or remove the GitHub toolset from the source/workflow if the review should not call them.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/sfl-pr-review.lock.yml at line 356, Align the MCP tool
configuration with the generated agent prompt: update the
GH_AW_MCP_CLI_SERVERS_LIST value to include the declared github MCP tools
(pull_requests and repos), or remove the github toolset from the workflow/source
if those tools should not be available. Keep the workflow’s declared tools and
prompt-listed tools consistent.
Source: HemSoft/set-it-free-loop@78483bb Version: 2.0.0 Tier: review Components: labels, governance, sfl-pr-review Engine policy: codex-gpt-55-high See https://github.com/HemSoft/set-it-free-loop for full documentation.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/sfl-pr-review.md:
- Line 185: Narrow the prohibition in the workflow instructions by replacing
“pull request metadata” with the specific fields the agent must not edit: title,
body, assignees, milestone, and agent-owned or approved labels. Explicitly allow
review comments, the consolidated review, and the “SFL Reviewer Approval” check
as required outputs, while retaining the existing restrictions on code,
branches, and other unauthorized changes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 9669f3da-fa73-4c66-9480-1349add8a8f8
📒 Files selected for processing (4)
.github/aw/actions-lock.json.github/workflows/sfl-pr-review.lock.yml.github/workflows/sfl-pr-review.mdsfl.json
| - `summary`: the verdict, head SHA, run ID, and severity counts | ||
| - `conclusion`: the approval-policy result above | ||
|
|
||
| Do not modify code, branches, pull request labels, or pull request metadata. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -u
rg -n -C3 \
'create-pull-request-review-comment|submit_pull_request_review|create_check_run|remove_trigger_label|Do not modify' \
.github/workflows/sfl-pr-review.md .github/workflows/sfl-pr-review.lock.yml || trueRepository: HemSoft/codexbar-ios
Length of output: 8559
🏁 Script executed:
#!/bin/bash
set -u
echo "== workflow outline =="
wc -l .github/workflows/sfl-pr-review.md .github/workflows/sfl-pr-review.lock.yml
echo
echo "== relevant sfl-pr-review.md sections =="
sed -n '1,230p' .github/workflows/sfl-pr-review.md
echo
echo "== safe output prompt sections in lock.yml =="
sed -n '300,317p' .github/workflows/sfl-pr-review.lock.yml
sed -n '576,630p' .github/workflows/sfl-pr-review.lock.ymlRepository: HemSoft/codexbar-ios
Length of output: 10116
🌐 Web query:
GitHub Apps pull-requests read permission submit_review labels remove_label can not assign review labels
💡 Result:
To perform operations like submitting reviews or managing labels on pull requests via a GitHub App, you must configure the appropriate repository permissions. If your GitHub App cannot perform these actions, it is likely due to insufficient or misconfigured permissions [1]. For managing labels on a pull request, you must have 'Issues' permission set to 'Read & write' [2][3]. Even though pull requests are distinct, label management is handled under the 'Issues' permission scope in the GitHub API [2][4]. With 'Read & write' access to Issues, your app can add, remove, and list labels on both issues and pull requests [3][5]. For submitting reviews (e.g., approving or commenting on a pull request), you must have 'Pull requests' permission set to 'Read & write' [3]. This permission allows the app to perform operations such as creating reviews, dismissing reviews, and managing requested reviewers [3]. If your app currently only has 'Read-only' access to these scopes, it will be unable to modify labels or submit reviews [1]. To troubleshoot, verify the following: 1. Ensure the app has the 'Issues' permission set to 'Read & write' to manage labels [3]. 2. Ensure the app has the 'Pull requests' permission set to 'Read & write' to submit reviews [3]. 3. Check the X-Accepted-GitHub-Permissions header in the response from the GitHub API, which will explicitly list the permissions required for the specific endpoint you are attempting to call [6][7].
Citations:
- 1: https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app
- 2: https://help.github.com/en/enterprise-server@3.0/rest/reference/permissions-required-for-github-apps
- 3: https://docs.github.com/en/enterprise-server@3.7/rest/overview/permissions-required-for-github-apps
- 4: https://docs.github.com/enterprise-server@3.0/rest/reference/permissions-required-for-github-apps
- 5: https://docs.github.com/en/enterprise-server@3.4/rest/overview/permissions-required-for-github-apps
- 6: https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps
- 7: https://docs.github.com/en/enterprise-cloud@latest/rest/authentication/permissions-required-for-github-apps
🌐 Web query:
GitHub REST API submit a pull request review permissions required pull_requests write Issues permission labels
💡 Result:
To submit a pull request review via the GitHub REST API, you generally need the "pull-requests: write" permission [1][2]. Key technical details: 1. Permission Syntax: When configuring permissions for GitHub Actions workflows or defining scopes for fine-grained personal access tokens (PATs) and GitHub Apps, the correct permission name is "pull-requests" (using a hyphen, not an underscore) [3][2]. Using "pull_requests" (with an underscore) in YAML configuration files will cause a syntax error [3]. 2. Endpoint Requirements: The specific endpoint used for creating or submitting reviews is located under the Pull Request Reviews REST API [4][5]. Fine-grained tokens must be granted "pull-requests: write" access to interact with these resources [1][2]. 3. Troubleshooting: If you receive a "Resource not accessible" error, you can check the "X-Accepted-GitHub-Permissions" header in the API response [6][7]. This header explicitly lists the permissions required to access the specific endpoint you are calling [7]. 4. Contextual Access: Note that the "Issues" permission is distinct and is not typically used for submitting pull request reviews, though some API operations related to issue labels or comments may require "issues: write" [3]. Always verify the specific documentation page for the endpoint you are targeting, as requirements can vary based on the action performed [6][8].
Citations:
- 1: [SPIKE] Expand FGP per-tool permission annotations + consolidate docs github/github-mcp-server#2679
- 2: https://github.com/peter-evans/create-pull-request
- 3: "Add labels to an issue" doc refers to
pull_requests:writepermission, but should bepull-requests:writegithub/docs#32167 - 4: https://docs.github.com/rest/pulls/reviews
- 5: https://docs.github.com/en/enterprise-cloud@latest/rest/pulls/reviews
- 6: https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2026-03-10
- 7: https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api
- 8: https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps
🌐 Web query:
GitHub Issues permission pull request labels remove_label GitHub App pull-requests read
💡 Result:
To remove a label from a pull request using a GitHub App, the app requires write-level permission for issues [1][2][3]. Although pull requests are a distinct feature on GitHub, they are treated as issues for many management actions, including managing labels, assignees, and milestones [1][4][3]. Consequently, the REST API endpoints for label operations are located within the Issues section of the documentation [1][3]. Key Technical Details: - Required Permission: Your GitHub App must be granted 'Issues: write' access [1][2]. A 'pull-requests: read' permission is insufficient for modifying labels [5][6]. - API Endpoint: The operation to remove a single label uses the 'DELETE /repos/{owner}/{repo}/issues/{issue_number}/labels/{name}' endpoint [1][3]. - Permission Troubleshooting: If your app encounters a 'Resource not accessible' error, check the 'X-Accepted-GitHub-Permissions' header in the API response, which explicitly states the permissions required for that specific endpoint [5][6]. - Common Pitfall: Ensure your permission configuration uses the correct syntax 'issues: write' (with a hyphen where applicable in workflow files, though the permission name is 'issues') [7]. While 'pull-requests' permissions are available, they do not cover label management for pull requests [1][2].
Citations:
- 1: https://docs.github.com/en/rest/issues/labels
- 2: https://docs.github.com/en/enterprise-server@3.18/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens
- 3: https://docs.github.com/en/enterprise-server@3.19/rest/issues/labels
- 4: https://docs.github.com/en/enterprise-server@3.18/rest/issues/labels
- 5: https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps
- 6: https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app
- 7: "Add labels to an issue" doc refers to
pull_requests:writepermission, but should bepull-requests:writegithub/docs#32167
Narrow the prohibition on pull-request metadata.
The workflow runs with only pull-requests: read, so label removal, review submission, and check runs are still limited by permissions regardless of this wording. Replace the broad “pull request metadata” prohibition with the specific metadata fields that should not be edited, such as title, body, assignees, milestone, and labels owned/approved by the agent. Explicitly list review comments, the consolidated review, and the SFL Reviewer Approval check as required safe outputs so the agent is not blocked from producing them.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/sfl-pr-review.md at line 185, Narrow the prohibition in
the workflow instructions by replacing “pull request metadata” with the specific
fields the agent must not edit: title, body, assignees, milestone, and
agent-owned or approved labels. Explicitly allow review comments, the
consolidated review, and the “SFL Reviewer Approval” check as required outputs,
while retaining the existing restrictions on code, branches, and other
unauthorized changes.
|
Closing this v2.0.0 SFL rollout as superseded. HemSoft now uses v2.1.0-rc.9, and hs-buddy is the only approved HemSoft SFL validation repository. This old deployment should not be merged or refreshed. |
1 participant
Set it Free Loop — Deployment
Version: 2.0.0
Tier: review
Source SHA:
380fe0edc7a87cfc7b31233a955b37df0223a3a8Engine policy:
codex-gpt-55-highComponents deployed
labelsgovernancesfl-pr-reviewWhat is the Set it Free Loop?
The Set it Free Loop is a continuous
quality improvement operating model for software repositories. See the
CATALOG
for all available workflows.
Before merging
.\deployment\governance\setup-labels.ps1 -Owner <org> -Repo <repo>if labels are not yet configured.mdworkflow: verifygh aw compile .github/workflows/<name>.mdsucceedssfl.jsonmanifest in the repo rootSummary by cubic
Deploys the Set it Free Loop review tier (v2.0.0), adding a label-triggered PR review that runs security, correctness, and quality passes, posts inline findings, submits a consolidated review, and publishes an approval check. Also adds the SFL badge and metadata, pins workflow actions, and treats lock files as generated.
New Features
sfl-pr-reviewworkflow (trigger:sfl-review; inline findings; one consolidated review;SFL Reviewer Approvalcheck; auto-removessfl-reviewafter run).github/gh-aw-actions/setup@v0.84.1via.github/aw/actions-lock.json, adds compiled lock workflow.yml, and marks lock workflows as generated andmerge=oursvia.gitattributes.README.mdandsfl.jsonmanifest with version, tier, components, and engine policy.Migration
.\deployment\governance\setup-labels.ps1 -Owner <org> -Repo <repo>if labels are not configured.gh aw compile .github/workflows/sfl-pr-review.md.sfl-reviewlabel to a test PR to validate output.sfl.jsonin the repo root.Written for commit 4995062. Summary will update on new commits.
Note
Deploy Set it Free Loop PR review workflow (review tier, v2.0.0)
sfl-reviewlabel command, usingmoonshotai/kimi-k3via OpenRouter.sfl.jsonand linking to the Set it Free Loop repository.Macroscope summarized 4995062.