@htekdev/actions-debugger 1.0.68 → 1.0.70

package/errors/known-unsolved/composite-action-no-pre-post-lifecycle-hooks.yml

@@ -0,0 +1,94 @@
+id: known-unsolved-043
+title: 'Composite actions do not support pre: and post: lifecycle hooks — no guaranteed setup or cleanup code'
+category: known-unsolved
+severity: limitation
+tags:
+  - composite-action
+  - pre-step
+  - post-step
+  - cleanup
+  - lifecycle
+patterns:
+  - regex: 'Unexpected value ''pre'''
+    flags: 'i'
+  - regex: 'Unexpected value ''post'''
+    flags: 'i'
+error_messages:
+  - "Unexpected value 'pre'"
+  - "Unexpected value 'post'"
+  - 'pre: and post: are only supported in JavaScript and Docker container actions'
+root_cause: |
+  GitHub Actions supports pre: and post: lifecycle hooks in JavaScript actions (using: node20/node24)
+  and Docker container actions (using: docker). These hooks run before and after the main action
+  step respectively, and the post: hook runs even when the workflow is cancelled or fails —
+  making them ideal for guaranteed resource cleanup.
+
+  Composite actions (using: composite) do NOT support pre: or post: hooks. Attempting to add
+  pre: or post: to an action.yml with using: composite causes a validation error. This means
+  shell-based or Python-based composite actions cannot register guaranteed cleanup code that
+  runs after the job, regardless of success, failure, or cancellation.
+
+  Common affected patterns:
+  - Database seeding in setup steps that must be torn down in post:
+  - Port forwarding or tunnel setup that must be closed after the job
+  - Temporary credential setup that must be revoked after the workflow
+  - Cloud resource creation that must be deleted to avoid cost leaks
+fix: |
+  There is no direct fix — this is a known GitHub Actions platform limitation. Common workarounds:
+
+  Option A: Add explicit cleanup steps in calling workflows using if: always().
+  Option B: Wrap the composite logic in a thin JavaScript action that shells out to scripts,
+  enabling pre:/post: hook support.
+  Option C: Use a separate cleanup job with needs: [main-job] and if: always() for teardown.
+  Note: Option C adds latency and does not run on runner process kill.
+fix_code:
+  - language: yaml
+    label: 'Workaround: use if: always() cleanup step in the calling workflow'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Setup composite action
+              uses: ./.github/actions/my-composite-action
+
+            - name: Run build
+              run: make build
+
+            # Cleanup runs even if previous steps fail or are cancelled
+            - name: Cleanup resources
+              if: always()
+              run: |
+                echo "Cleaning up resources created by composite action..."
+                # teardown commands here
+
+  - language: yaml
+    label: 'Workaround: separate cleanup job guaranteed to run after main job'
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: ./.github/actions/my-composite-action
+            - run: make build
+
+        cleanup:
+          runs-on: ubuntu-latest
+          needs: [build]
+          # Runs even when the build job fails or is cancelled
+          if: always()
+          steps:
+            - name: Teardown
+              run: |
+                echo "Running post-job cleanup..."
+prevention:
+  - "Design composite actions to be stateless and idempotent when possible — avoid side effects that require guaranteed cleanup"
+  - "Document in the composite action README that callers must add if: always() cleanup steps"
+  - "For actions that require guaranteed pre:/post: lifecycle hooks, consider wrapping in a JavaScript action"
+docs:
+  - url: 'https://github.com/actions/runner/issues/1478'
+    label: 'actions/runner#1478 — Support pre and post steps in Composite Actions (393 reactions)'
+  - url: 'https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-actions'
+    label: 'Metadata syntax for composite actions — GitHub Docs'
+  - url: 'https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspre'
+    label: 'pre: lifecycle hook — JavaScript and Docker actions only'

package/errors/permissions-auth/create-github-app-token-expires-one-hour.yml

