refactor(sdlc): migrate from GitHub to Gitea with tea CLI

- Replace github-app-token skill with GITEA_TOKEN env var and tea CLI
- Update all GitHub references to Gitea (auth, issues, PRs, origin policy)
- Add CLAUDE.md with org-level guidance for future Claude Code sessions

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

skills/sdlc/SKILL.md

@@ -1,25 +1,25 @@
 ---
 name: sdlc
 description: >
-  Software development lifecycle for CartSnitch. Covers GitHub authentication,
+  Software development lifecycle for CartSnitch. 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 GitHub-origin issue
+  status semantics, infrastructure layout, the Gitea-origin issue
   board-approval gate, the cc-cpfarhood visibility rule,
   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 writes it to `$GH_CONFIG_DIR/.gh-token` (or `$AGENT_HOME/.gh-token` as fallback) and authenticates `gh` automatically. **Never** run `gh auth login` — it hangs headless agents. Token expires after ~1 hour; re-invoke to regenerate.
+**Use the `GITEA_TOKEN`** environment variable for all Gitea operations. It is already set in the agent environment. Use the **`tea`** CLI for all Gitea/Git operations (e.g., `tea issue list`, `tea pr create`). The token expires when the environment variable is rotated — re-invoke any Gitea operation if you get a 401.
 
-GitHub is the **primary source of truth**. Every Paperclip issue must 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 must 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 GitHub (`originKind: "github"`), **do not begin work**. Immediately create a board approval:
+If a task originated from Gitea (`originKind: "gitea"`), **do not begin work**. Immediately create a board approval:
 
 ```
 POST /api/companies/{companyId}/approvals
@@ -28,7 +28,7 @@ POST /api/companies/{companyId}/approvals
   "requestedByAgentId": "{your-agent-id}",
   "issueIds": ["{issueId}"],
   "payload": {
-    "title": "Board approval required: GitHub issue",
+    "title": "Board approval required: Gitea issue",
     "summary": "Summarize what the GitHub issue requests.",
     "recommendedAction": "Approve to begin work.",
     "risks": ["Work begins without board review if approved."]
@@ -55,10 +55,10 @@ 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"
 ```
 
-GitHub branch protection requires CI checks (lint, test, build-and-push). Governance is enforced through the Paperclip SDLC — GitHub-native review approvals are not required because all agents share a GitHub App identity. Paperclip approval tracking is the authoritative record.
+Gitea branch protection requires CI checks (lint, test, build-and-push). Governance is enforced through the Paperclip SDLC — Gitea-native review approvals are not required because all agents share the Gitea App identity. Paperclip approval tracking is the authoritative record.
 
 ## PR review & merge policy
 
@@ -78,7 +78,7 @@ GitHub branch protection requires CI checks (lint, test, build-and-push). Govern
 
 ### 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 CMO (Markdown Martha) for review.
 * CMO: Accepted → CEO routes to CTO for work breakdown. Backlogged → CEO handles prioritization. Denied → closed as unplanned.
 * CTO breaks accepted work into atomic tasks and assigns to Engineering.
@@ -172,7 +172,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 (runs in each application repo):**
 - Triggered automatically on every merge to `main`
 - Builds and tags the Docker image: CalVer (`YYYY.MM.DD[.N]`), `latest`, and `sha-<hash>`
 - Pushes tagged images to `ghcr.io/cartsnitch/<service>`