specsfy-05-tasks

将规格拆分为任务

必须完成的准备工作

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

交互模式

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

计划中的数据库保护

对于 Laravel 项目，在规划或发布任何 [TEST] 任务前，执行 .agents/skills/specsfy-setup/scripts/check_database_safety.mjs --project <raiz>。计划必须保留 .env.testing、APP_ENV=testing，并明确使用与 .env 数据库不同的测试数据库。

结果为 PENDING 时，任何测试任务都不能标记为就绪，技能也不得调用 runner。结果为 IGNORED 时，丢弃会删除结构或记录的命令。绝不要在任务、 测试、准备、回归或 Definition of Done 中包含 migrate:fresh、 migrate:refresh、migrate:reset、migrate:rollback、db:wipe、 schema:drop、prisma migrate reset、DROP DATABASE、DROP SCHEMA、 DROP TABLE、TRUNCATE、RefreshDatabase、DatabaseMigrations 或 同等命令。

填写 specs/<estado>/<NNNN>-<slug>/spec.md 中的 14. Tarefas 部分。 该文件仍是唯一事实来源；每项任务都必须精简、可验证、按顺序排列，并关联 其中定义的 ID。

协调对话

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

前置条件

1. 阅读 specs/defined/<NNNN>-<slug>/spec.md 中指定的 spec，并要求其包含 Formato: Specsfy/2.0、Definition Gate: Passed，且 Status 为 Defined、Planned 或 Implementing。后两种状态仅在自动重新规划后续 步骤发现的待处理事项时接受。
2. 如果尚未证明 gate 通过，则执行规格验证。
3. 检查代码库，以使用实际的技术栈、命令和路径。对于 PHP，使用 Pest 进行 TDD；对于没有 PHP 的 Node 项目，在生成路径或命令前询问采用哪个 runner，并推荐 Vitest。
4. 规划前执行 monitor：

node .agents/skills/specsfy-setup/scripts/monitor_context.mjs \
  --project .

使用技术栈、应用、规则和持久化方面的信号，在变更的同时规划文档更新， 不要推断新需求。 5. 如果缺少会改变架构、数据或验收标准的决策，宣布并自动返回 $specsfy-02-backlog。决策完成后，如果 spec 已获批准，则使用 $specsfy-update-spec；如果仍处于初始定义阶段，则使用 $specsfy-03-specify。

生成

如果 .specsfy/templates/custom/Tasks.md 存在，则将其用作约定；否则使用 .specsfy/templates/Tasks.md。仅替换 <raiz>/specs/<estado>/<NNNN>-<slug>/spec.md 中的 14. Tarefas 和 15. Ordem de execução 部分；保留所有其他部分。

• 如果 spec 的状态为 Planned 或 Implementing，请说明待处理事项，重新打开 Ato II，并在编辑前将 Status: Defined、Plan Gate: Pending 和 Delivery Gate: Pending 设定好。计划更改后，先前的 Gate 和证据不再有效。
• 如果 spec 已处于 Defined 状态，请在编辑前将 Plan Gate: Pending 和 Delivery Gate: Pending 设定好。
• 更新时保留现有 ID；不要为已完成的任务重新编号。
• 按最小设置、必不可少的基础、按优先级排列的用户故事和收尾来组织。
• 将用户故事保持为可独立演示的垂直切片。
• 当 Interface para pessoas 为 Sim 时，除数据层或 API 外，还要针对第 10 节中描述的界面、菜单和主导航、表单及操作创建明确任务。 包含界面行为测试，覆盖导航、提交、验证、错误恢复以及选定的打开模式， 例如侧边面板或模态框。仅使用已记录的界面技术栈中的组件、约定和运行器； 每项任务都要指向真实的 React 区块、shadcn/ui 和 ReUI 组件或路由。添加 一项任务，用于更新 INTERFACE.md，记录所创建或更改的所有区块的用途、文件、API、 状态、使用方和复用规则。 在 React 项目中，每项界面任务都必须在实现前于 PREP 中记录使用 $specsfy-specialist-react-ui-components。该 skill 指导 如何查找、复用和调整项目中的实际组件。如果未安装此 skill，请返回 $specsfy-setup，先安装已识别的专家，再解锁 [CODE] 任务。 将这些任务归入第 14 节的必需子节 #### Fase de interface。每个已记录的 界面都至少要有一项专属任务；不要把这项交付隐藏在通用后端任务中。
• 针对每个 AC，创建一项独立的 [TEST] [TDD] 任务，其设计以 spec 中保留的 Gherkin 为参考。这些任务合起来，必须为整个功能以及每个 US、FR 和 NFR 至少形成三个不同的 TDD 用例。
• 绝不为 .feature 文件或 step definition 创建任务，也绝不执行 spec 中的 Gherkin。
• 在 PHP 中，TDD 任务必须指向 Pest 测试并要求 SPECSFY 标记；在 Node 中， 使用经用户确认的运行器和 test:tdd 脚本。
• 每项 [CODE] 任务都必须依赖同一切片中前置且处于 RED 状态的 TDD 任务。
• 只要任务创建或更改 schema、表、列、索引、关系或持久化 model，就要另建一项 [CODE] [MIGRATION] 任务。该任务必须指向项目 migration 目录中的版本控制文件， 依赖 TDD 测试，并先于使用新结构的代码任务。
• [MIGRATION] 任务的 VERIFY 项必须记录两个经 check_database_safety.mjs 批准的命令：一个用于在测试数据库中应用 migration， 另一个用于查询 migration 状态。没有此任务时，不得批准 Plan Gate。
• 当切片更改 manifests 或结构性配置时，创建一项针对 .specsfy/STACK.md 的 [DOC] 任务。当更改数据库、schema、持久化 model、表、字段、关系或 migration 时，必须创建一项针对 .specsfy/DATABASE.md 的 [DOC] 任务。
• 应用变更的任务收尾时，必须包含对 PROJECT.md 的审查。如果没有实质性影响， 则要求在证据中说明理由，而不是人为编写内容。
• 所有 [CODE] 任务都必须要求在 EXECUTE 前由 $specsfy-documentator 独立重建 docs/，即使文档在变更前已存在。
• 当某项约定成为已确认的规则时，创建一项针对 .specsfy/RULES.md 的 [DOC] 任务。
• 每项任务都必须有唯一结果、准确路径和可验证标准。
• 仅将 [MIGRATION] 标签与 [CODE] 或 [OPS] 搭配使用。路径必须根据找到的技术栈位于 database/migrations/、migrations/、prisma/migrations/ 或 supabase/migrations/。
• 仅仅读取、查询或使用现有表，本身不要求 [MIGRATION]。当计划创建或更改结构时， 必须使用该标签。
• 按照解析出的 Tasks.md 模板定义的顺序，为每项任务附上 PREP、EXECUTE、 VERIFY、VISUAL、EVIDENCE 和 IMPROVE 项。
• 即使没有用户要求，VISUAL 项也必须填写。它会在开发期间检查系统的边框、间距、 外边距、内边距和字体排印。没有界面时，请记录 Não aplicável，并说明具体原因。
• 将各项写成任务的具体结果，不要照抄通用句式。
• 生成任务时，保持父项和各项处于打开状态；实现 skill 会在取得证据后立即更新对应项。
• IMPROVE 项必须记录一项已实施的具体改进；如果无需改进，则须说明理由。
• 当 spec 声明 Evidence Contract: 1 时，每项已完成的 [CODE] 任务都必须包含一条 specsfy:evidence JSON 注释，其中含有 task、refs、files 和 commands（run 和 exit）。请在任务区块内生成该注释； 绝不要将其放入单独文件。
• 仅当任务之间不共享文件、可变状态或依赖时，才标记 [P]。
• 按 ID 声明依赖；不要只依赖视觉顺序。
• 覆盖所有适用的 FR、NFR 和 AC。除明确说明理由的 setup/polish 外，不得创建没有引用的任务。
• 不要包含通用示例或占位符。 规范格式：

