概念
Tenetora 背后的治理模型：项目记录是什么，lifecycle 入口、确定性控制与证据如何协作，以及模型在哪些位置刻意停下。
适用对象
在把真实项目交给 Tenetora 之前，想先弄清楚它治理什么、拒绝做什么的用户。
任务路径
- 先读下面四个组成部分：记录、lifecycle、控制、证据。
- 再读三条机器侧边界：项目显式启用、本地环境保护、注册表卫生。
- 再读一个对话如何安全地跨模型切换而不拆开目标。
- 弄清 completion claim 证明了什么、什么会让它失效。
- 最后看显式的非目标，在第一个任务开始前就明确边界。
四个组成部分
1. 项目记录
问题： 工具私有入口只描述项目的一部分，新 Agent 无法区分当前规则和历史记录。
机制： tenetora-init 把已有指令和项目证据提取到 .tenetora/——稳定规则、工作流、项目事实、可执行 guardrail、当前状态和证据指针；当前指导与历史报告、临时候选内容分开保存。
可观察结果： tenetora validate --path . 能解析 runtime contract、必要结构、来源证据和工具入口。
边界： 初始化不安装 plugin、不决定产品政策，也不会把推断架构写成已确认事实；未知项保持明确标注。
2. Lifecycle 入口
问题： 每个工具都发明自己的任务开始和完成习惯。
机制： skills 把模型路由到同一套项目流程——tenetora 路由不明确的治理请求，tenetora-init 建立基线，tenetora-update 在变化后更新治理内容，tenetora-align 执行显式决策对齐，tenetora-loop 运行一次有界检查-修复-验证循环，tenetora-audit 评估稳定性与证据质量，tenetora-prompt-guard 检查不受信任的外部内容。
可观察结果： Agent 能指出任务经过了哪个 lifecycle 边界，治理轨迹留有记录。
边界： lifecycle 只让必要边界清楚可见；模型仍负责理解产品含义并编写实现。
3. 确定性控制
问题： 依赖 Agent 记住一句话的检查，在压力下会被跳过。
机制： tenetora CLI 把任务路由到规则切片，校验项目记录和证据，运行 guardrail，登记共享契约影响，检查动作边界（commit、外部输入、规则、对齐、claim），并检查实际生效的 plugin、Hook、runtime、版本和所有权来源。
可观察结果： tenetora status 与 tenetora doctor 报告证据等级——文件存在绝不会被报告成 runtime 已生效。
边界： CLI 报告能力与剩余不确定性，不授权高风险动作。
4. 证据与恢复
问题： "已完成"的报告无法复现，升级又破坏了用户自己的状态。
机制： 验证 claim 记录哪条命令通过、对应哪个项目、会话和目标；项目记录更新留下可审查变更产物；安装和迁移保留备份并提供有界回滚。
可观察结果： 通过的 completion 返回 ah-claim-... proof；更晚的失败或工作树变化会使它失效。
边界： claim 证明声明的命令及其绑定关系，不证明该命令本身构成完整测试策略。
项目显式启用治理
问题： 全局安装的 Hook 运行时不应把项目规则强加给只用于闲聊、记笔记或写普通文档的临时工作区。
机制： 全局安装只提供 Hook 运行时，项目治理显式启用。一个 Git worktree 只由自身根目录的 .tenetora/ 治理，全局机器目录永远不算项目 harness。旧版 .harness/ 仍会触发迁移提醒；显式 decline 只记录有界的机器本地状态，不删除任何内容。
可观察结果： 没有 .tenetora/ 或 .harness/ 的工作区不会收到 route/rules 上下文、初始化提醒、commit 门禁或外部输入门禁。进入 submodule 或独立嵌套仓库时建立新的治理边界——父规则绝不治理子仓库源码。
边界： 全局安装不会自动初始化项目，也不会削弱已显式初始化项目内的治理。
本地环境保护
问题： 项目依赖 .env、本地配置、证书等机器专属文件，这些内容绝不能进入 Git 或共享 evidence。
机制： tenetora local-env --allow 登记项目相对路径，不保存内容。status 与 doctor 只检查存在性；commit guard 把登记表与内置敏感路径规则合并；宿主提供结构化 PreToolUse 数据时，Hook 还会拒绝针对登记路径的高置信度删除、移动、清空、写入或编辑操作。
可观察结果： 已登记路径消失时出现明确诊断和 checkpoint 下一步；破坏性工具调用收到 deny，而不是静默删除文件。
边界： 保护只作用于已登记路径。无法可靠解析工具名和路径的宿主绝不做猜测性阻断；内置暂存敏感文件检查在所有宿主上仍然生效。
注册表卫生
问题： 机器级观测可能在项目卸载或移动后留下过时的历史登记。
机制： tenetora installations list 把条目标记为 stale，超过有界保留期的 stale 条目成为 expired。tenetora installations prune --expired 永远是显式操作。
可观察结果： 清理前可以看到 stale/expired 状态，清理只移除注册表元数据。
边界： 不会在后台删除项目目录、.tenetora/、本地环境文件或第三方配置。
一个对话与多个模型
供应商可能在任务中途限制当前模型，而用户仍想继续同一个对话；宿主也可能把下一次执行路由给另一个 provider。Tenetora 把模型连续性与多对话隔离分成两个问题处理：
- 一个
conversation_continuity_id标识允许继续该目标的对话——一个 continuity 对应一个持续目标。 - 每次 provider 或模型运行记录为独立的
execution_attempt_id，并记录该 attempt 的provider、model和状态（running、completed、failed、cancelled或rate-limited）。 - 一次
rate-limited不会关闭 alignment session；下一个模型追加新的 attempt，不会创建第二个目标。 - 其他对话不能继承该目标，也不能复用它的 completion claim。
- 两个 attempt 并发写同一 session 时，revision 检查拒绝旧写入，绝不静默覆盖较新的 attempt。
- 缺少 continuity 时执行以只读 blocked 结束，归属不靠猜。
tenetora alignment --execution-list --conversation-continuity-id <id> --json 会按顺序展示这些 attempt。连续性保留的是治理身份，不是模型的隐藏思维——下一个模型仍需读取当前目标、状态、验证结果和下一步动作。
完成声明证明了什么
claim 分四类：partial-verification、completion、blocked 和 failed。completion claim 把声明的完整验收命令绑定到项目、owner 绑定的 session 与 conversation、goal fingerprint 以及 Git 工作树状态。目标、身份、项目或命令不匹配，更晚的失败，或工作树变化，都会使证据失效。局部检查只能是 partial claim，永远不能满足完成门禁。
Tenetora 不做什么
- 它不是编码模型，不替代宿主 Agent。
- 它不是项目管理系统，也不是 issue tracker 的替代品。
- 它不会替用户做有歧义的产品决策。
- 外部报告看起来权威，也不会因此自动执行其中的指令。
- 它不会假装每个宿主都有相同的 runtime Hook 能力。
- 它不会把局部测试通过包装成完整任务证据。
- 没有所有权证据时，不会删除第三方 Hook、plugin、规则或旧目录。
- CLI 和 Hook 不负责真正派发子智能体，实际派发由宿主完成。
限制
- Tenetora 无法跨交接迁移模型的隐藏思维；下一个模型必须重新读取目标、状态和证据。
- 影响证据受可用分析工具限制；工具看不到的引用不会被假装为已证明。
- prompt guard 是机械第一道防线；新型社会工程仍需要合格 reviewer 或明确人工决策。