SpecKit 原型生成

解决什么问题

从需求规格生成可交互原型时，最常见的失败是把“证明规格被实现”当成目标：评审矩阵、ID 映射、回放记录直接堆在页面上，业务用户看到的却是 CAP-*、PAGE-* 这类内部编号。另一个问题是一有改动就全量重建原型，改一句文案也要走一遍完整流程。speckit-prototype 把原型的第一目标固定为展示“产品完成后用户会看到什么、如何完成工作”，并按改动范围分流处理。

工作方式

• 执行档选择：先运行 scripts/plan_prototype_change.py，在 Patch、Delta、Full 之间选择。局部文案与样式调整用 Patch，有限页面或交互变化用 Delta，首次生成、IA/路由/共享行为变化或影响范围不明时才用 Full，避免把局部改动升级为全量重建。
• Preflight 门禁：所有宿主统一经过 Preflight，分别判断 readiness、authorization 和生成/验证能力，返回 READY、NEEDS_CLARIFICATION、SPEC_CHANGE_CANDIDATE、BLOCKED_INPUT 等状态；非 READY 必须停止并返回对应 stop code。宿主原生 Plan Mode 只是可选编排能力，不写进产品契约。
• 契约驱动生成：依次冻结 prototype/ia-plan.json、prototype/visual-plan.json 和 prototype/prototype-behavior-contract.json，再设计面向用户的任务路径。行为契约覆盖 P0/P1 的预期结果、禁止结果、持久化与时间触发方式，HTML 和测试脚本必须消费同一契约，不得反向降低要求。
• 配置直达运行时：字段密集型需求消费根目录 field-contract.json，生成 prototype/field-render-map.json 并用 data-field-id 建立不可见映射。配置页面必须有真实的编辑、校验、保存、发布路径，新增的模板、流程节点、负责人要能在同一会话中影响需求提报和任务生成。
• 旁路证据：评审矩阵、回放记录、截图与测试脚本写入 prototype/evidence/ 或明确的 sidecar 目录，不进入用户导航，也不作为页面正文或控件。
• 交付可控：Delivery-Mode 默认 Local，只写本地 prototype/，不自动上传、不自动提交 Git；用户明确要求时才按指定目标处理，并如实报告 prototype_path、delivery_mode 和 upload_target。

适用边界与注意点

• 只接受 input-contract.md 定义的 Draft spec、来源台账和 IA 文件，不得添加 spec 中不存在的角色、状态、流程阶段、能力或页面。
• 产品界面不得暴露 spec 章节号、内部 ID、角色切换器、重置演示数据或评审说明，这些内容只能进 sidecar 证据。
• 原型微调默认属于 prototype-presentation 或 prototype-fixture，不回流 spec.md；若调整改变了能力、数据源、权限或验收，必须停止直接改页面并输出 SPEC_CHANGE_CANDIDATE。
• 生成前后校验 spec digest，拒绝过期原型；缺少浏览器或截图能力时只能报告 Insufficient，不得伪造完整验收通过。