operationalize

将经验转化为可操作方案

将反复出现且有引用佐证的专业知识，转化为可复用产物的提案。

1. 要求提供有引用佐证的专业知识：真实发生过的实例，或明确的权威来源；若提案要将规则抽象出来，还须满足下文的三实例门槛。
2. 说明触发情境、期望行为、输入、输出、反例和证据。
3. 在选择产物形式前，先通过流程产物创建门槛。拟议的证书、台账、仪表板、矩阵、元报告、就绪度审查、推测性检查、技能或工作流，必须明确其具体使用者、它所把关的主题或发布决策、为其提供依据的已观察缺陷类别，以及其删除条件。仅为使用该产物而引入的代码或流程不符合要求。若有任何一项未明确，则不提议创建产物，并转而处理调用方要求的主题。仅在防止已明确指出的证据丢失或损坏模式所必需时，才允许保留最少的完整性或恢复状态。
4. 选择最精简且合适的形式：参考资料、技能、确定性检查，或由调用方负责的工作流。
5. 搜索现有能力，并优先扩展而非重复创建。
6. 提供启用示例、保留样本／反例、负责人，以及回滚或删除条件。
7. 将提案直接返回给调用方或撰写专员。若调用方要求创建持久化产物，先将其写入 .agents/scratch/operationalize/，再返回路径；无论哪种情况，提案都仅供参考。

三实例门槛

一条规则必须有三个真实实例，才能抽象出来。只统计实际发生且可引用的实例——例如会话、差异、判定或本仓库中可查证的产物——不统计假设案例或同一事件的复述。只有一两个实例时，改为提议一份以引文为依据的参考说明，不要进一步抽象成规则。只有在提案逐字转录明确的权威来源、而不做超出该来源的概括时，才可用该来源替代实例。这里明确指出的失败模式是过早抽象：从一个鲜明的单一事件中归纳出规则，把该事件中的偶然因素写成政策。

再应用证明

每条拟议规则都必须附带再应用证明：展示按当前措辞应用该规则时，无需额外上下文，就能在至少一个来源实例上得出正确判定。如果将草拟的规则应用到其来源场景时还需要未写明的判断，则该规则尚不可操作——应收紧措辞，直到再应用成功；或将提案降级为参考资料。若提案会创建流程，再应用证明还必须展示创建门槛能得出正确的创建或放弃判定。没有再应用证明，就不提出规则。

引文锚点库

每条规则都必须通过引文库关联到其来源场景：对每个计入的实例，提供简短的逐字引文或命令／输出摘录，并附上可在本地解析的引用（仓库路径、.agents/ao 摘要或会话产物）。无法引用和提供出处的实例，不计入三实例门槛。这些锚点让后续读者能够检验规则是否仍符合实际发生的情况，而非盲目信任抽象结论。

边界

将经验转化为可操作方案，不会创建跟踪事项、提升政策级别、启动工厂、验证自身输出或控制其他调用。提案仅供参考：将其纳入技能、确定性检查、参考资料或工作流，是另一个由调用方选择的步骤——通过 skill-builder、workflow-builder 或新建一次 RPI 完成；本流程绝不会代为执行。提案不能自行提升级别，纯流程类输出也不获得能力分。