@htekdev/actions-debugger 1.0.0 → 1.0.1

package/errors/silent-failures/composite-boolean-inputs-as-strings.yml

@@ -0,0 +1,110 @@
+id: silent-failures-004
+title: "Composite Action Boolean Inputs Treated as Strings — Conditions Always True or Always False"
+category: silent-failures
+severity: silent-failure
+tags:
+  - composite-actions
+  - boolean
+  - inputs
+  - string-coercion
+  - if-condition
+patterns:
+  - regex: "if:\\s*\\$\\{\\{\\s*inputs\\.[a-zA-Z_-]+\\s*\\}\\}"
+    flags: "i"
+  - regex: "inputs\\.[a-zA-Z_-]+\\s*==\\s*true(?!')"
+    flags: "i"
+error_messages:
+  - "realRun==false"
+  - "Step was skipped because it is conditional"
+root_cause: |
+  Composite actions store all inputs internally as strings regardless of the `type:` field declared in
+  `action.yml`. The `type: boolean` annotation is accepted by the YAML parser but has no runtime effect —
+  all values are coerced to strings before expressions are evaluated.
+
+  This creates two distinct silent failure modes:
+
+  1. `if: ${{ inputs.enabled }}` — the string "false" is truthy in GitHub Actions expression syntax,
+     so the step ALWAYS runs even when the caller explicitly passes `enabled: false`.
+
+  2. `if: ${{ inputs.enabled == true }}` — the string "true" never equals the boolean `true` in
+     expression syntax, so the step NEVER runs regardless of the input value.
+
+  In both cases no error is thrown, no warning is emitted, and the workflow succeeds. Only the
+  observable behavior is wrong (unexpected steps run or expected steps are skipped entirely).
+
+  This also affects composite action outputs: any output whose `value:` expression produces a boolean
+  (e.g., `${{ fromJSON(steps.x.outputs.flag) }}`) is silently coerced back to a string before it
+  leaves the composite action.
+fix: |
+  Always compare composite action boolean inputs using string equality:
+
+  - `if: inputs.enabled == 'true'` ✅
+  - `if: ${{ inputs.enabled == 'true' }}` ✅
+  - `if: ${{ inputs.enabled }}` ❌ (always truthy — string "false" is truthy)
+  - `if: ${{ inputs.enabled == true }}` ❌ (never matches — string never equals boolean)
+
+  When passing a boolean workflow_dispatch input into a composite action, cast it to a string explicitly:
+
+  ```yaml
+  with:
+    enabled: ${{ inputs.enabled == true }}   # evaluates to string 'true' or 'false'
+  ```
+fix_code:
+  - language: yaml
+    label: "Use string comparison for boolean inputs inside composite actions"
+    code: |
+      # action.yml (composite action)
+      inputs:
+        enabled:
+          description: "Enable the feature"
+          required: false
+          default: "false"
+          # Note: type: boolean has no runtime effect in composite actions — default must be a string
+
+      runs:
+        using: composite
+        steps:
+          # ❌ WRONG — string "false" is truthy, step always runs
+          # - name: Feature step
+          #   if: ${{ inputs.enabled }}
+
+          # ❌ WRONG — string "true" != boolean true, step never runs
+          # - name: Feature step
+          #   if: ${{ inputs.enabled == true }}
+
+          # ✅ CORRECT — compare as string
+          - name: Feature step
+            if: inputs.enabled == 'true'
+            shell: bash
+            run: echo "Feature is enabled"
+  - language: yaml
+    label: "Cast boolean workflow_dispatch input before passing to composite action"
+    code: |
+      on:
+        workflow_dispatch:
+          inputs:
+            run-tests:
+              type: boolean
+              default: false
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: ./.github/actions/my-composite
+              with:
+                # Explicitly cast to string — inputs.run-tests is boolean at this scope
+                run-tests: ${{ inputs.run-tests == true }}
+prevention:
+  - "Never rely on `type: boolean` in composite action inputs — it is parsed but not enforced at runtime."
+  - "Use string `'false'` not boolean `false` as default values in composite action input definitions."
+  - "Always compare composite action boolean inputs with `== 'true'` or `== 'false'` string comparison."
+  - "When passing boolean workflow inputs into composite actions, cast with `${{ inputs.flag == true }}`."
+  - "Document the string-only convention in the composite action README to prevent future contributors from introducing the bug."
+docs:
+  - url: "https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#inputs"
+    label: "Metadata syntax — inputs for composite actions"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions"
+    label: "Evaluate expressions in workflows and actions — truthiness rules"
+  - url: "https://github.com/actions/runner/issues/2238"
+    label: "actions/runner#2238 — Boolean inputs not actually booleans in composite actions (112 reactions)"

