[leonarduk]

What

Adds GitHub Actions (deepseek, gpt, dependency review, workflow lint, CodeQL, PR lint, cicaid updates):

• .github/workflows/_ai-pr-review.yml
• .github/cicaid-pins.env
• .github/scripts/pip_install_cicaid_pro.sh
• .github/workflows/update-cicaid.yml
• .github/scripts/update_cicaid_pins.py
• .github/workflows/deepseek-pr-review.yml
• .github/workflows/gpt-pr-review.yml
• .github/workflows/dependency-review.yml
• .github/workflows/workflow-lint.yml
• .github/workflows/pr-lint.yml
• .github/workflows/codeql.yml
• .github/ISSUE_TEMPLATE/bug_report.md
• .github/ISSUE_TEMPLATE/config.yml
• .github/ISSUE_TEMPLATE/feature_request.md
• .github/ISSUE_TEMPLATE/task_chore.md
• .github/cicaid-scaffold.json

Why

Automated PR review coverage, reusing the shared review logic shipped in the cicaid-devtools-pro package.

Testing

N/A (workflow files; will run on the next PR opened against this repo).

Checklist

• Provision CICAID_PRO_TOKEN (fine-grained PAT, Contents: Read-only, scoped to leonarduk/cicaid-pro) under Settings → Secrets and variables → Actions -- required to install cicaid-devtools-pro at all
• Provision the required API key secret(s) under Settings → Secrets and variables → Actions
• Confirm a review comment is posted on the next PR

Closes #2

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 78b7aaa8-325e-4c80-a98d-250a68a30011

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

DeepSeek AI Code Review

Review of PR: Set up GitHub Actions (deepseek, gpt, dependency review, workflow lint, CodeQL, PR lint, cicaid updates)

1. Acceptance criteria

The diff satisfies the primary AC of generating the GitHub Actions workflows and supporting files. However, there are gaps:

• Missing cicaid-scaffold.json: The issue lists .github/cicaid-scaffold.json as a file affected, but it's not present in the diff. This file is likely needed for future setup-review-actions runs to know what was scaffolded.
• Secrets provisioning: The AC requires DEEPSEEK_API_KEY, OPENAI_API_KEY, and CICAID_PRO_TOKEN secrets. The workflows reference these correctly, but there's no validation or documentation step in the workflows themselves to verify they're set before running. The pip_install_cicaid_pro.sh script does validate CICAID_PRO_TOKEN, but the AI review workflows will fail with confusing errors if DEEPSEEK_API_KEY or OPENAI_API_KEY are missing.
• Success criteria "subsequent PR shows a review comment": The workflows are correctly configured to post comments, but the deepseek-pr-review.yml and gpt-pr-review.yml both have if conditions checking vars.ENABLE_DEEPSEEK_REVIEW != 'false' and vars.ENABLE_GPT_REVIEW != 'false' respectively. If these vars aren't set, the workflows will run (good), but if someone sets them to 'false' expecting to disable, that works. However, there's no documentation about these vars.

2. Bugs and logic errors

Blocking issue in _ai-pr-review.yml - "Fail if provider did not approve" step:

- name: Fail if ${{ inputs.provider_name }} did not approve
  if: always() && contains(fromJson('["failure","skipped"]'), steps.check_approval.outcome)

This condition checks steps.check_approval.outcome, but the check_approval step has continue-on-error: true. When a step has continue-on-error: true and fails, its outcome is failure, but its conclusion is also failure. However, the if condition here uses outcome, which for a step that failed with continue-on-error: true will be failure. This means the final step will run and exit 1, correctly failing the job. But wait — the check_approval step sets approved=skipped for exit code 2 (provider outage), and the step succeeds (exit 0) in that case. So steps.check_approval.outcome would be success, not skipped. The condition contains(fromJson('["failure","skipped"]'), steps.check_approval.outcome) would never match skipped because the step doesn't fail when the verdict is "skipped". This means provider outages (exit code 2) won't trigger the final failure step, which is actually correct behavior (soft-fail). But the condition is misleading — it should check steps.check_approval.outputs.approved == 'false' instead.

