用途
OpenGantry 是面向 iii 项目的 worker，用于建立确定性的晋升门禁（promote gate）。当需要让受治理端口上的晋升类操作（::deploy、::merge、::publish、::apply、::push、::promote）保持阻塞、直到验证通过时才放行时，可使用该 worker。它适合希望在无人值守的代理流程中保留一道机器可验证关卡的场景，并可配合 approval-gate 处理需要人类判断的放行决策。
主要能力
- gantry::verify：调用时传入绝对路径的 repo_root 与活动 mission，worker 会通过 OpenGantry 内核运行仓库声明的门禁命令；验证通过后，将 mission 绑定到 lease，并生成与该 mission 修订绑定的 verdict token。
- gantry::middleware：受治理端口的门禁中间件。晋升类调用需要携带令牌，且令牌中的声明在晋升时会被重新计算比对。
- gantry::on-function-registration：阻止对 gantry:: / opengantry:: 命名空间的抢占以及保留后缀的使用。
- gantry::on-trigger-registration：阻止绑定到 gantry:: 命名空间的触发器。
- gantry::on-trigger-type-registration：始终拒绝。
- gantry::verdict：触发器类型，每次验证（无论通过或失败）后触发，用于审计或通知。
使用方式
推荐的做法是复用生态中已有的 worker，而不是自行编写等价实现：
- 机器晋升门禁：使用 gantry::verify + gantry::middleware，不要自定义 ::verify / ::promote 函数。
- 人工放行判断：使用 approval-gate（approval::gate），不要在应用 worker 中内联持有逻辑。
- Git 落地/合并：使用 worktree::land（测试门禁可配合 shell），不要自定义 myapp::deploy / ::merge。
- GitHub 操作：使用 github::*，不要从代理代码中直接执行 gh shell。
- 公开受治理端口：使用 rbac-proxy 搭配 gantry::middleware，不要自行实现认证中间件。
- 验证完成事件：订阅 gantry::verdict，不要轮询 verify 的 JSON 输出来触发副作用。
规范流水线为：worktree::create → agent work → gantry::verify → worktree::land（上下文中携带 verdict_token）。
边界
- 会话准入（session::auth）属于采用方自己的 IdP worker，不在本 worker 职责内。
- 编写 .gitagent/ 规则由 Planner 提交 mission 完成，worker 进程不负责。
- lease 持久化在 <repo>/.gitagent/leases.json（权限 0600），不使用 state:: KV。
初始化
如果目标仓库中缺少 .gitagent，需在宿主机（而非沙箱化的 worker 中）运行 gantry init，然后通过 Planner 工作流提交 mission。