@peterxiaoyang/superspec 0.1.47 → 0.1.48

package/templates/workflow/skills/superspec-explore/SKILL.md

@@ -12,7 +12,9 @@ metadata:
 
 ## 工作方式
 
-运行 `superspec transition next --change "<change>"`，以返回的当前事项为准。优先通过代码、文档、已有测试和需求源消除未知；只有业务语义、验收、范围、数据口径或关键取舍无法由现有证据裁决时才询问用户。
+运行 `superspec transition next --change "<change>"`，以返回的当前事项为准。工作流明确给出材料目标时，只在该目标位置创建或更新材料；路径、生命周期和后续动作都以工作流为准，不自行推断目录或推进方式。
+
+优先通过代码、文档、已有测试和需求源消除未知；只有业务语义、验收、范围、数据口径或关键取舍无法由现有证据裁决时才询问用户。
 
 用户明确说明 PRD、文档、原型或其他需求源已更新时，重新核对来源，不复用旧结论；需要继续或修改材料时，按工作流反馈处理。
 
@@ -23,7 +25,7 @@ metadata:
 1. 先读需求源、代码、测试和现有材料，主动消除可查证的事实；不要把可以继续搜索得到的答案包装成用户问题。
 2. 将真正会改变结果的未知整理为待确认事项：每项只对应一个业务理解、验收口径、范围或取舍；写清当前理解、可选结果或所需事实、推荐及依据、会受影响的结果。
 3. 需要用户确认时，不要只转述问题：先基于当前 Discovery 给出简短理解（目标、当前差异、影响和明确排除），再说明这件事的可选结果或需补充的事实、推荐及依据、影响。只围绕这一件事提问并等待答复；不要在同一轮要求用户确认一串问题，也不要把候选推荐写成既定需求。没有证据的内容明确为未知，不补造。不要在用户对话中展示文档编号。
-4. 用户答复后，先把结论与受影响事实回写到 discovery，再重新检查后续事项是否仍成立、是否需要重写或已被排除；前提变化时不能沿用旧顺序。
+4. 用户答复后按工作流反馈处理并回写 Discovery；勾选事项时保留原问题内容，将结论写入相邻正文。随后重新判断受影响事实与后续事项，前提变化时不沿用旧结论。
 
 没有需要用户决定的高影响未知时，不制造问答，直接完成基于证据的 Discovery。所有待确认事项都已回写且没有阻塞未知后，再继续形成后续计划。
 
@@ -95,7 +97,9 @@ Discovery 必须明确区分已确认事实、基于证据的推断和仍未裁
 
 ### 未知与用户决策
 
-先通过继续调查、阅读代码、运行已有测试或核对需求源消除未知。只有无法由现有证据裁决、且会影响需求范围、验收、用户可见行为、数据语义、安全、兼容或关键方案取舍的问题，才交给用户决定。
+先通过继续调查、阅读代码、运行已有测试或核对需求源消除未知。只有无法由现有证据裁决、且会影响需求范围、验收、用户可见行为、数据语义或安全的问题，才在 Explore 交给用户决定。
+
+需求目标与验收已经明确，但不同技术路线会改变迁移、兼容、数据归属、发布方式、成本或长期责任边界时，将它作为 Propose 的设计决策候选写入调查结论和风险依据，不在 Explore 提前替用户选择，也不把它伪装成需求问题。若路线差异会改变产品行为或验收，则仍属于 Explore。
 
 每个待决问题只表达一个会改变结果的确认点，并说明影响、可选方向或需要补充的信息及建议依据。选择型问题给出候选结果和推荐；事实型问题说明需要用户提供什么、现有证据为什么无法裁决，以及缺少它会阻塞什么。
 

package/templates/workflow/skills/superspec-propose/SKILL.md

@@ -12,7 +12,7 @@ metadata:
 
 ## 工作方式
 
-先运行 `superspec transition next --change "<change>"`，以返回的事项、确认、审查与提交命令为准。只把用户已确认的行为、边界和有证据的风险写成计划，不改业务代码。
+先运行 `superspec transition next --change "<change>"`，以返回的事项、材料目标、确认、审查与后续动作作为唯一流程依据；不要根据 Skill 模板猜测产物目录或推进方式。只把用户已确认的行为、边界和有证据的风险写成计划，不改业务代码。
 
 需求源、业务口径或验收更新时，先在 `proposal.md` 增加 `## 需求变化`，记录变化来源、变化、受影响能力、已修改材料、保持不变的范围和处理方式；再按实际影响同步规格、设计和测试契约。
 
