Migrate SDLC skill from GitHub to Gitea

- Replace GitHub auth section with GITEA_TOKEN + tea CLI instructions
- Remove github-app-token skill invocation
- GitHub-origin → Gitea-origin issue policy (originKind: gitea)
- gh pr create → tea pr create
- Phase 0: GitHub Issues → Gitea Issues
- CI: GitHub Actions → Gitea Actions

Co-Authored-By: Paperclip <noreply@paperclip.ing>

skills/safety/SKILL.md

@@ -29,23 +29,3 @@ 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,25 +1,29 @@
 ---
 name: sdlc
 description: >
-  Software development lifecycle for GroomBook. Covers GitHub authentication,
+  Software development lifecycle for GroomBook. Covers Gitea 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
-  GitHub-origin issue board-approval gate, the cc-cpfarhood visibility rule,
+  Gitea-origin issue board-approval gate, the cc-cpfarhood visibility rule,
   the scheduled penetration testing program, and delegation model tier policy.
 ---
 
 # Software Development Lifecycle
 
-## GitHub authentication
+## Gitea authentication
 
-**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.
+**Use the `tea` CLI** with the `GITEA_TOKEN` environment variable for all Gitea operations. Configure it once:
 
-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.
+```bash
+tea login add --url https://git.farh.net --token $GITEA_TOKEN --name groombook
+```
 
-## GitHub-origin issue policy — board approval required
+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.
 
-If a task originated from GitHub (`originKind: "github"`), **do not begin work**. Immediately create a board approval:
+## Gitea-origin issue policy — board approval required
+
+If a task originated from Gitea (`originKind: "gitea"`), **do not begin work**. Immediately create a board approval:
 
 ```
 POST /api/companies/{companyId}/approvals
@@ -28,8 +32,8 @@ POST /api/companies/{companyId}/approvals
   "requestedByAgentId": "{your-agent-id}",
   "issueIds": ["{issueId}"],
   "payload": {
-    "title": "Board approval required: GitHub issue",
-    "summary": "Summarize what the GitHub issue requests.",
+    "title": "Board approval required: Gitea issue",
+    "summary": "Summarize what the Gitea issue requests.",
     "recommendedAction": "Approve to begin work.",
     "risks": ["Work begins without board review if approved."]
   }
@@ -55,7 +59,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
-gh pr create --base dev --title "..." --body "... cc @cpfarhood"
+tea pr create --base dev --title "..." --body "... cc @cpfarhood"
 ```
 
 ## PR review & merge policy
@@ -79,7 +83,7 @@ gh pr create --base dev --title "..." --body "... cc @cpfarhood"
 
 ### Phase 0 — Product analysis (feature intake)
 
-* Feature requests arrive at the CEO via Paperclip or GitHub Issues.
+* Feature requests arrive at the CEO via Paperclip or Gitea Issues.
 * CEO delegates to CMPO (Pawla Abdul) for review.
 * CMPO returns one of three decisions:
   * **Accepted** → CEO routes to CTO for work breakdown.
@@ -176,7 +180,7 @@ Without this release, the receiving agent cannot check out the issue.
 
 ## Deployment — 2-stage Flux GitOps
 
-**Stage 1 — CI (GitHub Actions, runs in each application repo):**
+**Stage 1 — CI (Gitea Actions, uses GitHub Actions-compatible YAML syntax, 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>`