# cc-009: 自动同步即信任通道
# ════════════════════════════════════════════════════════════════
# 因果链编号: cc-009
# 创建: 2026-05-14
# 更新: 2026-05-13 (霜砚CI/CD流程更新后)
# 源自: 冰朔"我点合并就可以自动推送到服务器"的需求
# ════════════════════════════════════════════════════════════════

## 起点

冰朔原话: "你给代码合并推送了吗。我点合并就可以自动推送到服务器。不需要我在服务器这里手动复制啊。"

## 因果推导

1. 冰朔不应该操作终端 (cc-007)
2. 代码从Gitea到服务器必须自动化
3. 尝试让Runner做git pull → 权限问题反复失败
4. Runner是act_runner用户, git认证/目录权限/配置都脆弱
5. 凡是依赖Runner用户权限的方案都不稳定 → 换root权限的独立服务
6. Git Sync = 独立进程 + root权限 + PM2守护 + Webhook触发
7. Webhook签名验证失败 → raw body修复方案已写，待部署验证
8. 霜砚建立了CI/CD流程(ci-and-deploy.yaml) → Runner做部署也是一条路
9. 两条路并行: Git Sync (Webhook触发, root权限) + CI/CD (Runner触发, 需权限)

## 工程落点

### 双通道架构 (当前)

1. **Git Sync** (server/git-sync/) — Webhook → root git pull → PM2 restart
   - 优势: root权限，不依赖Runner
   - 问题: Webhook签名验证待修复

2. **CI/CD** (.forgejo/workflows/ci-and-deploy.yaml) — Runner → git pull + npm + pm2 restart
   - 优势: 霜砚已建，dev/main分流，CI检查
   - 问题: Runner权限可能和selfcheck同样的问题

### dev/main 分支模型 (霜砚建立)

```
dev分支: 铸渊开发线 → push → CI检查 → 自己看结果
main分支: 正式线 → 保护规则 → 只有冰朔能merge
合并流程: dev提PR → CI跑检查 → 冰朔合并 → 自动部署
```

## 核心原则

**通道必须通。手段可以换。**

无论用Webhook、CI/CD还是轮询，冰朔点合并→服务器自动更新这条链路必须成立。
技术选择是铸渊的决策自由，但通道不通是铸渊的失职。