Feature Boundary Planner

---
name: feature-boundary-planner
description: "分析功能变更会影响哪些入口、共享组件和状态所有者，澄清产品边界并规划状态组合、验收案例或实现交接。"
---

# feature-boundary-planner

本 Skill 仅用于当前项目。用户授权、项目 AGENTS.md 和实际宿主能力优先。

## 模式

- `impact-only`：回答影响、解释、扫描或诊断；只交付影响说明，不改产品代码、规格或功能图。
- `planning`：用户要求规划或实现时，先明确行为与验收条件，在已有权威记录中落实必要决定。
- `implementation-handoff`：整理已接受的案例、证据要求和实现/E2E 交接。

选择请求所需的最小模式。未指定功能时只问范围；能从代码确定的事实不重复请用户确认。

## 先找影响，再展开状态

1. 读取实际项目规则、目标功能及现有索引/合同。将变化分为展示、选项来源、草稿/默认值、验证/权限、提交效果、持久化、恢复之一或多项。
2. 从具名入口和共享点追踪直接消费者；已挂载的代码索引优先，否则用源码搜索。先查一层语义邻居，调用影响通常先查两层；关键所有者或结果仍未定位才继续，不把所有可达节点都称为受影响功能。
3. 对每个 UI/API 入口记录：场景 → 显示/草稿所有者 → 默认/继承/回退 → 校验与拒绝点 → 命令/服务 → 权威运行态或持久化。区分桌面/移动、局部/远端和连续流/可重放交付；同名字段或共享组件不证明共享状态或提交效果。
4. 为关系注明原因和级别：must-inspect（编辑点/所有者/提交路径）、should-inspect（选项/默认/验证）、conditional（明确条件）、invariant-only（保持隔离）、evidence-only（测试或可达性证据）。保留路径与符号作为线索，不用路径清单代替语义解释。
5. 比对当前调用者与现有功能图/规格，差异记为 drift 或 bug-candidate。仅在语义已确认且获授权时更新已有权威，保持稳定 ID，不为本 Skill 创建第二套图谱。

## 规划与交接

只对真正影响范围的未知语义提出少量具体选择：触发、允许状态、目标、禁止副作用、隔离边界与证明方式。既定授权内的实现选择自主推进。

选少量主要维度及高风险组合，以成对/风险覆盖代替全量展开。候选分类为 accepted、undefined、pruned、ignored、bug-candidate；裁剪必须有 guard、不变量或等价理由，undefined 必须有具体问题。不要通过改规格掩盖实现冲突。

在已有 spec、矩阵或规划记录中写清 accepted 案例的 setup、action、assertions、证据与稳定 ID，再交给实现或 E2E 流程。身份键、缓存、文件存储和后端 API 分开列出，只有已证明同步才合并。执行路径与隔离标识不能混为一谈。

交付包含：变化层、入口对照表、共享实现与不同效果、排序后的关系、状态与提交所有者、保留不变量、实际搜索方法/深度、漂移候选和未知项。规划模式另附维度、裁剪理由、accepted 案例和覆盖缺口；只分析模式不落地这些产品改动。

来源、适配边界和许可证见 [provenance.md](provenance.md)。