# Agent 能力归属规则

本规则用于判断新增或变更的 Rule、Workflow、Skill 及其他 Agent 能力应在哪一层分发和维护。判断依据是能力的目标使用者、分发范围和维护责任，而不是首次实现所在的位置。

## 三层模型

| 层级 | 归属 | 判定标准 | 典型内容 |
|---|---|---|---|
| L1 | 通用分发层 | 进入项目模板，面向所有普通项目分发并可直接使用 | 通用工程原则、标准工作流、可移植技能 |
| L2 | 项目实例层 | 仅由当前项目维护和使用，依赖该项目的结构、技术栈、交付流程或领域约束 | 项目工作流、仓库约定、项目专用技能 |
| L3 | 能力提供方自维护层 | 只服务 framework 或 capability-provider 自身的开发、维护和发布，不向普通项目分发 | 提供方内部维护规则、自举流程、能力发布工具 |

L1 是通用分发面，L2 是项目实例的本地扩展，L3 是能力提供方的自维护面。L2 可以约束或扩展 L1，但不得悄然改变 L1 的通用语义；L3 可以维护和生产 L1 能力，但 L3 自身的维护规则不得随模板分发给普通项目。

一次性任务、提案、Mission、实验记录和临时协作说明属于临时工件，不属于 L1/L2/L3 能力层级。它们应保存在对应的任务或计划目录中，不得仅因重复使用的可能性就包装成长期 Rule、Workflow 或 Skill。

## 决策流程

写入前按以下顺序判断：

1. **识别能力边界**：说明能力解决的问题、预期使用者、依赖项和生命周期。
2. **排除临时工件**：若内容只服务一次性任务、提案、Mission、实验或临时协作，将其保留为临时工件，不创建长期 Agent 能力。
3. **检查通用分发价值**：若移除项目名称、目录结构、业务术语和组织策略后，普通项目仍可直接使用，归为 L1 并进入模板。
4. **检查项目实例依赖**：若能力只依赖并服务当前项目的结构、技术栈、发布策略或团队约定，归为 L2，且不向其他项目分发。
5. **检查提供方自维护属性**：若能力只用于 framework 或 capability-provider 自身的开发、维护、自举或发布，归为 L3，并排除在普通项目模板之外。
6. **记录与验证**：在变更说明中记录所选层级、理由、目标路径及分发范围，并验证引用可解析、模板边界正确且不会覆盖更高优先级规则。

## 边界与升级

- 同时包含通用机制和项目策略时，拆分为 L1 机制与 L2 配置或扩展。
- 同时包含可分发能力和提供方维护逻辑时，拆分为 L1 能力与 L3 自维护规则，模板只包含 L1 部分。
- 从 L2 或 L3 提升到 L1 前，必须移除项目或提供方专用标识、私有状态和环境路径，并补充跨项目验证。
- 无法确定长期归属时，先保留为临时工件并请求维护者决策，不得默认归入 L3。
- 发生规则冲突时，遵循当前项目声明的优先级，并保持 L1 分发、L2 实例定制与 L3 提供方自维护的边界。

## 写入位置

- L1：写入通用能力源和项目模板，供所有普通项目初始化或更新时使用。
- L2：写入当前项目的 `.agent/` 对应目录，不回流到通用模板。
- L3：写入 framework 或 capability-provider 的自维护区域，并确保不会进入普通项目模板。
- 临时工件：写入对应任务、提案、Mission、实验或临时协作目录，并明确完成或清理条件。

## 新能力自举验证顺序

当 framework 或 capability-provider 通过 `/agent-update` 将新能力提升为可复用模板能力时，必须先在提供方自己的 `.agent/` 中完成自举验证，再同步到模板或下游项目。

标准顺序：

1. **先改提供方实例**：优先在提供方仓库的 `.agent/` 落地或补齐规则，确认它能约束当前会话。
2. **自用验证**：使用该能力跑一次真实或 dry-run 验证，留下可复查证据（命令、exit code、生成报告、产物路径或工作流检查记录）。
3. **再同步模板**：自举验证通过后，才同步到通用模板或共享能力源。
4. **最后同步下游项目**：模板语义稳定后，才通过 update/upgrade 流程同步到实际项目。
5. **汇报证据**：最终说明必须包含提供方 `.agent` 自举验证结果，不能只声明“已更新模板”。

纯文字 typo、链接修复、无行为变化的说明性改动可以跳过自举运行，但必须在汇报中明确说明“无行为变化，因此未执行自举验证”。

`/agent-update` 在创建或调整 Agent 能力前必须完成上述归属判断。