checklist

检查清单定位："面向需求文本的单元测试"

关键概念：检查清单本质上是针对需求写作质量的单元测试，用于验证特定领域中的需求是否清晰、完整且可执行。

不是用来做实现验证/功能测试的：

• ❌ NOT "Verify the button clicks correctly"
• ❌ NOT "Test error handling works"
• ❌ NOT "Confirm the API returns 200"
• ❌ NOT checking if code/implementation matches the spec

而是用来验证需求质量的：

• ✅ "Are visual hierarchy requirements defined for all card types?" (completeness)
• ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity)
• ✅ "Are hover state requirements consistent across all interactive elements?" (consistency)
• ✅ "Are accessibility requirements defined for keyboard navigation?" (coverage)
• ✅ "Does the spec define what happens when logo image fails to load?" (edge cases)

类比理解：如果把规格说明看成“用自然语言写成的代码”，那么检查清单就是它的单元测试套件。你验证的是需求本身是否写得好、是否完整、是否无歧义、是否已准备好进入实现阶段，而不是验证实现结果是否正确。

用户输入

$ARGUMENTS

在继续之前，你必须考虑用户输入（如果不为空）。

语言要求

• 所有问题、生成的检查项、分类标题、摘要和报告都必须使用简体中文。
• CHK001、[Spec §X.Y]、文件路径与命令等可追踪标记保持原始机器可读形式。

执行步骤

1. 设置：从仓库根目录运行 {SCRIPT} 并解析 JSON 输出，获取 FEATURE_DIR 和 AVAILABLE_DOCS 列表。

   • 所有文件路径必须是绝对路径。
   • 对于参数中的单引号（例如 "I'm Groot"），使用转义语法：例如 'I'\''m Groot'（或尽量使用双引号）。

2. Clarify intent (dynamic): Derive up to THREE initial contextual clarifying questions (no pre-baked catalog). They MUST:

   • Be generated from the user's phrasing + extracted signals from spec/plan/tasks
   • Only ask about information that materially changes checklist content
   • Be skipped individually if already unambiguous in $ARGUMENTS
   • Prefer precision over breadth

   Generation algorithm:

   1. Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts").
   2. Cluster signals into candidate focus areas (max 4) ranked by relevance.
   3. Identify probable audience & timing (author, reviewer, QA, release) if not explicit.
   4. Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria.
   5. Formulate questions chosen from these archetypes:
      • Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?")
      • Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?")
      • Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
      • Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
      • Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")
      • Scenario class gap (e.g., "No recovery flows detected—are rollback / partial failure paths in scope?")