需求澄清与写回

解决模糊需求带来的返工

需求评审中最常见的问题，是把「要不要做」和「具体怎么做」混在一起。当业务方回答了字段默认值、按钮位置或配置项后，团队很容易误以为概念已经确认，于是继续完善原型和文档。等到开发阶段才发现，真正的前提——这个概念是否纳入本期、适用哪些角色、异常时如何恢复——其实从未被确认，返工往往从这里开始。

@user_3085d0c0/speckit-clarify-cimi 把澄清拆成可追踪的决策事件。它不追求一次性补齐所有细节，而是先锁定前提，再把回答定点写回受影响的 spec 对象、信息架构和来源台账。

核心机制与关键步骤

• 区分执行画像：先确定 Execution-Profile: Delta | Full。局部澄清只读取当前 open question、受影响对象和相关 spec 片段；当 IA、路由、基线或交付模式发生变化时，升级为 Full，避免用局部回答覆盖全局。
• 启动前置检查：执行前运行 ../speckit-specify/scripts/resolve_workflow.py。只有 Draft + no pending analysis 才能进入 Clarify；Frozen 返回 FROZEN_BEGIN_REVISION_REQUIRED，Ready-for-Specify 返回 ANALYSIS_NOT_MATERIALIZED_USE_SPECIFY，不允许跳过分析直接提问。
• 前提优先提问：按 admission、scope、behavior、configuration 的顺序推进。配置问题不能替代概念准入确认；用户质疑前提时标记为 Disputed，停止追问属性，转而追踪受影响的 FR/STATE/TRANS/PAGE/VIEW/AC 对象。
• 内容先分流再写回：原型演示、布局、视觉样式、mock/seed/占位数据默认写入 prototype-adjustment-ledger.json，决策事件使用 target_artifact=prototype 与 normative=false，不修改 spec.md。若回答影响业务能力、数据来源、权限、状态或验收，先标记 SPEC_CHANGE_CANDIDATE，得到显式确认后才提升为正式需求。
• 记录决策事件：使用 speckit-workspace/scripts/record_decision_event.py 追加事件，而不是每轮重写整份 spec、IA 和来源台账。每轮最多提出五个相互独立的高影响问题，每次回答立即写回问题、回答、准入影响和受影响 ID，保持 ID 稳定。
• 生成写回凭证：结束时生成 .specify/clarification-writeback.json，记录前后 digest、已解决问题、受影响对象和剩余 open 项。没有写回凭证，就不报告完成。

适用边界与注意点

• 字段澄清按 FIELD-CANDIDATE-* 或 FIELD-* 写回，至少覆盖来源、必填/条件、类型/边界、唯一性、角色/状态访问、依赖、持久化、审计、错误和验收，不能用一张字段名表替代字段契约。
• 澄清过程只修改与回答直接相关的内容，不自动调用 prototype、review、version 或 publish。
• 一次性脚本、问答缓存和失败日志统一写入 .specify/work/clarify//，不要在 FEATURE_DIR 根目录留下临时文件；失败运行保留 run manifest，成功运行由 speckit-workspace 审计并归档。
• 未解决的前提保持 open，不要因为用户回答了下游属性问题就标记为 Resolved，也不要用「是否强制」「由谁配置」这类带前提的问题替代准入确认。