| 1 | --- |
| 2 | name: "branch-protection-pr-workflow" |
| 3 | description: "Respect branch protection by routing automation through approved PR or publish-branch workflows instead of bypasses." |
| 4 | domain: "repo-operations" |
| 5 | confidence: "high" |
| 6 | source: "recurring learnings across Leela, Bender, Amy, and Hermes histories" |
| 7 | --- |
| 8 | |
| 9 | ## Context |
| 10 | |
| 11 | Protected branches are part of the product's safety system. When automation needs to write data or generated artifacts, the solution is to choose an approved write path — not to weaken protection or add bypass actors. |
| 12 | |
| 13 | ## Patterns |
| 14 | |
| 15 | - Prefer a PR-based workflow when repository settings allow automation to open and merge pull requests. |
| 16 | - Use an unprotected `publish` branch for self-sufficient automated output when PR creation is unavailable. |
| 17 | - Keep `main` protected and reserve it for reviewed changes. |
| 18 | - Use artifacts for inter-job handoff instead of trying to push partial state through protected refs. |
| 19 | |
| 20 | ## Examples |
| 21 | |
| 22 | - Good: create a timestamped branch, open a PR, and auto-merge after checks succeed. |
| 23 | - Good: push generated data to `publish` while leaving `main` behind branch protection. |
| 24 | - Good: force checkout the target automation branch after artifact downloads if the working tree is dirty. |
| 25 | |
| 26 | ## Anti-Patterns |
| 27 | |
| 28 | - Adding bypass actors just to make a workflow pass. |
| 29 | - Pushing directly to `main` from automation because PR creation is disabled. |
| 30 | - Mixing deployment strategy decisions with branch-protection exceptions. |