More critically: The check_approval step has continue-on-error: true, and when it exits 1 (REQUEST CHANGES), the step's outcome is failure. The final step checks contains(fromJson('["failure","skipped"]'), steps.check_approval.outcome) — this will be true when the step failed. But the step also sets approved=false in GITHUB_OUTPUT before exiting 1. The final step should check steps.check_approval.outputs.approved == 'false' rather than relying on outcome, because outcome for a continue-on-error step that failed is failure, but the step's conclusion would also be failure. Actually, looking more carefully: when a step with continue-on-error: true fails, the job continues, and steps.<id>.outcome is failure while steps.<id>.conclusion is success. So the condition contains(fromJson('["failure","skipped"]'), steps.check_approval.outcome) will be true when the step failed (exit 1), which is correct. But it will never be true for the "skipped" case since that's a successful exit. This is a logic bug but not blocking since the "skipped" case (provider outage) should not fail the job anyway.

Blocking issue in update-cicaid.yml - branch deletion race:

if git ls-remote --exit-code --heads origin "$BRANCH" >/dev/null 2>&1; then
  echo "Deleting stale branch $BRANCH from a previous failed run."
  git push origin --delete "$BRANCH"
fi

This deletes the remote branch before pushing. But between the ls-remote check and the git push --delete, another run could have pushed to that branch (e.g., a concurrent workflow_dispatch). The concurrency group prevents concurrent runs of the same workflow, but the workflow_dispatch and schedule events share the same concurrency group, so this should be safe. However, if a human manually created a branch with the same name, this would delete it. This is a minor risk, not blocking.

Bug in _ai-pr-review.yml - "Get linked issue body" step:

ISSUE_NUM=$(gh pr view ${{ github.event.pull_request.number }} --json body,title \
  | jq -r '[.title, .body] | join(" ")' \
  | python3 -m cicaid_devtools.lib.linked_issue || true)

The || true swallows all errors from the pipeline, including failures from gh pr view or jq. If gh pr view fails (e.g., token issue), ISSUE_NUM will be empty, and the step will proceed with "No linked issue found" — masking a real authentication problem. This should distinguish between "no linked issue" (valid outcome) and "couldn't fetch PR" (error).

3. CLI and API safety

No new Python dependencies: The diff adds only shell scripts, Python scripts (stdlib-only), and workflow YAML files. No pyproject.toml changes needed.

GitHub API token usage:

• _ai-pr-review.yml correctly uses secrets.GITHUB_TOKEN for gh CLI calls with pull-requests: write and issues: write permissions.
• update-cicaid.yml uses secrets.CICAID_PRO_TOKEN for the private repo releases API lookup, which is correct given the token scope (Contents: Read-only on cicaid-pro).
• The pip_install_cicaid_pro.sh script embeds the token in a git URL via GIT_CONFIG_* environment variables. The token is visible in the process list during the pip install, but this is a common pattern and the token is scoped read-only to a single repo.

Shell injection risks:

• In update-cicaid.yml, the CHECK_RE validation ensures versions match [A-Za-z0-9._+-]+ before interpolating into shell commands. Good.
• The BRANCH_VERSION substitution replaces + with - for branch names, preventing URL encoding issues. Good.
• In _ai-pr-review.yml, ${{ inputs.provider_id }} and ${{ inputs.provider_name }} are interpolated into shell commands. These come from the calling workflow's with: block, which is controlled by the repo owner, so injection risk is low but not zero if a malicious actor could modify the workflow file.

Missing secret validation: The _ai-pr-review.yml workflow doesn't validate that openai_api_key or deepseek_api_key are set before calling the provider API. The failure mode would be an unclear API error. The pip_install_cicaid_pro.sh script does validate CICAID_PRO_TOKEN, which is good.

4. Test coverage

The diff includes no tests. The update_cicaid_pins.py script has no unit tests, and the shell scripts have no test coverage. Given this is infrastructure setup (workflows), the acceptance criteria are validated by the workflows running successfully on subsequent PRs. However, the update_cicaid_pins.py script has complex logic (version parsing, pin file manipulation) that would benefit from unit tests, especially the _parse_version and _versions_equal functions which handle edge cases like 1.0 vs 1.0.0.

5. Suggested follow-up issues

• Add unit tests for update_cicaid_pins.py version parsing and pin file manipulation logic
• Add validation steps in _ai-pr-review.yml to check for missing API keys with clear error messages
• Document the ENABLE_DEEPSEEK_REVIEW and ENABLE_GPT_REVIEW repository variables
• Add cicaid-scaffold.json to the PR or explain why it's omitted
• Fix the misleading condition in the "Fail if provider did not approve" step to check steps.check_approval.outputs.approved == 'false' instead of outcome
• Add error handling in "Get linked issue body" step to distinguish between "no linked issue" and API failures

