Plan Decompose

read brief.goal.completion_condition
对每条 observable：
  问"要让这条为真，需要哪些独立的产出物？"
  产出物 = 顶层 compound task（待递归分解）
检查：是否每条 observable 都映射到至少一个顶层 task？
  没映射 → 标 coverage_gap

查概念邻域（真 CLI）：./tw concept graph-show <concept_id>；扩邻域用 ./tw concept slice <concept_id>
识别 task 涉及哪些 concept（用 @ 引用记录）
按 concept 边界找 low coupling / high cohesion 的子切分

对每个 compound task:
  问"零上下文 fork 能直接做吗？"

  能 → 标为 primitive，停止分解
  不能 → 继续按 concept 边界 / 价值单元切分

F-06a 6 项停止检查：
  □ 零上下文 fork 能执行
  □ 有明确 read_set + write_set（write_set 含每条 done_criteria 必然要写的全部文件：主实现 + 接线点 + 测试）
  □ 有可验证 done_criteria
  □ 能独立 commit
  □ 预估 token ≤ 50K
  □ write_set 不跨 >3 个独立模块

对每个 primitive task:
  问"这是完整的价值单元吗？执行者做完后能 demo 吗？"
  是 → 垂直切片，OK
  否（只是某层的活）→ 标 horizontal_slicing_warning
        建议合并兄弟 task 成垂直切片

  例外：全局 schema migration → 允许水平切片（标 exception_reason）

对每条 completion_condition.observable:
  哪些 primitive task 的 done_criteria 覆盖它？

  覆盖 → 加入 coverage_matrix
  未覆盖 → coverage_gap，需要补 task 或标 PlanningUncertainty
  3+ task 覆盖 → redundancy 检查（是否过度分解）

在我已 Read 进来的 .claude/skills/planning/knowledge/planner-casebook.md 里
找最接近的例子（线性 / 并行 / 状态机 / 模糊 / 粒度太大/太小 / 跨计划）
比对差异——差异在分解关键维度 → 不适用该 case
没有接近 case → confidence: low

plan_decompose_proposal:
  # 候选拆法（可能有多种）
  decomposition_candidates:
    - candidate_id: string
      confidence: high | medium | low
      tasks:
        - task_id_tentative: string
          task_type: enum [7 种 taxonomy]
          description: string
          done_criteria:
            - criterion: string
              verification_type: enum
              evidence_ref:                        # ↓ 硬化——每条标准溯源
                source_type: brief.completion_condition.observable | concept_definition | nature_judgment
                source_id: string
                quoted_claim: string
          parent_task_id: string?
          concept_refs:
            - {concept_id, at_reference, why_referenced}
          read_set:
            - {entity_type, entity_id, derived_from: concept_ref_id}
          write_set:
            - {entity_type, entity_id, derived_from: done_criterion_id}
            # ⚠ write_set 完整性：从每条 done_criterion 反推「实现它必然要写的全部文件」，
            #   不止主实现文件 —— 还含 ① 接线点文件（done_criterion 断言「接进某流水线 / 真被调用 /
            #   门真拒 X」时，新代码不接进那个调用点 = 建好没生效=假完成，故调用点文件必入 write_set）
            #   + ② 测试文件（done_criterion 断言「拒绝测试存在 / 行为被测试验证」时，那条测试要写在
            #   tests/… 下，故对应测试文件必入 write_set）。漏了 = 执行时写越界、撞 V-01 owner-guard 卡死。
          stopping_evidence:                       # 为什么这是 primitive
            zero_context_executable: bool
            verification_clear: bool
            token_budget_ok: bool
            independent_commit: bool

      coverage_matrix:                             # 100% 覆盖证明
        - observable: string
          covered_by_tasks: [task_id]
          evidence: string

      coverage_gaps:                               # 未覆盖的 observable
        - observable: string
          why_not_covered: string
          suggested_resolution: enum [add_task | return_to_interview | planning_uncertainty]

      slicing_assessment:
        vertical_slice_count: int
        horizontal_warnings: [{task_ids, suggested_merge}]

      decomposition_rationale: string
      casebook_reference: string?                  # 类比辅助

  # 推荐选择（不替主 session 决定）
  recommended_candidate_id: string
  why_recommended: string

  # 不确定区
  uncertainties:
    - description, blocking_observable, suggested_action