kxenBots -> 创建 Bot 把自然语言需求转换为可验证的 Bot definition。这里不存在一个拥有固定人格的全局 Builder Bot。每个 Bot 从取得自己的 identity 开始，就拥有一项只服务于自身定义的受限 self-builder capability，并以自己的名称回复 Owner。
self-builder 只运行在 design-time BuilderSession 中，不是已发布的 BotRun。它可以追问并提出完整草稿，但不能替 Owner 获得权限、执行工具或直接发布。
创建流程
- 输入 Bot 名称，以及需要长期重复完成的工作、输入、输出和成功标准。系统先创建该 Bot 的稳定 identity 和
BuilderSession。 - Bot 通过自己的 self-builder capability，根据 runtime capability catalog 回复、追问并生成草稿。
- 继续与这个 Bot 对话，检查 system prompt、输入输出契约、预算、工具、Connector、路径和 Bot-to-Bot policy。
- 展开检查 capability、Workspace path、Connector、contract、budget、context、memory、approval 和 Bot-to-Bot policy；Owner 输入授权理由后，授权绑定当前草稿 hash 的完整权限快照。
- 运行 controlled test，保存结构化测试结果。
- 通过 deterministic validation 后发布 immutable revision。
BuilderSession 是 durable 的。切换页面或重启后，从 Bot 管理 选择该 Bot 并点击「与 Bot 对话编辑」，应用会自动恢复它最近的 active 构建对话，不要求用户保存或输入内部 Session ID。需要分离新的调整上下文时，也可以为同一个 Bot 开始新一轮对话。
self-builder 的身份与限制
- 每条新回复和草稿变更都由目标 Bot identity 记录；其他 Bot 不能修改这个
BuilderSession。 - self-builder 只能从当前 runtime catalog 选择真实存在的 capability。
- self-builder 不能自行增加 Workspace path、Connector、MCP server 或审批豁免。
- design-time 对话没有可继承给正式 BotRun 的工具权限。
- self-builder 不能运行工具、创建 Routine 或 Group，也不能绕过 controlled test、validation 或 Owner publish。
- grant、controlled test、validation 触发、publish 和 cancel 都是 Owner 或 Runtime 的独立命令，不是 Bot 自助操作。授权理由不能为空。
- 不存在的 tool、Skill 或 Connector 会 validation
FAIL，不会作为占位能力发布。
Evidence 绑定
授权、controlled test 和 validation report 都绑定草稿的精确 content hash。任何会改变执行行为的草稿修改都会使旧 evidence 失效，必须重新授权、测试和验证。
这条规则防止先测试低权限定义，再在发布前偷偷扩大路径、Connector、预算或 peer policy。
发布前检查
- 输入和输出 contract 能覆盖真实调用方。
- required fields 与 controlled test 使用的数据一致。
- capability 和路径是完成任务所需的最小集合。
- Connector 属于当前 Workspace，并且 MCP server grant 精确匹配。
- Approval policy 不把高风险副作用改成永久授权。
- budget、turn、tool call 和协作深度上限足够但不过度放宽。
- Bot-to-Bot direct policy 只包含确实需要协作的 peer。
发布完成后，从 Bot 管理 手动运行，再按需要创建 Routine 或 Bot-to-Bot Conversation。