---

APPROVE — The workflows are well-structured with good security practices (token scoping, validation, retry logic). The issues identified are non-blocking improvements or edge cases that don't prevent the core functionality from working. The missing cicaid-scaffold.json is noted but doesn't block the PR's primary purpose of setting up the review workflows.

---

Reviewed by DeepSeek via deepseek-pr-review.yml. Advisory only.

[github-actions]

GPT AI Code Review

Skipped: API key not configured

The OPENAI_API_KEY repository secret is not set.

To enable GPT reviews, add OPENAI_API_KEY as a repository secret:

1. Go to Settings > Secrets and variables > Actions in this repo.
2. Click New repository secret.
3. Name: OPENAI_API_KEY
4. Value: your GPT API key.

Once the secret is configured, re-run this workflow or push a new commit to trigger a fresh review.

REVIEW SKIPPED - API KEY NOT CONFIGURED

---

Reviewed by GPT via gpt-pr-review.yml. Advisory only.

[github-actions]

GPT AI Code Review

Skipped: API key not configured

The OPENAI_API_KEY repository secret is not set.

To enable GPT reviews, add OPENAI_API_KEY as a repository secret:

1. Go to Settings > Secrets and variables > Actions in this repo.
2. Click New repository secret.
3. Name: OPENAI_API_KEY
4. Value: your GPT API key.

Once the secret is configured, re-run this workflow or push a new commit to trigger a fresh review.

REVIEW SKIPPED - API KEY NOT CONFIGURED

---

Reviewed by GPT via gpt-pr-review.yml. Advisory only.

[github-actions]

DeepSeek AI Code Review

1. Acceptance criteria

The PR adds all the listed workflow files and issue templates. However, there's a critical gap: the acceptance criteria require the PR to be merged and secrets provisioned, but the PR itself doesn't include any documentation or setup instructions for the required secrets (DEEPSEEK_API_KEY, OPENAI_API_KEY, CICAID_PRO_TOKEN). The workflows will fail on every PR until these are manually provisioned, which isn't documented anywhere in the repo.

2. Bugs and logic errors

Blocking: _ai-pr-review.yml line 336 - Unconditional failure on skipped reviews
The final step "Fail if provider did not approve" has condition always() && contains(fromJson('["failure","skipped"]'), steps.check_approval.outcome). When the verdict script returns exit code 2 (provider outage, soft-fail), the step sets approved=skipped and doesn't exit 1. However, the final step checks steps.check_approval.outcome which would be "success" (since the step didn't fail), not "skipped". This means the condition never matches for the soft-fail case, which is actually correct behavior. But if the check_approval step itself fails (exit 1 from REQUEST CHANGES), the outcome is "failure" and this step correctly fails the job. This logic appears sound.

Blocking: update-cicaid.yml - Missing git diff --exit-code check
After updating the pin in the "Update pin on a dependency branch" step, there's no verification that the file actually changed. If update_cicaid_pins.py fails silently or the version comparison has an edge case, the workflow would proceed to create a PR with no changes.

Non-blocking: pip_install_cicaid_pro.sh - Token exposure in process list
The script embeds the token in GIT_CONFIG_KEY_0 environment variable. While this is scoped to the process, it's visible in /proc/<pid>/environ to any process with same-user access on the runner. This is a standard GitHub Actions pattern and acceptable.

3. CLI and API safety

Blocking: _ai-pr-review.yml line 132 - Unauthenticated git fetch
The "Get PR diff" step runs git fetch origin "$BASE_REF" without any authentication. For a public repo this works, but if this template is used on a private repo, this will fail. The checkout step uses the default GITHUB_TOKEN which has read access, but the fetch command doesn't use it.

Blocking: update-cicaid.yml - Missing error handling for gh pr create
The final step "Push and open pull request" doesn't check if gh pr create succeeds. If the PR creation fails (e.g., rate limit, validation error), the workflow reports success but no PR is opened, violating the acceptance criteria.

Non-blocking: _ai-pr-review.yml - gh_token secret passed but not used for install
The cicaid_pro_token secret is correctly used for the pip install, but the gh_token secret is only used for gh CLI calls. The workflow uses secrets.GITHUB_TOKEN in the calling workflows, which is fine, but the reusable workflow accepts a gh_token input that's never validated for required scopes.