- [ ] T001 [TEST] [TDD] [US-001] Derivar teste Pest do BDD da spec em tests/Feature/AuthTest.php — Refs: FR-002, AC-003 — Depends: none
- [ ] T002 [CODE] [US-001] Implementar validação em app/Services/AuthService.php — Refs: FR-002, AC-003 — Depends: T001

ID 后允许的标签：[P]、[TEST]、[TDD]、[CODE]、 [DOC]、[OPS] 和 [US-NNN]。

验证

执行：

node .agents/skills/specsfy-05-tasks/scripts/validate_tasks.mjs specs/<estado>/<NNNN>-<slug>/spec.md --allow-draft

存在面向用户的界面时，还要执行：

node .agents/skills/specsfy-05-tasks/scripts/validate_interface_tasks.mjs specs/<estado>/<NNNN>-<slug>/spec.md

修正重复 ID、无效/循环依赖、不存在的引用、缺少三个 BDD 场景的条目、 没有独立 TDD 任务的 AC、每个 feature/US/FR/NFR 缺少三个 前置任务/测试用例的计划、没有 TDD 前置任务的代码、缺失/顺序错误的 检查清单、不一致的父项/子项、被阻塞任务的进度或含糊的任务。最多进行 三轮。 在证据契约中，同一验证器还会拒绝缺失的文件、无效的引用、不含 exit: 0 的命令，或没有 evidence 的已完成任务。

当结构通过验证但仍显示 Plan Gate: Pending 时，自动以 prepare 模式调用 $specsfy-06-tdd-bdd。它会使用 spec 中的 BDD 来生成 TDD 前置任务，观察 RED，并且只完成这项测试任务。随后自动恢复此技能，以便：

1. 使用 --allow-draft 重新运行验证器；
2. 将 Plan Gate 改为 Passed，并设置 Status: Planned；
3. 在 Gate do Ato II — Plano 中记录结果；
4. 不使用 --allow-draft 运行。

通过 Plan Gate 后，执行 specsfy transition <id> planned。当对话改变范围、依赖项 或所需能力时，在重新规划前调用 $specsfy-interviewer，并附上理由更新 Effort。

严格模式会在某个 [CODE] 任务的 TDD 前置任务仍未完成时，拒绝 Plan Gate: Passed。如果验证失败，保留 Status: Defined、Plan Gate: Failed、 Delivery Gate: Pending，并报告阻塞项。

报告

报告总数/各类型数量、关键路径、[P] 机会、ID 覆盖率；当 gate 通过时，宣布并 自动加载 $specsfy-07-implement。绝不创建 tasks.md。

按需调用专家

在分解需要专属检查清单的技术、数据、界面或运维工作时，阅读 references/specialists.md。