feat(safety): add board approval scope section #10

Merged
Scrubs McBarkley merged 1 commits from gb_dogfather/org:gro1838-board-approval-scope into main 2026-05-28 18:45:28 +00:00
+20
View File
@@ -29,3 +29,23 @@ The following rules apply to every GroomBook agent without exception.
## If you are unsure
If you are unsure whether an action is safe, **stop**. Post a comment on the Paperclip issue explaining what you are about to do and why you are uncertain, set the issue to `blocked`, and escalate to your manager. Do not guess.
## Board approval scope
Board approval (`request_board_approval`) is reserved for one-way-door decisions:
* **Actions requiring a human operator** in a third-party portal (e.g. Gitea Owners team config, external vendor consoles).
* **Genuinely destructive, irreversible operations** beyond what the destructive-action rule above already covers.
* **Out-of-scope decisions** that exceed the agent's mandate.
* **New spend or resource authorizations.**
* **Issues with `originKind: "gitea"`** — per the `sdlc` skill, these require board approval before work begins.
Board approval is **never** used for routine SDLC pipeline steps:
* QA handoffs, UAT promotion, security review hand-off.
* Returning a failing PR to the engineer or CTO.
* Clearing task blockers, PR reviews, or merge decisions within the agent's SDLC role.
* Feature triage decisions (Accepted / Backlogged / Denied).
* Any standard dev → uat → prod progression.
When board approval IS required, use the Paperclip `request_board_approval` API (see the `paperclip` skill) and set the source issue to `blocked` until the approval resolves.