@htekdev/actions-debugger 1.0.23 → 1.0.25

package/errors/known-unsolved/merge-group-paths-filter-not-supported.yml

@@ -0,0 +1,137 @@
+id: known-unsolved-028
+title: "merge_group Event Does Not Support paths, branches, or tags Filters"
+category: known-unsolved
+severity: limitation
+tags:
+  - merge_group
+  - merge-queue
+  - paths
+  - branches
+  - filters
+  - monorepo
+  - known-limitation
+patterns:
+  - regex: "merge_group:\\s*\\n\\s+paths:"
+    flags: "ms"
+  - regex: "merge_group:\\s*\\n\\s+branches:"
+    flags: "ms"
+error_messages:
+  - "on:\n  merge_group:\n    paths:\n      - 'src/**'"
+  - "workflow triggered for merge_group despite paths filter"
+root_cause: |
+  The merge_group event (used with GitHub's merge queue feature) does not support
+  the standard event activity filters that other events support. Specifically,
+  the following filters are silently IGNORED when listed under merge_group:
+
+  - paths and paths-ignore
+  - branches and branches-ignore
+  - tags
+
+  When a workflow defines:
+    on:
+      pull_request:
+        paths: ['src/**']
+      merge_group:
+        paths: ['src/**']   # silently ignored
+
+  The paths filter applies to pull_request but NOT to merge_group. The workflow
+  always triggers for every merge_group event regardless of which files changed,
+  even if no files in src/** were modified.
+
+  This is particularly painful for monorepos that use paths filters to scope CI
+  workflows to service boundaries — the merge queue bypasses those boundaries
+  and runs all required checks for every PR regardless of which service changed.
+
+  The merge_group event only supports filtering by:
+    types: [checks_requested]   (default and only supported activity type)
+
+  GitHub has acknowledged this is a known limitation with no native fix planned.
+fix: |
+  There is no native path filtering for merge_group. Workarounds:
+
+  1. Step-level change detection: Use a job step with dorny/paths-filter or
+     tj-actions/changed-files to detect whether relevant files changed, then
+     gate subsequent steps on that output. This allows individual steps to
+     short-circuit while the job still runs (satisfying required check status).
+
+  2. Gate job pattern: Add a detect-changes job that runs paths detection and
+     exposes outputs. Downstream jobs use needs: + if: to conditionally run
+     based on the detected changes.
+
+  3. Accept always-run: For merge queue, it is generally safer to run all
+     required checks regardless of file changes. This ensures complete
+     validation before merging and avoids stale-cache scenarios.
+fix_code:
+  - language: yaml
+    label: "Workaround — step-level paths filter inside merge_group triggered job"
+    code: |
+      on:
+        pull_request:
+          paths: ['src/**']   # pull_request respects this filter
+        merge_group:            # merge_group ignores all path/branch filters
+
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                fetch-depth: 0
+
+            - uses: dorny/paths-filter@v3
+              id: changes
+              with:
+                filters: |
+                  src:
+                    - 'src/**'
+
+            - name: Build (skip if no src changes on pull_request)
+              if: steps.changes.outputs.src == 'true' || github.event_name == 'merge_group'
+              run: npm run build
+              shell: bash
+
+  - language: yaml
+    label: "Workaround — detect-changes gate job for monorepo required checks"
+    code: |
+      on:
+        pull_request:
+        merge_group:
+
+      jobs:
+        detect-changes:
+          runs-on: ubuntu-latest
+          outputs:
+            src-changed: ${{ steps.filter.outputs.src }}
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                fetch-depth: 0
+            - uses: dorny/paths-filter@v3
+              id: filter
+              with:
+                filters: |
+                  src:
+                    - 'src/**'
+
+        build:
+          needs: detect-changes
+          if: needs.detect-changes.outputs.src-changed == 'true' || github.event_name == 'merge_group'
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: npm run build
+              shell: bash
+prevention:
+  - "Do not add paths: or branches: under merge_group: — they are silently ignored."
+  - "For monorepo required checks, plan for merge_group always running all required checks regardless of file changes."
+  - "Use step-level change detection (dorny/paths-filter, tj-actions/changed-files) to short-circuit expensive work inside jobs."
+  - "Document that merge queue bypasses path filters in your monorepo CI design documentation."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#merge_group"
+    label: "GitHub Docs: merge_group event — supported filter types"
+  - url: "https://stackoverflow.com/questions/76655935/when-does-a-github-workflow-trigger-for-merge-group-and-is-it-restricted-by-branch"
+    label: "Stack Overflow: merge_group trigger and branch restrictions (Score: 7, 9K views)"
+  - url: "https://github.com/orgs/community/discussions/90533"
+    label: "GitHub Community: merge_group does not support path filters"
+  - url: "https://github.com/dorny/paths-filter"
+    label: "dorny/paths-filter: step-level changed-files detection for monorepos"

package/errors/known-unsolved/no-job-allow-failure.yml

@@ -0,0 +1,73 @@
+id: known-unsolved-026
+title: "No Native allow-failure Mechanism for Jobs"
+category: known-unsolved
+severity: limitation
+tags:
+  - continue-on-error
+  - allow-failure
+  - job-status
+  - pr-checks
+  - known-limitation
+patterns:
+  - regex: "allow.?failure"
+    flags: "i"
+  - regex: "continue-on-error.*(still|marked).*(fail|error)"
+    flags: "i"
+error_messages:
+  - "allow-failure is not a valid key for jobs"
+  - "Job failed but continue-on-error is set — result is still 'failure'"
+root_cause: |
+  GitHub Actions has no native `allow-failure` key for jobs (unlike GitLab CI's `allow_failure`).
+  Adding `allow-failure: true` to a job produces a YAML validation error or is silently ignored
+  because it is not a recognized field.
+
+  The closest equivalent is `continue-on-error: true`, but this has different semantics:
+  - The job still shows as failed in the workflow run summary (yellow warning icon, not green check).
+  - If the job is listed as a required status check in branch protection, the PR is still blocked.
+  - The overall workflow conclusion becomes "success" but the individual job result remains "failure".
+  - Downstream jobs using `needs.<job>.result == 'success'` will not execute.
+
+  This is a long-standing platform gap with 1,571 GitHub reactions (actions/runner#2347) and a
+  community discussion with broad support (orgs/community/discussions/15452).
+fix: |
+  There is no perfect equivalent to allow-failure. The recommended workaround is `continue-on-error: true`
+  on the optional job, combined with a separate "gate" job that aggregates results and is made the
+  required status check in branch protection instead.
+
+  1. Add `continue-on-error: true` to the optional job.
+  2. Add a gate job with `needs: [optional-job]` and `if: always()`.
+  3. The gate job always succeeds — make it the required branch-protection check.
+  4. Downstream jobs check `needs.optional-job.result` explicitly if needed.
+fix_code:
+  - language: yaml
+    label: "Workaround: gate job pattern for allow-failure equivalent"
+    code: |
+      jobs:
+        optional-flaky:
+          runs-on: ubuntu-latest
+          continue-on-error: true   # job can fail without blocking workflow
+          steps:
+            - run: ./run-flaky-tests.sh
+
+        required-gate:
+          runs-on: ubuntu-latest
+          needs: [optional-flaky]
+          if: always()              # always runs regardless of optional-flaky result
+          steps:
+            - name: Report optional job outcome
+              run: |
+                echo "Optional job result: ${{ needs.optional-flaky.result }}"
+                # This step always exits 0 — make required-gate the branch protection check
+                exit 0
+prevention:
+  - "Do not add allow-failure: true to jobs — it is not a recognized Actions field and causes a workflow validation error."
+  - "Use continue-on-error: true as the closest equivalent but understand its PR check implications."
+  - "For required status checks, use the gate/aggregator job pattern — never the optional job itself."
+  - "Track orgs/community/discussions/15452 for official platform support of allow-failure."
+docs:
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-jobs-in-a-workflow"
+    label: "GitHub Actions — Using jobs in a workflow (continue-on-error)"
+  - url: "https://github.com/actions/runner/issues/2347"
+    label: "actions/runner #2347 — allow-failure support request (1571 reactions)"
+  - url: "https://github.com/orgs/community/discussions/15452"
+    label: "Community discussion #15452 — allow-failure for jobs"

package/errors/known-unsolved/schedule-cron-hours-long-queue-drift.yml

@@ -0,0 +1,101 @@
+id: known-unsolved-025
+title: "Scheduled Workflow Queue Drift Exceeds Hours and Worsens Over Time"
+category: known-unsolved
+severity: limitation
+tags:
+  - cron
+  - schedule
+  - drift
+  - queue-delay
+  - best-effort
+  - platform-load
+patterns:
+  - regex: "schedule"
+    flags: "i"
+error_messages:
+  - "Scheduled workflows can be delayed during periods of high loads of GitHub Actions workflow runs."
+root_cause: |
+  GitHub Actions scheduled workflows use a best-effort queue. GitHub does not guarantee
+  that a schedule: trigger fires at the exact cron time. During periods of high platform
+  load, workflows are queued and the dispatch delay can reach multiple hours.
+
+  Since 2025, average delays have been growing on the GitHub-hosted infrastructure:
+  workflows that previously started within 10-20 minutes now commonly wait 1-4+ hours.
+  The drift is not constant — it varies by time of day and platform load and compounds
+  over months for daily/nightly jobs.
+
+  Key contributing factors:
+  - Growth in GitHub's user base means more repositories with scheduled workflows compete
+    for the same dispatch queue infrastructure.
+  - The midnight UTC window is severely congested; nearby times face similar load.
+  - GitHub dispatches schedule events in batches; individual repos have no dispatch priority.
+  - Repositories with no activity for 60+ days have their schedules disabled entirely.
+  - GitHub's documentation explicitly states schedules are best-effort with no SLA.
+
+  This is a known platform-capacity limitation, not a bug. No fix or workaround guarantees
+  on-time execution from within GitHub's scheduler.
+  Reported in actions/runner#4468 (open Jun 2026); discussed in community/196910.
+fix: |
+  There is no way to guarantee on-time execution of a scheduled GitHub Actions workflow.
+  Mitigation strategies depend on how time-sensitive the job is.
+
+  Mitigation 1: Schedule away from congestion windows.
+  Avoid exact hours and midnight UTC. Use irregular minutes and off-peak hours
+  (e.g., 23 14 * * * instead of 0 0 * * *).
+
+  Mitigation 2: Use an external cron service with workflow_dispatch.
+  Remove the on: schedule trigger and replace it with workflow_dispatch. An external
+  scheduler (cloud function, server cron, GitHub App) calls the GitHub REST API dispatches
+  endpoint on time. The workflow starts immediately because workflow_dispatch jobs are not
+  subject to the schedule queue.
+
+  Mitigation 3: Accept the delay and build tolerance.
+  For non-time-critical automations (nightly builds, maintenance tasks), build tolerance
+  into downstream systems rather than fighting the delay.
+
+  Mitigation 4: Self-hosted runners with external scheduling.
+  For strict timing requirements, combine self-hosted runners with an external trigger so
+  the job bypasses GitHub hosted-runner queuing entirely.
+fix_code:
+  - language: yaml
+    label: "Use irregular schedule time to avoid peak congestion"
+    code: |
+      on:
+        schedule:
+          # Avoid :00, :15, :30, :45 and midnight UTC — use irregular off-peak times
+          - cron: '23 14 * * *'   # 2:23 PM UTC
+        workflow_dispatch: {}     # Manual fallback for missed or delayed runs
+  - language: yaml
+    label: "External cron dispatch via GitHub API (reliable timing)"
+    code: |
+      # External scheduler (Lambda, cron job, GitHub App) calls:
+      # curl -X POST \
+      #   -H "Authorization: Bearer $GH_TOKEN" \
+      #   https://api.github.com/repos/OWNER/REPO/actions/workflows/nightly.yml/dispatches \
+      #   -d '{"ref":"main"}'
+      #
+      # Your workflow — no on: schedule needed:
+      on:
+        workflow_dispatch: {}
+
+      jobs:
+        nightly:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+            - run: ./scripts/nightly-build.sh
+prevention:
+  - "Never build SLAs or downstream dependencies that assume a scheduled workflow starts within minutes of its cron time."
+  - "Always add workflow_dispatch: alongside schedule: so delayed or missed runs can be manually triggered from the Actions UI."
+  - "Use non-round-number cron minutes (17, 23, 41, etc.) to avoid the most congested slots."
+  - "For time-critical jobs, use an external scheduler that calls the GitHub API rather than relying on GitHub scheduler queue."
+  - "Track repository activity — GitHub disables scheduled workflows on repos inactive for 60+ days."
+docs:
+  - url: "https://github.com/actions/runner/issues/4468"
+    label: "actions/runner#4468 — Continuously increasing schedule drift (Jun 2026)"
+  - url: "https://github.com/orgs/community/discussions/196910"
+    label: "Community discussion: schedule drift increasing over time"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule"
+    label: "schedule event — best-effort documentation"
+  - url: "https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/disabling-and-enabling-a-workflow"
+    label: "Scheduled workflow disabled after 60 days inactivity"

package/errors/permissions-auth/checkout-persist-credentials-token-write.yml

@@ -0,0 +1,90 @@
+id: permissions-auth-028
+title: "checkout persist-credentials:true Default Stores GITHUB_TOKEN in .git/config"
+category: permissions-auth
+severity: warning
+tags:
+  - checkout
+  - persist-credentials
+  - github-token
+  - security
+  - credential-helper
+patterns:
+  - regex: "persist.credentials.*(true|default)|persist-credentials.*not.*false"
+    flags: "i"
+  - regex: "\\.git.config.*token|credential.*helper.*store.*github"
+    flags: "i"
+error_messages:
+  - "GITHUB_TOKEN persisted in .git/config by actions/checkout"
+  - "Unexpected repository write from a non-commit step"
+root_cause: |
+  `actions/checkout` defaults to `persist-credentials: true`. When enabled, the action configures
+  a credential helper that stores the GITHUB_TOKEN in the repository local `.git/config`.
+  Every repository operation in subsequent steps automatically uses this token for authentication,
+  without any explicit credential setup in those steps.
+
+  Consequences:
+  - Any step that invokes the source control client (directly or via tools that do so internally)
+    inherits repository write access if the job holds `contents: write` permission.
+  - Third-party tools that call the source control client internally (Docker buildx, dependency
+    managers reading version tags, build tools) receive unintended repository access.
+  - In fork PR workflows (`pull_request_target`), checking out a fork ref with persisted
+    credentials gives forked code implicit access to secrets via subsequent repository operations.
+  - Unintended repository writes can occur from any step that invokes write-mode operations.
+
+  The default remains `true` for backward compatibility, but silently increases attack surface
+  for every job that does not need post-checkout write access.
+
+  167 reactions on actions/checkout#485 (open since 2021).
+fix: |
+  Set `persist-credentials: false` on all checkout steps that do not require authenticated
+  repository operations in later steps. Jobs that do need to write back to the repo should
+  use a scoped credential pattern or a dedicated auto-commit action that manages credentials
+  explicitly in its own isolated context.
+fix_code:
+  - language: yaml
+    label: "Recommended: disable persist-credentials for read-only jobs (build, lint, test)"
+    code: |
+      steps:
+        # Token NOT stored in .git/config — safe for read-only jobs
+        - uses: actions/checkout@v4
+          with:
+            persist-credentials: false
+
+        - name: Build and test
+          run: npm ci && npm test
+
+  - language: yaml
+    label: "Scoped: only persist credentials for jobs that explicitly write back to repo"
+    code: |
+      jobs:
+        read-only-analysis:
+          runs-on: ubuntu-latest
+          steps:
+            - uses: actions/checkout@v4
+              with:
+                persist-credentials: false   # no ambient write access
+
+        write-back:
+          runs-on: ubuntu-latest
+          permissions:
+            contents: write
+          steps:
+            # persist-credentials: true (default) only where write is explicitly intended
+            - uses: actions/checkout@v4
+
+            - name: Generate and commit output
+              uses: stefanzweifel/auto-commit-action@v5
+              with:
+                commit_message: "chore: auto-generated output"
+prevention:
+  - "Default to persist-credentials: false — only omit (use default true) when authenticated repository operations are explicitly needed in later steps."
+  - "Audit jobs that rely on the implicit default and also hold contents:write permission."
+  - "In pull_request_target workflows, always set persist-credentials: false when checking out fork refs."
+  - "Review third-party tools in the job that invoke the source control client internally."
+docs:
+  - url: "https://github.com/actions/checkout/issues/485"
+    label: "actions/checkout #485 — Remove persist-credentials or change default (167 reactions)"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions"
+    label: "GitHub Security Hardening for GitHub Actions"
+  - url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs"
+    label: "GitHub Actions — GITHUB_TOKEN permissions"

package/errors/permissions-auth/checkout-v6-cross-repo-token-override.yml

@@ -0,0 +1,103 @@
+id: permissions-auth-029
+title: "checkout@v6 http.extraheader overrides inline token for cross-repository push"
+category: permissions-auth
+severity: error
+tags:
+  - checkout
+  - v6
+  - cross-repo
+  - extraheader
+  - token
+  - push
+  - persist-credentials
+
+patterns:
+  - regex: "remote: Permission to .+ denied to github-actions\\[bot\\]"
+    flags: "i"
+  - regex: "fatal: unable to access '.+': The requested URL returned error: 403"
+    flags: "i"
+  - regex: "The requested URL returned error: 403"
+    flags: "i"
+
+error_messages:
+  - "remote: Permission to org/other-repo.git denied to github-actions[bot]."
+  - "fatal: unable to access 'https://github.com/org/other-repo.git/': The requested URL returned error: 403"
+
+root_cause: |
+  checkout@v6 changed how credentials are stored compared to v4/v5. Instead of writing the
+  GITHUB_TOKEN directly into .git/config, v6 stores credentials in a separate file under
+  $RUNNER_TEMP and registers it via a git includeIf directive. This injects an
+  http.extraheader = Authorization: Bearer <GITHUB_TOKEN> for ALL https://github.com/ URLs.
+
+  When a workflow adds a second remote using an inline Personal Access Token (PAT) in the URL
+  (e.g., https://PAT@github.com/other-org/other-repo.git), git still sends the checkout-injected
+  Authorization header alongside the URL-embedded token. The injected GITHUB_TOKEN header takes
+  precedence over the URL-embedded PAT, and since GITHUB_TOKEN only has access to the current
+  repository, the push to the other repository is rejected with 403 Forbidden.
+
+  This regression is specific to workflows that push to repositories other than the one that
+  was checked out. Workflows that only interact with the current repository are unaffected.
+
+fix: |
+  Option 1 (recommended): Set persist-credentials: false in the checkout step. This prevents
+  checkout@v6 from injecting the extraheader entirely. Configure authentication explicitly in
+  subsequent steps using the token in the remote URL or via GH_TOKEN environment variable.
+
+  Option 2 (targeted): Explicitly unset the http extraheader before performing cross-repo
+  operations. Add a step that clears the auth override for github.com URLs before pushing
+  to the other repository.
+
+  Option 3 (fallback): Pin to checkout@v5 for workflows that require cross-repo push
+  until a v6 upstream fix is available (actions/checkout#2424 is open).
+
+fix_code:
+  - language: yaml
+    label: "Option 1: Disable persist-credentials to prevent extraheader injection"
+    code: |
+      steps:
+        - name: Checkout current repo
+          uses: actions/checkout@v6
+          with:
+            persist-credentials: false   # No extraheader injected; manual auth required
+
+        - name: Push tag to target repository
+          env:
+            TARGET_PAT: ${{ secrets.TARGET_REPO_PAT }}
+          run: |
+            # Token embedded in remote URL; no competing extraheader present
+            TARGET_REMOTE="https://x-access-token:${TARGET_PAT}@github.com/org/target-repo.git"
+            git remote add target "${TARGET_REMOTE}"
+            git tag -f nightly
+            git push -f target nightly
+
+  - language: yaml
+    label: "Option 2: Clear the injected extraheader before cross-repo operations"
+    code: |
+      steps:
+        - uses: actions/checkout@v6
+
+        # ... build steps ...
+
+        - name: Unset checkout extraheader for cross-repo push
+          run: git config --unset-all "http.https://github.com/.extraheader" || true
+
+        - name: Push tag to target repository
+          env:
+            TARGET_PAT: ${{ secrets.TARGET_REPO_PAT }}
+          run: |
+            git remote add target "https://x-access-token:${TARGET_PAT}@github.com/org/target-repo.git"
+            git push -f target nightly
+
+prevention:
+  - "Use persist-credentials: false on all checkout steps in workflows that interact with multiple repositories."
+  - "Avoid embedding tokens directly in remote URLs when checkout@v6 is used without persist-credentials:false."
+  - "Test cross-repo operations in a staging branch after upgrading from checkout@v4 or v5 to v6."
+  - "Check actions/checkout release notes for credential storage changes when upgrading major versions."
+
+docs:
+  - url: "https://github.com/actions/checkout/issues/2424"
+    label: "actions/checkout#2424: Unable to create tags in another repo with v6"
+  - url: "https://github.com/actions/checkout/releases/tag/v6.0.0"
+    label: "checkout@v6.0.0 release notes — persist-credentials storage change"
+  - url: "https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication"
+    label: "GitHub Docs: Automatic token authentication and GITHUB_TOKEN scopes"

package/errors/permissions-auth/create-github-app-token-cross-job-token-revoked.yml

@@ -0,0 +1,95 @@
+id: permissions-auth-027
+title: "create-github-app-token token auto-revoked in post step — cannot pass to downstream jobs"
+category: permissions-auth
+severity: silent-failure
+tags:
+  - create-github-app-token
+  - github-app
+  - token-revocation
+  - cross-job
+  - job-outputs
+  - masked-secrets
+patterns:
+  - regex: "HttpError.*401.*Bad credentials"
+    flags: "i"
+  - regex: "Token has been revoked"
+    flags: "i"
+  - regex: "RequestError.*401"
+    flags: "i"
+error_messages:
+  - "HttpError: Bad credentials"
+  - "Error: 401 Bad credentials"
+  - "RequestError: 401 Unauthorized"
+root_cause: |
+  actions/create-github-app-token automatically revokes the generated installation token
+  in the action's post step (after the job completes). This means a token generated in
+  job A and passed as a job output to job B will already be revoked by the time job B
+  runs. Additionally, GitHub Actions automatically masks any value that looks like a
+  token (matching the ghp_, ghs_, ghu_, github_pat_, etc. prefixes). Masked values
+  cannot be passed through job outputs — the runner replaces them with "***" in outputs,
+  so the downstream job receives a masked/empty string rather than the actual token value.
+  Setting skip-token-revoke: true is necessary but not sufficient: the masking mechanism
+  still prevents the token from appearing as a job output.
+fix: |
+  Recreate the token in each job that needs it by calling actions/create-github-app-token
+  as a step within each dependent job. This is the recommended pattern from the action
+  maintainers. Do not attempt to pass the token through job outputs.
+fix_code:
+  - language: yaml
+    label: "Wrong: token passed through job output (always fails)"
+    code: |
+      jobs:
+        get-token:
+          runs-on: ubuntu-latest
+          outputs:
+            token: ${{ steps.app-token.outputs.token }}  # BROKEN: masked, will be ***
+          steps:
+            - id: app-token
+              uses: actions/create-github-app-token@v1
+              with:
+                app-id: ${{ vars.APP_ID }}
+                private-key: ${{ secrets.APP_PRIVATE_KEY }}
+        use-token:
+          needs: get-token
+          runs-on: ubuntu-latest
+          steps:
+            - run: echo "token is ${{ needs.get-token.outputs.token }}"
+              # Always prints "***" — token unusable
+  - language: yaml
+    label: "Correct: recreate token in each job that needs it"
+    code: |
+      jobs:
+        build:
+          runs-on: ubuntu-latest
+          steps:
+            - id: app-token
+              uses: actions/create-github-app-token@v1
+              with:
+                app-id: ${{ vars.APP_ID }}
+                private-key: ${{ secrets.APP_PRIVATE_KEY }}
+            - uses: actions/checkout@v4
+              with:
+                token: ${{ steps.app-token.outputs.token }}
+        deploy:
+          runs-on: ubuntu-latest
+          steps:
+            - id: app-token       # recreate — do not reuse from build job
+              uses: actions/create-github-app-token@v1
+              with:
+                app-id: ${{ vars.APP_ID }}
+                private-key: ${{ secrets.APP_PRIVATE_KEY }}
+            - run: ./deploy.sh
+              env:
+                GH_TOKEN: ${{ steps.app-token.outputs.token }}
+prevention:
+  - "Never pass GitHub App tokens through job outputs — the token is masked and will be empty"
+  - "Recreate the token in every job that needs it using a dedicated create-github-app-token step"
+  - "Store APP_ID as a repository variable (vars.APP_ID) and private key as a secret"
+  - "Consider using a GitHub App with fine-grained permissions to minimize the blast radius of token exposure"
+docs:
+  - url: "https://github.com/actions/create-github-app-token/issues/66"
+    label: "actions/create-github-app-token#66: output token cannot be used across jobs"
+  - url: "https://github.com/actions/create-github-app-token#usage"
+    label: "actions/create-github-app-token: Usage documentation"
+  - url: "https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-to-access-secrets"
+    label: "GitHub Docs: Security hardening — intermediate environment for secrets"