refactor(release): 改为 Agent 双阶段人工发布

删除 Gitea Actions、Tag/Main 自动流水线和旧 Runner 配置，取消 Git 操作与发布授权的绑定。\n\n新增本地镜像发布、固定生产部署助手、digest manifest、迁移安全检查、simulation 冒烟及显式回滚流程。\n\n验证：pnpm lint、pnpm test、pnpm build、Go 全量测试、ShellCheck、Compose 配置、人工发布测试和 linux/amd64 完整栈冒烟。

AGENTS.md

@@ -9,19 +9,28 @@
 3. `type` 使用小写英文，可选值为 `feat`、`fix`、`docs`、`test`、`refactor`、`perf`、`build`、`ci`、`chore`、`revert`。
 4. 提交摘要和正文必须使用中文；专有名词、协议名称、命令、路径、代码标识符和第三方原始错误可保留原文。
 5. 摘要应简洁明确，末尾不加句号，不得使用“更新代码”“修复问题”等无法说明意图的模糊描述。
-6. 非简单变更应在提交正文或 PR 描述中用中文说明原因、影响、风险和验证结果。
+6. 非简单变更应在提交正文中用中文说明原因、影响、风险和验证结果。
 
 ## 仓库边界
 
 1. 后端位于 `apps/api`，前端位于 `apps/web`，共享 TypeScript 契约位于 `packages/contracts`。
 2. 修改 HTTP 接口、请求或响应类型后，必须执行 `pnpm openapi` 并提交匹配的 OpenAPI 产物。
-3. 数据库迁移只能新增，禁止修改已经进入生产基线的历史迁移；迁移必须通过生产迁移安全检查。
-4. 不得把 `.env`、密码、Secret、Token、授权码、私钥或生产凭据提交到 Git、日志、测试输出或验收证据中。
+3. 数据库迁移只能新增，禁止修改或删除已经进入 Git 历史的迁移；发布前必须相对当前线上 SHA 执行迁移安全检查。
+4. 不得把 `.env`、密码、Secret、Token、授权码、私钥或生产凭据提交到 Git、日志、测试输出、release manifest 或验收证据中。
 5. 当前工作区存在用户改动时必须保留，不得覆盖、清理、重置或混入当前任务提交；需要隔离时使用独立分支、克隆或 worktree。
 
 ## 验证要求
 
-根据改动范围执行最小充分验证；准备合并或发布时执行完整门禁：
+根据改动范围执行最小充分验证。修改 Shell 脚本后必须执行 `bash -n` 和 ShellCheck；修改 Go 文件后必须确认 `gofmt -l` 没有输出。
+
+本地发布的快速强制门禁由 `scripts/publish-release-images.sh` 固定执行：
+
+```bash
+cd apps/api && env -u AI_GATEWAY_TEST_DATABASE_URL go test ./... -count=1
+node scripts/ci-validate-migrations.mjs <当前线上完整 Git SHA>
+```
+
+完整测试、审计和镜像扫描不再由 Gitea 自动运行。需要合并大范围重构、准备安全审计或人工要求完整验证时执行：
 
 ```bash
 cd apps/api && go vet ./... && go test ./... && govulncheck ./...
@@ -31,18 +40,27 @@ pnpm test
 pnpm build
 pnpm audit --audit-level high
 docker compose -f docker-compose.yml config --quiet
-./tests/ci/ci-build-images-test.sh
 ./tests/ci/migrations-test.sh
-./tests/ci/pipeline-test.sh
-./tests/ci/semver-test.sh
+./tests/release/manual-release-test.sh
 ```
 
-修改 Shell 脚本后还必须执行 `bash -n` 和 ShellCheck。修改 Go 文件后必须确认 `gofmt -l` 没有输出。
+## Git 与人工发布
 
-## Git 与 CI/CD
+1. 仓库不使用 Gitea Actions，不存在 Push、PR、Tag、Webhook、轮询或定时触发的自动构建和自动部署。
+2. `main` 不设置受保护分支或 required status；允许 Agent 在获得用户明确授权后直接提交并推送，但 commit 或 push 永远不等于发布授权。
+3. 发布只能使用工作区干净、已经提交并属于 `origin/main` 历史的完整 SHA。镜像 Tag 使用完整 SHA，线上只能使用 Registry digest，禁止使用 `latest`。
+4. 本地镜像发布必须由用户明确要求后单独执行：
 
-1. 一个提交只包含一个逻辑变更，提交前检查暂存差异并确认不含敏感信息。
-2. `main` 只能通过短生命周期分支和 PR 合并，禁止直接推送或强制推送。
-3. PR 必须通过精确的 `ci / verify (pull_request)` 状态后才能合并；合并后还要确认同一 SHA 的 `ci / verify (push)` 成功。
-4. 生产版本仅使用稳定 SemVer `vMAJOR.MINOR.PATCH` 标签，并同时要求 `release-ci / verify-tag (push)` 成功。
-5. 未验证 protected tag、发布账本、数据库备份、健康检查和回滚路径时，不得声称 CI/CD 或生产发布已经完成。
+   ```bash
+   ./scripts/publish-release-images.sh --components auto
+   ```
+
+   该命令只能构建、冒烟、推送镜像和生成 `dist/releases/<SHA>.json`，不得修改生产。
+5. publish 成功后，Agent 必须报告 manifest、组件、digest 和验证结果并停止。只有用户再次明确确认上线，才可单独执行：
+
+   ```bash
+   ./scripts/deploy-production-release.sh dist/releases/<SHA>.json
+   ```
+
+6. deploy 前后必须验证线上基线、镜像架构/revision、数据库备份条件、内部及公网健康检查和自动应用回滚。未实际完成这些验证时不得声称生产发布成功。
+7. 回滚也必须由用户明确要求，只能选择服务器已有的历史 manifest；应用回滚不自动恢复数据库。