actions

Summary Add input. When set, the project status update on accept only runs if the PR carries that label. Use case: the spec repo wants on SEP PRs to move them to _Accepted_ in the SEP Review Pipeline project, but on non-SEP PRs (docs fixes, schema tweaks) should not add those to the SEP board. now receives the full PR object so it can check without a second API call. Label removal () is unchanged — runs on every accept regardless of the gate. Default is empty → existing behavior (update project for every accepted PR when is set). Test plan [ ] on a PR with the gate label → project updated [ ] on a PR without the gate label → project skipped (logged), labels still cleaned up [ ] unset → project updated for all accepted PRs (no regression)

Summary When (or ) accepts a PR, optionally: Remove staging labels — input takes a comma-separated list (e.g. ). Missing labels are silently ignored. Move the PR to _Accepted_ in an org Project — input enables this. Resolves the project, its single-select field (configurable via ), and the option (configurable via ). Adds the PR to the project if not already present, then sets the field. Both are opt-in — defaults are empty, so existing callers are unchanged. Project update failures are warned, not thrown, so a missing permission or misconfigured project doesn't block the approval flow. New App permission required** for project updates: Organization Projects (write). Test plan [ ] Point spec repo workflow at with and the SEP Review Pipeline project number [ ] on a PR with label → label removed, added, PR moved to _Accepted_ in the project [ ] without project-number set → no project calls, labels still cleaned up [ ] with wrong project-number → warning logged, approval still succeeds

Summary When branch protection enables Require review from Code Owners, the GitHub App's APPROVE review does not satisfy it — Apps cannot be members of org teams, so they cannot be code owners via a team entry. Auto-merge also does not inherit the App's ruleset-bypass privileges, so the PR sits in / forever with auto-merge enabled but never firing. Read back from the mutation. If still after we submitted an approval, attempt a direct merge — a direct merge does use the App's bypass. Extract a shared helper for both this path and the existing clean-status fallback. Catches failures and emits an actionable warning pointing at the ruleset bypass-list setup. README: document the bypass-list requirement under the Merge gate section with the exact Settings navigation path. Test plan [ ] Point a consuming repo's workflow at [ ] on a PR where branch protection has and the App is in the ruleset bypass list → merges directly instead of stalling on auto-merge [ ] on a PR without code-owner requirement → auto-merge enabled, no behavior change