fix: 统一发布计划与 webhook identity

project-management/PJ2026-01/specs/PJ2026-010601-controlled-release.md

@@ -69,7 +69,7 @@
 | 边界项 | 内容 |
 | --- | --- |
 | 外部使用者 | 平台管理员、发布操作人员、服务维护者和需要发布状态的业务模块。 |
-| 外部输入 | source commit、deploy 配置、lane 选择、发布计划请求、带计划指纹的手动触发请求、SecretRef presence 和验证请求。 |
+| 外部输入 | source commit、deploy 配置、lane 选择、发布计划请求、带 `plan identity` 的手动触发请求、SecretRef presence 和验证请求。 |
 | 受控资源 | Tekton PipelineRun、Argo Application、runtime namespace、workload、image、release status、health/readiness 和发布判定结果。 |
 | 外部输出 | PipelineRun 状态、image digest、promotion revision、Argo sync 状态、runtime readiness、发布候选结论和 redacted 失败信息。 |
 | 用户接口 | UniDesk CI/CD CLI、服务自有 CLI 发布/验证相关入口、服务 health/readiness、Tekton/Argo 受控状态查询入口。 |
@@ -85,7 +85,7 @@
 | PJ2026-01060102 | 镜像Promotion | 本规格 6.2 | env image reuse、digest-pinned image、artifact promotion 和 image readiness | Source commit、Containerfile、registry | 需要运行镜像的服务 |
 | PJ2026-01060103 | 发布判定 | 本规格 6.3 | source/GitOps/runtime 一致性、health/readiness 和 migration/SecretRef presence | CI/CD、GitOps、YAML运维 | 平台管理员、业务模块 |
 | PJ2026-01060104 | 验证分层 | 本规格 6.4 | 自测试、综合联调、CLI/API 交互和真实运行面通过口径 | 目标 runtime、业务模块测试需求 | 发布决策 |
-| PJ2026-01060108 | 手动发布 | 本规格 6.5 | L2/L3 发布计划、范围审阅和带计划指纹的受控手动触发 | 源码同步、YAML运维、镜像Promotion | 全部 L2/L3 runtime 服务 |
+| PJ2026-01060108 | 手动发布 | 本规格 6.5 | L2/L3 发布计划、范围审阅和带 plan identity 的受控手动触发 | 源码同步、YAML运维、镜像Promotion | 全部 L2/L3 runtime 服务 |
 | PJ2026-01060105 | AgentRun发布 | [PJ2026-01060105 AgentRun发布Lane](PJ2026-01060105-agentrun-v01-release-lane.md) | AgentRun `v0.1` 的发布 lane、Pipeline、runtime namespace 和真实联调细则 | 源码同步、YAML运维、Agent编排 | AgentRun runtime |
 | PJ2026-01060106 | HWLAB双环境 | [PJ2026-01060106 HWLAB双环境](PJ2026-01060106-hwlab-dev-production-lanes.md) | HWLAB `v0.3` development 与 `release` production 的分支、流水线、公开入口和数据隔离 | 源码同步、YAML运维、Workbench实时权威 | HWLAB runtime |
 | PJ2026-01060107 | NC01 CI资源治理 | [PJ2026-01060107 NC01 CI资源治理](PJ2026-01060107-nc01-ci-resource-governance.md) | NC01 构建并发、排队、资源合同、稳定去重和核心运行面保护 | 发布流水、YAML运维、CI/CD目标治理 | NC01 CI 与核心服务 |
@@ -152,6 +152,21 @@ L2 与 L3 发布必须使用 `plan -> 人工审阅 -> trigger` 的受控手动
 
 `plan` 必须是只读操作，并针对精确 target、lane 和 source commit 输出：env identity 及 reuse/build 判定、待构建镜像数量与服务列表、待 rollout 服务、全部受影响服务、范围基线和相对基线新增项。`plan` 不得同步 mirror、创建 snapshot、修改 branch、创建 PipelineRun 或写入运行面。
 
+- `plan identity` 必须由规范化的计划输入与执行范围确定：
+  - 输入至少绑定 target、consumer、lane、source commit、base commit、catalog authority、catalog source、catalog digest、registry probe 模式和结果；
+  - 执行范围至少绑定 build、rollout 和 affected 服务列表；
+  - 列表与对象键必须规范排序，时间戳、临时路径和运行编号不得参与 identity；
+  - 相同输入与范围必须产生相同 identity，任一绑定输入或范围变化必须产生不同 identity。
+- `trigger` 必须显式携带操作者刚审阅的 `plan identity`：
+  - 发送 webhook 前必须用当前 source、base、catalog 和 registry 输入重新生成计划；
+  - 重算 identity 与已审阅 identity 不一致时不得发送 webhook；
+  - webhook 只携带规范化计划事实，不引入可变计划存储或第二 authority。
+- Pipeline 必须在 build 前用同一组输入重新生成计划：
+  - 实际 identity 与 webhook 携带的已审阅 identity 不一致时立即失败；
+  - build、rollout 或 affected 范围任一扩大时必须输出 expected、actual 和新增服务；
+  - identity 校验通过前不得启动镜像构建，CLI 显示 `build=0` 时 Pipeline 不得构建镜像；
+  - 不得通过补跑、提高 timeout、忽略 warning 或继续后续 Task 绕过该失败。
+
 `plan` 恢复 artifact catalog 时必须满足：
 
 - 读取 owning YAML 声明的 GitOps read URL 与 branch；