Distillation

Date: Aug 29, 2026

• 🟡 (11:51) Full yarn vitest run succeeded: 10 test files passed and 46 tests passed. Test duration was 1.72s (transform 195ms, import 1.39s, tests 237ms); Yarn completed in 2.25s.
• 🟡 (11:51) Passing Vitest suites were: src/modules/__tests__/post-workflow-details.js (1 test), src/publish/__tests__/validate-approval-attestation.js (6), src/publish/__tests__/authorize-approval.js (3), src/modules/__tests__/approval-attestation.js (4), src/publish/__tests__/record-ci-ready-attestation.js (2), src/modules/__tests__/approval-authorizer.js (14), src/modules/__tests__/process-end-state.js (4), src/modules/__tests__/update-issue.js (5), src/modules/__tests__/details-from-context.js (5), and src/libs/__tests__/github.js (2).
• 🟡 (11:52) Assistant reported all 46 tests passing and began complete-diff and repository validation, distinguishing authorization-gate failures from the known unrelated workflow-lint violation.
• 🟡 (11:53) Working tree modifications included .github/workflows/ci-poller.yml, .github/workflows/publish.yml, AGENTS.md, src/libs/__tests__/github.js, src/libs/github.js, src/modules/__tests__/details-from-context.js, src/modules/details-from-context.js, src/modules/post-workflow-details.js, src/modules/process-end-state.js, src/modules/update-issue.js, src/publish/inputs.js, src/publish/post-result.js, src/publish/post-workflow-details.js, and src/publish/update-issue.js; untracked files included .lore.md, approval-attestation/authorizer modules and tests, src/publish/__tests__/, src/publish/authorize-approval.js, src/publish/record-ci-ready-attestation.js, and src/publish/validate-approval-attestation.js.
• 🟡 (11:53) Diffstat for the tracked modified files was 14 files changed, 293 insertions, and 56 deletions. .github/workflows/ci-poller.yml had 117 additions/changes; .github/workflows/publish.yml had 97 additions; src/modules/update-issue.js had 35 changes; src/modules/__tests__/details-from-context.js had 22 changes.
• 🟡 (11:57) Repository-wide yarn eslint src .github --ignore-pattern '!.github' failed solely on pre-existing .github/workflows/cocoapods-keepalive.yml:1:7: yml/plain-scalar error “Must use plain style scalar”; 1 error, 0 warnings, potentially fixable with --fix.
• 🟡 (11:58) Assistant identified the repository-wide lint failure as the pre-existing cocoapods-keepalive.yml scalar violation and chose targeted lint/format validation for changed JavaScript and workflows, followed by attestation-diff inspection.
• 🟡 (12:00) Targeted eslint src passed in 0.81s.
• 🟡 (12:00) Prettier validation passed in 0.91s for .github/workflows/ci-poller.yml, .github/workflows/publish.yml, src/modules/approval-attestation.js, src/modules/approval-authorizer.js, src/modules/details-from-context.js, related module tests, src/publish/authorize-approval.js, src/publish/record-ci-ready-attestation.js, src/publish/validate-approval-attestation.js, and their tests; all matched files used Prettier style.
• 🟡 (12:00) Assistant began final adversarial review of approval and CI-ready attestations, event ordering, and cleanup paths.
• 🟡 (12:03) Task status: completed—inspect current CI-ready attestation implementation/workflow handoff; complete CI-ready proof recording/publication validation; add regression coverage for attestation parsing and CI-ready proof; run focused/full validation. In progress—final adversarial review of approval and CI-ready attestations.
• 🔴 (12:06) User asserted that the poller always adds ci-ready after checking CI; waiting-for-ci first removes any existing ci-ready so a fresh labeled event triggers publish.yml on the happy path.
• 🟡 (12:06) Inspected .github/workflows/publish.yml lines 1–270. Workflow triggers on issue labeled events; concurrency group is ${{ github.event.issue.title }} with cancel-in-progress: false; permissions are contents: read, issues: write, and packages: write.
• 🟡 (12:06) publish.yml job waiting-for-ci runs only when accepted is the added label, issue is open, and title starts publish: . It checks out with actions/checkout@v6 and persist-credentials: false, creates an internal-app token, and creates a getsentry release-bot token with continue-on-error: true.
• 🟡 (12:06) waiting-for-ci runs src/publish/authorize-approval.js with APPROVAL_TOKEN, APPROVAL_ACTOR, APPROVAL_ISSUE_NUMBER, APPROVAL_ISSUE_REPOSITORY, and APPROVAL_ISSUE_TITLE; on authorization success with authorized == 'true', it posts approval_attestation as an issue comment using github.token.
• 🟡 (12:06) waiting-for-ci validates the posted approval proof via src/publish/validate-approval-attestation.js using APPROVAL_TOKEN: github.token and APPROVAL_ATTESTATION_AUTHOR: github-actions[bot]. If authorization, attestation posting, or validation fails, it removes accepted, comments “Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.”, and exits 1.
• 🟡 (12:06) On valid approval, waiting-for-ci removes ci-failed and ci-ready, then adds ci-pending using the internal-app token. It comments either “Retrying — CI was previously failed. Checking CI status now.” or “Approved. Checking CI status on the release branch. Publishing will start automatically when CI passes.”
• 🟡 (12:06) waiting-for-ci best-effort enables the cron poller by setting repository variable CI_POLLER_HAS_PENDING to "true" using a dedicated poller-app token, then triggers ci-poller.yml through gh workflow run using the internal-app token because GITHUB_TOKEN-originated workflow_dispatch events are suppressed.
• 🟡 (12:06) publish.yml job publish runs only for open issues where added label is ci-ready, current labels include both accepted and ci-ready, and exclude ci-pending and ci-failed; timeout is 90 minutes. It validates approval with REQUIRE_CI_READY_ATTESTATION: "true" before proceeding, and on failure removes accepted, posts the standard invalid-approval retry message, and exits 1.
• 🟡 (12:09) Inspected diff showing ci-poller.yml permissions changed from issues: read to issues: write, added checkout via actions/checkout@v6 with persist-credentials: false, and replaced sed parsing of publish: owner/repo[/path]@version titles with approval-attestation validation before CI processing.
• 🔴 (12:09) User directed that the poller must never move a release to ci-ready after either protected value changes: the issue title or the latest accepted-label event.
• 🔴 (12:09) User directed that a renamed or re-approved issue never reaches ci-ready.
• 🟡 (12:09) Assistant found a race: final validation could accept a fresh, separately attested re-approval during the same poller pass. It chose to bind the poller to the accepted event observed before CI checks, so a later re-approval prevents the ci-ready transition even when a new attestation arrives quickly.
• 🟡 (12:12) Inspected src/publish/__tests__/validate-approval-attestation.js (298 lines), which imports validateApprovalAttestation, createApprovalAttestation, and createCiReadyAttestation; afterEach() restores Vitest mocks.
• 🟡 (12:12) validate-approval-attestation.js regression tests cover: accepting a current accepted event with a trusted github-actions[bot] approval attestation; rejecting after title changes from publish: getsentry/sentry-javascript@10.0.0 to publish: getsentry/sentry-python@10.0.0; rejecting after accepted is removed; and rejecting when accepted is re-added with a new event ID (100 replaced by 200).
• 🟡 (12:12) CI-ready validation tests require a live accepted and ci-ready label, approval attestation tied to accepted event { actor: "contractor", eventId: "100" }, and CI-ready attestation tied to the ci-ready label actor sentry-internal-app[bot]; they reject a manually added ci-ready label whose actor is contractor, even if a syntactically matching CI-ready attestation exists.