@@ -27,7 +27,11 @@ metadata:
 3. task 优先按垂直交付拆分：一个 task 完成一段用户或调用方可验收的能力，并携带足以实现和验证它的来源、设计、验收与边界。共享机械改动只有确实不能独立交付时才按真实依赖拆开。
 4. 每步只安排满足当前已确认行为所需的最小改动；不要把未来能力、理论故障模型、通用基础设施升级或未采纳方案预支进计划。
 
-这不是要求所有 task 机械地一一对应单个场景；紧密相关行为可共用方案和 task，独立行为或真实前置交付才需要拆分。
+参考实现是现有能力与候选机制的证据，不是本次 change 的默认结构。根据已确认目标重新判断最小责任边界；不能因为参考模块存在某组接口、实体、表或服务，就直接复制其形态。当前证据范围内尚未核实的外部仓库或模块变化，应标为待核实依赖、实施前置或风险，不得写成已经成立的实现事实。
+
+已证实受影响的外部仓库、平台或运行时，在计划中明确外部交付物、责任边界、可核验准入条件和联调验收，或有证据地排除。会改变数据归属、调用路径、一致性或发布顺序的实现路线，在 Propose 中选定其一；不把“两种方式均可”留为 Apply 的架构任务。
+
+这不是要求所有 task 机械地一一对应单个场景；紧密相关行为可共用方案和 task，独立行为或真实前置交付才需要拆分。能够独立发布、失败或验证的系统边界通常不应混入同一 task，除非它们确实构成不可分割的原子交付。
 
 ## 产物模板
 
@@ -116,6 +120,10 @@ metadata:
 |---|---|---|---|
 | <方案> | <收益> | <代价> | <采用或放弃原因> |
 
+<!-- 可选：存在必须由使用者承担结果的高影响设计取舍时保留；确认后回写最终方案 -->
+## 待用户确认
+- [ ] DEC-001 <决定、候选结果、推荐与依据、对交付的影响>
+
 <!-- 可选：同一契约被多个功能点共享时保留，局部契约写在对应方案内 -->
 ## 关键契约
 
@@ -174,9 +182,13 @@ metadata:
 
 数据传递、字段形态或上下游契约变化时，在测试表后说明输入完整性如何得到证明；只证明使用方算法不足以证明新输入真的到达使用方。
 
-## 未知与审查
+## 设计决策与审查
+
+Propose 以已确认的 Discovery 为需求边界。范围、业务行为、验收、数据语义或安全仍不明确时，回同一 change 的 Explore 澄清，不静默采用默认业务语义。
+
+当需求结果已经明确，但多个可行技术路线会让使用者承担不同的迁移、兼容、数据归属、发布、成本或长期维护边界时，不替使用者静默选择。在 `design.md` 的 `## 待用户确认` 中保留当前高影响设计决定，说明已知事实、候选结果、推荐及依据和会受影响的交付；内部命名、文件组织、局部实现和不改变这些结果的技术选择由模型自主决定。没有这类取舍时不制造问答。
 
-Propose 只综合已经确认的 Discovery。若发现范围、验收、兼容、数据语义、安全或关键方案取舍仍无法由已确认材料裁决，回同一 change 的 Explore 澄清；不要静默采用默认业务语义，也不要把未决的用户选择留在 Proposal、Design 或 Tasks 中。
+每项使用 `DEC-xxx` 标识并只表达一个决定。工作流一次返回当前一项；用户答复后按工作流反馈处理，勾选时保留决定项原文，将最终选择与影响写入相邻正文及相关 design、specs、tasks 和测试契约，并按新方案重新判断后续事项。审查角色只能依据本次目标和直接证据指出缺失的决定，不能把个人偏好或更理想的架构升级为用户义务。
 
 只要计划包含 task，就向用户展示任务交付摘要。单个 task 同样展示，不能通过 task 数量或依赖字段猜测其复杂度。用户选择继续完善计划时，可据此调整交付粒度、依赖或顺序；材料变更后再按工作流继续。