specsfy-02-backlog

完善并深入梳理待办事项

必须完成的准备工作

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

交互模式

交互模式：提问。 提出任何问题前，请阅读并应用 .specsfy/Spec.md 中的 编号问题约定。

将模糊的输入转化为清晰易懂的待办事项；如果意图需要规格说明，则深入探讨相关决策，直至产出可测试的简报。这是框架中的第二个连续阶段。它整合记录、细化和探索，不会将待办事项转变为规范性来源。

协调对话

完成此阶段或发现属于其他阶段的工作时，宣布 Pendência detectada: <descrição> — ação: resolvendo nesta etapa，并在该事项属于本阶段范围时予以解决。责任发生转移时，宣布 Transição automática: $specsfy-02-backlog → $<destino> — motivo: <motivo> — resultado esperado: <resultado>，并立即加载目标技能，不要请求确认，也不要重复命令。继续在同一对话中处理。

完成本阶段所需的更正后，宣布 Retomada automática: $<destino> → $specsfy-02-backlog — pendência resolvida: <resultado>，并立即恢复处理。每次交接后都要重新评估状态，避免循环。交接无需确认；敏感操作仍需获得具体授权。

搜索重复项和相关参考资料

1. 提取用户请求中的相关词语，包括领域名称以及对话中已使用的明显同义词。
2. 创建或更新待办事项前，在以下位置搜索这些词语：
   • specs/inbox/*.md；
   • specs/backlog/*.md；
   • specs/<estado>/*/spec.md；
   • docs/**/*.md。
3. 仅阅读合理的搜索结果，并对每项关系进行分类：
   • 可能的重复项：问题、相关人员、结果和背景实质上相同；
   • 相关待办事项：补充项、依赖项或前置事项；
   • 相关规格说明：已定义或已交付、会限制该待办事项的行为；
   • 相关文档：项目中的术语、规则或背景。
4. 通过路径展示实质性匹配项。发现可能的重复项时，请确认用户是要更新现有事项，还是要记录实际差异。
5. 在 相关参考资料 中记录有用来源，并注明相对路径和关系类型。不要将发现的决策转述为用户的声明。

如果某个回答实质性地改变了相关词语、问题、相关人员、结果或背景，请重新搜索。

复用 MVP 中已确认的回答

当待办事项清单来自基于 MVP.md 的里程碑时，在提出任何问题之前：

1. 阅读 specs/milestones/M01.md 和待办事项清单中的 Registros confirmados no MVP 部分；如果记录了原始文件的路径，也打开 原始 MVP.md；
2. 提取每条关于问题、用户、结果、范围、旅程、规则、数据、集成、限制或验收标准的声明；
3. 将声明转换为待办事项清单中适用字段的标准化回答，并保留原文片段和来源路径作为出处；
4. 即使文件没有使用与问题相同的标签，只要 MVP 中明确写出了答案，就将该问题视为已回答；
5. 仅针对实际缺失、重要歧义，或 MVP、相关来源与当前对话之间的矛盾提问。

MVP 已经明确给出答案时，不要要求确认、选择或改写。可以简短说明复用了哪些内容，但不要因此开启新一轮提问。如果合理的解读不止一种，只需指出该歧义，并引用引发歧义的原文片段。

如果导入记录了 Default aplicado automaticamente，且指定依据明确或没有歧义，就将其视为已确认。如果某个问题只有一个选项与 MVP 相符，就应用该选项、记录标准化结果，并继续处理下一处缺失。只有存在实际选择、多种兼容的解读，或来源无法确认某项建议时，才展示选项。访谈只应询问 MVP 无法回答或无法安全推断的内容。

确保最低限度的信息采集

1. 保留对话中收到的原始表述，或 specs/inbox/<data-hora>-<slug>.md 中的原始表述。分别标注声明、推断和待确认事项。
2. 确认上下文是否足以说明：
   • 感知到的问题；
   • 受影响或受益的人；
   • 预期结果或价值；
   • 足够区分当前需求与类似需求的上下文。