package/errors/silent-failures/conditional-output-null-downstream.yml

@@ -0,0 +1,82 @@
+id: silent-failures-007
+title: "Step Output Only Written When Condition Passes — Downstream Reads Empty String"
+category: silent-failures
+severity: silent-failure
+tags:
+  - outputs
+  - steps
+  - context
+  - conditionals
+  - GITHUB_OUTPUT
+  - empty-string
+patterns:
+  - regex: "steps\\.[a-z_-]+\\.outputs\\.[a-z_-]+"
+    flags: "i"
+  - regex: "GITHUB_OUTPUT"
+    flags: "i"
+error_messages:
+  - "Warning: Unexpected input(s) '', valid inputs are ['version']"
+root_cause: |
+  A step output written to `$GITHUB_OUTPUT` (or the deprecated `set-output` command)
+  only exists if the step that writes it actually executed **and** reached the `echo`
+  statement. When a step is conditional (`if: github.event_name == 'push'`) and the
+  condition is false, the step is skipped entirely — no output is written.
+
+  Downstream steps that reference `${{ steps.<id>.outputs.<key> }}` receive an empty
+  string rather than an error, making the failure silent. The workflow continues, but
+  subsequent steps silently operate on empty values — potentially deploying with no
+  version tag, pushing an empty config, or skipping critical logic without any warning.
+fix: |
+  Guard against empty outputs in consuming steps, or restructure so outputs are always
+  written unconditionally and logic is controlled by the value itself.
+fix_code:
+  - language: yaml
+    label: "WRONG — output only written on push, silently empty on PR"
+    code: |
+      steps:
+        - name: Compute version
+          id: version
+          if: github.event_name == 'push'
+          run: echo "tag=v$(date +%Y%m%d%H%M%S)" >> $GITHUB_OUTPUT
+
+        - name: Build Docker image
+          run: |
+            # On pull_request, steps.version.outputs.tag is "" — image tagged as ""
+            docker build -t myapp:${{ steps.version.outputs.tag }} .
+  - language: yaml
+    label: "CORRECT — always write output, vary value by condition"
+    code: |
+      steps:
+        - name: Compute version
+          id: version
+          run: |
+            if [ "${{ github.event_name }}" = "push" ]; then
+              echo "tag=v$(date +%Y%m%d%H%M%S)" >> $GITHUB_OUTPUT
+            else
+              echo "tag=dev-${{ github.sha }}" >> $GITHUB_OUTPUT
+            fi
+
+        - name: Build Docker image
+          run: docker build -t myapp:${{ steps.version.outputs.tag }} .
+  - language: yaml
+    label: "CORRECT — guard against empty value in consuming step"
+    code: |
+      steps:
+        - name: Deploy
+          if: steps.version.outputs.tag != ''
+          run: ./deploy.sh ${{ steps.version.outputs.tag }}
+
+        - name: Warn if no version
+          if: steps.version.outputs.tag == ''
+          run: |
+            echo "::warning::No version tag output — skipping deploy"
+            exit 1
+prevention:
+  - "Write a default/fallback value in the output step rather than skipping the entire step."
+  - "Validate critical outputs with `if: steps.<id>.outputs.<key> != ''` before consuming them."
+  - "Use `if: always()` or no condition on steps that must always emit outputs."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs"
+    label: "Passing information between jobs"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-output-parameter"
+    label: "Setting an output parameter"

package/errors/silent-failures/continue-on-error-masks-failure.yml

