Distillation

Date: September 10, 2026

• 🔴 (03:02) User’s worktree at /home/byk/Code/getsentry/publish is based on commit 7c60ddb7f43040fe8fbfea70efc833f689c04e75 and contains extensive staged, unstaged, and untracked changes across GitHub workflows, documentation, source modules, and tests.
• 🔴 (03:02) Modified workflow/configuration and documentation files include .github/workflows/auto-approve.yml, .github/workflows/ci-poller.yml, .github/workflows/cocoapods-keepalive.yml, .github/workflows/publish.yml, .github/workflows/test.yml, AGENTS.md, README.md, docs/key_rotation_vault_changes.md, and docs/rfc.md.
• 🔴 (03:02) Modified library/module files include src/libs/github.js, src/modules/ci-poller-input.js, src/modules/details-from-context.js, src/modules/post-workflow-details.js, src/modules/process-end-state.js, src/modules/publish-location.js, src/modules/release-revision.js, and src/modules/update-issue.js.
• 🔴 (03:02) Modified publish files include src/publish/discover-location.js, src/publish/inputs.js, src/publish/post-result.js, src/publish/post-workflow-details.js, src/publish/resolve-ci-poller-input.js, and src/publish/update-issue.js.
• 🔴 (03:02) Modified tests include src/libs/__tests__/github.js, src/modules/__tests__/ci-poller-input.js, src/modules/__tests__/ci-poller-workflow.js, src/modules/__tests__/details-from-context.js, src/modules/__tests__/publish-location.js, src/modules/__tests__/publish-workflow.js, src/modules/__tests__/release-revision.js, src/modules/__tests__/update-issue.js, src/publish/__tests__/discover-location.js, and src/publish/__tests__/resolve-release-revision.js.
• 🔴 (03:02) New untracked workflow/module files include .github/workflows/ci-poller-dispatch.yml, .lore.md, src/modules/approval-attestation.js, src/modules/approval-authorizer.js, src/publish/authorize-approval.js, src/publish/current-accepted-event.js, src/publish/record-auto-approval-attestation.js, src/publish/record-ci-ready-attestation.js, src/publish/request-digest-from-event.js, and src/publish/validate-approval-attestation.js.
• 🔴 (03:02) New untracked tests include src/modules/__tests__/approval-attestation.js, src/modules/__tests__/approval-authorizer.js, src/publish/__tests__/authorize-approval.js, src/publish/__tests__/auto-approval-workflow.js, src/publish/__tests__/ci-poller-workflow.js, src/publish/__tests__/current-accepted-event.js, src/publish/__tests__/publish-workflow.js, src/publish/__tests__/record-auto-approval-attestation.js, src/publish/__tests__/record-ci-ready-attestation.js, src/publish/__tests__/request-digest-from-event.js, src/publish/__tests__/validate-approval-attestation.js, and src/publish/__tests__/workflow-action-pinning.js.
• 🔴 (03:02) Audit plan status: 1. “Freeze and inventory the exact uncommitted worktree” completed (high priority); 2. “Trace workflow and source lifecycle transitions and cleanup paths” in progress (high priority); 3. “Audit regression tests and run scoped/full validation” pending (high priority); 4. “Verify unchanged worktree and report evidence-backed findings” pending (high priority).
• 🔴 (03:02) [enforced-security-workflow] User requires workflow_dispatch handling to “Always run trusted code”; checkout must use ${{ github.event.repository.default_branch }} because workflow_dispatch can target any ref.
• 🔴 (03:02) [enforced-release-invariant] User requires: “Never move a release to ci-ready after it changes.” The CI poller compares the publish issue revision before inspecting CI so a changed release cannot advance.
• 🔴 (03:02) [enforced-release-invariant] User requires that a renamed or re-approved issue “never reaches ci-ready”; approval is revalidated before the transition.
• 🔴 (03:02) [enforced-label-workflow] User stated the poller “always adds ci-ready”; publish.yml fires its publish path only on ci-ready label events, not accepted, to avoid racing with the waiting-for-ci path on the same event.
• 🔴 (03:02) [enforced-secret-isolation] User requires repository secrets to “never be used by this workflow”; .github/workflows/ci-poller-dispatch.yml uses the protected production environment so an arbitrary dispatched ref cannot add repository secrets.
• 🔴 (03:02) .github/workflows/ci-poller-dispatch.yml defines name: Run CI Status Poller, trigger workflow_dispatch, top-level permissions: {}, and one dispatch job using environment: production, runs-on: ubuntu-latest, and a single run: ":" step.
• 🔴 (03:02) .github/workflows/ci-poller.yml listens for workflow runs named Run CI Status Poller, executes in environment: production, and limits relevant workflow_run handling to ${{ github.event.repository.default_branch }}.
• 🔴 (03:02) The CI poller searches for issues carrying both ci-pending and accepted; its logging reports Found ${count} ci-pending + accepted issue(s).
• 🔴 (03:02) The CI poller reads each issue body into a temporary file, parses publish input, and obtains the requested revision as issue_sha=$(echo "$publish_input" | jq -r '.revision').
• 🔴 (03:02) Invalid or unverifiable approval causes an issue comment: Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.
• 🔴 (03:02) CI readiness considers check runs fetched from repos/${repo}/commits/${sha}/check-runs; unsuccessful checks are completed checks whose conclusion is not success, neutral, or skipped.
• 🔴 (03:02) On commit-status CI failure, the poller swaps ci-pending to ci-failed and removes accepted.
• 🔴 (03:02) .github/workflows/publish.yml uses a concurrency group so issues for the same repo@version share serialization; adding accepted initiates the waiting-for-CI path, while publishing fires only for ci-ready and excludes issues still carrying ci-pending.
• 🔴 (03:02) .github/workflows/publish.yml pins actions/create-github-app-token to bcd2ba49218906704ab6c1aa796996da409d3eb1 and actions/checkout to 3d3c42e5aac5ba805825da76410c181273ba90b1.
• 🔴 (03:02) The publish workflow rejects publish paths outside the target checkout with ::error::Publish path must remain inside the target checkout.
• 🔴 (03:02) The publish workflow pins Craft’s publish-state directory outside the target checkout and supports an optional GitHub release-repository override.
• 🔴 (03:03) src/modules/process-end-state.js defines processEndState({ context, octokit, inputs, status }): it obtains workflow-run details with octokit.rest.actions.getWorkflowRun, posts an issue comment, closes the issue only when status === "success", and then reports a Sentry session.
• 🔴 (03:03) githubIssueComment() in src/modules/process-end-state.js maps failure to Failed to publish. plus run logs and a branch-deletion link; cancelled to Publish workflow cancelled. plus the same links; success to Published successfully: [run#${run_id}](${workflowInfo.html_url}); unknown statuses throw Error("Unknown status: '${status}'").
• 🔴 (03:03) reportSession() in src/modules/process-end-state.js initializes Sentry with dsn: process.env.SENTRY_DSN and release ${details.repo}@${details.version}, tags repository, records context release with issue_number and inputs, captures a message, starts/ends a session, and awaits Sentry.close().
• 🔴 (03:03) sentryInfoFromDetails() maps failure to message Release failed: ${repo}, severity error, status crashed; cancelled to Release cancelled: ${repo}, severity warn, status crashed; success to Release succeeded: ${repo}, severity info, status ok; unknown statuses throw.
• 🔴 (03:03) src/publish/post-result.js loads processEndState from ../modules/process-end-state, obtains an Octokit client via github.getOctokit(getGitHubToken()), parses process.env.PUBLISH_ARGS, reads the first CLI argument as status, and invokes processEndState({ context, octokit, inputs, status }).