@htekdev/actions-debugger 1.0.95 → 1.0.97

package/errors/caching-artifacts/caching-artifacts-053.yml

@@ -0,0 +1,90 @@
+id: caching-artifacts-053
+title: "download-artifact@v4 finds no artifacts in workflow_run context without run-id"
+category: caching-artifacts
+severity: error
+tags:
+  - download-artifact
+  - workflow_run
+  - run-id
+  - cross-workflow
+  - artifact
+patterns:
+  - regex: 'No artifacts found'
+    flags: 'i'
+  - regex: 'Unable to find any artifacts for the associated workflow'
+    flags: 'i'
+error_messages:
+  - "No artifacts found for the associated workflow run"
+  - "Unable to find any artifacts for the associated workflow"
+  - "Error: Unable to find any artifacts for the associated workflow run"
+root_cause: |
+  `actions/download-artifact@v4` defaults to downloading artifacts from the
+  CURRENT workflow run (`github.run_id`). In a `workflow_run`-triggered
+  workflow, the current run is the downstream (deploy) workflow — which has
+  produced no artifacts. The upstream (build) workflow's artifacts belong to
+  the triggering run, identified by `github.event.workflow_run.id`.
+
+  Without setting `run-id: ${{ github.event.workflow_run.id }}`, the download
+  step searches the current run's artifacts, finds nothing, and either fails
+  with "No artifacts found" or silently exits (depending on `if-no-files-found`
+  setting). No artifact was ever associated with the downstream run, so the
+  error can be confusing — the artifact clearly exists in the Actions UI under
+  the upstream run.
+
+  This is a distinct issue from the cross-run permissions error (ca-040):
+  that occurs when `run-id` IS set but `actions: read` permission is missing.
+  This issue occurs when `run-id` is simply not set at all.
+fix: |
+  Set `run-id: ${{ github.event.workflow_run.id }}` on the download step to
+  target the triggering workflow's run. Also provide `github-token` (required
+  for cross-run downloads) and ensure `actions: read` permission is set.
+fix_code:
+  - language: yaml
+    label: "Correct: set run-id from triggering workflow in workflow_run context"
+    code: |
+      on:
+        workflow_run:
+          workflows: ["CI"]
+          types: [completed]
+
+      permissions:
+        actions: read
+        contents: read
+
+      jobs:
+        deploy:
+          if: github.event.workflow_run.conclusion == 'success'
+          runs-on: ubuntu-latest
+          steps:
+            - name: Download build artifacts
+              uses: actions/download-artifact@v4
+              with:
+                name: build-output
+                # Required: point to the upstream run, not the current run
+                run-id: ${{ github.event.workflow_run.id }}
+                github-token: ${{ secrets.GITHUB_TOKEN }}
+
+            - name: Deploy
+              run: echo "Deploying from artifact"
+  - language: yaml
+    label: "Incorrect: missing run-id causes 'No artifacts found'"
+    code: |
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Download build artifacts
+              uses: actions/download-artifact@v4
+              with:
+                name: build-output
+                # Missing run-id — searches the CURRENT run, which has no artifacts
+prevention:
+  - "In any `workflow_run`-triggered workflow, always set `run-id: ${{ github.event.workflow_run.id }}`"
+  - "Pair with `github-token: ${{ secrets.GITHUB_TOKEN }}` and `permissions: actions: read`"
+  - "Verify artifacts exist under the triggering run via the Actions UI before debugging download steps"
+  - "Name artifacts consistently between upload (in CI) and download (in deploy) workflows"
+docs:
+  - url: "https://github.com/actions/download-artifact?tab=readme-ov-file#download-artifacts-from-other-workflow-runs-or-repositories"
+    label: "actions/download-artifact: Downloading from other workflow runs"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run"
+    label: "GitHub Docs: workflow_run event"

package/errors/caching-artifacts/caching-artifacts-054.yml

