feat(deploy): 新增 deploy 命令集，一键为新仓库生成/升级部署能力

[Guo-Zhang]

feat(deploy): 新增 deploy 命令集，一键为新仓库生成/升级部署能力

背景

qtcloud-devops 目前只覆盖 build → test → release 生命周期，部署环节（site/studio/provider 上线到 .quanttide.com）完全依赖每个仓库手工复制一份 .github/workflows/deploy-*.yml + manifests/terraform/。这次为 qtcrowd 上线 crowd.quanttide.com 便是手工照抄 qtcloud-agent 的一整套配置，里面含有多个容易踩坑的点（SSL 证书绑定、SPA 回退改写、私有 OSS 回源鉴权、DNS CNAME、缓存策略分离）。

现状痛点（量化重复）

• 全仓共 71 个 deploy-*.yml workflow（site/studio/provider/docs/oss 多形态），彼此高度相似。
• 13 份重复的 manifests/terraform（cdn.tf + site-bucket.tf/studio-bucket.tf），仅域名/桶名/技术栈不同。
• 平台已有一批可复用模板（assets/quanttide-platform/manifests/github/workflows/ 里的 deploy-site.yml、deploy-studio.yml、react-web-deploy.yml、flutter-web-deploy.yml、myst-deploy.yml 等），但没有任何机制把它们一键套用到新仓库，也没做模板与 per-repo 拷贝的收敛。
• qtcloud-devops CLI 的 src/ 里 0 处 deploy，说明部署尚未纳入工具链。

建议：在 qtcloud-devops 新增 deploy 命令集

与现有 release 同级，作为生命周期的一环（build → test → release → deploy）。建议命令族：

1. deploy scaffold（一键为新仓库生成/获得部署能力）

   • 输入：--domain <host>、--kind site|studio|provider|docs、--stack vite|flutter|python|rust|myst、--bucket <name>（缺省按 {repo}-site 推导）。
   • 输出：生成 deploy-site.yml/deploy-studio.yml（或引用模板的薄 wrapper）+ manifests/terraform/*；自动推导构建目录、CDN 域名、DNS rr、cache-control 策略。
   • 可选 --apply：生成后直接 terraform apply 建桶/CDN/DNS。

2. deploy status（当前仓库部署就绪度）

   • 检查：是否存在 workflow、terraform manifest、所需 org secrets、CDN 域名 status、DNS CNAME、证书 ServerCertificateStatus、SPA 回退是否已配。

3. deploy audit（对现有部署做一致性/漂移审计）

   • 对照平台标准模板，检测：缓存放是否分离（assets 长缓存 / index.html no-cache）、是否缺 SPA 回退、证书状态、私有回源鉴权开关、DNS 记录、site/studio 桶命名是否合规。

4. deploy apply（可选）：把 workflow 里的 build+upload+refresh 抽成 CLI 可调用，支持 --dry-run；也可保留 CI 触发，CLI 只做编排与状态查询。

复用现有资产

• 把 assets/quanttide-platform/manifests/github/workflows/deploy-site.yml 等模板作为脚手架源（deploy scaffold 从模板实例化，替换 build_dir/oss_bucket/cdn_domains 参数）。
• 把 13 份重复的 cdn.tf/site-bucket.tf/studio-bucket.tf 收敛为一个 Terraform module（如 modules/site、modules/studio），per-repo 只用变量调用；甚至由 deploy scaffold 据此生成最小 wrapper。

已知坑（scaffold/audit 应自动处理）

• SSL 证书：terraform 不管理，需绑定。单层子域可用 *.quanttide.com 泛域名；更高层子域需单域名证书。deploy status/audit 应能识别 ServerCertificateStatus=off。
• SPA 回退：React/Router 子路由直接访问/刷新会 404，需 back_to_origin_url_rewrite 改写（本次 qtcrowd 就补了一次）。
• 私有 OSS 回源鉴权：RAM 用户无权限设公共读，CDN 需私有回源（l2_oss_key private_oss_auth=on + 账号级 RAM 角色/策略），且存在控制台开关与首页重写的已知冲突。
• 缓存策略：assets 长缓存（max-age=31536000）+ 入口 index.html 不缓存（no-cache）。
• 域名备案：.quanttide.com 需要 ICP 备案前置。

Open Questions（供维护者决断）

• deploy 应偏向「生成配置」（scaffold / config-as-code）还是「执行上线」（apply / 编排），抑或两者兼顾？
• 模板收敛：以 assets/quanttide-platform/manifests/github/workflows/* 为准，还是以各 per-repo 已上线的为准？建议以后者反推、前者为源，消除两套并存。
• Terraform module 归属：放在 quanttide-platform（共享 IaC）还是 qtcloud-devops？倾向 module 放 platform、CLI 只负责生成/审计。

验收标准（Acceptance Criteria）

1. qtcloud-devops deploy scaffold --domain crowd.quanttide.com --kind site --stack vite 能在空仓库生成一份可用的 deploy-site.yml + terraform（含 SPA 回退、缓存分离、DNS、证书提示），无需手工复制。
2. deploy status 能正确报告某仓库是否就绪（缺 secrets/证书/SPA 回退时给出明确提示）。
3. deploy audit 能对现有 71 份 workflow 做漂移检测，输出差异清单。
4. （阶段二）terraform module 收敛后，13 份 manifest 可瘦身为薄 wrapper。
5. 文档：README 新增 deploy 部分，说明新仓库获得部署能力的标准流程。

[Guo-Zhang]

命名决策：deploy init（而非 scaffold）

讨论后定为 deploy init 作为一键生成/升级部署能力的主命令。

理由

• 就地操作：deploy init 作用于当前仓库，把 deploy-*.yml + manifests/terraform/ 就地写入 .github/ 与 manifests/ 下，是补齐标准配置而非从零产出一套独立项目骨架。这与 git init / terraform init / go mod init / npm init 语义一致。
• 天然涵盖「生成 + 升级」：在已有仓库上重复跑 init 即更新/收敛配置，无需 re-scaffold 这类别扭表述。
• 命令族一致性：deploy init → status → audit → apply，先初始化、再看状态、后审计/应用，读起来顺。

边界：何时才用 scaffold

若未来出现「从模板实例化出一套独立可运行项目」的场景（如 examples/default 实验室那种），scaffold 更贴切。本 issue 的输入是 --domain/--kind/--stack/--bucket，输出是叠加在既有仓库上的部署配置，因此归入 init。

落地

• 主命令 deploy init，支持 --domain/--kind/--stack/--bucket。
• 默认幂等：已存在则合并/提示，--force 全量覆盖；一个入口同时覆盖「生成 + 升级」。
• 如需保留原 issue 措辞，可保留 scaffold 作为 init 的等价别名。