specsfy-update-spec

更新现有规范

必须完成的准备

执行此技能前，必须先在项目根目录加载 $specsfy-setup。自动交接时，在此步骤前重新加载。复用对话中已确认的根目录；如果 setup 指出有未解决事项，则不要继续。

交互模式

交互模式：perguntas。 提出任何问题前，先阅读并遵循 .specsfy/Spec.md 中的 Contrato de perguntas numeradas。

将初始定义完成后提出的请求纳入其中，不要隐瞒变更、重复规范性来源，也不要强迫对方了解各项操作和关卡。

协调对话

完成此步骤或发现其他步骤的工作时，宣布 Pendência detectada: <descrição> — ação: resolvendo nesta etapa，并在属于本步骤范围时解决。责任发生转移时，宣布 Transição automática: $specsfy-update-spec → $<destino> — motivo: <motivo> — resultado esperado: <resultado>，并立即加载目标技能，无需请求确认或重复命令。在同一对话中继续。完成此步骤所需的修正后，宣布 Retomada automática: $<destino> → $specsfy-update-spec — pendência resolvida: <resultado>，并立即继续处理。每次交接后重新评估状态，以避免循环。交接无需请求确认；敏感操作仍须获得明确授权。

确认输入

1. 在解读新请求前，逐字保留它。
2. 在 specs/<estado>/<NNNN>-<slug>/spec.md 中定位规范的规范文件，并阅读其元数据、需求、场景、计划、任务、关卡和证据。
3. 阅读项目说明、PROJECT.md、.specsfy/STACK.md、.specsfy/RULES.md、.specsfy/DATABASE.md 以及适用的已索引研究资料。
4. 检查规范中预先存在的 Git 变更，不要将其归因于当前请求。
5. 如果规范不存在，宣布待处理事项；如果只是初步想法，则加载 $specsfy-02-backlog；如果已有明确意图要创建此切片，则加载 $specsfy-03-specify。
6. 如果规范仍处于 Draft，且从未通过 Definition Gate: Passed，则加载 $specsfy-03-specify；本技能仅负责修订已进入后续阶段的定义。

先分类，再编写

如果请求可能改变行为、计划或规范之间的边界，请阅读变更分类矩阵。

• 对于没有可观察影响的可逆内部修复，不要修改规范：在任务证据中记录评估结果，然后继续 $specsfy-07-implement。
• 对于不改变含义的编辑性澄清，保留各关卡，只修改必要措辞。
• 对于行为、验收、范围、数据、安全或接口变更，从第一幕开始重新开放。
• 对于仅涉及解决方案、任务或测试策略的变更，从第二幕开始重新开放。
• 对于独立于当前切片目标和参与者的能力，不要悄悄加入：根据请求的成熟度，加载 $specsfy-02-backlog 或 $specsfy-03-specify。
• 如果存在多个合理选项，且它们会实质性地改变结果，则交接至 $specsfy-02-backlog，执行自适应周期，并在周期结束后继续此技能。如果对方选择 avançar，则应用中央契约中定义的确认和记录要求；如仍有适用事项，从第一幕开始重新开放；不要将定义标记为已批准，也不要在本次恢复时重新启动同一周期。

本技能不会创建新规范、不会替对方决定实质性需求、不会修改生产代码，也不会实现请求。

合并变更

1. 确认对方已授权将请求合并到当前 spec 中。明确要求更改、添加、删除或修正，即构成此授权；无需重复确认。
2. 仅编辑 spec.md 和必要的已索引 research。不要创建 change-request.md、plan.md、tasks.md、research.md 或其他并行来源。
3. 更新所有受影响的规范性章节，保留仍然有效的 ID 和决策，绝不要重新编号现有 ID。对于行为变更，在第 17 节记录原因、决策和受影响的 ID。对于仅涉及计划的变更，在受影响的计划或风险章节记录原因，不要人为创建产品决策。
4. 不要把历史证据改写成仿佛是针对新输入生成的。将依赖已失效版本的后续证明标记为待处理。
5. 执行影响投影：

node .agents/skills/specsfy-update-spec/scripts/analyze_change.mjs \
  specs/<estado>/<NNNN>-<slug>/spec.md --base HEAD --mode impact

使用 --mode changelog 列出新增、删除和变更的 ID。分类依据规范标题，而非章节编号；unknown 出于安全考虑会从第一幕重新开始。该脚本只读，不能替代与请求进行语义比较。

仅使必要内容失效

• 对第一幕的变更，设置 Status: Draft、 Definition Gate: Pending、Plan Gate: Pending 和 Delivery Gate: Pending。
• 对仅涉及第二幕的变更，设置 Status: Defined，保留 Definition Gate: Passed，并将 Plan Gate 和 Delivery Gate 设为 Pending。
• 对经证实不涉及语义变更的编辑性澄清，保留状态和 gates。
• 绝不要在输入已失效时保留已通过的后续 gate。
• 保留仍然有效的任务和证据；$specsfy-05-tasks 会在新的 RED 之前协调受影响的项目及其依赖项。

验证中间结构：

node .agents/skills/specsfy-04-validate/scripts/validate_spec.mjs \
  specs/<estado>/<NNNN>-<slug>/spec.md --allow-draft

恢复工作流

• 自第一幕以来发生变更：加载 $specsfy-04-validate；然后依次进行 tasks、TDD/BDD 和发起变更的阶段。如果待办事项细化以 avançar 结束，则在本次恢复中不要执行此交接：报告差距并以 gates 待处理结束。
• 仅第二幕发生变更：加载 $specsfy-05-tasks，由其协调计划、调用 $specsfy-06-tdd-bdd 并恢复变更来源。
• 在实现期间检测到变更：只有在 Definition 和 Plan Gate 恢复为 Passed，且新行为或已变更行为存在有效 RED 后，才恢复 $specsfy-07-implement。
• 在 Complete 之后检测到变更：重新走完所有已失效的阶段，只有在 Delivery Gate 和 DoD 均有证明后，才恢复 Complete。

汇报

说明保留的请求、已修改的 spec、分类、受影响的 ID 和章节、已失效的 gates、保留或标记为待处理的证据，以及加载的下一项 skill。不要在结果出现前透露框架的复杂性：先说明请求已合并，必要的工作流将自动恢复。