@@ -0,0 +1,86 @@
+id: silent-failures-005
+title: "continue-on-error: true Masks Step Failures — Job Reports Success"
+category: silent-failures
+severity: silent-failure
+tags:
+  - continue-on-error
+  - failure
+  - masking
+  - job-status
+  - outcome
+patterns:
+  - regex: "continue-on-error"
+    flags: "i"
+  - regex: "steps\\.[a-z_-]+\\.outcome.*failure"
+    flags: "i"
+error_messages:
+  - "##[error]Process completed with exit code 1."
+  - "Error: Process completed with exit code 1."
+root_cause: |
+  When `continue-on-error: true` is set on a step, GitHub Actions marks the step's
+  `outcome` as `failure` but sets `conclusion` to `success` and allows the job to
+  continue. Critically, the **job itself reports success** even if one or more steps
+  failed — the failure is effectively swallowed.
+
+  This is frequently misunderstood: developers use `continue-on-error` to avoid blocking
+  a pipeline on non-critical steps, but they don't realise the overall job will show a
+  green checkmark even when those steps fail. Branch protection rules, required status
+  checks, and downstream `needs` jobs all see a passing job.
+
+  The `outcome` context (`steps.<id>.outcome`) still reports `failure`, but this is only
+  visible if explicitly checked in a later conditional.
+fix: |
+  If you need a step to be non-blocking, check its outcome explicitly in a downstream
+  step and surface the failure in a way that's visible (job summary, annotation, or
+  dedicated reporting step). Do not rely on `continue-on-error` as a silent suppressor.
+fix_code:
+  - language: yaml
+    label: "WRONG — failure silently swallowed, job shows green"
+    code: |
+      steps:
+        - name: Run flaky integration test
+          id: integration
+          continue-on-error: true
+          run: ./run-integration.sh
+
+        - name: Deploy
+          run: ./deploy.sh   # runs even if integration test failed, job still green
+  - language: yaml
+    label: "CORRECT — check outcome and fail loudly if needed"
+    code: |
+      steps:
+        - name: Run integration test
+          id: integration
+          continue-on-error: true
+          run: ./run-integration.sh
+
+        - name: Report integration failure
+          if: steps.integration.outcome == 'failure'
+          run: |
+            echo "::error::Integration test failed — review before shipping"
+            echo "## ⚠️ Integration Test Failed" >> $GITHUB_STEP_SUMMARY
+            exit 1   # fail the job explicitly if the failure matters
+  - language: yaml
+    label: "CORRECT — use outcome in branch protection-aware way"
+    code: |
+      steps:
+        - name: Lint (non-blocking)
+          id: lint
+          continue-on-error: true
+          run: npm run lint
+
+        - name: Annotate lint result
+          if: always()
+          run: |
+            if [ "${{ steps.lint.outcome }}" = "failure" ]; then
+              echo "::warning::Linting failed but is non-blocking for this branch"
+            fi
+prevention:
+  - "Treat `continue-on-error: true` as a visibility-reduction tool — always pair it with explicit outcome checking."
+  - "Add a final step that fails the job if any non-critical steps failed and the failure actually matters."
+  - "Prefer `allowed-failure` patterns at the matrix level for known-unstable configurations."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error"
+    label: "continue-on-error"
+  - url: "https://docs.github.com/en/actions/learn-github-actions/expressions#steps-context"
+    label: "Steps context — outcome vs conclusion"

package/errors/silent-failures/github-token-no-trigger.yml