3. 如果有内容缺失、含糊、矛盾或存在歧义，选择影响最大的实际缺失项，并且每轮只提出一个编号问题。
4. 每次收到回答后，重新评估缺失项。不要把这些条目变成固定问卷，也不要重复已提供的信息。
5. 只要任何必要信息仍然缺失或存在歧义，就不要创建或更新文件。如果对方不知道答案，请说明缺失之处，不要编造内容。

最低限度的信息采集不要求提供技术方案、完整验收标准或优先级。这些信息可以在深入梳理时逐步完善。

创建或更新条目

1. 如果对方只想探讨而不想记录，请先交流，并在写入前确认。
2. 如果已存在对应条目，请在不更改其 ID 的前提下更新，并保留之前的表述。
3. 如果来源是 specs/inbox/，请在 Referências relacionadas 中记录该路径；不要修改或删除原始记录。
4. 要创建新条目，请运行：

node <diretório-da-skill>/scripts/iniciar_backlog.mjs \
  --title "<título curto>" \
  --idea "<formulação original>" \
  --problem "<problema percebido>" \
  --person "<pessoa afetada ou beneficiada>" \
  --result "<resultado ou valor esperado>" \
  --context "<contexto que distingue a ideia>" \
  [--slug <slug>] [--root <raiz>]

5. 使用脚本打印的绝对路径。脚本优先使用 .specsfy/templates/custom/Backlog.md，并在不可用时回退到 .specsfy/templates/Backlog.md。

组织和确定优先级

在组织、细化、确定优先级或评估就绪度时，请阅读 references/backlog-quality.md。

• 在已知的情况下，按产品 → 史诗 → 功能 → 条目的层级分类。
• 使用史诗、故事、规则、技术和改进等类型，不要将类型与优先级混为一谈。
• 根据价值、风险、依赖关系、紧迫性、工作量、解锁效果和不确定性排序；不要把所有条目都标为高优先级。
• 根据风险和复杂性深入完善字段。身份验证、支付、权限、隐私和异步操作需要格外谨慎。
• 优先描述可观察到的行为，而不是界面方案。
• 对重要的质量属性设定可衡量的指标。
• 在有助于减少歧义时，使用列表、流程、场景或矩阵。

深入完善规范

当用户要求深入完善、升级或创建规范时：

1. 阅读 specs/inbox/ 中的输入、specs/backlog/ 中的条目或指定的规范。如果有多个候选项，询问要深入完善哪一个。
2. 用一句话概述问题、涉及的人以及对方能感知到的结果。
3. 区分已确定的内容与可能影响范围、体验、安全性、数据、测试或架构的内容。
4. 阅读 references/discovery-map.md，挑选相关问题；不要机械地逐项遍历。
5. 如果交付内容包含面向用户的界面，请阅读 .specsfy/Spec.md 中的 Contrato de experiência de interface，并将 Interface 作为单独的发现领域。询问页面、信息流、菜单和主要导航、表单、操作模式（如侧边面板或模态框）以及布局组合。存在实际选项时，不要替用户决定模式。提问前，阅读中央契约所指明的技术栈和现有页面。如果已有系统，请检查受影响的区域，并记录新交付需要保留或更改的导航、组件、内容、权限和状态。根据这些信息提供兼容的选项，而不是默认建议使用新库。即使用户没有提到“界面”，只要请求创建或修改页面、仪表板、列表、表单、可视化流程或 CRUD，就应启用此领域。 在结束此领域的讨论前，加载 $specsfy-specialist-interface-experience；它负责协调对当前系统的分析以及后续专家的工作。在确定用户旅程前，加载 $specsfy-specialist-ux-design；在确定布局组合前，加载 $specsfy-specialist-ui-design。 如果 React 和 Tailwind 技术栈使用 ReUI，那么发现阶段中声明的每个 CRUD 都必须记录 Data Grid 或 List、Filters、Form、Dialog 或 Sheet，以及适用的 ReUI 状态；在结束此领域的讨论前，加载 $specsfy-specialist-reui。
6. 阅读 ../specsfy-03-specify/references/mcr-10.md，并在提出第一个问题前，默默完成类别分析。
7. 仅当技术或专业领域需要补充背景时，才阅读 references/specialists.md。

