# 新系统与玩法内容：先查可复用能力

仅在新增系统、玩法内容或扩展机制时使用本文。普通修复先定位受影响代码。

1. 用一句话明确目标行为和约束；不要增加未提出的玩法联动。
2. 执行 `shrink inspect capabilities "关键词" --root <项目>`。先读最多三个候选的用途、限制、扩展点和证据，再查选中模块的 `symbol` / `flow`。中文使用项目业务词，例如 `存档`、`状态`、`属性`；不同叫法可另查别名。
3. 按 **配置 → 组合 → 扩展已有机制 → 新模块** 判断。候选命中不是复用证明；对照真实接口、实例和行为测试。资料缺失不能解释成能力不存在。
4. 确认状态归属、操作入口、结构化结果和退出时的撤销。只展开实际相关的持久化、联机、UI 或生命周期约束。
5. 明确列出已存在、本次新增和待确认。不要为复用绕开权限、反向依赖模块、用无结果事件执行需要裁决的操作，或把大量胶水代码包装成零新增能力。

默认输出四项：复用方案及证据、必要改动、协作关系、影响与验证。只有会改变结果而无法从项目推导的选择才询问用户。

例如击杀怒气机制，需要分别核对击杀事实、计量、条件触发、属性修饰及效果撤回。存在 EventBus 不证明这些业务能力已经存在；存在存档功能也不意味着这次怒气必须持久化。

## 能力说明格式

在模块现有 README 中只保留一个区段。说明业务含义，不重复生成的 API 签名、依赖和版本。

```text
<!-- shrink:capabilities -->
Capability: 能实现的行为
Aliases: 常见中文叫法 English aliases
Limits: 明确不支持的行为或成立条件
Extension: 可配置或组合的位置；需要新增代码的边界
Evidence: 相对本 README 的源码、配置类型和可运行示例路径
<!-- /shrink:capabilities -->
```

框架维护 SDK 能力，消费项目维护自己的业务能力。业务目录即使共享 asmdef 也可以声明能力。不得假定所有项目都有背包、战斗、任务或属性系统。