4. Test coverage

The workflows include validation steps (pin format checks, install verification), but there's no test for the critical path: whether the AI review modules actually exist in the pinned versions of cicaid-devtools-pro. The install step would catch this, but only at runtime on every PR.

5. Suggested follow-up issues

• Add documentation for required secrets provisioning to the repo README or a SETUP.md
• Add a workflow validation step that checks for required secrets before running AI reviews
• Consider adding a workflow_dispatch trigger to the AI review workflows for manual testing
• Add a check in update-cicaid.yml to verify the pin file actually changed before creating a PR

REQUEST CHANGES — The unauthenticated git fetch in _ai-pr-review.yml will fail on private repos, and the missing error handling for gh pr create in update-cicaid.yml means the workflow can silently fail to open the required PR.

---

Reviewed by DeepSeek via deepseek-pr-review.yml. Advisory only.

[github-actions]

GPT AI Code Review

Skipped: API key not configured

The OPENAI_API_KEY repository secret is not set.

To enable GPT reviews, add OPENAI_API_KEY as a repository secret:

1. Go to Settings > Secrets and variables > Actions in this repo.
2. Click New repository secret.
3. Name: OPENAI_API_KEY
4. Value: your GPT API key.

Once the secret is configured, re-run this workflow or push a new commit to trigger a fresh review.

REVIEW SKIPPED - API KEY NOT CONFIGURED

---

Reviewed by GPT via gpt-pr-review.yml. Advisory only.

[github-actions]

DeepSeek AI Code Review

Review of PR: Set up GitHub Actions

1. Acceptance criteria

The PR adds all the workflows and files listed in the issue. However, there are gaps:

• Missing hadolint.yml and shellcheck.yml from the issue's file list: The diff includes these files but they are not listed in the "Files Affected" section of the issue. This is a minor discrepancy but not blocking.
• The issue mentions "using the shared workflows from cicaid-devtools-pro" — the PR generates standalone workflow files rather than referencing shared workflows via uses: leonarduk/cicaid-pro/.github/workflows/...@ref. This is a design choice, not a bug, but worth noting.
• Success criteria require "A subsequent PR shows a review comment from each enabled provider" — this cannot be verified from the diff alone; it depends on secrets being provisioned and the workflows running correctly.

2. Bugs and logic errors

Blocking: None found.

Non-blocking observations:

• _ai-pr-review.yml line ~300: The "Fail if provider did not approve" step uses contains(fromJson('["failure","skipped"]'), steps.check_approval.outcome). The check_approval step has continue-on-error: true, so its outcome will be "failure" when it exits 1 (REQUEST CHANGES). However, when the verdict script exits with code 2 (provider outage), the step sets approved=skipped and exits 0, so outcome will be "success" but outputs.approved will be "skipped". The condition contains(fromJson('["failure","skipped"]'), steps.check_approval.outcome) checks outcome, not outputs.approved. This means:

  • When the verdict script exits 2 (provider outage), outcome is "success" (because the step exits 0 after setting approved=skipped), so the fail step will NOT trigger. This is correct behavior (soft-fail on outage).
  • When the verdict script exits 1 (REQUEST CHANGES), outcome is "failure", so the fail step triggers. Correct.
  • However, if the verdict script exits with any other non-zero code (e.g., 3 for missing verdict), the step exits 1, outcome is "failure", and the fail step triggers. This is correct.
  • The condition is checking outcome which will never be "skipped" — the approved=skipped is an output, not an outcome. This is slightly confusing but functionally correct because the step exits 0 when it sets approved=skipped.

• update-cicaid.yml line ~150: The BODY heredoc in the "Create or reuse a linked issue" step uses indentation that will be stripped by the shell, but the content includes backticks around ${{ matrix.dependency }} which will be interpreted by the shell as command substitution. Since matrix.dependency is a controlled value (either cicaid-devtools or cicaid-devtools-pro), this is safe but fragile. If the matrix ever expands, this could break.

• pip_install_cicaid_pro.sh: The script embeds the token in a git config URL. While the comment explains why this approach is used over credential helpers, embedding secrets in environment variables that are visible in process listings (GIT_CONFIG_KEY_0 and GIT_CONFIG_VALUE_0) is a minor security concern. The token is visible in the process environment during the pip install, which could be exposed via /proc on the runner. This is a known trade-off and the comment addresses the reliability rationale, but it's worth noting.

