CloudBase Declarative Deploy 是一个声明式部署技能：用一份 cloudbaserc 配置作为期望状态，部署整个 CloudBase 项目，通过 deployBuild（本地托管构建）、deployPlan（dry-run 预演）和 deployApply（应用）三个 MCP 工具完成。编排器按固定依赖顺序应用资源：database → functions → app → hosting → gateway。
【适用场景】 项目存在 cloudbaserc.json / .yaml / .yml / .js 且描述多个资源，用户希望作为一份配置整体部署；用户提出声明式部署、配置式部署、从 cloudbaserc 部署或部署整个项目；用户希望在应用前预览变更（dry-run 计划）；用户希望先在本地构建静态托管产物（声明式托管部署不再隐式构建，见 deployBuild）；通过 mode + envOverrides 进行多环境（生产/预发）部署。
【不适用场景】 通过 tcb CLI 部署单个云函数或单个静态站点（应使用 cloudbase-cli 技能）；应用内 SDK 集成（web/小程序/node，应使用对应 SDK 技能）；控制台 UI 操作。
【云模式说明】 deployBuild / deployPlan / deployApply 是本技能的本地形式声明式执行器。在云端托管 MCP 模式下，这些工具被有意不注册（在工具注册阶段被过滤），因为该运行时没有本地 cwd 或绑定文件系统的执行路径。若处于云模式且工具列表中看不到它们，属预期行为。此时改用云端上传通道：调用 queryApps(action=getUploadUrl) 获取 uploadUrl、uploadHeaders、unixTimestamp；携带返回头将源/构建 zip 上传到 uploadUrl；若云端构建需要私有/离线依赖，需显式打包 node_modules，公有依赖通常上传 package.json + lockfile 即可；再调用 manageApps(action=deployApp, cosTimestamp=<unixTimestamp>, installCmd?, buildCmd?, deployCmd?)；installCmd / buildCmd / deployCmd 是在云端容器中执行的流水线声明，智能体只传递数据与声明，不执行本地 shell 命令。规划的云端声明式路径（增量路线图）为：将 cloudbaserc 作为数据产物上传，再在服务端运行 plan/apply 编排；deployApply 仍是同一声明式规范的本地形式执行器。参数细节见 references/plan-and-apply.md（云端托管上传流水线路径）。
【核心原则】 先计划后应用——始终先运行 deployPlan（dry-run，零副作用），读取每个资源的动作分类并展示给用户后再调用 deployApply。应用需显式确认——deployApply 除非传入 confirm=true，否则拒绝执行，这是破坏性写入防护。部署门禁——任何 apply 前需完成 cloudbase-platform/references/protocols/deployment-gate.md 并给出强制声明。默认对已有资源保守——yes 默认为 false，已有资源被跳过而非覆盖；仅当用户明确希望覆盖/更新已有资源时才传 yes=true。database 失败必定中止——即使 continueOnError=true，database 阶段失败也会停止整个部署，因为后续资源依赖它。显式解析 envId——不要依赖隐式默认值，需明确目标环境并应用前与用户确认。
【计划动作分类】 deployPlan 返回资源条目列表，每个 status 含义：create（新资源，将被创建）、update（已存在，将被覆盖/更新）、skip（无需变化）、conflict（检测到冲突，部署将中止，必须先解决）、deploy（直接覆盖上传）。若任一条目为 conflict，停止并在应用前解决。
【envId 解析优先级】 显式 envId 参数 > cloudbaserc 中的 envId > 已登录/绑定的环境。若均无法解析，工具报错。建议在生产环境应用前与用户确认解析出的 envId。
【本地工作流（build → plan → apply）】 当 hosting 声明了 buildCommand，声明式部署为三步流程，deployApply 不再隐式运行本地构建：一、确保项目根目录（cwd）下存在 cloudbaserc 配置；二、先构建（仅当 hosting 有 buildCommand 时），调用 deployBuild({ cwd, mode? }) 生成本地产物（构建每个 hosting 项；没有构建命令的纯静态项自动跳过）；若 apply 时构建产物缺失，deployApply 会以 BUILD_OUTPUT_NOT_FOUND 失败并指引回到此步——先调用 deployBuild 再重试。deployBuild 不需要 envId 也不需要 confirm（仅本地构建，绝不触碰云资源）；若依赖未安装会以 DEPENDENCY_NOT_INSTALLED 失败并提示先运行 install。三、调用 deployPlan（可选带 mode、envId、only、skip），阅读计划。四、向用户展示计划与部署门禁声明并获取确认。五、调用 deployApply 并传 confirm=true（按需传 yes / concurrency / continueOnError），复用与计划相同的 mode / envId / only / skip。已有构建产物的 hosting 项会被直接上传（工具会清除构建命令并报告 hostingNeutralized: true）；源码变更后需用 deployBuild 重新构建，以免上传过期产物。六、向用户回报应用结果。云托管 MCP 模式下，不要请求本地 cwd/文件系统读取，改用上述云模式上传通道流程。
【构建与流水线执行】 心智模型：build → plan → apply，构建执行器取决于资源类型。hosting：deployBuild（本地 shell 构建，应用前运行），deployApply 直接上传构建产物，产物缺失则 BUILD_OUTPUT_NOT_FOUND；app（framework=static）：本地预构建产物，包上传 + 部署记录；app（非静态框架）：云端流水线，源码 zip 上传 + 云端构建 + 部署；functions：本地 zip / 云端构建 / 镜像流水线，取决于 buildStrategy（zip/cloud/local/image）。deployBuild 会构建每个有 buildCommand 的 hosting 项（框架映射或 package.json 自动检测），跳过纯静态项。构建失败表现为 BUILD_FAILED，本地依赖缺失为 DEPENDENCY_NOT_INSTALLED（先运行 install——deployBuild 不会替你安装依赖）。构建命令解析遵循声明优先级：显式配置 > 框架映射默认 > package.json 自动检测。buildCommand / installCommand / deployCmd 是配置中的声明式意图，执行归属取决于路径：本地形式路径的某些步骤可能在本地 shell 执行器运行；云托管路径的命令由云流水线容器执行（staticCmd），或被预构建产物上传取代。因此“云模式能否运行本地 CLI 命令”的答案是：执行权从本地 shell 转移到云流水线，智能体只传递声明与产物。
【路由】 cloudbaserc 资源字段与期望状态配置形态 → references/config-schema.md；deployPlan → deployApply 两步流程、参数、安全 → references/plan-and-apply.md；多环境（mode / envOverrides）、envId 优先级、环境变量 → references/multi-env.md；参数细节（云端托管上传流水线路径）见 references/plan-and-apply.md。
【最小自检】 hosting 声明 buildCommand 时是否先构建了托管产物（deployBuild）？deployApply 前是否运行了 deployPlan 并阅读动作分类？是否解析并确认目标 envId？应用前是否完成部署门禁声明？是否仅在用户确认后才传 confirm=true？除非明确要求覆盖已有资源，是否保持 yes=false？应用前是否处理了任何 conflict 条目？
【参考索引】所有打包参考文件（技能检查可达性所需）：config-schema.md、plan-and-apply.md、multi-env.md。