用途：Ulysses 是 Thoughtbox 拥有的调试协议，用于调试变得不确定时，强制显式记录计划、结果与反思。协议不变量位于服务端 tb.ulysses(...) 实现中，持久轨迹保存在 Thoughtbox 的 thoughts 与 knowledge 中，Codex hooks 仅执行当前服务端状态。
主要能力：通过 Code Mode 的公开 MCP 接口操作，发现用 thoughtbox_search，执行用 thoughtbox_execute，协议操作为 tb.ulysses({ ... })。支持 init（问题与可选约束）、plan（主行动、恢复行动及绑定验证器单元）、outcome（提交观测数据，由验证器判定）、bind_final_validator、reflect（可证伪假设与证伪标准）、status、complete。验证器是 notebook 代码单元，读取 process.env.TB_OBSERVED_PATH 并写入 process.env.TB_VERDICT_PATH，可用自动生成的 ./tb-validate.js 辅助函数 observed、pass、fail。单元在 plan 时按源码、package.json、tsconfig 的 sha256 快照冻结，后续编辑不影响判定。
使用方式：每次 thoughtbox_execute 最多包含一个会改变状态的 Ulysses 操作；只读的 status 可安全用于状态检查。进入协议为显式操作。若需 schema 或示例确认，先调用 thoughtbox_search。示例：async () => { return await tb.ulysses({ operation: "status" }); }。plan 前不得行动。outcome 的 observed 为任意可 JSON 序列化值，验证器通过则 S→0 并检查点，S=1 失败则 S→2 并待恢复，S=2 失败则记录 forbidden_moves 并要求 REFLECT；快照哈希不匹配会立即强制 S=2 并记录 validator_tampering。
适用场景：调试不确定、需要可审计计划与结果、需要防止事后修改判定标准、需要可复用知识产物的场景。
限制：v1 仅显式进入；服务端报告 S=2 时 hooks 可能阻止变更操作，只读检查仍允许；辅助代理只能在 reflect 后收集证据，且只有协调者调用 tb.ulysses；子代理不得调用 tb.ulysses，hooks 不得自动生成子代理；complete(resolved) 在绑定最终验证器时被硬性门控，验证器失败或哈希不匹配则拒绝；其他终态 insufficient_information、environment_compromised 不运行最终验证器。不要使用 .ulysses/ 文件或 scripts/ulysses.sh 作为权威状态，也不要在 Code Mode 可用时使用 thoughtbox_gateway 或 thoughtbox_ulysses 等旧直接句柄。验证器需确定性，同一观测输入必须产生同一判定；应在执行步骤前编写单元。协议实现见 src/protocol/ulysses-tool.ts，规范参考 references/protocol-spec.md。