3. CLI and API safety

Blocking: None found.

Observations:

• update_cicaid_pins.py: The script uses urllib.request with a timeout of 30 seconds. It handles OSError and ValueError but not urllib.error.HTTPError specifically. An HTTP 404 (private repo without token) would raise HTTPError, which is a subclass of OSError in Python 3, so it is caught. Good.

• _ai-pr-review.yml: The workflow requests pull-requests: write, contents: read, and issues: write permissions. The gh_token secret is passed as secrets.GITHUB_TOKEN which has these permissions. The cicaid_pro_token is a fine-grained PAT with Contents: Read-only, which is appropriate for the pip install. No over-scoped tokens are used.

• update-cicaid.yml: Uses permissions: contents: write, pull-requests: write, issues: write. The GITHUB_TOKEN is used for creating PRs and issues, which requires these permissions. The CICAID_PRO_TOKEN is only used for the releases API lookup and pip install, which is appropriate.

• Shell injection safety: The update-cicaid.yml workflow interpolates ${{ matrix.dependency }} and version strings into shell commands. The CHECK_RE validation regex ensures versions match [A-Za-z0-9._+-]+ before they are used in commands, which prevents injection. The dependency name is from a fixed matrix, so it's safe.

• _ai-pr-review.yml: The review_module input is interpolated directly into python3 -m ${{ inputs.review_module }}. This is a workflow input that could be malicious if an attacker can trigger the workflow with arbitrary inputs. However, the workflow is called from other workflows in the same repo with hardcoded values, so this is not exploitable in practice.

4. Test coverage

The PR includes no tests for the new Python script (update_cicaid_pins.py). Given that this script is stdlib-only by design and handles parsing, version comparison, and file updates, it would benefit from unit tests. However, the script is scaffolded by cicaid setup-review-actions and is meant to be overwritten, so tests would need to live in the generator repo (cicaid-pro), not here.

The update-cicaid.yml workflow includes an "Install dependencies from the updated pin" step that validates the pin actually resolves and installs, which serves as an integration test for the pin update logic.

5. Suggested follow-up issues

• Add unit tests for update_cicaid_pins.py in the cicaid-pro generator repo
• Consider using gh api instead of raw urllib.request in update_cicaid_pins.py for better error handling and rate-limit awareness
• Document the ENABLE_DEEPSEEK_REVIEW and ENABLE_GPT_REVIEW repo variables in the README or workflow comments
• Consider adding a workflow_dispatch trigger to the AI review workflows for manual re-review after addressing comments

---

APPROVE — No blocking issues found. The workflows are well-structured with appropriate permissions, error handling, and security considerations. The acceptance criteria are met by the generated files.

---

Reviewed by DeepSeek via deepseek-pr-review.yml. Advisory only.

[github-actions]

GPT AI Code Review

Skipped: API key not configured

The OPENAI_API_KEY repository secret is not set.

To enable GPT reviews, add OPENAI_API_KEY as a repository secret:

1. Go to Settings > Secrets and variables > Actions in this repo.
2. Click New repository secret.
3. Name: OPENAI_API_KEY
4. Value: your GPT API key.

Once the secret is configured, re-run this workflow or push a new commit to trigger a fresh review.

REVIEW SKIPPED - API KEY NOT CONFIGURED

---

Reviewed by GPT via gpt-pr-review.yml. Advisory only.

[github-actions]

DeepSeek AI Code Review

1. Acceptance criteria

The diff includes all the files listed in the PR description and the linked issue. The workflows for deepseek, gpt, dependency review, workflow lint, CodeQL, PR lint, and cicaid updates are all present. The issue templates and scaffold config are also included.

However, there's a notable gap: the PR description mentions CodeQL as one of the workflows to set up, but the diff does not include a .github/workflows/codeql.yml file. The file is listed in "Files Affected" but is absent from the actual diff. This is a missing acceptance criterion.

2. Bugs and logic errors

Blocking: Missing CodeQL workflow
The linked issue explicitly requires CodeQL setup, and the PR lists .github/workflows/codeql.yml in "Files Affected", but the diff does not contain this file. This is a direct miss against the acceptance criteria.