@@ -0,0 +1,124 @@
+id: permissions-auth-046
+title: 'actions/create-github-app-token output token expires after 1 hour — long-running jobs hit 401 Unauthorized'
+category: permissions-auth
+severity: error
+tags:
+  - github-app
+  - installation-token
+  - token-expiry
+  - create-github-app-token
+  - long-running-jobs
+patterns:
+  - regex: '401 Unauthorized'
+    flags: 'i'
+  - regex: 'Bad credentials'
+    flags: 'i'
+  - regex: 'installation.*token.*expired'
+    flags: 'i'
+  - regex: 'HttpError: Bad credentials'
+    flags: 'i'
+error_messages:
+  - '401 Unauthorized'
+  - 'Bad credentials'
+  - 'HttpError: Bad credentials'
+  - 'Installation tokens expire one hour from the time you create them'
+root_cause: |
+  GitHub App installation tokens — generated by actions/create-github-app-token — have a fixed
+  1-hour expiry enforced by the GitHub platform. The token is generated once at the step where
+  the action runs, stored as a step output, and typically exported to an env var. If subsequent
+  steps take longer than 60 minutes to reach the point where the token is used, all GitHub API
+  calls and authenticated git operations will return 401 Unauthorized or "Bad credentials".
+
+  From GitHub's REST API docs:
+  "Installation tokens expire one hour from the time you create them. Using an expired token
+  produces a status code of 401 - Unauthorized, and requires creating a new installation token."
+
+  Common affected patterns:
+  - Long test suites (>60 min) where a GitHub App token is generated upfront for a final
+    PR comment or status check post at the end.
+  - Build pipelines that generate an app token for private package registry authentication
+    at the start, then run a multi-hour compilation and upload step at the end.
+  - Self-hosted runners on slow networks where upload + deploy sequences exceed 60 minutes.
+  - Jobs that poll or sleep mid-run (e.g., waiting for an external deployment to stabilize).
+
+  Important: The built-in GITHUB_TOKEN is NOT subject to this expiry — it remains valid for
+  the entire job duration (up to the job's timeout-minutes). Only tokens from
+  actions/create-github-app-token or direct GitHub App JWT exchanges expire after 1 hour.
+fix: |
+  Generate a fresh GitHub App token immediately before the step that needs it rather than
+  once at the beginning of the job. For jobs that have multiple distinct phases requiring
+  the token, generate a separate token for each phase. Alternatively, split long-running
+  work into shorter jobs — each job generates its own fresh token on startup.
+fix_code:
+  - language: yaml
+    label: 'Generate token immediately before the step that needs it (not at job start)'
+    code: |
+      jobs:
+        long-build:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Checkout
+              uses: actions/checkout@v4
+
+            - name: Run long test suite
+              # This may run for over an hour
+              run: make test
+
+            # Generate a fresh token just before the API call — never stale
+            - name: Generate GitHub App token
+              id: app-token
+              uses: actions/create-github-app-token@v2
+              with:
+                app-id: ${{ vars.APP_ID }}
+                private-key: ${{ secrets.APP_PRIVATE_KEY }}
+
+            - name: Post PR comment
+              env:
+                GH_TOKEN: ${{ steps.app-token.outputs.token }}
+              run: |
+                gh pr comment ${{ github.event.pull_request.number }} \
+                  --body "Tests completed successfully"
+
+  - language: yaml
+    label: 'Split into sub-jobs so each job generates its own short-lived token'
+    code: |
+      jobs:
+        long-tests:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: make test
+
+        notify:
+          runs-on: ubuntu-latest
+          needs: [long-tests]
+          steps:
+            # Each job generates a token on startup — always fresh
+            - name: Generate GitHub App token
+              id: app-token
+              uses: actions/create-github-app-token@v2
+              with:
+                app-id: ${{ vars.APP_ID }}
+                private-key: ${{ secrets.APP_PRIVATE_KEY }}
+
+            - name: Post PR comment
+              env:
+                GH_TOKEN: ${{ steps.app-token.outputs.token }}
+              run: |
+                gh pr comment ${{ github.event.pull_request.number }} \
+                  --body "Tests completed successfully"
+prevention:
+  - "Never store a GitHub App installation token at job start assuming it stays valid — generate it immediately before use"
+  - "For jobs expected to run longer than 45 minutes, split into sub-jobs so each generates its own fresh token"
+  - "Prefer the built-in GITHUB_TOKEN for operations within the same repository — it is valid for the entire job duration"
+  - "Set job-level timeout-minutes to catch unexpectedly long jobs and keep total runtime well under the 1-hour token expiry"
+  - "The actions/create-github-app-token README prominently warns: 'An installation access token expires after 1 hour'"
+docs:
+  - url: 'https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app'
+    label: 'Generating an installation access token — expires after 1 hour (GitHub Docs)'
+  - url: 'https://github.com/actions/create-github-app-token'
+    label: 'actions/create-github-app-token — README warning about 1-hour expiry'
+  - url: 'https://github.com/actions/create-github-app-token/issues/128'
+    label: 'actions/create-github-app-token#128 — token only lasts 1 hour, long-running jobs fail'
+  - url: 'https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication'
+    label: 'GITHUB_TOKEN automatic token authentication — valid for entire job duration'

package/errors/runner-environment/docker-build-push-provenance-default-manifest-index.yml

@@ -0,0 +1,81 @@
+id: runner-environment-130
+title: 'docker/build-push-action default provenance: true pushes OCI image index for single-platform builds — breaks registries that do not support image indexes'
+category: runner-environment
+severity: silent-failure
+tags:
+  - docker
+  - build-push-action
+  - provenance
+  - oci
+  - manifest-index
+patterns:
+  - regex: 'manifest unknown'
+    flags: 'i'
+  - regex: 'unexpected status: \d{3}'
+    flags: 'i'
+error_messages:
+  - 'manifest unknown'
+  - 'unexpected status: 400'
+  - 'unexpected status: 403'
+root_cause: |
+  Starting with docker/build-push-action v4, the provenance input defaults to mode=min,
+  which attaches an SLSA provenance attestation to every pushed image. This causes the action
+  to push an OCI image index (manifest list) to the registry instead of a plain image manifest,
+  even for single-platform builds.
+
+  Registries and tools that do not support OCI image indexes may return "manifest unknown"
+  errors, return 400/403 HTTP responses, or silently resolve to an unexpected image variant.
+  Some container registries (such as older versions of GCR) display the provenance attestation
+  as a separate image entry with a creation timestamp of 0 epoch (Unix epoch), causing
+  confusion in image management dashboards.
+
+  The behavior is silent in successful-looking cases: the push completes without error, but
+  downstream 'docker pull' or 'FROM image:tag' in a Dockerfile may resolve the image index
+  instead of a plain image manifest, causing unexpected platform or size differences.
+fix: |
+  Set provenance: false in docker/build-push-action to restore plain image manifest behavior
+  for single-platform builds. If SLSA provenance is required, use actions/attest-build-provenance
+  as a separate step after the push.
+fix_code:
+  - language: yaml
+    label: 'Disable provenance to push plain image manifest for single-platform builds'
+    code: |
+      - name: Build and push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
+          # Disable default provenance attestation to push a plain image manifest.
+          # Required for registries that do not support OCI image indexes.
+          provenance: false
+
+  - language: yaml
+    label: 'Add SLSA provenance separately using actions/attest-build-provenance'
+    code: |
+      - name: Build and push
+        id: push
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          push: true
+          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
+          provenance: false
+
+      - name: Attest build provenance
+        uses: actions/attest-build-provenance@v2
+        with:
+          subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
+          subject-digest: ${{ steps.push.outputs.digest }}
+          push-to-registry: true
+prevention:
+  - "Set 'provenance: false' in docker/build-push-action unless your target registry explicitly supports OCI image indexes"
+  - "Test image pulling from the registry after pushing to confirm the correct manifest type was stored"
+  - "Use 'docker manifest inspect' to verify the pushed image is a plain manifest and not a manifest index when provenance is enabled"
+docs:
+  - url: 'https://github.com/docker/build-push-action/issues/755'
+    label: 'docker/build-push-action#755 — Action started to push manifest indexes instead of images for a single platform'
+  - url: 'https://docs.docker.com/build/ci/github-actions/attestations/'
+    label: 'Docker build attestations with GitHub Actions'
+  - url: 'https://docs.docker.com/reference/cli/docker/buildx/build/#provenance'
+    label: 'docker buildx build --provenance flag documentation'

package/errors/runner-environment/setup-node-yarn-packagemanager-corepack-conflict.yml

@@ -0,0 +1,71 @@
+id: runner-environment-129
+title: 'setup-node cache: yarn fails when packageManager specifies Yarn 4 in package.json — Corepack version mismatch'
+category: runner-environment
+severity: error
+tags:
+  - setup-node
+  - yarn
+  - corepack
+  - packageManager
+  - package-json
+patterns:
+  - regex: 'Presence of the "packageManager" field indicates that the project is meant to be used with Corepack'
+    flags: 'i'
+  - regex: 'the current global version of Yarn is \d+\.\d+'
+    flags: 'i'
+error_messages:
+  - 'This project''s package.json defines "packageManager": "yarn@4.x.x". However the current global version of Yarn is 1.22.22.'
+  - 'Presence of the "packageManager" field indicates that the project is meant to be used with Corepack'
+root_cause: |
+  When package.json contains a "packageManager" field specifying Yarn 4 (e.g., "yarn@4.1.1"),
+  Yarn's integrity check detects the field and requires the project to be managed via Corepack.
+  The system Yarn installed on GitHub-hosted runners is Yarn Classic (1.x), which responds to
+  the "packageManager" constraint by throwing an error if Corepack is not enabled.
+
+  When actions/setup-node is configured with cache: 'yarn', it detects the "packageManager"
+  field, attempts to use the specified Yarn version via Corepack, but Corepack is not enabled
+  by default on GitHub-hosted runners. The resulting error prevents setup-node from completing
+  and fails the job before any build steps run.
+
+  This affects workflows being upgraded from Yarn Classic to Yarn 4 (Berry) via the
+  "packageManager" field in package.json, or projects that adopted the "packageManager"
+  field for strict version pinning.
+fix: |
+  Enable Corepack before running setup-node. Two options depending on your setup-node version:
+
+  Option A: Add a 'corepack enable' run step before setup-node (works with all versions).
+  Option B: Use 'enable-node-corepack: true' input (requires setup-node v4.2+).
+  Option C: Remove 'packageManager' from package.json and manage Yarn version via .yarnrc.yml only.
+fix_code:
+  - language: yaml
+    label: 'Enable Corepack before setup-node (Yarn 4 / Berry projects)'
+    code: |
+      - name: Enable Corepack
+        run: corepack enable
+
+      - name: Set up Node.js with Yarn cache
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'yarn'
+
+  - language: yaml
+    label: 'Alternative: enable-node-corepack input (setup-node v4.2+)'
+    code: |
+      - name: Set up Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+          cache: 'yarn'
+          enable-node-corepack: true
+prevention:
+  - "Always run 'corepack enable' before setup-node when package.json has a 'packageManager' field specifying Yarn 4+"
+  - "Verify Corepack is enabled before relying on setup-node's yarn cache integration in Yarn Berry projects"
+  - "Pin the Yarn version in .yarnrc.yml in addition to the packageManager field to ensure consistent resolution"
+docs:
+  - url: 'https://github.com/actions/setup-node/issues/1027'
+    label: 'actions/setup-node#1027 — If cache: yarn is specified, this action fails (38 reactions)'
+  - url: 'https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#corepack'
+    label: 'setup-node advanced usage — Corepack support'
+  - url: 'https://yarnpkg.com/getting-started/install'
+    label: 'Yarn Berry — Installation via Corepack'

package/errors/silent-failures/steps-conclusion-always-success-with-continue-on-error.yml

@@ -0,0 +1,90 @@
+id: silent-failures-068
+title: 'steps.<id>.conclusion is always success when continue-on-error: true — using conclusion to detect step failure never triggers'
+category: silent-failures
+severity: silent-failure
+tags:
+  - continue-on-error
+  - steps-context
+  - outcome
+  - conclusion
+  - if-condition
+  - step-failure
+patterns:
+  - regex: 'steps\.\w+\.conclusion\s*==\s*[''"]failure[''"]'
+    flags: 'i'
+  - regex: 'continue-on-error.*true'
+    flags: 'i'
+error_messages:
+  - 'steps.<id>.conclusion == ''failure'' never evaluates to true'
+  - 'cleanup step silently skipped despite step failure'
+root_cause: |
+  GitHub Actions provides two properties on the `steps` context for inspecting a completed step:
+
+  - `steps.<id>.outcome` — the raw result BEFORE `continue-on-error` is applied. Values:
+    `success`, `failure`, `cancelled`, `skipped`.
+  - `steps.<id>.conclusion` — the final result AFTER `continue-on-error` is applied. When
+    `continue-on-error: true` and the step fails, `conclusion` is `success` (not `failure`).
+
+  When a step has `continue-on-error: true` set, a step failure does NOT propagate to
+  `conclusion`. Developers who write:
+
+    if: steps.my-step.conclusion == 'failure'
+
+  expecting to detect when `my-step` failed will find that this condition is NEVER true — even
+  when the step actually failed — because `continue-on-error` overwrites the conclusion to
+  `success`. The downstream step silently never runs.
+
+  This commonly affects:
+  - Cleanup steps that should run when a flaky test step fails (continue-on-error: true)
+  - Notification steps that should alert on specific step failures in a pipeline
+  - Conditional logic that differentiates between "step was skipped" and "step failed"
+fix: |
+  Use `steps.<id>.outcome` (not `conclusion`) to detect the raw result of a step that has
+  `continue-on-error: true`. The `outcome` property reflects the actual step result before
+  the error suppression is applied and correctly returns `failure` even when the final
+  conclusion is `success`.
+fix_code:
+  - language: yaml
+    label: 'WRONG: conclusion is always success when continue-on-error is true — cleanup never runs'
+    code: |
+      steps:
+        - name: Run flaky tests
+          id: tests
+          continue-on-error: true
+          run: pytest tests/
+
+        - name: Send failure notification
+          # NEVER RUNS — conclusion is 'success' even when tests fail
+          if: steps.tests.conclusion == 'failure'
+          run: echo "Tests failed — notifying team"
+
+  - language: yaml
+    label: 'CORRECT: use outcome to detect the raw step result before continue-on-error'
+    code: |
+      steps:
+        - name: Run flaky tests
+          id: tests
+          continue-on-error: true
+          run: pytest tests/
+
+        - name: Send failure notification
+          # CORRECT — outcome reflects the raw result before continue-on-error override
+          if: steps.tests.outcome == 'failure'
+          run: echo "Tests failed — notifying team"
+
+        - name: Always-run cleanup
+          # For cleanup that must run regardless, use always() + outcome check
+          if: always() && steps.tests.outcome != 'success'
+          run: echo "Running cleanup after non-success outcome"
+prevention:
+  - "When a step has continue-on-error: true, always use steps.<id>.outcome (not conclusion) to detect failures in downstream if conditions"
+  - "steps.<id>.conclusion == 'success' is always true when continue-on-error: true — it is safe for 'did this step not skip?' checks only"
+  - "The failure() status function is also bypassed by continue-on-error — use steps.<id>.outcome != 'success' instead"
+  - "Review GitHub Docs context reference table to understand outcome vs conclusion semantics before writing conditional cleanup steps"
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#steps-context'
+    label: 'steps context — outcome vs conclusion properties with continue-on-error (GitHub Docs)'
+  - url: 'https://github.com/actions/runner/blob/main/docs/adrs/0274-step-outcome-and-conclusion.md'
+    label: 'actions/runner ADR: outcome vs conclusion design — why two separate properties exist'
+  - url: 'https://stackoverflow.com/questions/71433926/how-do-to-run-the-next-github-action-step-even-if-the-previous-step-failed-whil'
+    label: 'Stack Overflow: using steps.outcome vs steps.conclusion with continue-on-error'

package/errors/triggers/release-published-fires-on-prerelease-creation-and-promotion.yml

@@ -0,0 +1,106 @@
+id: triggers-049
+title: 'on.release types: [published] fires for pre-release creation AND pre-release-to-full promotion — deploy workflows run twice'
+category: triggers
+severity: silent-failure
+tags:
+  - release
+  - published
+  - prerelease
+  - on-release
+  - double-trigger
+  - deploy
+patterns:
+  - regex: 'github\.event\.action.*prereleased'
+    flags: 'i'
+  - regex: 'github\.event\.release\.prerelease.*true'
+    flags: 'i'
+error_messages:
+  - 'github.event.action: prereleased'
+  - 'github.event.action: released'
+  - 'github.event.release.prerelease: true'
+root_cause: |
+  The GitHub `release` event supports multiple activity types: `created`, `published`,
+  `prereleased`, `released`, `edited`, `deleted`, and `unpublished`. The `published` type
+  is frequently misunderstood:
+
+  - `published` fires whenever ANY release is made public — this includes both pre-releases
+    (action=prereleased) and full releases (action=released). It is a superset, not a
+    specific activity type for "final" releases.
+
+  A typical release lifecycle that triggers `on.release.types: [published]` twice:
+  1. Developer creates a pre-release (e.g., v1.2.0-rc.1) and clicks "Publish release"
+     → workflow fires (github.event.action=prereleased, github.event.release.prerelease=true)
+  2. Developer edits the release and unchecks "Set as a pre-release" to promote it to a
+     full release → workflow fires again (github.event.action=released, github.event.release.prerelease=false)
+
+  Additionally, the GitHub docs note that `prereleased` does NOT fire for pre-releases
+  published from a draft release, but `published` DOES fire — creating another asymmetry.
+
+  Workflows using `on.release.types: [published]` for deployment, package publishing,
+  or Docker image tagging will run twice for the same version tag, potentially creating
+  duplicate deployments, duplicate npm/PyPI publishes, or conflicting artifact versions.
+fix: |
+  For production deploy workflows that should only run on final (non-pre-release) releases,
+  add an `if:` condition to check `github.event.release.prerelease == false`. Alternatively,
+  use `types: [released]` — which fires only when a stable release is published directly
+  or when a pre-release is promoted to full release, but NOT on initial pre-release creation.
+
+  To target pre-releases explicitly, use `types: [prereleased]`, but note it does not fire
+  for pre-releases published from drafts (use `published` + `if: github.event.release.prerelease == true`
+  in that case).
+fix_code:
+  - language: yaml
+    label: 'Guard with if condition to skip pre-release publishes'
+    code: |
+      on:
+        release:
+          types: [published]
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          # Only deploy for final (non-pre-release) releases
+          if: github.event.release.prerelease == false
+          steps:
+            - name: Deploy release
+              run: echo "Deploying ${{ github.event.release.tag_name }}"
+
+  - language: yaml
+    label: 'Use released type to target only final releases (not pre-release creation)'
+    code: |
+      on:
+        release:
+          # released: fires when a release is published as final, OR when a pre-release
+          # is promoted to a full release. Does NOT fire on initial pre-release creation.
+          types: [released]
+
+      jobs:
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Deploy release
+              run: echo "Deploying ${{ github.event.release.tag_name }}"
+
+  - language: yaml
+    label: 'Log release event fields at the start of release workflows for debugging'
+    code: |
+      jobs:
+        release-info:
+          runs-on: ubuntu-latest
+          steps:
+            - name: Debug release event
+              run: |
+                echo "action: ${{ github.event.action }}"
+                echo "prerelease: ${{ github.event.release.prerelease }}"
+                echo "tag: ${{ github.event.release.tag_name }}"
+                echo "draft: ${{ github.event.release.draft }}"
+prevention:
+  - "Prefer types: [released] over types: [published] for production deployment workflows"
+  - "Always guard release deploy steps with: if: github.event.release.prerelease == false"
+  - "Make deployment and publish workflows idempotent so accidental double-runs cannot cause irreversible side effects"
+  - "Log github.event.action and github.event.release.prerelease at workflow start when debugging unexpected runs"
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#release'
+    label: 'release event activity types — published fires for both prereleased and released (GitHub Docs)'
+  - url: 'https://stackoverflow.com/questions/78085080/how-to-limit-a-github-action-to-fire-only-once-on-a-release-trigger'
+    label: 'Stack Overflow: release action triggered 3 times for pre-release — limit using types and if conditions'

package/errors/triggers/schedule-workflow-disabled-on-fork.yml

@@ -0,0 +1,69 @@
+id: triggers-048
+title: 'Scheduled workflows silently disabled on forked repositories — on.schedule never fires until manually re-enabled in Settings'
+category: triggers
+severity: silent-failure
+tags:
+  - schedule
+  - fork
+  - workflow-disabled
+  - cron
+  - repository-settings
+patterns:
+  - regex: 'Scheduled workflows are disabled for this repository'
+    flags: 'i'
+  - regex: 'This workflow is disabled'
+    flags: 'i'
+error_messages:
+  - 'Scheduled workflows are disabled for this repository'
+  - 'This workflow is disabled'
+root_cause: |
+  When a repository containing scheduled workflows is forked, GitHub automatically disables
+  all workflow triggers in the fork. This prevents scheduled CI runs from unexpectedly
+  consuming GitHub Actions minutes from the fork owner's account and avoids unintended
+  side effects from cloned automation.
+
+  Scheduled workflows (on.schedule:) stop firing entirely on the fork, even if the workflow
+  YAML is correct and the branch is up to date. The workflow appears in the Actions tab and
+  can be triggered manually via workflow_dispatch, but on.schedule: events are suppressed.
+
+  This commonly affects:
+  - Contributors forking repos to test or contribute scheduled jobs (e.g., nightly builds,
+    dependency updates, scheduled reports)
+  - Organizations using forks as part of their branching or release strategy and expecting
+    scheduled maintenance tasks to continue
+  - CI setups where scheduled smoke tests or integration tests are part of the fork workflow
+
+  The only indicator is the workflow showing as "disabled" in the Actions tab or in the
+  workflow run history, which is easy to miss.
+fix: |
+  Navigate to the fork repository and enable workflows manually:
+  Settings (fork repo) -> Actions -> General -> Allow all actions and reusable workflows.
+  Then enable the specific workflow in the Actions tab by clicking "Enable workflow".
+  There is no workflow-level or API-level way to force-enable schedules on a fork automatically.
+fix_code:
+  - language: yaml
+    label: 'Add workflow_dispatch fallback so contributors can trigger manually on forks'
+    code: |
+      on:
+        # Note: scheduled runs are DISABLED on forked repositories by default.
+        # Contributors must enable workflows in Settings -> Actions -> General.
+        schedule:
+          - cron: '0 2 * * *'
+
+        # Add workflow_dispatch as a fallback for manual triggering on forks
+        workflow_dispatch:
+          inputs:
+            reason:
+              description: 'Reason for manual run (required when testing on a fork)'
+              required: false
+              default: 'manual trigger'
+
+prevention:
+  - "Document in CONTRIBUTING.md that scheduled workflows must be manually enabled on forks via Settings -> Actions -> General"
+  - "Add workflow_dispatch to all scheduled workflows so contributors can manually trigger them on forks during development"
+  - "Use repository_dispatch or workflow_run from the upstream repo to trigger downstream automation instead of relying on fork schedules"
+docs:
+  - url: 'https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/disabling-and-enabling-a-workflow'
+    label: 'Disabling and enabling a workflow — GitHub Docs'
+  - url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule'
+    label: 'schedule event — GitHub Docs'

package/errors/yaml-syntax/paths-and-paths-ignore-combined-on-same-event.yml

@@ -0,0 +1,97 @@
+id: yaml-syntax-045
+title: 'Using paths and paths-ignore together on the same event trigger causes a workflow validation error'
+category: yaml-syntax
+severity: error
+tags:
+  - paths
+  - paths-ignore
+  - trigger-filter
+  - on-push
+  - validation-error
+patterns:
+  - regex: "You can't use both 'paths' and 'paths-ignore'"
+    flags: 'i'
+  - regex: 'Invalid workflow file.*paths.*paths-ignore'
+    flags: 'i'
+  - regex: 'paths.*and.*paths-ignore.*cannot.*same event'
+    flags: 'i'
+error_messages:
+  - "Invalid workflow file: You can't use both 'paths' and 'paths-ignore' for the same event trigger"
+  - "You can't use both 'paths' and 'paths-ignore' for the same event trigger"
+  - "Path and Path-ignore cannot be added in the same event"
+root_cause: |
+  GitHub Actions enforces a mutual exclusivity rule: `paths` and `paths-ignore` cannot be
+  specified simultaneously for the same event trigger. The same rule applies to:
+  - `branches` and `branches-ignore`
+  - `tags` and `tags-ignore`
+
+  `paths` is an allowlist — the trigger only fires when at least one of the listed patterns
+  matches a changed file. `paths-ignore` is a denylist — the trigger is suppressed when ALL
+  changed files match patterns in the list. Because their semantics are complementary, GitHub
+  disallows combining them to avoid ambiguous filter behavior.
+
+  Attempting to use both results in a validation error at workflow parse time:
+  "Invalid workflow file: You can't use both 'paths' and 'paths-ignore' for the same event trigger"
+
+  Developers commonly hit this when they want to trigger on a specific directory but exclude
+  documentation or test-only changes within that directory, assuming both filters can be
+  stacked like CSS selectors.
+
+  Example of the problematic pattern:
+    on:
+      push:
+        paths:
+          - 'src/**'
+        paths-ignore:          # INVALID: cannot combine with paths
+          - 'src/**/*.md'
+fix: |
+  Use only one of `paths` or `paths-ignore`. To achieve both include and exclude behavior
+  within a single filter:
+  - Use the `paths` filter with `!` negation patterns to explicitly exclude paths from an
+    allowlist. List all positive patterns before negative patterns — order matters.
+  - Alternatively, use `paths-ignore` alone if you just need to exclude a small set of paths
+    and want the workflow to run for everything else.
+fix_code:
+  - language: yaml
+    label: 'WRONG: paths and paths-ignore combined (validation error)'
+    code: |
+      # This is INVALID — causes "You can't use both" validation error
+      on:
+        push:
+          paths:
+            - 'src/**'
+          paths-ignore:
+            - 'src/**/*.md'
+
+  - language: yaml
+    label: 'CORRECT: use paths with negation pattern to exclude within an allowlist'
+    code: |
+      # Use ! negation in paths to exclude specific sub-paths from the allowlist
+      on:
+        push:
+          paths:
+            - 'src/**'          # include all changes under src/
+            - '!src/**/*.md'    # but exclude markdown files within src/
+
+  - language: yaml
+    label: 'CORRECT: use only paths-ignore to suppress trigger for specific paths'
+    code: |
+      # If the workflow should run for everything EXCEPT docs, use paths-ignore alone
+      on:
+        push:
+          paths-ignore:
+            - 'docs/**'
+            - '**/*.md'
+            - '**/*.txt'
+prevention:
+  - "Never combine paths with paths-ignore (or branches/branches-ignore, or tags/tags-ignore) for the same event"
+  - "To include a directory but exclude sub-paths: use paths with ! negation entries"
+  - "Use actionlint to validate workflow YAML locally before pushing — it catches this misconfiguration"
+  - "The same mutual exclusivity rule applies to branches/branches-ignore and tags/tags-ignore"
+docs:
+  - url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpaths'
+    label: 'on.push.paths — cannot be used with paths-ignore for the same event (GitHub Docs)'
+  - url: 'https://stackoverflow.com/questions/64896276/github-action-trigger-pipeline-for-root-folder-except-one-sub-folder'
+    label: 'Stack Overflow: "Path and Path-ignore cannot be added in the same event" — use ! negation in paths instead'
+  - url: 'https://github.com/rhysd/actionlint'
+    label: 'actionlint — static checker for GitHub Actions workflow files'

package/package.json

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