feat(safety): add board approval scope section

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

skills/safety/SKILL.md

@@ -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.

skills/sdlc/SKILL.md

@@ -1,29 +1,25 @@
 ---
 name: sdlc
 description: >
-  Software development lifecycle for GroomBook. Covers Gitea authentication,
+  Software development lifecycle for GroomBook. Covers GitHub authentication,
   branch strategy across Dev/UAT/Prod, the four-phase SDLC pipeline with
   product analysis intake, PR review and merge policy, the handoff protocol,
   status semantics, infrastructure layout, the canonical tools list, the
-  Gitea-origin issue board-approval gate, the cc-cpfarhood visibility rule,
+  GitHub-origin issue board-approval gate, the cc-cpfarhood visibility rule,
   the scheduled penetration testing program, and delegation model tier policy.
 ---
 
 # Software Development Lifecycle
 
-## Gitea authentication
+## GitHub authentication
 
-**Use the `tea` CLI** with the `GITEA_TOKEN` environment variable for all Gitea operations. Configure it once:
+**Invoke the `github-app-token` skill** before any GitHub operation. It generates a short-lived installation token and sets `GH_TOKEN`. **Never** run `gh auth login` — it hangs headless agents. Token expires after ~1 hour; re-invoke to regenerate.
 
-```bash
-tea login add --url https://git.farh.net --token $GITEA_TOKEN --name groombook
-```
+GitHub is the **primary source of truth**. Every Paperclip issue should have a corresponding GitHub issue (create one if missing). Both stay open until the work is completed, reviewed, approved, merged, and QA-verified.
 
-Gitea is the **primary source of truth**. Every Paperclip issue should have a corresponding Gitea issue (create one if missing). Both stay open until the work is completed, reviewed, approved, merged, and QA-verified.
+## GitHub-origin issue policy — board approval required
 
-## Gitea-origin issue policy — board approval required
-
-If a task originated from Gitea (`originKind: "gitea"`), **do not begin work**. Immediately create a board approval:
+If a task originated from GitHub (`originKind: "github"`), **do not begin work**. Immediately create a board approval:
 
 ```
 POST /api/companies/{companyId}/approvals
@@ -32,8 +28,8 @@ POST /api/companies/{companyId}/approvals
   "requestedByAgentId": "{your-agent-id}",
   "issueIds": ["{issueId}"],
   "payload": {
-    "title": "Board approval required: Gitea issue",
-    "summary": "Summarize what the Gitea issue requests.",
+    "title": "Board approval required: GitHub issue",
+    "summary": "Summarize what the GitHub issue requests.",
     "recommendedAction": "Approve to begin work.",
     "risks": ["Work begins without board review if approved."]
   }
@@ -59,7 +55,7 @@ Three long-lived branches map to the three deployment environments:
 All changes happen via pull request. Always include `cc @cpfarhood` at the bottom of the PR body for visibility — never as a reviewer.
 
 ```bash
-tea pr create --base dev --title "..." --body "... cc @cpfarhood"
+gh pr create --base dev --title "..." --body "... cc @cpfarhood"
 ```
 
 ## PR review & merge policy
@@ -83,7 +79,7 @@ tea pr create --base dev --title "..." --body "... cc @cpfarhood"
 
 ### Phase 0 — Product analysis (feature intake)
 
-* Feature requests arrive at the CEO via Paperclip or Gitea Issues.
+* Feature requests arrive at the CEO via Paperclip or GitHub Issues.
 * CEO delegates to CMPO (Pawla Abdul) for review.
 * CMPO returns one of three decisions:
   * **Accepted** → CEO routes to CTO for work breakdown.
@@ -180,7 +176,7 @@ Without this release, the receiving agent cannot check out the issue.
 
 ## Deployment — 2-stage Flux GitOps
 
-**Stage 1 — CI (Gitea Actions, uses GitHub Actions-compatible YAML syntax, runs in each application repo):**
+**Stage 1 — CI (GitHub Actions, runs in each application repo):**
 - Triggered automatically on every merge to `main`
 - Builds and tags the Docker image
 - Pushes tagged images to `ghcr.io/groombook/<service>`