Blocking: hadolint.yml and shellcheck.yml are not in the PR description
The diff includes .github/workflows/hadolint.yml and .github/workflows/shellcheck.yml, but these are not listed in the PR description or the linked issue. While they may be beneficial, they represent scope creep. More critically, the hadolint.yml workflow references a Dockerfile with hadolint/hadolint-action@v3.1.0, but the Dockerfile changes in this PR are unrelated to the stated purpose of setting up review actions. This suggests the PR may have been generated from a template that includes more than what was requested.

Blocking: workflow-lint.yml uses continue-on-error: true
The workflow-lint job has continue-on-error: true, which means actionlint failures will not fail the CI. This defeats the purpose of having a workflow linter — it will report issues but never block merges. This is a silent failure mode that undermines the quality gate the PR is supposed to add.

Blocking: pip_install_cicaid_pro.sh embeds token in URL
The script embeds the CICAID_PRO_TOKEN directly in a git URL via insteadOf configuration. While the script's comments explain why this approach was chosen over a credential helper, embedding tokens in URLs can leak them through:

• Process listings (ps aux) during the pip install
• Git error messages that may print the full URL
• Shell history if the script is ever run manually with debugging

The token is also exposed in the environment to any process that runs during the pip install, including any hooks or build scripts in the packages being installed.

Blocking: update_cicaid_pins.py swallows HTTP errors
In _http_json, the except (OSError, ValueError) clause catches all network and JSON errors but doesn't distinguish between a 404 (repo not found, wrong token) and a 500 (server error). A 404 from the private repo's releases API would be reported as "failed to fetch" without indicating the likely cause (missing/invalid token).

3. CLI and API safety

Blocking: workflow-lint.yml downloads and executes a remote script
The workflow downloads download-actionlint.bash from a raw GitHub URL and pipes it directly to bash. This is a supply-chain risk — if the rhysd/actionlint repository is compromised, this workflow would execute arbitrary code with the repository's permissions. The script should be pinned to a specific commit SHA rather than main.

Blocking: hadolint.yml and shellcheck.yml are not in the PR description
These workflows are not mentioned in the PR description or linked issue. They appear to be scope creep from a template. The hadolint.yml references a Dockerfile that is modified in this PR, but the Dockerfile changes (adding SHELL directive, moving WORKDIR) are unrelated to the stated purpose of setting up review actions.

Blocking: update-cicaid.yml uses GITHUB_TOKEN for issue creation
The workflow uses ${{ github.token }} for gh issue create and gh pr create. The default GITHUB_TOKEN has limited permissions and may not have the issues: write scope needed. The workflow declares issues: write in its permissions block, but the actual token used for gh commands is github.token, which may not inherit those permissions depending on the repository's settings.

Non-blocking: _ai-pr-review.yml passes secrets to a reusable workflow
The reusable workflow accepts openai_api_key, deepseek_api_key, gh_token, and cicaid_pro_token as secrets. The gh_token is passed as ${{ secrets.GITHUB_TOKEN }}, which is fine, but the cicaid_pro_token is a fine-grained PAT that must be provisioned. The workflow correctly fails fast if this is missing, but the error message in pip_install_cicaid_pro.sh is helpful.

4. Test coverage

The PR includes no tests for the new Python script update_cicaid_pins.py. While this is a scaffolded utility, it has non-trivial logic (version parsing, regex matching, HTTP calls) that could benefit from unit tests. The script is stdlib-only by design, which makes testing straightforward.

The pip_install_cicaid_pro.sh script has no tests either, but its logic is simple enough that manual validation through the workflow itself may be sufficient.

5. Suggested follow-up issues

• Pin download-actionlint.bash to a specific commit SHA in workflow-lint.yml
• Add unit tests for update_cicaid_pins.py version parsing and pin validation logic
• Consider using a dedicated token with minimal scopes for the update-cicaid workflow instead of the default GITHUB_TOKEN
• Add a check in workflow-lint.yml to fail on actionlint errors rather than using continue-on-error: true
• Document the scope creep of hadolint.yml and shellcheck.yml in the PR description

---

REQUEST CHANGES — Missing CodeQL workflow (listed in AC but absent from diff), workflow-lint uses continue-on-error: true which silently allows broken workflows, and the remote script download in workflow-lint.yml is a supply-chain risk.

---

Reviewed by DeepSeek via deepseek-pr-review.yml. Advisory only.