# HLCC-PUSH-TO-DEPLOY-EVENT-PROTOCOL

状态：本地实现候选，尚未部署；当前现实层不得宣称可派发

语言层在冰朔明确确认“该提交需要部署”后，主动发出 `guanghu.deployment-intent/v1`。推送本身不会产生部署事件。意图必须绑定：

- 代码频道仓库、分支和完整提交 SHA；
- `REQUEST-ID@完整提交SHA` 的不可变资源；
- `deployment/requests/` 下的部署清单。

语言人格体通过 `/api/deployment/dispatch` 派发这一意图；接口要求一张单独的 `server-ops / dispatch-approved-deployment` 工单，且资源必须为同一 `REQUEST-ID@完整提交SHA`。服务端才写入 `guanghu.deployment-event/v1` 到本机队列。常驻部署 Agent 订阅此队列，读取同一提交中的清单，执行备份、部署、健康检查与回滚，并将回执回写到原工单。

没有部署意图的提交照常入库，回执为 `not_requested`；无效意图回执为 `rejected`，不会部署。推送工单绝不扩大为部署权限；服务器也不扫描仓库主动拉取部署。

`resource` 中的 `REQUEST-ID` 必须与清单文件名完全一致：`deployment/requests/<REQUEST-ID>.json`。批准 A 而执行 B 必须在派发端和常驻 Agent 端分别拒绝。

首次新单元使用 `guanghu.architecture-provision-request/v1`；已经在线的 systemd 服务必须使用 `guanghu.existing-service-update-request/v1`，先完整备份声明目标，再重启和逐项验收，失败恢复全部旧文件与旧单元。二者不得互相冒充。

当前京东节点若尚未安装 `/api/deployment/dispatch`、事件队列和常驻 worker，则先通过已有的主人邮件批准固定管理动作引导这套运行时。没有这个固定引导动作时应回执 `BOOTSTRAP_ACTION_NOT_DEPLOYED`，不得绕回人类 SSH 或云控制台，也不得发送一张服务器根本不会执行的部署工单。