Distillation

🔴 (12:07) User requires the CI poller’s deliberate ci-ready transition to remain intact: after CI succeeds, remove any stale ci-ready label, revalidate the exact approved release snapshot, and always add ci-ready again so a fresh label event triggers publishing; adding the label must never be treated as an idempotent optimization. 🔴 (12:07) User requires the CI poller to revoke or stop processing an issue if its title is renamed, release details change, or it is re-approved through a different accepted event; such an issue must never reach ci-ready. 🔴 (12:07) User requires focused CI-poller regressions proving stale-label removal, final snapshot revalidation, and per-issue termination, including mutation checks demonstrating that tests fail when any of those protections is removed. 🔴 (12:07) User requires workflow_dispatch wherever operators need manual recovery. 🔴 (12:07) For privileged manual recovery, user chose a no-secret relay protected by a main-only environment plus a successful default-branch workflow_run handoff over direct secret-bearing dispatch, because dispatchers select workflow YAML before jobs, guards, or checkout execute. 🔴 (12:07) User requires workflows to be identified by checked-in filenames such as ci-poller.yml, not placeholders or numeric IDs. 🔴 (12:07) User requires release authorization and attestations to be bound to the exact live request, a trusted actor, and current label-event provenance. 🔴 (12:07) Automated approval requires request-bound proof from github-actions[bot] before sentry-internal-app[bot] adds accepted; generic app identity is insufficient. 🔴 (12:07) User requires validation of the captured label event and request digest before CI, after CI, while recording CI-ready proof, immediately before adding ci-ready, and immediately before Craft; repeated live fencing was chosen over initial-only validation because issue state can change during CI or setup. 🔴 (12:07) User requires publishing and CI workflow boundaries to be treated as security gates: before applying accepted, moving an issue to ci-ready, or publishing, validate the live canonical issue, current label events, actor provenance, and matching attestations. 🔴 (12:07) User requires renamed, closed, changed, re-approved, self-approved, or unverifiable release requests to be rejected. 🔴 (12:07) User states the CI poller is solely responsible for adding ci-ready. 🔴 (12:07) User requires recovery via workflow_dispatch to avoid executing arbitrary dispatched-ref code or exposing repository secrets; workflows must check out a trusted ref and use protected environments. 🔴 (12:07) User requires least-privilege permissions, no exposure of RBAC data, and immutable revision or digest pinning for actions and publishing images. 🔴 (12:07) User requires regression tests for workflow ordering and final revalidation immediately before credential-bearing publication. 🔴 (12:07) User requires approval, CI-poller, and publication workflows to fail closed using trusted, snapshot-bound release checks. 🔴 (12:07) User requires the exact triggering issue snapshot to be immutable security input, with attestations and validation bound to the raw title, body, labels, and dry-run state; requests must be rejected when their live state no longer matches. 🔴 (12:07) Snapshot verification must apply to human approval, automated approval, CI-ready proof creation, and final publication, and must occur at every entry point rather than being optional. 🔴 (12:07) User requires trusted default-branch code to run before credentials are created and forbids interpolation of untrusted issue text into shell commands. 🔴 (12:07) User requires concurrency handling in which the poller always re-adds ci-ready after checking CI, even if that label is already present, because another workflow may remove it. 🔴 (12:07) User requires fail-first regression tests for mutation, stale-event, provenance, and workflow-ordering bypasses, followed by targeted and full validation. 🔴 (12:07) Publish terminal reporting must parse PUBLISH_ARGS inside main() with a warning and fallback rather than at module load, then use one always() reporter that derives exactly one status from the Craft outcome; separate cancellation, failure, and success always() steps are rejected because missing inputs can suppress reporting and cancellation predicates can overlap. 🔴 (12:07) For missing publish inputs, update-issue.js uses undefined to skip target restoration, while post-result.js uses {} so terminal reporting continues. 🔴 (12:07) User requires comprehensive validation before declaring changes complete: run relevant focused regression tests, then the full test suite, linting, formatting/whitespace checks, and workflow/YAML validation. 🔴 (12:07) For GitHub Actions changes, validation must also verify trusted-code execution, protected-secret usage, trigger safety, and immutable action pinning. 🔴 (12:07) Validation reports must include exact test and file counts and clearly distinguish failures introduced by the current change from pre-existing or unrelated formatting/lint failures; passing unit tests alone is insufficient evidence that a workflow-heavy change is ready. 🔴 (12:07) User requires defense in depth when modifying GitHub Actions release, approval, or CI-poller flows: run only trusted default-branch code before token access, keep secret-bearing jobs behind the protected production environment, prevent dispatched refs from receiving secrets, and pin actions and containers to immutable digests. 🔴 (12:07) User requires approvals to be bound to immutable request details and current label-event IDs, prohibits self-approval, and requires attestation revalidation immediately before every privileged state transition or publish operation. 🔴 (12:07) If a release request or approval changes, user requires approval-related labels to be removed and processing to stop rather than continue. 🔴 (12:07) User requires focused automated tests enforcing workflow ordering, token identity, action pinning, dispatch restrictions, exact issue-body preservation, cleanup, and race-condition handling.