实现预分配 RunnerService facade

docs/runner-protocol-roadmap.md

@@ -22,6 +22,12 @@ controller 使用单一 Go 二进制；默认在同一进程启用 `scheduler`
 `vm-worker`，也可通过 `--components` 只启用其中一部分。组件是独立应用服务边界，
 共享进程不意味着共享后端状态或把 assignment 降级为内存 channel。
 
+executor 直接运行固定版本的官方 Gitea Runner 二进制，不 fork workflow 执行引擎。
+controller 暴露兼容 RunnerService 的 facade：`FetchTask` 只返回已分配 assignment，
+`UpdateTask` 与 `UpdateLog` 转发真实 Gitea。facade 同时验证逻辑 SPIFFE ID、assignment
+ID，以及由 controller 密钥确定性生成的 assignment HMAC capability；该 capability
+只绑定执行实例，不参与 Zot/OpenBao 等业务授权。
+
 这与“收到 webhook 后临时注册另一个 act_runner”不同。`FetchTask` 已经完成任务分配，
 不能再期待 Gitea 把同一个 task 分配给随后启动的 runner。协议调度器必须让 executor
 执行已经领取的 task，并继续完成日志、状态、心跳、取消和最终结果上报。
@@ -58,6 +64,8 @@ controller 使用单一 Go 二进制；默认在同一进程启用 `scheduler`
   Pod UID 等短暂未就绪状态以及临时后端错误使用延迟 NAK。
 - assignment ACK 后的运行、结果回报和清理由 backend reconciler 根据 Kubernetes、
   OpenSandbox 与 Gitea 的事实状态驱动，不继续占用 JetStream delivery。
+- consumer 在 executor 使用上述 facade 成功 claim task 后确认 assignment；无需把完整
+  task 写入 Pod annotation、OpenSandbox metadata 或环境变量。
 - Pod 与 VM 共享 task/executor 协议，只有环境创建和销毁实现不同。
 
 ## 实现顺序