用途与实际影响
这项功能怎样使用
为什么需要它
一项任务里常会同时出现这轮新要求、项目自己的规矩、全局规则、历史说明和当前状态。解释权不清楚，AI 就可能让旧计划盖过用户更正，或用通用做法盖过项目真实验收。
举个实际例子
我会直接说：“按这个项目自己的测试把问题修好，别拿上个月的报告当现状；如果发布状态和电脑状态对不上，就分别查清。”系统先读这轮要求和最近的项目规则，需要仓库事实才查 Git，需要机器事实才查 PCConfig；我拿到的是各来源的当前结论，不是一份拼出来的故事。
最后我会得到什么
任务会从有效规则和当前事实出发。若两个来源真的冲突，系统只停受影响的判断，告诉我冲突在哪里、该由谁裁定，以及其余工作还能不能继续。
正常时
这次要求、项目约定和现场事实对得上时，按项目自己的方式继续。
发现问题时
两份来源确实冲突时只停依赖它的步骤，说明应该由谁核实。
入口不可用或证据不足时
必要规则或现场暂时读不到时写清无法判断，不让旧报告冒充现在。
从哪里开始
在已接入活动 E 规则的 AI 对话中说出项目和具体问题，请它按当前规则处理。
需要准备什么
- 项目名称与目标
- 这轮更正或限制
从开始到拿到结果
- 1
先说清本次要求与项目
AI 先核对这轮原话、活动规则和项目自身约定，找到这件事由谁解释。
- 2
把事实交给正确来源
代码仓库的发布状态查 GitHub 总索引，电脑路径和任务查 PCConfig，具体功能问所属项目；旧报告只作线索。
- 3
交回决定与冲突
说明能继续的动作、确切依据；若两份有效来源冲突，只暂停受影响的判断并指出下一处取证入口。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
已落地并处于活动规则中关键规则与设计选择
项目有更具体规则时，优先按项目规则执行。
需要 Git 或机器动态事实时，改去对应控制面现场读取。
只有当前问题真正触发时才展开专项合同。
来源冲突无法同时满足时停止，不用猜测拼接。
本模块用到的名词
- Fact Owner（事实责任源）
- 某类动态事实的唯一负责来源。文档指针可以导航，但不能代替它的现场回读。
- Project rule nonoverride（项目规则通常不覆盖）
- 全局规则不能改写具体项目的业务语义、命令或兼容约束。授权合同拥有两项窄例外：PUBLIC（公开） 个人数据分级及项目收紧 L1/L2 默认的授权条件；既有耐久明确授权的解释，项目不能把它降为不存在或要求同轮重述。
- 渐进读取
- 先确认 metadata（元数据） 是否相关，再读取必要正文，不把全部合同机械灌进每个任务。
专业定义
先弄清这次该听谁的、现场事实该去哪里查；遇到冲突就指出责任来源，不把几份旧材料硬拼成答案。
解决什么
当全局要求、项目规则、历史文档和现场状态同时存在时，必须有一套稳定方法判断谁拥有事实、哪一层优先，否则模型会把旧报告当规则、用全局原则覆盖项目业务，或者一次性加载所有材料后丢失注意力。
当前怎样实现
- 根规则只保留跨项目元规则和硬边界；保护、授权、三控制面和能力选择分别下沉到专项合同。
- 项目根到当前目录链上的最近规则拥有业务语义、真实命令、兼容、生成区、Owner 和项目安全；全局通常只能取交集或收紧。窄例外是授权合同唯一拥有的 PUBLIC（公开） 个人数据分级与项目收紧授权。
- contract catalog（目录） 只保存触发 metadata（元数据）、owner、文档和 validator（校验器） 指针。模型先看 metadata（元数据），再按当前决定的信息价值读取正文。
- 历史计划、报告、生成物和记忆只作线索，不会自动成为当前指令或动态事实。
执行流程
- 1
Inspect current（当前状态） E release 并取得同一 ruleset 的根规则
- 2
读取当前项目最近的规则并确定业务 Owner
- 3
用 catalog（目录） metadata（元数据） 判断是否需要保护、授权、能力或三控制面合同
- 4
只展开会改变当前决定的正文和现场 Provider（事实入口）
- 5
发生冲突时按上位指令、项目语义和全局硬边界逐层处理
边界
- README 和操作指南面向人，不是执行规则或动态权威
- catalog（目录） 只能选择候选正文，不能证明某个 effect（外部现实动作） 已发生
- 全局规则不能以统一为理由覆盖项目业务与测试；项目若要收紧 L1/L2 公开默认，必须有真实需要和用户对精确项目、范围、限制的明确授权
- 兼容文件名和历史命名不能恢复已经退役的控制面；本人已冻结的项目，批量“全部完善”也默认不读代码、不主动维护；之后明确提出该项目的具体需求，就只处理这次范围，不需要额外解除口令，也不恢复日常维护。目录、服务或备份仍存在，不等于允许主动改动。
失败与恢复
- 规则优先级冲突
- 保留冲突两端的原文和 Owner；无法同时满足时失败关闭并说清差异。
- catalog（目录） 缺项或 schema（数据结构） 漂移
- 停止依赖该 catalog（目录） 的跨控制面结论，回到真实 Owner 修复 coverage。
- 人类指南与活动规则不一致
- current（当前状态） E release 继续作为权威，同时把过期指南视为待修缺陷。
真实入口
E:\.agents\AGENTS.md跨项目根规则的 canonical source（唯一维护源）
E:\.agents\docs\contracts\README.md合同导航和三控制面关系说明
E:\.agents\config\control-plane-contract-catalog.json触发 metadata（元数据）、owner 和 validator（校验器） 的唯一目录
如何验证
- E rules Inspect 确认根规则来自 current（当前状态） E171 release，而不是 dirty canonical source（唯一维护源） 或 C 盘历史
- GlobalRulesStructure 验证根承诺唯一性、合同指针和字符预算
- ContractCatalog 与 ContractRouting 验证 schema（数据结构）、路由和 unknown（未验证） trigger 的失败关闭
- 跨控制面 coverage 单独验证所有 owner 合同是否进入 catalog（目录）
与其他模块的关系
这个模块决定从哪里开始和应该读什么；能力路由决定怎样做，授权与 Owner 决定谁可以做，保护策略决定重大动作依据哪一代规则。