Distillation

Date: Aug 28, 2026

• 🟡 (19:51) Background task “Review approval security” completed with an empty task_result; assistant nevertheless identified two security races: an unproven ci-ready label can initiate publishing, and re-approval can occur between the CI poller’s final validation and its label transition.
• 🟡 (19:51) Assistant planned to bind the CI handoff to the same accepted event and require that proof before publication.
• 🔴 [continued-task] (19:52) User instructed assistant to continue.
• 🔴 (19:57) User stated that the poller always adds ci-ready.
• 🟡 (19:57) Inspected .github/workflows/ci-poller.yml excerpts. The workflow triggers on issues labeled events; has waiting-for-ci and production-environment jobs; uses actions/create-github-app-token@v3; invokes approval validation with APPROVAL_ISSUE_REPOSITORY: ${{ github.repository }}, APPROVAL_ISSUE_NUMBER: ${{ github.event.issue.number }}, and APPROVAL_TOKEN: ${{ github.token }}; rejects invalid approvals by commenting “Approval is invalid or could not be verified. Re-add the accepted label to retry after resolving the issue.”; and includes a comment that the poller’s later --add-label is guaranteed to trigger on the happy path.
• 🔴 (20:02) User directed: “Never move a release to ci-ready after either value changes.”
• 🔴 (20:02) User stated that a renamed or re-approved issue never reaches ci-ready.
• 🟡 (20:02) Inspected CI-poller script excerpts. It lists up to 200 open issues; before initial CI processing calls node src/publish/validate-approval-attestation.js; extracts an issue SHA via grep -oP '(?<=commit/)[0-9a-f]{40}(?=/checks)'; evaluates commit statuses and check runs; and, after CI is ready, revalidates approval immediately before adding ci-ready. On failed revalidation it comments and avoids the transition; on success it logs CI passed! Adding ci-ready label.
• 🟡 (20:02) Assistant specified a two-proof design: CI completion must bind to the same current accepted event and title; the poller will create this CI-ready proof before applying ci-ready; publication will require both approval proof and CI-ready proof.
• 🟡 (20:06) Inspected src/publish/validate-approval-attestation.js (119 lines). validateApprovalAttestation({ attestationAuthor, issueNumber, issueTitle, repository }) concurrently retrieves the issue, all events, and all comments; requires the fetched title to equal issueTitle, an active accepted label, a non-null currentAcceptedEvent(events), and a matching trusted approval attestation. GitHub API calls use APPROVAL_TOKEN, Accept: application/vnd.github+json, and X-GitHub-Api-Version: "2026-03-10"; paginated records use per_page=100; required CLI environment variables are APPROVAL_TOKEN, APPROVAL_ISSUE_NUMBER, APPROVAL_ISSUE_REPOSITORY, APPROVAL_ISSUE_TITLE, and APPROVAL_ATTESTATION_AUTHOR.
• 🟡 (20:12) Inspected prior src/modules/approval-attestation.js (108 lines). It used ATTESTATION_PREFIX = "<!-- publish-approval " and ATTESTATION_SUFFIX = " -->"; createApprovalAttestation() base64url-encoded { actor, eventId: String(eventId), title }; currentAcceptedEvent() selected the numerically latest valid accepted label event; and hasApprovalAttestation() required a trusted comment whose parsed actor, event ID, and title exactly match the current accepted event and issue title.
• 🟡 (20:14) Modified src/modules/approval-attestation.js.
• 🟡 (20:17) Inspected modified src/modules/approval-attestation.js (190 lines). It adds APPROVAL_ATTESTATION_PREFIX = "<!-- publish-approval ", CI_READY_ATTESTATION_PREFIX = "<!-- publish-ci-ready ", generic createAttestation(prefix, value), createCiReadyAttestation({ acceptedEvent, ciReadyEvent, title }), parseCiReadyAttestation(), currentLabeledEvent(events, labelName), currentCiReadyEvent(events), and hasCiReadyAttestation({ comments, acceptedEvent, ciReadyEvent, title, attestationAuthor }). A valid CI-ready attestation must bind acceptedActor, acceptedEventId, ciReadyActor, ciReadyEventId, and title to the current events and title, and be posted by attestationAuthor.
• 🟡 (20:17) Identified a newly introduced parsing defect in src/modules/approval-attestation.js: generic parseAttestation(body, prefix) slices the encoded body starting at start + ATTESTATION_PREFIX.length, but ATTESTATION_PREFIX no longer exists after the constants were renamed to APPROVAL_ATTESTATION_PREFIX and CI_READY_ATTESTATION_PREFIX; it should use prefix.length. As shown, parsing either attestation would throw a ReferenceError, be caught, and return null, causing approval/CI-ready attestations to fail validation. No fix or test result for this defect was shown.