开展自适应发现

每个领域最多执行一轮八个问题：

1. 每轮开始前，重新阅读输入、已确认的决策、累积的上下文和新回答，以及 MVP 记录。
2. 重新分类缺口和依赖项。只要仍有适用的缺口且问题数量未达上限，就继续；每项缺口都已确定、不适用或有证据解决后，结束。
3. 选择 影响 × 不确定性 最高的真实缺口，并按照核心约定提出本轮问题。
4. 记录每条原始回答、规范化后的决策及其影响。返回第一步；不要重复使用固定的问题队列。

达到八个问题后，给出总结，记录未解决的缺口并停止。只有当用户明确要求继续提问并说明想回答多少个问题时，才重新开启循环。

从第一轮开始，就在每个问题中加入 Avançar。如果用户选择此选项：

• 在下一轮确认：用户要永久结束该领域的问题、稍后回答，还是现在返回回答；
• 将确认作为该轮唯一的编号问题；
• 结束时，记录 Área encerrada pelo usuário: <área>，除非用户明确要求重新开启，否则不要再次提问；
• 延后时，记录 Área adiada pelo usuário: <área>，并保留未回答的要点以便之后继续；
• 不要通过推断补全答案；
• 允许用户要求交接；若仍有适用的缺口，则保持 Status: Draft 和 Definition Gate: Pending。

对话期间：

• 在能减少回答负担时，至少提供三个编号选项，并简要说明推荐选项及理由；
• 接受自由回答，并在重新分析时纳入这些回答；
• 保留原始术语，并区分陈述、推断、假设、决策、冲突和未解决事项；
• 通过总结确认实际操作意图；
• 不要逐一列举十个类别，也不要把每个类别都变成一个问题。

确保充分覆盖问题、参与者、结果、范围、用户旅程、故障、限制、规则、数据、安全、隐私、性能、无障碍、现有约束，以及客观的验收和成功指标。

对于供人使用的界面，还要覆盖屏幕、导航、信息流、菜单和主导航、表单字段与验证、每项操作的打开方式、元素布局、状态和键盘操作。将文本回答和观察到的技术栈记录到 backlog，确保 spec 不会把 CRUD 简化为端点，也不会替换项目所用的技术。

如果用户旅程依赖已存储、查询、共享或删除的信息，请在宣布 brief 完成前，说明将自动切换到 $specsfy-data-discovery。将 .specsfy/DATABASE.md 中已确认的记录作为上下文，继续处理 backlog，不要把对话转变为技术设计。

维护条目

严格使用 specs/backlog/<NNNN>-<slug>.md，并保持以下状态：

• Status: Captured：条目仅已记录时；
• Status: Refining：正在完善或发现时；
• Status: Ready for specification：brief 已足够完善时；
• Status: Promoted：派生 spec 已创建后。

在标题下方的表格中保留元信息。不要虚构优先级、期限、stakeholder、解决方案或证据。将 Pronto para desenvolvimento 仅用作诊断，不得将其视为实施授权。

结束

提供一份可用于编写规范的简报，包含：

1. 问题和目标。
2. 参与者。
3. 范围和范围之外的内容。
4. 关键用户旅程和规则。
5. 采用 Given/When/Then 格式的验收标准。
6. 技术和质量限制。
7. 假设。
8. 待定决策或无适用缺口。
9. 模糊词汇和已确认的推断。

当用户授权记录时，更新待办事项。如果简报已足够完善，或用户选择继续，则在该步骤因已批准规范的后续变更而被调用时，自动返回 $specsfy-update-spec。若要创建或整合初始定义，则调用 $specsfy-03-specify。如果用户选择继续，则提供部分简报，并说明阻碍 Definition Gate 的缺口。

限制

• 不得更改或删除 Inbox 条目。
• 不得创建 spec.md、任务、research、测试或代码。
• 不得臆造利益相关者、集成、限制或决策。
• 不得将技术假设转化为需求。
• 未经确认，不得移动或删除现有条目。