@@ -1,57 +1,57 @@
-id: silent-failures-002
-title: "GITHUB_TOKEN Cannot Trigger Downstream Workflows"
-category: silent-failures
-severity: silent-failure
-tags:
-  - github-token
-  - triggers
-  - downstream
-  - workflow-chain
-  - authentication
-patterns:
-  - regex: "events triggered by the GITHUB_TOKEN.*will not create a new workflow run"
-    flags: "i"
-  - regex: "github-actions\\[bot\\]"
-    flags: "i"
-  - regex: "GITHUB_TOKEN"
-    flags: "i"
-error_messages:
-  - "Events triggered by the GITHUB_TOKEN will not create a new workflow run."
-root_cause: |
-  Commits, tags, and releases created with the repository `GITHUB_TOKEN` are intentionally
-  prevented from triggering most downstream workflows. This is a platform safety feature to
-  stop accidental recursion and workflow loops.
-
-  The upstream workflow appears to succeed, but the dependent workflow never starts, which
-  makes this feel like a silent trigger failure.
-fix: |
-  Use a GitHub App installation token or a PAT when you intentionally need one workflow to
-  trigger another via `push`, `create`, or `release`. Keep `GITHUB_TOKEN` for normal repo
-  automation that should not fan out into new workflow runs.
-fix_code:
-  - language: yaml
-    label: "Use a non-GITHUB_TOKEN credential for recursive automation"
-    code: |
-      jobs:
-        release:
-          runs-on: ubuntu-latest
-          steps:
-            - uses: actions/checkout@v4
-            - name: Create tag with a PAT
-              env:
-                GH_TOKEN: ${{ secrets.RELEASE_PAT }}
-              run: |
-                git tag v${{ github.run_number }}
-                git push https://x-access-token:${GH_TOKEN}@github.com/${{ github.repository }}.git --tags
-prevention:
-  - "Assume `GITHUB_TOKEN` will not fan out into downstream workflow runs unless you are using `workflow_dispatch` or `repository_dispatch`."
-  - "Document which automations require a GitHub App token or PAT."
-  - "Avoid recursive workflow designs that depend on implicit `push` triggers from `github-actions[bot]`."
-docs:
-  - url: "https://docs.github.com/en/actions/security-guides/automatic-token-authentication"
-    label: "Automatic token authentication"
-  - url: "https://docs.github.com/en/actions/reference/events-that-trigger-workflows"
-    label: "Events that trigger workflows"
-source:
-  article: "https://htek.dev/articles/github-actions-debugging-guide"
-  section: "GITHUB_TOKEN downstream trigger limitations"
+id: silent-failures-002
+title: "GITHUB_TOKEN Cannot Trigger Downstream Workflows"
+category: silent-failures
+severity: silent-failure
+tags:
+  - github-token
+  - triggers
+  - downstream
+  - workflow-chain
+  - authentication
+patterns:
+  - regex: "events triggered by the GITHUB_TOKEN.*will not create a new workflow run"
+    flags: "i"
+  - regex: "github-actions\\[bot\\]"
+    flags: "i"
+  - regex: "GITHUB_TOKEN"
+    flags: "i"
+error_messages:
+  - "Events triggered by the GITHUB_TOKEN will not create a new workflow run."
+root_cause: |
+  Commits, tags, and releases created with the repository `GITHUB_TOKEN` are intentionally
+  prevented from triggering most downstream workflows. This is a platform safety feature to
+  stop accidental recursion and workflow loops.
+
+  The upstream workflow appears to succeed, but the dependent workflow never starts, which
+  makes this feel like a silent trigger failure.
+fix: |
+  Use a GitHub App installation token or a PAT when you intentionally need one workflow to
+  trigger another via `push`, `create`, or `release`. Keep `GITHUB_TOKEN` for normal repo
+  automation that should not fan out into new workflow runs.
+fix_code:
+  - language: yaml
+    label: "Use a non-GITHUB_TOKEN credential for recursive automation"
+    code: |
+      jobs:
+        release:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - name: Create tag with a PAT
+              env:
+                GH_TOKEN: ${{ secrets.RELEASE_PAT }}
+              run: |
+                git tag v${{ github.run_number }}
+                git push https://x-access-token:${GH_TOKEN}@github.com/${{ github.repository }}.git --tags
+prevention:
+  - "Assume `GITHUB_TOKEN` will not fan out into downstream workflow runs unless you are using `workflow_dispatch` or `repository_dispatch`."
+  - "Document which automations require a GitHub App token or PAT."
+  - "Avoid recursive workflow designs that depend on implicit `push` triggers from `github-actions[bot]`."
+docs:
+  - url: "https://docs.github.com/en/actions/security-guides/automatic-token-authentication"
+    label: "Automatic token authentication"
+  - url: "https://docs.github.com/en/actions/reference/events-that-trigger-workflows"
+    label: "Events that trigger workflows"
+source:
+  article: "https://htek.dev/articles/github-actions-debugging-guide"
+  section: "GITHUB_TOKEN downstream trigger limitations"

