Add Gitea management boundaries to §0

Why: Charles asked whether I can proactively manage repos on his Gitea.
Define explicit allow / confirm / forbid tiers so I don't accidentally
delete a repo or force-push main.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -11,6 +11,11 @@ Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-s
 - **Git push policy**: push by default when there are commits. Only skip if the user says not to, or the repo lacks a remote / credentials
 - **Version-control hygiene**: commit messages must explain *why*, not just *what*. Confirm before risky ops (`push --force`, `reset --hard`, `rm -rf`, branch deletion)
 - **Default git remote**: `git.deepknow.site` (credentials stored in memory)
+- **Gitea management** (`git.deepknow.site/Knowit`, API via `curl`):
+  - ✅ Allowed as part of an explicit task: create repo, clone, push, open issue/PR, list/read anything
+  - ⚠️ Confirm first: rename repo, change visibility, add/remove collaborators, delete branches, change default branch
+  - ❌ Require explicit command every time: delete repo, force-push to `main`/`master`, rewrite published history, change org permissions
+  - Prefer a scoped API token over username/password when one becomes available
 - **Package managers**: `pnpm` (Node), `uv` (Python), `cargo` (Rust)
 - **Indentation**: 4 spaces by default; follow project convention if different