@@ -0,0 +1,102 @@
+id: caching-artifacts-054
+title: "upload-artifact@v4 Rejects Artifact Names Containing Special Characters"
+category: caching-artifacts
+severity: error
+tags:
+  - upload-artifact
+  - artifact-name
+  - v4-migration
+  - special-characters
+  - validation
+  - branch-name
+patterns:
+  - regex: 'The artifact name is not valid'
+    flags: "i"
+  - regex: 'Artifact name .+ is not valid'
+    flags: "i"
+  - regex: 'characters are not allowed in artifact names?'
+    flags: "i"
+error_messages:
+  - "Error: The artifact name is not valid. The following characters are not allowed in artifact names: \\ / : * ? \" < > |"
+  - "Artifact name 'feature/login-ui' is not valid. The following characters are not allowed: /"
+  - "Error: An artifact name must not contain the following characters: \\ / : * ? \" < > |"
+root_cause: |
+  actions/upload-artifact@v4 introduced strict server-side validation of
+  artifact names. The following characters are now explicitly rejected because
+  they are illegal in file or directory names on the artifact storage backend:
+
+    \ / : * ? " < > |
+
+  In v3, artifact names were either silently sanitized or accepted with these
+  characters (depending on the storage backend behavior). v4 fails hard with a
+  clear error.
+
+  The most common failure mode is dynamic artifact names constructed from:
+  - Branch names: github.ref_name or github.head_ref (contain /)
+  - Pull request titles: github.event.pull_request.title (contain : / " etc.)
+  - Matrix values: matrix.os or matrix.target (may contain : on Windows paths)
+  - Composite keys: combining multiple context values with : as separator
+
+  Example patterns that break:
+    name: build-${{ github.ref_name }}         # "feature/login" contains /
+    name: results-${{ matrix.os }}             # "windows-latest" is fine but
+                                               # some custom os values may not be
+    name: ${{ github.event.pull_request.title }} # PR titles can contain any char
+fix: |
+  Sanitize the artifact name before passing it to upload-artifact. Replace or
+  strip disallowed characters using a shell substitution or a prior step that
+  outputs a safe name. The simplest approach is replacing / with - or _.
+fix_code:
+  - language: yaml
+    label: "Sanitize branch name artifact using shell substitution"
+    code: |
+      - name: Upload build artifact
+        uses: actions/upload-artifact@v4
+        with:
+          # Replace / with - to make branch name safe
+          name: build-${{ github.ref_name && replace(github.ref_name, '/', '-') || 'main' }}
+          path: dist/
+
+  - language: yaml
+    label: "Compute safe artifact name in prior step output"
+    code: |
+      - name: Compute safe artifact name
+        id: artifact-name
+        run: |
+          # Strip or replace characters not allowed in artifact names: \ / : * ? " < > |
+          SAFE_NAME=$(echo "${{ github.ref_name }}" | tr '/:*?"<>|\\' '-')
+          echo "name=build-${SAFE_NAME}" >> $GITHUB_OUTPUT
+
+      - name: Upload artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: ${{ steps.artifact-name.outputs.name }}
+          path: dist/
+
+  - language: yaml
+    label: "Use matrix hash or index for safe matrix artifact names"
+    code: |
+      strategy:
+        matrix:
+          config: [debug, release]
+          os: [ubuntu-latest, windows-latest, macos-latest]
+
+      steps:
+        - name: Upload matrix artifact
+          uses: actions/upload-artifact@v4
+          with:
+            # Safe: all matrix.* values here contain no special chars
+            name: build-${{ matrix.os }}-${{ matrix.config }}
+            path: dist/
+prevention:
+  - "Never pass github.ref_name, github.head_ref, or PR titles directly as artifact names without sanitization."
+  - "When constructing dynamic artifact names, run them through tr or sed to replace / : * ? \" < > | \\ with - or _."
+  - "Use actionlint or a pre-commit hook to flag unescaped context expressions in artifact name: fields."
+  - "Consider using a matrix index or a hash of the artifact key for truly collision-safe names."
+docs:
+  - url: "https://github.com/actions/upload-artifact/releases/tag/v4.0.0"
+    label: "upload-artifact v4.0.0 release notes — breaking changes"
+  - url: "https://github.com/actions/upload-artifact#inputs"
+    label: "upload-artifact README — name input and allowed characters"
+  - url: "https://stackoverflow.com/questions/77975069"
+    label: "SO#77975069 — upload-artifact v4 artifact name is not valid"

package/errors/concurrency-timing/concurrency-timing-045.yml

@@ -0,0 +1,70 @@
+id: concurrency-timing-045
+title: "workflow_run-triggered workflows run concurrently — no upstream concurrency linkage"
+category: concurrency-timing
+severity: silent-failure
+tags:
+  - workflow_run
+  - concurrency
+  - deployment
+  - build-deploy-pipeline
+  - downstream-workflow
+patterns:
+  - regex: 'on:\s+workflow_run:'
+    flags: 'si'
+error_messages:
+  - "Multiple deployments triggered simultaneously for the same branch"
+  - "Deploy workflow triggered concurrently"
+root_cause: |
+  Workflows triggered via `on: workflow_run:` do not inherit any concurrency
+  group from the triggering (upstream) workflow. If multiple upstream runs
+  complete in quick succession — for example, two commits pushed rapidly — each
+  `completed` event spawns an independent downstream run. All downstream runs
+  execute concurrently with no serialization or cancellation, even when the
+  upstream workflow had a concurrency group that serialized upstream runs.
+
+  The downstream workflow runs in the context of the default branch and receives
+  the triggering run's metadata via `github.event.workflow_run.*`, but GitHub
+  does not propagate any concurrency scope from upstream to downstream.
+
+  For build-then-deploy pipelines this creates a race condition: two deploy runs
+  may begin simultaneously, with whichever finishes last determining the final
+  deployed state regardless of commit order.
+fix: |
+  Add an explicit `concurrency:` block to the `workflow_run`-triggered workflow,
+  keyed on `github.event.workflow_run.head_branch` to scope per branch.
+
+  Use `cancel-in-progress: true` for idempotent deploys (only the latest commit
+  matters) or `cancel-in-progress: false` for non-idempotent operations that
+  must complete once queued.
+fix_code:
+  - language: yaml
+    label: "Add explicit concurrency group to workflow_run-triggered deploy workflow"
+    code: |
+      on:
+        workflow_run:
+          workflows: ["CI"]
+          types: [completed]
+          branches: [main]
+
+      # Without this block, concurrent CI completions spawn concurrent deploys
+      concurrency:
+        group: deploy-${{ github.event.workflow_run.head_branch }}
+        cancel-in-progress: true
+
+      jobs:
+        deploy:
+          if: github.event.workflow_run.conclusion == 'success'
+          runs-on: ubuntu-latest
+          steps:
+            - name: Deploy
+              run: echo "Deploying ${{ github.event.workflow_run.head_sha }}"
+prevention:
+  - "Always define an explicit `concurrency:` block in `workflow_run`-triggered workflows"
+  - "Key the concurrency group on `github.event.workflow_run.head_branch` to scope by branch"
+  - "For CI-to-deploy pipelines, use `cancel-in-progress: true` so only the latest commit deploys"
+  - "Consider consolidating CI and deploy into a single workflow using `needs:` if elevated permissions are not required"
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run"
+    label: "GitHub Docs: workflow_run event"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/controlling-workflow-and-job-execution"
+    label: "GitHub Docs: Controlling workflow and job execution (concurrency)"

package/errors/permissions-auth/permissions-auth-054.yml

@@ -0,0 +1,99 @@
+id: permissions-auth-054
+title: "OIDC sub claim format changes when environment: block added — IdP trust policy breaks"
+category: permissions-auth
+severity: error
+tags:
+  - oidc
+  - environment
+  - aws
+  - gcp
+  - azure
+  - sub-claim
+  - trust-policy
+  - deployment-protection
+patterns:
+  - regex: 'Not authorized to perform sts:AssumeRoleWithWebIdentity'
+    flags: 'i'
+  - regex: 'Error: Credentials could not be loaded'
+    flags: 'i'
+  - regex: 'Permission.*denied.*generateAccessToken|WorkloadIdentityPool.*rejected'
+    flags: 'i'
+error_messages:
+  - "Not authorized to perform sts:AssumeRoleWithWebIdentity"
+  - "Error: Credentials could not be loaded, please check your action inputs: Could not load credentials from any providers"
+  - "Permission 'iam.serviceAccounts.getOpenIdToken' denied on resource"
+  - "The provided token could not be validated"
+root_cause: |
+  GitHub Actions OIDC token `sub` (subject) claim format depends on whether the
+  job has an `environment:` key. Without an environment, the subject is:
+    `repo:OWNER/REPO:ref:refs/heads/BRANCH`
+
+  When `environment: production` is present on the job, the format changes to:
+    `repo:OWNER/REPO:environment:production`
+
+  The branch/ref component is replaced entirely by the environment name. AWS IAM
+  role trust policies, GCP Workload Identity Federation conditions, and Azure
+  federated credential filters that matched the branch-ref format now receive a
+  token with a different sub claim and reject the OIDC exchange with a 403 or
+  permission-denied error.
+
+  This commonly occurs when a team adds environment protection rules (required
+  reviewers, wait timers) to an existing workflow that already had OIDC
+  credentials working. CI passes before adding `environment:` but fails after.
+fix: |
+  Update the IdP trust policy to match the new subject format containing the
+  environment name. Options:
+  1. Narrow to environment: change the condition to match
+     `repo:OWNER/REPO:environment:production`.
+  2. Use a wildcard: match `repo:OWNER/REPO:*` to accept both formats (less secure).
+  3. GitHub subject claim customization (Enterprise): define a consistent sub
+     claim format that does not change based on environment presence.
+fix_code:
+  - language: yaml
+    label: "Workflow: annotate environment and required OIDC permissions"
+    code: |
+      permissions:
+        id-token: write
+        contents: read
+
+      jobs:
+        deploy:
+          # Adding this key changes the OIDC sub claim format — update IdP trust policy
+          environment: production
+          runs-on: ubuntu-latest
+          steps:
+            - uses: aws-actions/configure-aws-credentials@v4
+              with:
+                role-to-assume: arn:aws:iam::123456789012:role/DeployRole
+                aws-region: us-east-1
+                # AWS trust policy must now use:
+                # "token.actions.githubusercontent.com:sub":
+                #   "StringEquals": "repo:org/repo:environment:production"
+                # (not "repo:org/repo:ref:refs/heads/main")
+  - language: yaml
+    label: "AWS IAM trust policy: match environment sub claim"
+    code: |
+      # AWS IAM Role Trust Policy — update Condition after adding environment:
+      # Before (no environment):
+      #   "token.actions.githubusercontent.com:sub": "repo:org/repo:ref:refs/heads/main"
+      #
+      # After (with environment: production):
+      #   "token.actions.githubusercontent.com:sub": "repo:org/repo:environment:production"
+      #
+      # Wildcard to accept both (less restrictive):
+      #   "token.actions.githubusercontent.com:sub":
+      #     StringLike: "repo:org/repo:*"
+      #
+      # GCP: update attribute.repository_environment or use attribute mapping
+prevention:
+  - "Before adding `environment:` to a job using OIDC, audit and update all IdP trust policies"
+  - "Document the expected sub claim format in trust policy comments to avoid future confusion"
+  - "Use GitHub's OIDC token debugger step to inspect the actual sub claim at runtime"
+  - "For consistent sub format across environment and non-environment jobs, consider subject claim customization"
+docs:
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#filtering-for-a-specific-environment"
+    label: "GitHub Docs: OIDC filtering for a specific environment"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-subject-claims-for-an-organization-or-repository"
+    label: "GitHub Docs: Customizing subject claims"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services"
+    label: "GitHub Docs: Configuring OIDC in AWS"

package/errors/permissions-auth/permissions-auth-055.yml

@@ -0,0 +1,110 @@
+id: permissions-auth-055
+title: "GITHUB_TOKEN Cannot Push to .github/workflows/ — Requires PAT with workflow Scope"
+category: permissions-auth
+severity: error
+tags:
+  - github-token
+  - workflow-files
+  - workflow-scope
+  - pat
+  - contents-write
+  - self-modifying-workflow
+patterns:
+  - regex: 'refusing to allow .+ to create or update workflow .+\.yml'
+    flags: "i"
+  - regex: 'refusing to allow a GitHub Actions App to create or update workflow'
+    flags: "i"
+  - regex: 'GH006.*refusing to allow.*workflow'
+    flags: "i"
+error_messages:
+  - "refusing to allow a GitHub Actions App to create or update workflow .github/workflows/ci.yml"
+  - "remote: error: GH006: Protected branch update failed for refs/heads/main. remote: error: refusing to allow a GitHub Actions App to create or update workflow .github/workflows/deploy.yml"
+  - "refusing to allow GitHub Actions Bot to update .github/workflows/release.yml"
+  - "remote: Resolving deltas: 100% (1/1), done. remote: error: refusing to allow a GitHub Actions App to create or update workflow"
+root_cause: |
+  GitHub enforces a hard server-side restriction preventing GITHUB_TOKEN from
+  creating or modifying files under .github/workflows/. This restriction applies
+  regardless of the permissions: block in the workflow. Even with
+  permissions: contents: write, GITHUB_TOKEN will be rejected when the push
+  includes changes to workflow files.
+
+  This security control exists to prevent privilege escalation: a compromised or
+  malicious workflow cannot modify itself or other workflows to gain additional
+  permissions or persist access. The restriction is enforced at the remote push
+  validation layer, not by the GitHub Actions runtime.
+
+  Common scenarios that trigger this:
+  - Automated dependency update workflows that pin action versions
+    (e.g., actions/checkout@v3 -> @v4) in workflow files
+  - Workflow generators that create or update .github/workflows/*.yml
+  - Renovate, Dependabot, or custom bots using GITHUB_TOKEN to update action refs
+  - Release automation that stamps version information into workflow files
+  - Repository template sync tools that propagate workflow updates
+
+  Note: fine-grained PATs WITH the repository contents:write permission DO allow
+  workflow file updates (this restriction only applies to GITHUB_TOKEN
+  specifically, not all tokens).
+fix: |
+  Use a Personal Access Token (classic PAT) with the workflow scope, a
+  fine-grained PAT with the repository contents:write permission, or a GitHub
+  App with the workflows repository permission. Store the token as a repository
+  or organization secret and use it in place of GITHUB_TOKEN for the checkout
+  or push steps.
+fix_code:
+  - language: yaml
+    label: "Use PAT with workflow scope via checkout persist-credentials"
+    code: |
+      jobs:
+        update-workflow:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                # Use a PAT with workflow scope — GITHUB_TOKEN cannot push workflow files
+                token: ${{ secrets.WORKFLOW_PAT }}
+
+            - name: Update workflow file
+              run: |
+                sed -i 's/actions\/checkout@v3/actions\/checkout@v4/g' .github/workflows/*.yml
+
+            - name: Commit and push workflow changes
+              env:
+                GH_TOKEN: ${{ secrets.WORKFLOW_PAT }}
+              run: |
+                echo "Commit workflow changes using PAT token"
+                # repository operations using the authenticated token
+
+  - language: yaml
+    label: "Use GitHub App token with workflows permission"
+    code: |
+      jobs:
+        update-workflow:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/create-github-app-token@v1
+              id: app-token
+              with:
+                app-id: ${{ secrets.APP_ID }}
+                private-key: ${{ secrets.APP_PRIVATE_KEY }}
+
+            - uses: actions/checkout@v4
+              with:
+                token: ${{ steps.app-token.outputs.token }}
+
+            - name: Modify workflow file and push
+              env:
+                GH_TOKEN: ${{ steps.app-token.outputs.token }}
+              run: |
+                echo "Commit workflow changes via GitHub App token"
+prevention:
+  - "Store a classic PAT with the workflow scope as a secret (e.g., WORKFLOW_PAT) for any job that writes to .github/workflows/."
+  - "Do not expect permissions: contents: write to grant GITHUB_TOKEN the ability to modify workflow files — it will always be rejected."
+  - "Use GitHub Apps with the workflows repository permission for scalable, org-wide workflow automation."
+  - "Prefer Renovate or Dependabot (which use their own token/app with workflow scope) for automated action version pinning."
+docs:
+  - url: "https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic"
+    label: "GitHub Docs — Classic PAT workflow scope"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token"
+    label: "GitHub Docs — GITHUB_TOKEN permissions"
+  - url: "https://stackoverflow.com/questions/64059610"
+    label: "SO#64059610 — refusing to allow GitHub Actions App to create or update workflow"

package/errors/permissions-auth/permissions-auth-057.yml

@@ -0,0 +1,97 @@
+id: permissions-auth-057
+title: "gh CLI Uses GITHUB_TOKEN Env Variable, Not actions/checkout Custom Token"
+category: permissions-auth
+severity: silent-failure
+tags:
+  - gh-cli
+  - GITHUB_TOKEN
+  - checkout
+  - PAT
+  - token-scope
+patterns:
+  - regex: 'Resource not accessible by integration'
+    flags: "i"
+  - regex: 'gh:.*HTTP 403'
+    flags: "i"
+  - regex: 'gh:.*could not resolve to a node'
+    flags: "i"
+error_messages:
+  - "gh: Resource not accessible by integration (HTTP 403)"
+  - "remote: Permission to org/repo.git denied to github-actions[bot]."
+  - "gh: GraphQL: Could not resolve to a node with the global id of ''"
+root_cause: |
+  When `actions/checkout` is configured with a custom `token:` (e.g., a PAT or
+  GitHub App installation token), the custom token is written into the local
+  git credential helper so that git operations (push, fetch) authenticate with
+  the custom token.
+
+  However, the `gh` CLI does NOT read from the git credential helper. It resolves
+  authentication by checking these environment variables in priority order:
+    1. `GH_TOKEN`
+    2. `GITHUB_TOKEN`
+    3. System keychain / credential store (unavailable on hosted runners)
+
+  GitHub Actions always sets `GITHUB_TOKEN` to the default job token, regardless
+  of any custom token supplied to `actions/checkout`. When a step uses `gh` CLI
+  without an explicit `GH_TOKEN`, it picks up the default `GITHUB_TOKEN` which
+  may lack the required scopes (e.g., packages:write, org membership, cross-repo
+  access) — producing a 403 or permission error that appears to contradict the
+  checkout step succeeding with the PAT.
+
+  This mismatch is especially confusing because `git push` (using credentials
+  from checkout) succeeds while `gh pr create` or `gh release create` (using
+  GITHUB_TOKEN) fails in the same job.
+fix: |
+  Explicitly pass the custom token to `gh` via the `GH_TOKEN` or `GITHUB_TOKEN`
+  environment variable. Do not rely on `actions/checkout token:` to authenticate
+  `gh` CLI.
+
+  Setting `GH_TOKEN` at the step or job level is preferred as it keeps the scope
+  limited to where the elevated token is needed.
+fix_code:
+  - language: yaml
+    label: "Explicitly set GH_TOKEN for gh CLI steps"
+    code: |
+      jobs:
+        release:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                # Custom token sets git credentials — does NOT affect gh CLI
+                token: ${{ secrets.ORG_PAT }}
+
+            - name: Create GitHub release
+              # gh reads GH_TOKEN (not checkout token) — pass it explicitly
+              env:
+                GH_TOKEN: ${{ secrets.ORG_PAT }}
+              run: |
+                gh release create v1.0.0 --title "v1.0.0" --generate-notes
+  - language: yaml
+    label: "Set GITHUB_TOKEN at job level to override for all gh CLI steps"
+    code: |
+      jobs:
+        release:
+          runs-on: ubuntu-latest
+          # Override GITHUB_TOKEN for the entire job so all gh steps use the PAT
+          env:
+            GITHUB_TOKEN: ${{ secrets.ORG_PAT }}
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                token: ${{ secrets.ORG_PAT }}
+            - run: gh pr create --title "Automated PR" --body "Auto-generated"
+prevention:
+  - "Always check which token gh CLI is using — it reads GH_TOKEN or GITHUB_TOKEN, not git credentials set by actions/checkout."
+  - "Set GH_TOKEN or GITHUB_TOKEN explicitly in env: blocks for any step that uses gh CLI with elevated permissions."
+  - "Use permissions: at the job level to grant additional scopes to the default GITHUB_TOKEN before reaching for a PAT."
+  - "When using a custom checkout token for git operations, remember gh CLI still needs GH_TOKEN set separately."
+docs:
+  - url: "https://cli.github.com/manual/gh_help_environment"
+    label: "gh CLI — GH_TOKEN environment variable"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication"
+    label: "GitHub Docs — GITHUB_TOKEN automatic authentication"
+  - url: "https://github.com/cli/cli/issues/2534"
+    label: "cli/cli#2534 — gh CLI ignores git credential helper token"
+  - url: "https://github.com/actions/checkout/issues/1168"
+    label: "actions/checkout#1168 — Custom token not used by gh CLI"

package/errors/runner-environment/runner-environment-164.yml

@@ -0,0 +1,89 @@
+id: runner-environment-164
+title: "setup-python python-version-file Fails with pyenv Pre-Release Version Notation"
+category: runner-environment
+severity: error
+tags:
+  - setup-python
+  - python-version-file
+  - pyenv
+  - pre-release
+  - version-format
+patterns:
+  - regex: 'Version \d+\.\d+\.\d+[ab]\d+ with arch .* not found'
+    flags: "i"
+  - regex: 'No available version found for [\d.]+[ab]'
+    flags: "i"
+  - regex: 'python-version-file.*\.python-version'
+    flags: "i"
+error_messages:
+  - "Version 3.13.0a4 with arch x64 not found"
+  - "Version 3.14.0b2 with arch x64 not found"
+  - "No available version found for 3.13.0a1"
+  - "The version '3.13.0rc1' with architecture 'x64' was not found."
+root_cause: |
+  pyenv-style `.python-version` files use native Python pre-release notation:
+    - `3.13.0a4`  (alpha 4)
+    - `3.14.0b2`  (beta 2)
+    - `3.13.0rc1` (release candidate 1)
+
+  `actions/setup-python` looks up versions using semver-style notation in the
+  GitHub toolcache, where pre-releases are labeled differently:
+    - `3.13.0-alpha.4`
+    - `3.14.0-beta.2`
+    - `3.13.0-rc.1`
+
+  When setup-python reads a `.python-version` file containing pyenv-style
+  notation (e.g., `3.13.0a4`), it cannot find a matching toolcache entry and
+  fails with "Version not found". Stable releases (e.g., `3.11.5`, `3.12.3`)
+  are unaffected because their notation is identical in both conventions.
+
+  This commonly surprises developers who pin a pre-release Python locally for
+  testing using pyenv and commit the `.python-version` file expecting CI to
+  use the same version.
+fix: |
+  Convert the `.python-version` file to semver notation for pre-releases, or
+  specify the Python version directly in the workflow using `python-version:`
+  to avoid relying on the file format.
+
+  For CI purposes, pinning to a stable minor version (e.g., `3.13`) is usually
+  sufficient and avoids both the notation mismatch and toolcache fallback issues.
+fix_code:
+  - language: yaml
+    label: "Use semver notation in .python-version for pre-releases"
+    code: |
+      # .python-version — use semver, not pyenv pre-release notation
+      #
+      # Wrong (pyenv style):   3.13.0a4
+      # Correct (semver style): 3.13.0-alpha.4
+      #
+      # Other mappings:
+      #   3.14.0b2  →  3.14.0-beta.2
+      #   3.13.0rc1 →  3.13.0-rc.1
+
+      # Workflow using the corrected file:
+      - uses: actions/setup-python@v5
+        with:
+          python-version-file: '.python-version'
+          allow-prereleases: true  # Required for any pre-release version
+  - language: yaml
+    label: "Pin version directly in workflow to bypass file format issues"
+    code: |
+      - uses: actions/setup-python@v5
+        with:
+          # Use stable minor version — avoids pre-release notation issues
+          python-version: '3.13'
+          # Or use explicit semver pre-release notation:
+          # python-version: '3.13.0-alpha.4'
+          allow-prereleases: true
+prevention:
+  - "Use semver notation (3.13.0-alpha.4) not pyenv notation (3.13.0a4) in .python-version files consumed by CI."
+  - "Prefer pinning to a stable minor version (3.13) in CI rather than a specific pre-release patch."
+  - "Always set allow-prereleases: true in setup-python when using any pre-release Python version."
+  - "Add a comment in .python-version documenting the notation convention to avoid confusion for contributors."
+docs:
+  - url: "https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#using-the-python-version-file-input"
+    label: "setup-python docs — python-version-file input"
+  - url: "https://github.com/actions/setup-python/issues/770"
+    label: "actions/setup-python#770 — Pre-release version notation mismatch"
+  - url: "https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work"
+    label: "Python.org — Version numbering scheme"

package/errors/runner-environment/runner-environment-165.yml

@@ -0,0 +1,86 @@
+id: runner-environment-165
+title: "ARM64 Linux Runners: Python Packages Without linux_aarch64 Binary Wheels Fail Installation"
+category: runner-environment
+severity: error
+tags:
+  - arm64
+  - ubuntu-arm
+  - python
+  - pip
+  - binary-wheels
+  - linux-aarch64
+patterns:
+  - regex: 'No matching distribution found for .+==[\d.]+'
+    flags: "i"
+  - regex: 'Could not find a version that satisfies the requirement .+ \(from versions: none\)'
+    flags: "i"
+  - regex: 'ERROR: .+ is not supported on this platform'
+    flags: "i"
+error_messages:
+  - "ERROR: Could not find a version that satisfies the requirement numpy==1.21.0 (from versions: none)"
+  - "ERROR: No matching distribution found for numpy==1.21.0"
+  - "error: command '/usr/bin/gcc' failed with exit code 1"
+  - "Building wheels for collected packages: X ... error: subprocess-exited-with-error"
+root_cause: |
+  When migrating from x64 runners (ubuntu-latest, ubuntu-22.04) to ARM64
+  runners (ubuntu-24.04-arm, ubuntu-22.04-arm), Python packages pinned to
+  older versions may not have linux_aarch64 binary wheels on PyPI. Without a
+  pre-compiled wheel, pip falls back to building from source, which either
+  fails outright (missing build dependencies, compiler errors) or succeeds
+  slowly. For packages like numpy, scipy, Pillow, cryptography, and pandas,
+  ARM64 wheel support was only added in later releases. The error message "No
+  matching distribution found" is misleading because the package does exist on
+  PyPI — just not the specific version for the linux_aarch64 platform.
+
+  Commonly affected packages and the minimum version with ARM64 wheel support:
+  - numpy: >= 1.24.0
+  - Pillow: >= 9.2.0
+  - cryptography: >= 38.0.0
+  - grpcio: >= 1.50.0
+  - scipy: >= 1.9.0
+  - lxml: >= 4.9.0
+
+  This is distinct from PEP 668 (system pip blocked by externally managed env),
+  macOS Rosetta (x86_64 binary executing on Apple Silicon), and
+  ubuntu-arm64-docker-not-preinstalled (Docker not available on arm runners).
+fix: |
+  Upgrade pinned package versions to releases that include linux_aarch64 binary
+  wheels. Use pip install --only-binary=:all: to get a clear platform error
+  instead of a slow source-build failure. If upgrading is impossible, install
+  the required build dependencies (gcc, python3-dev, libssl-dev, etc.) before
+  running pip install.
+fix_code:
+  - language: yaml
+    label: "Upgrade pinned packages to ARM64-compatible versions"
+    code: |
+      - name: Install Python dependencies (ARM64 compatible)
+        run: |
+          # Upgrade pinned packages to versions with linux_aarch64 wheels
+          pip install "numpy>=1.24.0" "Pillow>=9.2.0" "cryptography>=38.0.0"
+
+  - language: yaml
+    label: "Use --only-binary to detect missing wheels early"
+    code: |
+      - name: Install dependencies (fail fast if no wheel)"
+        run: pip install --only-binary=:all: -r requirements.txt
+
+  - language: yaml
+    label: "Install build dependencies for packages requiring source compilation"
+    code: |
+      - name: Install build dependencies for source compilation
+        run: sudo apt-get install -y gcc python3-dev libssl-dev libffi-dev
+
+      - name: Install Python packages
+        run: pip install -r requirements.txt
+prevention:
+  - "Before migrating to ARM64 runners, audit requirements.txt for packages lacking linux_aarch64 wheels at pinned versions."
+  - "Use pip install --only-binary=:all: -r requirements.txt in a test run to surface platform compatibility gaps."
+  - "Reference PyPI package pages to verify linux_aarch64 wheel availability for the specific version you are pinning."
+  - "Prefer unpinned or range-pinned dependencies (numpy>=1.24) over exact-pinned (numpy==1.21.0) to allow ARM64-capable versions."
+docs:
+  - url: "https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources"
+    label: "GitHub Docs — Supported GitHub-hosted runners (ARM64)"
+  - url: "https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-only-binary"
+    label: "pip docs — --only-binary option"
+  - url: "https://stackoverflow.com/questions/75782839"
+    label: "SO#75782839 — pip no matching distribution on ARM64 runner"

package/errors/triggers/triggers-064.yml

@@ -0,0 +1,122 @@
+id: triggers-064
+title: "workflow_run Triggered Workflow Cannot Access github.event.pull_request — PR Number Is Empty"
+category: triggers
+severity: silent-failure
+tags:
+  - workflow_run
+  - pull-request
+  - event-context
+  - pr-number
+  - artifact
+patterns:
+  - regex: 'github\.event\.pull_request\.number'
+    flags: "i"
+  - regex: 'event\.number.*workflow_run'
+    flags: "i"
+error_messages:
+  - "# No error thrown — github.event.pull_request.number evaluates to empty string"
+  - "Error: PR number is empty"
+root_cause: |
+  When a workflow is triggered by `on: workflow_run`, the event payload is a
+  `workflow_run` object — NOT the event that triggered the upstream workflow.
+
+  This means `github.event.pull_request`, `github.event.number`, and all
+  other pull_request-specific context keys evaluate to empty string (not an
+  error). The only event data available is under `github.event.workflow_run.*`,
+  which exposes run metadata (run ID, head branch, head SHA, conclusion, etc.)
+  but NOT the original pull request event payload.
+
+  The common pattern breaks when developers write `workflow_run`-triggered
+  workflows to post PR comments or add labels and reference
+  `${{ github.event.pull_request.number }}` — the expression silently evaluates
+  to empty string, causing downstream API calls to fail or act on the wrong
+  resource without a clear error.
+
+  `github.event.workflow_run.pull_requests` is populated by GitHub only when
+  the triggering workflow was itself triggered by a pull_request event, providing
+  a lighter-weight alternative to the artifact pattern.
+fix: |
+  Upload the needed PR context (number, head SHA, labels) as a JSON artifact
+  in the upstream workflow. In the downstream `workflow_run` workflow, download
+  the artifact and extract the values.
+
+  For simpler cases, read `github.event.workflow_run.pull_requests[0].number`
+  — GitHub populates this array when the triggering workflow ran on a PR.
+fix_code:
+  - language: yaml
+    label: "Upstream workflow: upload PR context as artifact"
+    code: |
+      on:
+        pull_request:
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: make build
+            - name: Save PR context for downstream workflow
+              run: |
+                mkdir -p /tmp/pr-context
+                echo '${{ toJSON(github.event.pull_request) }}' \
+                  > /tmp/pr-context/pr.json
+            - uses: actions/upload-artifact@v4
+              with:
+                name: pr-context
+                path: /tmp/pr-context/pr.json
+  - language: yaml
+    label: "Downstream workflow_run: download artifact and read PR number"
+    code: |
+      on:
+        workflow_run:
+          workflows: ["CI"]
+          types: [completed]
+
+      jobs:
+        report:
+          runs-on: ubuntu-latest
+          permissions:
+            actions: read
+            pull-requests: write
+          steps:
+            - uses: actions/download-artifact@v4
+              with:
+                name: pr-context
+                run-id: ${{ github.event.workflow_run.id }}
+                github-token: ${{ secrets.GITHUB_TOKEN }}
+            - name: Read PR number and comment
+              run: |
+                PR_NUMBER=$(jq '.number' pr.json)
+                echo "PR: $PR_NUMBER"
+              env:
+                GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+  - language: yaml
+    label: "Lightweight alternative: use github.event.workflow_run.pull_requests array"
+    code: |
+      on:
+        workflow_run:
+          workflows: ["CI"]
+          types: [completed]
+
+      jobs:
+        report:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Get PR number from workflow_run context
+              run: |
+                echo "PR: ${{ github.event.workflow_run.pull_requests[0].number }}"
+                # Note: pull_requests array is only populated when the triggering
+                # workflow was triggered by a pull_request event from a non-fork.
+                # For forks, the array is empty — use the artifact pattern instead.
+prevention:
+  - "Never reference github.event.pull_request in workflow_run-triggered workflows — the event payload is workflow_run, not pull_request."
+  - "Upload PR context (number, head SHA, labels) as a JSON artifact in the upstream workflow for downstream consumption."
+  - "Use github.event.workflow_run.pull_requests[0].number for a lighter approach when the triggering workflow ran on a non-fork pull_request."
+  - "Add defensive checks: if the PR number resolves to empty, skip steps that require it to avoid silent API failures."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run"
+    label: "GitHub Docs — workflow_run event"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#using-data-from-the-triggering-workflow"
+    label: "GitHub Docs — Using data from the triggering workflow"
+  - url: "https://stackoverflow.com/questions/71570882"
+    label: "SO#71570882 — Get PR number in workflow_run triggered workflow"

package/errors/yaml-syntax/yaml-syntax-059.yml

@@ -0,0 +1,93 @@
+id: yaml-syntax-059
+title: "needs: key does not accept runtime expressions — must be static job IDs"
+category: yaml-syntax
+severity: error
+tags:
+  - needs
+  - expressions
+  - dynamic-jobs
+  - job-dependencies
+  - parse-time
+  - actionlint
+patterns:
+  - regex: "The pipeline is not valid.*needs|needs.*references.*job.*does not exist"
+    flags: 'i'
+  - regex: 'Unrecognized named-value.*steps.*in needs|needs.*invalid.*expression'
+    flags: 'i'
+error_messages:
+  - "The pipeline is not valid. Job 'deploy' needs 'steps' which does not exist"
+  - "Unrecognized named-value: 'steps'"
+  - "Job 'X' depends on unknown job '${{ fromJSON(...) }}'"
+  - "needs: field value '${{ ... }}' is not a valid job identifier"
+root_cause: |
+  The `needs:` key in a GitHub Actions job definition must contain static job ID
+  strings. It is evaluated at workflow parse time — before any step or job runs
+  — so runtime expressions such as `${{ steps.gen.outputs.jobs }}` or
+  `${{ fromJSON(env.DYNAMIC_JOBS) }}` are not evaluated. They are treated as
+  literal strings, and since no job with that literal name exists, GitHub reports
+  a validation error or the dependency is silently ignored.
+
+  This surprises developers who successfully use `fromJSON()` in `matrix:` or
+  `env:` blocks (which ARE expression-capable) and assume `needs:` works the
+  same way. The difference is that the job dependency graph must be fully
+  resolved before execution begins; expressions in `needs:` would create a
+  circular dependency at parse time.
+
+  actionlint statically detects this and reports: "needs: field cannot be
+  computed by a dynamic value. Use a literal value instead."
+fix: |
+  Job dependencies must be statically defined. Use one of these patterns:
+  1. List all potential dependent jobs statically; use `if:` conditions on
+     each downstream job to skip those not needed.
+  2. Use a matrix fan-out + fan-in pattern where the fan-in job has a single
+     static `needs:` on the matrix job name (not individual matrix legs).
+  3. Restructure so the dependency graph is known at workflow authoring time.
+fix_code:
+  - language: yaml
+    label: "Correct: static needs: with if: conditions to control execution"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          outputs:
+            should_deploy: ${{ steps.check.outputs.deploy }}
+          steps:
+            - id: check
+              run: echo "deploy=true" >> $GITHUB_OUTPUT
+
+        deploy:
+          # Static needs: always declared; if: controls whether it runs
+          needs: [build]
+          if: needs.build.outputs.should_deploy == 'true'
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "deploying"
+  - language: yaml
+    label: "Incorrect: expression in needs: causes parse-time validation error"
+    code: |
+      jobs:
+        generate:
+          runs-on: ubuntu-latest
+          outputs:
+            jobs: ${{ steps.list.outputs.jobs }}
+          steps:
+            - id: list
+              run: echo 'jobs=["build","lint"]' >> $GITHUB_OUTPUT
+
+        # ERROR: needs: does not evaluate expressions — this is a parse-time failure
+        deploy:
+          needs: ${{ fromJSON(needs.generate.outputs.jobs) }}
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "this never runs"
+prevention:
+  - "Always use static job ID string literals in `needs:` — no expressions, no fromJSON()"
+  - "Use actionlint to pre-validate workflows before pushing: it catches invalid expression contexts"
+  - "For dynamic fan-in, depend on the matrix job name itself, not individual matrix leg names"
+  - "Use `if: contains(needs.*.result, 'failure')` for conditional logic after static needs"
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds"
+    label: "GitHub Docs: jobs.<job_id>.needs"
+  - url: "https://rhysd.github.io/actionlint/"
+    label: "actionlint: Static checker for GitHub Actions workflow files"
+

package/errors/yaml-syntax/yaml-syntax-060.yml

@@ -0,0 +1,100 @@
+id: yaml-syntax-060
+title: "Object Filter Expression .* on Null Parent Context Raises Template Validation Error"
+category: yaml-syntax
+severity: error
+tags:
+  - expression
+  - object-filter
+  - null-context
+  - wildcard
+  - pull_request
+  - multi-trigger
+patterns:
+  - regex: 'Object filter left operand must be of type Array or Object but is Null'
+    flags: "i"
+  - regex: 'github\.event\.[a-z_]+\.\*\.[a-z_]+'
+    flags: "i"
+  - regex: 'The template is not valid.*Object filter'
+    flags: "i"
+error_messages:
+  - "Error: The template is not valid. .github/workflows/ci.yml (Line: 12, Col: 8): Object filter left operand must be of type Array or Object but is Null"
+  - "Object filter left operand must be of type Array or Object but is Null"
+  - "Unexpected value 'null'. Located at position 0 within expression: contains(github.event.pull_request.labels.*.name, 'skip-ci')"
+root_cause: |
+  GitHub Actions supports object filtering via the .* wildcard syntax, which
+  maps over an array or object and extracts a named property from each element.
+  For example: github.event.pull_request.labels.*.name returns an array of
+  label names on a pull_request event.
+
+  When the parent context object is null — which occurs whenever the event
+  payload does not include that property — the .* filter throws a template
+  validation error at expression evaluation time rather than returning an empty
+  array. This is a common pitfall in workflows that handle multiple event types:
+
+  - On push events, github.event.pull_request is null
+  - On schedule events, github.event.issue is null
+  - On workflow_dispatch events, github.event.commits is null
+
+  The expression evaluator does NOT fall back to an empty result for null .*.
+  Instead it fails the step with a template error, even though null.property
+  (single property access) would silently return an empty string.
+
+  Typical pattern that fails on push events:
+    if: contains(github.event.pull_request.labels.*.name, 'skip-ci')
+fix: |
+  Guard the object filter expression with an event type check so the .* filter
+  is only evaluated when the parent context is known to be non-null. Use
+  github.event_name to gate the condition, or split the if: into separate
+  trigger-specific jobs.
+fix_code:
+  - language: yaml
+    label: "Guard with event type check"
+    code: |
+      # BAD: fails on push events because pull_request context is null
+      # if: contains(github.event.pull_request.labels.*.name, 'skip-ci')
+
+      # GOOD: gate on event type first
+      - name: Check for skip-ci label
+        if: >
+          github.event_name == 'pull_request' &&
+          contains(github.event.pull_request.labels.*.name, 'skip-ci')
+        run: echo "skip-ci label found, skipping build"
+
+  - language: yaml
+    label: "Use separate jobs per event trigger"
+    code: |
+      on:
+        push:
+          branches: [main]
+        pull_request:
+
+      jobs:
+        # Only runs on pull_request — safe to use pull_request context
+        label-check:
+          if: github.event_name == 'pull_request'
+          runs-on: ubuntu-latest
+          steps:
+            - name: Check labels
+              if: contains(github.event.pull_request.labels.*.name, 'skip-ci')
+              run: echo "Label found"
+
+        # Runs on both push and pull_request — no pull_request context access
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: make build
+prevention:
+  - "Before using github.event.X.*.property, verify the event type with github.event_name == 'X' in the same if: expression."
+  - "In multi-trigger workflows (on: push, pull_request), never access pull_request context properties without an event type guard."
+  - "Use actionlint to catch null context dereferences statically before they fail in CI."
+  - "When checking PR labels in workflows triggered by both push and pull_request, consider splitting into separate per-event jobs."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#object-filters"
+    label: "GitHub Docs — Object filters in expressions"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/contexts#github-context"
+    label: "GitHub Docs — github context availability by event"
+  - url: "https://github.com/rhysd/actionlint"
+    label: "actionlint — Static checker for GitHub Actions workflow files"
+  - url: "https://stackoverflow.com/questions/67368005"
+    label: "SO#67368005 — Object filter left operand must be of type Array or Object but is Null"

package/errors/yaml-syntax/yaml-syntax-062.yml

@@ -0,0 +1,101 @@
+id: yaml-syntax-062
+title: "if: always() Runs Even on Manual Workflow Cancellation — Use if: !cancelled() for Cleanup Jobs"
+category: yaml-syntax
+severity: silent-failure
+tags:
+  - if-condition
+  - always
+  - cancelled
+  - status-functions
+  - cleanup-job
+patterns:
+  - regex: 'if:\s*always\(\)'
+    flags: "i"
+  - regex: 'always\(\).*cleanup\|cleanup.*always\(\)'
+    flags: "i"
+error_messages:
+  - "# No error — cleanup job unexpectedly runs after manual workflow cancellation"
+  - "# Job marked 'Cancelled' in UI but cleanup/notify step still executed"
+root_cause: |
+  The `always()` status check function evaluates to `true` in ALL job states:
+  `success`, `failure`, `cancelled`, and `skipped`. This is intentional and
+  documented, but the implication for cleanup/notification jobs surprises many
+  developers.
+
+  When a workflow is manually cancelled (via the GitHub UI, API, or CLI), all
+  running and queued jobs receive a `cancelled` status. Jobs with
+  `if: always()` will still execute because `always()` explicitly includes the
+  `cancelled` state.
+
+  The common intent is "always run this cleanup step even if the build failed"
+  — but the actual effect includes "run even when an operator stops the workflow
+  mid-run." This can cause cleanup jobs to run unexpectedly, send spurious
+  notifications, or consume runner minutes after an intentional cancellation.
+
+  Status function reference:
+    - `success()`    — true only when job status is success (default when no if:)
+    - `failure()`    — true only when job status is failure
+    - `cancelled()`  — true only when workflow was manually cancelled
+    - `always()`     — true for success, failure, cancelled, AND skipped
+    - `!cancelled()` — true for success and failure; skips on cancelled/skipped
+
+  `if: always()` and `if: !cancelled()` are NOT equivalent — the difference
+  becomes apparent only when workflows are manually cancelled.
+fix: |
+  For cleanup and notification jobs that should respect manual cancellation,
+  use `if: !cancelled()` instead of `if: always()`.
+
+  Reserve `if: always()` for jobs that genuinely must run in every state,
+  including intentional cancellations (rare).
+fix_code:
+  - language: yaml
+    label: "Use !cancelled() for cleanup jobs that should respect manual cancellation"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - run: make build
+
+        notify:
+          runs-on: ubuntu-latest
+          needs: build
+          # Bad: always() runs even when workflow is manually cancelled
+          # if: ${{ always() }}
+
+          # Good: !cancelled() runs on success and failure, skips on cancellation
+          if: ${{ !cancelled() }}
+          steps:
+            - name: Send Slack notification
+              run: echo "Build result: ${{ needs.build.result }}"
+  - language: yaml
+    label: "Status function comparison"
+    code: |
+      jobs:
+        # Runs only on success (implicit default — no if: needed)
+        deploy:
+          if: ${{ success() }}
+
+        # Runs on success or failure — skips on manual cancellation
+        notify:
+          if: ${{ !cancelled() }}
+
+        # Runs in every state including manual cancellation (use sparingly)
+        audit-log:
+          if: ${{ always() }}
+
+        # Runs only when the workflow was manually cancelled
+        on-cancel:
+          if: ${{ cancelled() }}
+prevention:
+  - "Use if: !cancelled() for cleanup and notification jobs to respect manual workflow cancellation."
+  - "Reserve if: always() for jobs that must run even when an operator intentionally stops the workflow."
+  - "When combining status functions with needs: checks, use needs.X.result == 'failure' for explicit conditions."
+  - "Run actionlint to detect common if: expression issues before pushing."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#status-check-functions"
+    label: "GitHub Docs — Status check functions"
+  - url: "https://github.com/rhysd/actionlint/blob/main/docs/checks.md"
+    label: "actionlint — Expression checks"
+  - url: "https://stackoverflow.com/questions/58457140"
+    label: "SO#58457140 — Difference between if: always() and if: !cancelled()"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@htekdev/actions-debugger",
-  "version": "1.0.95",
+  "version": "1.0.97",
   "description": "65+ real GitHub Actions errors, queryable by agents. CLI + MCP server + Copilot skills + error database.",
   "type": "module",
   "main": "./dist/index.js",