建立 Pod 与 VM 调度消息契约

docs/design-principles.md

@@ -28,6 +28,12 @@ ephemeral runner，只执行一个 job；任务结束后注销 runner，并删
 `job_id` 仅用于消息去重、状态追踪、实例关联和失败清理，不进入 workload 身份，也
 不参与资源授权。
 
+Gitea 不保证由某次 `queued` webhook 创建的 runner 一定领取该 webhook 对应的 job。
+因此创建环境时只赋予无业务权限的启动身份。runner 实际领取任务后，controller 根据
+`in_progress` webhook 返回的 `runner_name` 和真实 job 名称绑定业务身份；环境中的
+job-start hook 必须等目标 SVID 可用后才放行 workflow 的第一步。不能依据 queued
+事件提前赋予任务权限。
+
 ## 环境只提供运行边界
 
 基础镜像只提供启动 runner 和执行 workflow 所需的最小环境。Docker、BuildKit、
@@ -48,14 +54,15 @@ kind 等工具由 pipeline 按需安装和启动，而不是由 controller 预
 SPIFFE ID 由具有业务意义且稳定的 workflow 上下文派生：
 
 ```text
-spiffe://ddupan.top/ci/<owner>/<repository>/<workflow>/<job-name>
+spiffe://ddupan.top/ci/<owner>/<repository>/<job-name>
 ```
 
 同一种任务在不同运行中使用相同的逻辑 SPIFFE ID；每次运行取得独立、短期的 SVID。
 Pod 与 VM 是可替换的执行实现，因此默认不写入 SPIFFE ID。
 
-workflow 和 job 名称必须经过确定性的路径规范化。规范化结果必须保留仓库边界，并在
-发生冲突时拒绝创建环境，不能静默地让两个任务共享身份。
+job 名称必须经过确定性的路径规范化。规范化结果必须保留仓库边界，并在发生冲突时
+拒绝创建环境，不能静默地让两个任务共享身份。同一仓库内需要不同权限的任务应使用
+不同的 job 名称；workflow 文件只是编排载体，不进入权限身份。
 
 ## Self-service 与授权边界
 
@@ -64,7 +71,7 @@ allowlist。能够修改仓库 CI 的主体本来就能修改该仓库已有任
 重复审批不能形成额外的安全边界，只会破坏 self-service。
 
 身份不等于权限。新任务可以立即取得自己的 SPIFFE ID，但默认不会因此获得 Zot、
-OpenBao 或其他资源的特殊权限。资源所有者在资源端按照有意义的 workflow/job 身份
+OpenBao 或其他资源的特殊权限。资源所有者在资源端按照有意义的 job 身份
 配置授权策略。
 
 ## 非目标设计