Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitattributes
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
.github/workflows/*.lock.yml linguist-generated=true merge=ours

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

git config --show-origin --get-regexp '^merge\.ours\.' || true
git check-attr merge -- .github/workflows/sfl-pr-review.lock.yml

Repository: HemSoft/codexbar-mac

Length of output: 212


🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

echo "== gitattributes =="
cat -n .gitattributes || true

echo
echo "== config merge.ours references =="
git config --show-origin --get-regexp '^merge\.ours\.' || true

echo
echo "== repo merge config entries =="
git config --show-origin --name-only | rg '(^|/)merge(\.|$)' || true

echo
echo "== workflow lock files =="
git ls-files .github/workflows '*lock*.y[l]m' '.*lock*.{yml,yaml}' || true

Repository: HemSoft/codexbar-mac

Length of output: 472


🌐 Web query:

gitattributes merge driver built-in merge theirs rename binary conflict documentation merge=ours merge builtin ours

💡 Result:

In Git, the merge attribute in.gitattributes allows you to specify how file-level merge conflicts are handled [1][2]. This is distinct from global merge strategies (like -s ours) and functions as a low-level merge driver invoked only when a file has conflicting changes on both sides of a merge [3][4]. Built-in Merge Drivers: Git provides several built-in merge drivers that can be referenced in.gitattributes: text: The standard 3-way merge driver used for ordinary text files, which marks conflicts with <<<<<<<, =======, and >>>>>>> [1]. binary: Takes the version from the current branch (ours) and marks the file as having conflicts. This is intended for files without defined merge semantics [1]. union: Attempts to keep lines from both versions. Custom Merge Drivers: To define custom behavior, you must first register a driver in your Git configuration (.git/config or.gitconfig) and then assign it to files in.gitattributes [2][5]. Example: "Ours" Strategy for Specific Files To automatically resolve conflicts by always preferring your local version (an "ours" approach for specific files), you can define a custom driver named ours: 1. Configure the driver: git config --global merge.ours.driver true 2. Assign it in.gitattributes: filename.ext merge=ours Setting the driver to true tells Git that the merge is always successful and to retain the current version [5]. Note that this custom driver is only invoked if both branches have modified the file [3][4]. If only one side changed the file, Git will automatically take that side's version regardless of the merge driver setting [3]. Important Distinctions: Merge Driver vs. Merge Strategy: The merge= attribute in.gitattributes defines a per-file driver [2]. This is separate from the -s ours or -X ours options used during a git merge command, which affect the entire merge operation [6][7][8]. Binary Files: Marking a file as binary in.gitattributes (via the binary macro, which sets -text -diff) prevents line-ending conversion and textual diffs, but it does not automatically define a custom merge driver unless specified [1][5]. Configuration Limitations: Merge driver definitions (the [merge "drivername"] sections in.git/config) are not tracked in the repository and must be configured on every machine that clones the repository [3][9]. To ensure consistency, teams often document these requirements or use automation [9][5].

Citations:


Do not rely on an undeclared merge=ours driver.

.gitattributes only names a low-level merge driver; it does not configure merge.ours.driver. Use a built-in driver such as binary/merge=binary for the generated lock file, or add and test the merge.ours driver in each merge environment.

🤖 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, Update the .github/workflows/*.lock.yml attribute
rule to use a declared built-in merge behavior such as binary instead of the
undeclared merge=ours driver, unless the repository explicitly configures and
tests merge.ours in every merge environment.

9 changes: 9 additions & 0 deletions .github/aw/actions-lock.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
{
"entries": {
"github/gh-aw-actions/setup@v0.84.1": {
"repo": "github/gh-aw-actions/setup",
"version": "v0.84.1",
"sha": "029204130cb73f6ba684e56428c7f3e9319b708c"
}
}
}
1,483 changes: 1,483 additions & 0 deletions .github/workflows/sfl-pr-review.lock.yml

Large diffs are not rendered by default.

185 changes: 185 additions & 0 deletions .github/workflows/sfl-pr-review.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,185 @@
---
description: |
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.

on:
label_command:
name: sfl-review
events: [pull_request]
remove_label: true

permissions:
contents: read
pull-requests: read

models:
default-ai-credits-pricing:
input: 3
output: 15

engine:
id: copilot
env:
COPILOT_PROVIDER_BASE_URL: https://openrouter.ai/api/v1
COPILOT_PROVIDER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
COPILOT_PROVIDER_TYPE: openai
COPILOT_PROVIDER_WIRE_API: responses
COPILOT_MODEL: moonshotai/kimi-k3

model: moonshotai/kimi-k3

network:
allowed:
- openrouter.ai

tools:
github:
toolsets: [pull_requests, repos]
github-app:
client-id: ${{ vars.SFL_APP_CLIENT_ID }}
private-key: ${{ secrets.SFL_APP_PRIVATE_KEY }}

safe-outputs:
threat-detection: false
github-app:
client-id: ${{ vars.SFL_APP_CLIENT_ID }}
private-key: ${{ secrets.SFL_APP_PRIVATE_KEY }}
Comment on lines +41 to +49

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Files:"
git ls-files | rg '(^|/)\.github/workflows/sfl-pr-review\.md|sfl-pr-review|github-app|auth|gh-aw|safe-outputs' || true

echo
echo "Target file excerpt:"
if [ -f .github/workflows/sfl-pr-review.md ]; then
  nl -ba .github/workflows/sfl-pr-review.md | sed -n '1,110p'
fi

echo
echo "Search gh-aw usage and ignore-if-missing:"
rg -n "gh-aw|github-app:|safe-outputs:|ignore-if-missing|activation|fork" .github README.md 2>/dev/null || true

Repository: HemSoft/codexbar-mac

Length of output: 304


🌐 Web query:

GitHub Actions gh-aw reference auth ignore-if-missing

💡 Result:

In the context of GitHub Agentic Workflows (gh-aw), "ignore-if-missing: true" is a configuration setting used in GitHub App authentication to allow a workflow to gracefully handle missing credentials [1][2]. By default, GitHub Agentic Workflows jobs will fail if the required GitHub App credentials (specifically client-id or private-key) are missing or resolve to empty strings [1][3]. This is common, for example, when App secrets are unavailable during fork pull request builds [1][2]. When you set "ignore-if-missing: true", the workflow skips the attempt to mint a token using the GitHub App [1][3]. Instead, it falls back to the standard non-App token chain: secrets.GH_AW_GITHUB_TOKEN or, if that is not set, secrets.GITHUB_TOKEN [1][2]. This setting can be used under the github-app configuration block (e.g., in safe-outputs or tools configuration) and applies consistently across token minting paths, including safe outputs, activation, pre-activation, and repository checkout [1][3][4]. The default behavior—failing if keys are missing—remains in effect if the field is omitted or explicitly set to false [1][2].

Citations:


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Target file excerpt:"
awk '{printf "%5d  %s\n", NR, $0}' .github/workflows/sfl-pr-review.md | sed -n '1,130p'

echo
echo "Search gh-aw usage and ignore-if-missing:"
rg -n "gh-aw|github-app:|safe-outputs:|ignore-if-missing|activation|fork-head|GH_AW_GITHUB_TOKEN|GITHUB_TOKEN" .github README.md 2>/dev/null || true

echo
echo "Lockfile excerpt:"
awk '{printf "%5d  %s\n", NR, $0} ' .github/workflows/sfl-pr-review.lock.yml | sed -n '1,160p'

Repository: HemSoft/codexbar-mac

Length of output: 50376


Defend fork PRs before App token minting.

The generated workflow only skips fork-head PRs in the activation guard, but both .github/workflows/sfl-pr-review.md App blocks lack ignore-if-missing: true. gh-aw fails when App credentials are missing or empty before that guard can drop fork PRs. Add ignore-if-missing: true to both blocks, or keep only a read-only fallback token behind the fork guard. If fork PRs are unsupported, state that in the acceptance criteria and define label cleanup.

🤖 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 28 - 35, Add
ignore-if-missing: true to both github-app configuration blocks under github-app
and safe-outputs in the generated workflow template, preserving the existing
client-id and private-key mappings so missing App credentials are tolerated
before the activation guard handles fork PRs.

create-pull-request-review-comment:
side: RIGHT
max: 20
Comment on lines +50 to +52

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "Tracked workflow files:"
git ls-files '.github/workflows/*' | sed -n '1,120p'

echo
echo "Search for sfl-pr-review and gh-aw commands:"
rg -n "sfl-pr-review|gh-aw|create-pull-request-review-comment|max:|side:|findings|findings|report" .github/workflows/sfl-pr-review.md .github/workflows 2>/dev/null | sed -n '1,220p'

echo
if [ -f .github/workflows/sfl-pr-review.md ]; then
  wc -l .github/workflows/sfl-pr-review.md
  sed -n '1,160p' .github/workflows/sfl-pr-review.md | nl -ba
fi

Repository: HemSoft/codexbar-mac

Length of output: 42525


🌐 Web query:

github gh-aw reference safe outputs pull requests create-pull-request-review-comment max

💡 Result:

In GitHub Agentic Workflows (gh-aw), the create-pull-request-review-comment safe output allows for the creation of review comments on code lines [1][2][3]. The max parameter defines the maximum number of review comments that can be created per workflow run [1][4][5]. As of the current configuration, the default value for max is 10 [2][3][6]. While some documentation or schema files previously suggested a default of 1 [6], this has been clarified to match the runtime behavior of 10 [6]. You can configure this limit within your workflow's safe-outputs configuration block as follows [1][4][5]: safe-outputs: create-pull-request-review-comment: max: 3 # Example setting to override the default of 10 When using this output, you may also configure additional parameters such as: - side: Specifies the side of the diff ("LEFT" or "RIGHT", default: "RIGHT") [1][5]. - target: Defines the target PR for the comments ("triggering" by default, or "*" for all applicable PRs, or a specific PR number) [1][4]. - target-repo: Enables cross-repository commenting by specifying "owner/repo" [1][4].

Citations:


🌐 Web query:

site:github.com github/gh-aw-tools create_pull_request_review_comment max safeoutputs 20

💡 Result:

In GitHub Agentic Workflows (gh-aw), the create_pull_request_review_comment tool is a "safe-output" tool used to post review comments on specific lines of code within a pull request [1][2]. To use this tool, you must define it within the safe-outputs section of your workflow's configuration (usually in the workflow's frontmatter or configuration file) [1][3]. The max parameter controls the maximum number of review comments the agent is permitted to create during a single workflow run [1][4]. Example configuration: yaml safe-outputs: create-pull-request-review-comment: max: 20 # Specifies the limit (e.g., 20) side: "RIGHT" # Default side for the comment target: "triggering" # Default target PR Key usage details: - Default Limit: If not explicitly configured, the default maximum is typically 10 [1][2]. - Target Configuration: The target field determines which PR is commented on [3]. If target: "*" is configured, the agent must provide the pull_request_number in the tool call; otherwise, the comment will fail [1][5]. - Cross-Repository: For cross-repository comments, you can specify the repo (in owner/repo format) if it is listed in the allowed-repos configuration [1][3]. - Context Requirements: The tool requires a valid pull request context (e.g., pull_request or pull_request_target event) to function correctly [6]. If you encounter a "Tool does not exist" error despite proper configuration, ensure your workflow lock file is up to date and that the tool is correctly declared in the shared workflow components [4].

Citations:


🌐 Web query:

site:github.com/awf-ci/awf-tools create_pull_request_review_comment max: 20

💡 Result:

The matching GitHub documentation shows:

safe-outputs:
  create-pr-review-comment:
    max: 20

This configures up to 20 pull-request review comments. (github.github.com)

Citations:


Increase or remove the inline-review-comment cap.

safe-outputs caps create-pull-request-review-comment at 20, and the lock file encodes create_pull_request_review_comment(max:20) for this workflow. If a PR has more than 20 findings, the workflow cannot create one inline thread per finding as the policy requires. Use a higher supported cap, omit inline comment creation, or document and report omitted findings in the consolidated review.

🤖 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 36 - 38, Update the
create-pull-request-review-comment configuration to remove the max: 20 cap or
raise it to a supported value that accommodates all findings; ensure the
corresponding safe-outputs lock configuration is updated consistently, or
explicitly report any findings omitted by the chosen cap in the consolidated
review.

submit-pull-request-review:
allowed-events: [APPROVE, REQUEST_CHANGES]
supersede-older-reviews: true
footer: always
create-check-run:
max: 1
name: "SFL Reviewer Approval"
---
# Deployed from: HemSoft/set-it-free-loop/deployment/workflows/sfl-pr-review.md@78483bbf7edf0a4f8d3bf2f68e58678da36044ae
# To upgrade: re-run deploy-workflow.ps1 at the desired SHA

<!-- sfl:
status: active
version: "1.0.0"
category: review
risk-class: trivial
target-labels: [sfl-review]
outcome-definition: |
The triggering pull request receives a current-head structured review,
one inline thread per finding, and an SFL Reviewer Approval check.
acceptance-criteria:
- The sfl-review label triggers exactly one current-head review run
- The trigger label is consumed during authorized activation
- Security, correctness/reliability, and quality/maintainability are reviewed
- Every finding is an inline thread classified Critical, High, Medium, or Low
- The review body reports the run ID, head SHA, verdict, and severity counts
- Critical or High findings fail the approval check and request changes
- Medium or Low findings do not fail the approval check
- Zero findings produce an approving review and successful approval check
source-repo: HemSoft/set-it-free-loop
-->

# SFL Review - Full-Spectrum Pull Request Review

Review only the pull request that triggered this workflow. The reviewed commit
must be `${{ github.event.pull_request.head.sha }}` and the SFL run ID is
`${{ github.run_id }}`.
Comment on lines +87 to +89

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Refuse to review an obsolete PR head

When a commit is pushed after the sfl-review label starts this potentially long-running workflow, these instructions still force the agent to review the event-time SHA. Because sfl-pr-review.md subscribes only to the labeled event and never instructs the agent to revalidate the live head before publishing its review, check, and label removal, it can report a result for code that is no longer current. Re-fetch the PR head immediately before producing outputs and abort or retrigger when it differs from the reviewed SHA.

Useful? React with 👍 / 👎.


Use the GitHub pull request tools to read the triggering PR, its changed files,
and the complete diff. Before creating comments, list existing review comments
and unresolved threads on the current head so you do not repeat a finding.
Comment on lines +91 to +93

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

MAJOR Finding: Carry unresolved findings into re-review verdicts.

The workflow suppresses duplicate comments after reading existing unresolved threads. The approval policy does not define whether those unresolved findings count. On a re-review, a prior Critical or High finding can have no new inline comment and still produce APPROVE. Include unresolved current-head findings in the severity counts, or block approval until they are resolved.

Also applies to: 130-137

🤖 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 81 - 83, Update the
approval-policy instructions in the workflow so unresolved review findings on
the current head are included in severity counts even when duplicate comments
are suppressed; alternatively, explicitly block approval while any unresolved
Critical or High finding remains. Ensure the verdict logic defined near the
existing review-comment and unresolved-thread instructions cannot return APPROVE
when prior unresolved findings still violate the policy.


## Required review passes

Perform all three evidence-based passes independently before producing output.

1. **Security**
- Injection, unsafe command or path construction, XSS, SSRF, and deserialization
- Authentication, authorization, privilege boundaries, and secret exposure
- Dependency, workflow, and supply-chain risks
2. **Correctness and Reliability**
- Logic errors, regressions, incorrect assumptions, null and boundary cases
- Error handling, races, resource leaks, data loss, and compatibility
- Whether tests cover every meaningful new or changed behavior
3. **Quality and Maintainability**
- Excessive complexity, duplication, coupling, unclear ownership, and dead code
- Type safety, performance regressions, operational risk, and repository conventions
- Whether the implementation is the smallest complete and defensible change

## Finding policy

Classify every finding into exactly one severity:

- **CRITICAL** - exploitable security issue, data loss, production crash,
public API break, race, or deadlock
- **HIGH** - serious correctness, authorization, reliability, or operational defect
- **MEDIUM** - material bug avenue, missing logic-branch tests, performance
regression, or maintainability problem
- **LOW** - actionable improvement with concrete value and low implementation risk

Do not report style preferences, speculative concerns, or findings without
specific evidence from the changed code.

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.

## Approval policy

Count all inline findings by severity.

- If any Critical or High finding exists, submit `REQUEST_CHANGES` and create
the `SFL Reviewer Approval` check with conclusion `failure`.
- If only Medium or Low findings exist, submit `APPROVE` and create the check
with conclusion `success`.
- If no findings exist, submit `APPROVE` and create the check with conclusion
`success`.

Submit exactly one consolidated review with this body:

```markdown
## SFL Full-Spectrum Review

SFL run ID: ${{ github.run_id }}
Head SHA: ${{ github.event.pull_request.head.sha }}
Verdict: APPROVE

| Severity | Count |
| --- | ---: |
| Critical | 0 |
| High | 0 |
| Medium | 0 |
| Low | 0 |

### Review passes

- Security: complete
- Correctness and Reliability: complete
- Quality and Maintainability: complete

### Summary

Concise evidence-based summary of the review result.
```

Replace the verdict and counts with the actual result. Use
`Verdict: CHANGES_REQUESTED` when Critical or High findings exist.

Create exactly one check run named `SFL Reviewer Approval` with:

- `title`: `SFL full-spectrum review complete`
- `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.
4 changes: 4 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,9 @@
# CodexBar 🎚️ for Mac

[![Set it Free Loop](https://img.shields.io/badge/dynamic/json?url=https%3A%2F%2Fraw.githubusercontent.com%2FHemSoft%2Fcodexbar-mac%2Fmain%2Fsfl.json&query=%24.version&prefix=v&label=Set%20it%20Free%20Loop&color=FFD700&style=flat&logo=githubactions&logoColor=white)](https://github.com/HemSoft/set-it-free-loop)
<!-- SFL_BADGE: auto-updated by deploy-workflow.ps1 -->
Comment on lines +3 to +4

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Record the deployment in the changelog

This public badge and the associated review automation are introduced without updating the Unreleased section of CHANGELOG.md. The repository explicitly requires user-visible changes to be recorded in the same branch or PR and developer-experience changes to use their own heading, so add an entry describing this deployment.

AGENTS.md reference: AGENTS.md:L30-L33

Useful? React with 👍 / 👎.

# CodexBar 🎚️ for Mac
Comment on lines +3 to +5

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

LOW Finding: Remove the duplicate # CodexBar heading.

The opening contains the title at Line 1 and repeats it at Line 5. markdownlint-cli2 reports MD024. Keep one title around the badge and deployment marker.

🧰 Tools
🪛 markdownlint-cli2 (0.23.1)

[warning] 5-5: Multiple headings with the same content

(MD024, no-duplicate-heading)

🤖 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 `@README.md` around lines 3 - 5, Remove the duplicate “CodexBar for Mac”
Markdown heading in the README, keeping a single title positioned with the
existing badge and SFL_BADGE deployment marker so the document passes MD024.

Source: Linters/SAST tools


A native macOS menu bar app that keeps your AI provider usage limits visible. The Mac member of the CodexBar family:

- [codexbar](https://github.com/HemSoft/codexbar) — Windows (C# / WPF / .NET 9)
Expand Down
36 changes: 36 additions & 0 deletions sfl.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
{
"version": "2.0.0",
"deployedAt": "2026-08-02T03:32:25Z",
"tier": "review",
"source": "HemSoft/set-it-free-loop",
"sourceSha": "78483bbf7edf0a4f8d3bf2f68e58678da36044ae",
"components": [
"governance",
"labels",
"sfl-pr-review"
],
"enginePolicy": {
"defaultProfile": "codex-gpt-55-high",
"workflows": [
{
"name": "sfl-pr-review",
"profile": "openrouter-kimi-k3-high",
"provider": "copilot",
"model": "moonshotai/kimi-k3",
"effort": null,
"renderedModel": "moonshotai/kimi-k3",
"requiredSecretsAnyOf": [
"OPENROUTER_API_KEY"
],
"arguments": [],
"environment": {
"COPILOT_PROVIDER_BASE_URL": "https://openrouter.ai/api/v1",
"COPILOT_PROVIDER_API_KEY": "${{ secrets.OPENROUTER_API_KEY }}",
"COPILOT_PROVIDER_TYPE": "openai",
"COPILOT_PROVIDER_WIRE_API": "responses",
"COPILOT_MODEL": "moonshotai/kimi-k3"
}
}
]
}
}