Distillation

Date: Sep 8, 2026

• 🔴 (21:07) User stated: “Always run trusted code.”
• 🔴 (21:07) User stated: “Never move a release to ci-ready after it changes.”
• 🔴 (21:07) User stated that a renamed or re-approved issue never reaches ci-ready.
• 🟡 (21:07) .github/workflows/ci-poller.yml:99-106 polls only open issues carrying both ci-pending and accepted, with --limit 200 and JSON fields number,title,labels,body; if count is 0, the CI-check step exits successfully.
• 🟡 (21:07) .github/workflows/ci-poller.yml:121-153 obtains the current accepted-label event through src/publish/current-accepted-event.js, extracts .actor and .eventId, and validates the github-actions[bot] approval attestation with EXPECTED_ACCEPTED_ACTOR and EXPECTED_ACCEPTED_EVENT_ID before inspecting CI. Any binding/validation failure removes both ci-pending and accepted and posts: Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.
• 🟡 (21:07) .github/workflows/ci-poller.yml:170-217 extracts a 40-character lowercase commit SHA from the issue body’s /commit/{SHA}/checks link; it resolves the release branch using repos/${repo}/commits/${issue_sha}/check-suites, resolves branch HEAD through repos/${repo}/git/ref/heads/${branch}, falls back to issue_sha on either lookup failure, and replaces the SHA in the issue body if the branch head changed.
• 🟡 (21:07) .github/workflows/ci-poller.yml:221-253 uses release-bot authenticated API calls for repos/${repo}/commits/${sha}/status and paginated repos/${repo}/commits/${sha}/check-runs; any API failure skips that issue rather than deriving state from partial data. It refuses to treat CI as started when both total_checks and total_statuses equal 0.
• 🟡 (21:07) .github/workflows/ci-poller.yml:256-270 defines CI-ready as commit status success or zero commit statuses, plus zero pending check runs and zero completed check runs with conclusions other than success, neutral, or skipped.
• 🟡 (21:07) .github/workflows/ci-poller.yml:272-354 revalidates the approval attestation after CI passes, records a CI-ready proof with src/publish/record-ci-ready-attestation.js, requires output beginning ci_ready_attestation=, posts that proof using ${{ github.token }}, then validates the attestation a third time immediately before applying ci-ready. Any failure removes ci-pending and accepted and posts the invalid-approval retry comment.
• 🟡 (21:07) .github/workflows/ci-poller.yml:356-364 advances a validated passing issue by removing ci-pending, adding ci-ready, and commenting CI checks passed for ${repo}@${version}. Publishing is starting now.
• 🟡 (21:07) .github/workflows/ci-poller.yml:366-391 handles failed CI in two cases: failed completed check runs cause ci-pending → ci-failed and removal of accepted, with failed check names; a failed/error combined commit status with otherwise passing checks makes the same label changes and comments failed status contexts. Both responses direct the author to re-add accepted after fixing CI.
• 🟡 (21:07) .github/workflows/ci-poller.yml:395-436 always counts remaining open issues with both ci-pending and accepted, then—if the pinned CI_POLLER_APP_CLIENT_ID token step succeeds—sets repository variable CI_POLLER_HAS_PENDING to false when count is 0, otherwise true.
• 🟡 (21:07) .github/workflows/ci-poller.yml:438-463 self-dispatches only when the auth token and remaining-issues steps succeeded and remaining count is nonzero. It increments ATTEMPT using attempt=$((10#$ATTEMPT + 1)), stops at attempt >= 60, and otherwise POSTs {event_type: "ci-poller", client_payload: {attempt: $attempt}} to repos/$GITHUB_REPOSITORY/dispatches; comments state this gives roughly 30–60 seconds between checks, allows 1 running plus 1 queued due to concurrency, and cron remains fallback after approximately 30 minutes.