package/errors/silent-failures/reusable-workflow-env-secrets-empty.yml

@@ -0,0 +1,90 @@
+id: silent-failures-003
+title: "Reusable Workflow Environment-Scoped Secrets Resolve as Empty String"
+category: silent-failures
+severity: silent-failure
+tags:
+  - reusable-workflows
+  - secrets
+  - environments
+  - workflow-call
+  - secrets-inherit
+patterns:
+  - regex: "MY_SECRET length: 0"
+    flags: "i"
+  - regex: "secrets\\.[A-Z_]+\\s*:\\s*$"
+    flags: "m"
+error_messages:
+  - "MY_SECRET length: 0"
+  - "EMPTY"
+root_cause: |
+  When a reusable workflow (called via `workflow_call`) declares `environment: ${{ inputs.environment_name }}`
+  on its job, the GitHub Actions documentation states that environment-scoped secrets should resolve from
+  that environment. In practice, secrets resolve to empty string unless the caller adds `secrets: inherit`.
+
+  The `secrets: inherit` flag passes all of the caller's accessible secrets to the reusable workflow,
+  including environment-scoped secrets. Without it, the called workflow's secret resolution context is
+  narrowly scoped to explicitly mapped secrets — and environment-scoped secrets are not injected even when
+  the job correctly declares the environment name.
+
+  This is especially dangerous in matrix-based CI/CD pipelines where different matrix entries target
+  different environments (e.g., per-tenant deployments). The reusable workflow appears to run normally but
+  every secret it tries to use is silently empty. The failure can be masked for days if downstream systems
+  tolerate empty credentials during a grace period (e.g., pods using in-cluster Kubernetes Secrets).
+fix: |
+  Add `secrets: inherit` to the caller's job definition. This enables the reusable workflow to resolve
+  environment-scoped secrets from the environment declared on its job:
+
+  Alternatively, explicitly enumerate each secret you need to pass via the `secrets:` mapping block.
+  The explicit form is more secure for cross-repository reusable workflows.
+fix_code:
+  - language: yaml
+    label: "Add secrets: inherit so environment-scoped secrets resolve in the reusable workflow"
+    code: |
+      # Caller workflow
+      jobs:
+        deploy:
+          uses: ./.github/workflows/deploy.yml
+          with:
+            target_environment: production
+          secrets: inherit   # required — without this, env-scoped secrets are empty
+
+      # Reusable workflow (.github/workflows/deploy.yml) — no changes needed
+      on:
+        workflow_call:
+          inputs:
+            target_environment:
+              required: true
+              type: string
+      jobs:
+        worker:
+          runs-on: ubuntu-latest
+          environment: ${{ inputs.target_environment }}
+          steps:
+            - name: Use secret
+              env:
+                API_KEY: ${{ secrets.API_KEY }}
+              run: |
+                echo "API_KEY length: ${#API_KEY}"
+  - language: yaml
+    label: "Explicit secrets mapping (more secure for cross-repo reusable workflows)"
+    code: |
+      jobs:
+        deploy:
+          uses: org/infra/.github/workflows/deploy.yml@main
+          with:
+            target_environment: production
+          secrets:
+            API_KEY: ${{ secrets.API_KEY }}
+            DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
+prevention:
+  - "Always add `secrets: inherit` when a reusable workflow needs environment-scoped secrets."
+  - "Verify secret resolution by printing the secret length: `echo \"length ${#MY_SECRET}\"` — never print the value."
+  - "In matrix deployments targeting different environments, confirm each matrix item resolves its secrets before shipping."
+  - "Consider explicit secrets mapping for cross-repository workflows to avoid accidentally leaking unrelated secrets."
+docs:
+  - url: "https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-secrets-to-called-workflows"
+    label: "Passing secrets to called workflows"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-environments-for-deployment"
+    label: "Using environments for deployment"
+  - url: "https://github.com/actions/runner/issues/4453"
+    label: "actions/runner#4453 — Environment-scoped secrets unreachable without secrets: inherit"

package/errors/silent-failures/scheduled-workflow-disabled.yml

