feat(hlcc): dispatch approved deployments by explicit signal

deployment/HLCC-AI-PUSH-WORKFLOW.hdlp

@@ -42,9 +42,11 @@ Content-Type: application/json
 
 接口返回 `request_url` 后，AI 只把链接交给冰朔。冰朔核对目标节点、仓库、范围和说明，确认后授权邮件才会发往服务器预登记邮箱。AI 不得绕过该步骤，也不得要求冰朔提供邮箱密码或授权码。
 
-## 3. 授权完成后的推送
+## 3. 授权完成后的安全推送
 
-授权会话只允许已登记的 `repo-push` 能力，默认短时有效，持续执行同一绑定任务时可自动续期。AI 回到原任务后，用人类已配置的 Git 凭据管理器推送：
+授权会话只允许已登记的 `repo-push` 能力，默认短时有效，持续执行同一绑定任务时可自动续期。AI 必须先读取操作回执；许可本身不是 Git 登录凭证。安全 bundle 接收器尚未部署时，回执会明确返回 `repo_push_transport_unavailable`，此时停止，不得把它误判为密码问题或反复重试。
+
+安全接收器部署后，AI 依照回执所给的受限上传路径提交 bundle；服务器校验仓库、分支、预期远端 SHA、快进关系后，使用代码频道的正常接收路径写入。下面的普通 Git 命令仅是人工已拥有独立凭据时的兼容路径：
 
 ```text
 git remote set-url origin https://guanghulab.com/code/bingshuo/guanghu-ice-heart.git
@@ -53,6 +55,12 @@ git push origin HEAD:main
 
 不要把密码写入 remote URL、脚本、提交、日志或聊天记录。共享电脑或临时环境完成后应清理凭据。
 
+## 3.1 推送后的自动部署事件
+
+只有冰朔与语言层明确确认“该提交需要部署”后，提交模块的人格体才发出第二个、与完整提交 SHA 绑定的 `guanghu.deployment-intent/v1`。它通过单独的 `server-ops / dispatch-approved-deployment` 工单派发到京东服务器本机队列；常驻部署 Agent 自动响应，完成清单校验、备份、部署、健康检查与回滚回执。冰朔不需要重新描述任务，但部署范围仍必须明确批准。
+
+没有部署意图的提交仅入库，回执为 `not_requested`。推送授权不能偷渡扩大为部署授权；服务器不扫描仓库自行拉取部署。
+
 ## 4. 被拒绝时
 
 遇到 `repo_push_grant_expired`、`authorization_pending`、`NO_TRUSTED_PATH` 或目标仓库不匹配：停止重试，保留本地完整 SHA，重新创建 `repo-push` 工单，并等待冰朔确认。登录失败时先检查是否误用了旧入口或旧 Token，不要把凭据粘贴到聊天中。

deployment/HLCC-PUSH-TO-DEPLOY-EVENT-PROTOCOL.hdlp

@@ -0,0 +1,13 @@
+# 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`，不会部署。推送工单绝不扩大为部署权限；服务器也不扫描仓库主动拉取部署。