@@ -1,59 +1,59 @@
-id: silent-failures-001
-title: "Scheduled Workflows Silently Disabled After 60 Days"
-category: silent-failures
-severity: silent-failure
-tags:
-  - schedule
-  - cron
-  - inactivity
-  - disabled
-  - automation
-patterns:
-  - regex: "This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days"
-    flags: "i"
-  - regex: "schedule.*workflow.*disabled"
-    flags: "i"
-error_messages:
-  - "This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days"
-root_cause: |
-  In public repositories, GitHub automatically disables scheduled workflows after about
-  60 days with no repository activity. Nothing in the workflow YAML is technically wrong,
-  but the cron job stops firing until someone re-enables it or new activity occurs.
-
-  This feels like a silent failure because the expected schedule disappears rather than
-  producing a normal failed run.
-fix: |
-  Re-enable the workflow in the Actions UI and keep the repository active. If the schedule
-  must stay alive in a low-activity repository, add a keepalive workflow that periodically
-  creates harmless activity.
-fix_code:
-  - language: yaml
-    label: "Keep scheduled workflows active"
-    code: |
-      name: Keepalive
-
-      on:
-        schedule:
-          - cron: '0 6 * * 1'
-        workflow_dispatch:
-
-      jobs:
-        keepalive:
-          runs-on: ubuntu-latest
-          steps:
-            - uses: gautamkrishnar/keepalive-workflow@v2
-              with:
-                committer_username: github-actions[bot]
-                committer_email: 41898282+github-actions[bot]@users.noreply.github.com
-prevention:
-  - "Check the Actions tab periodically for disabled scheduled workflows in low-activity repositories."
-  - "Pair important cron automations with `workflow_dispatch` for manual recovery."
-  - "Use a keepalive strategy for public repos that rely on unattended schedules."
-docs:
-  - url: "https://docs.github.com/en/actions/reference/events-that-trigger-workflows#schedule"
-    label: "schedule event"
-  - url: "https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow"
-    label: "Disable and enable a workflow"
-source:
-  article: "https://htek.dev/articles/github-actions-debugging-guide"
-  section: "Scheduled workflows disabled after inactivity"
+id: silent-failures-001
+title: "Scheduled Workflows Silently Disabled After 60 Days"
+category: silent-failures
+severity: silent-failure
+tags:
+  - schedule
+  - cron
+  - inactivity
+  - disabled
+  - automation
+patterns:
+  - regex: "This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days"
+    flags: "i"
+  - regex: "schedule.*workflow.*disabled"
+    flags: "i"
+error_messages:
+  - "This scheduled workflow is disabled because there hasn't been activity in this repository for at least 60 days"
+root_cause: |
+  In public repositories, GitHub automatically disables scheduled workflows after about
+  60 days with no repository activity. Nothing in the workflow YAML is technically wrong,
+  but the cron job stops firing until someone re-enables it or new activity occurs.
+
+  This feels like a silent failure because the expected schedule disappears rather than
+  producing a normal failed run.
+fix: |
+  Re-enable the workflow in the Actions UI and keep the repository active. If the schedule
+  must stay alive in a low-activity repository, add a keepalive workflow that periodically
+  creates harmless activity.
+fix_code:
+  - language: yaml
+    label: "Keep scheduled workflows active"
+    code: |
+      name: Keepalive
+
+      on:
+        schedule:
+          - cron: '0 6 * * 1'
+        workflow_dispatch:
+
+      jobs:
+        keepalive:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: gautamkrishnar/keepalive-workflow@v2
+              with:
+                committer_username: github-actions[bot]
+                committer_email: 41898282+github-actions[bot]@users.noreply.github.com
+prevention:
+  - "Check the Actions tab periodically for disabled scheduled workflows in low-activity repositories."
+  - "Pair important cron automations with `workflow_dispatch` for manual recovery."
+  - "Use a keepalive strategy for public repos that rely on unattended schedules."
+docs:
+  - url: "https://docs.github.com/en/actions/reference/events-that-trigger-workflows#schedule"
+    label: "schedule event"
+  - url: "https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow"
+    label: "Disable and enable a workflow"
+source:
+  article: "https://htek.dev/articles/github-actions-debugging-guide"
+  section: "Scheduled workflows disabled after inactivity"