原型生成（Prototype）
先根据改动范围选择 Execution-Profile: Patch | Delta | Full。已有原型的局部文案、
样式或单页调整默认使用 Patch；有限页面或交互变化使用 Delta；首次生成、IA/路由/
共享行为变化或影响范围不明时才使用 Full。先运行
scripts/plan_prototype_change.py，不要凭经验把局部改动升级为全量重建。
所有宿主统一经过本 Skill 的 Preflight 门禁。Patch/Delta/Full 只决定读取范围和校验深度，
不等同于风险或人工审批。Preflight 还要分别判断 readiness、authorization 和生成/验证
能力，并返回 READY、NEEDS_CLARIFICATION、SPEC_CHANGE_CANDIDATE、BLOCKED_INPUT、
BLOCKED_CAPABILITY 或 APPROVAL_REQUIRED。Codex、WorkBuddy、Claude Code 或其他宿主的
原生 Plan Mode 都是可选编排能力，不能成为本 Skill 的依赖，也不能写入产品契约。
原型的第一目标是展示“产品完成后用户会看到什么、如何完成工作”，不是展示
spec 如何被验证。默认生成 product 模式：面向业务用户、使用自然业务语言、
具有连贯的数据和可操作的关键路径。评审矩阵、ID 映射、回放结果和测试日志是
旁路证据，放入 prototype/evidence/ 或其他明确的 sidecar 目录，不进入用户导航，
不作为业务页面的正文或控件。
读取 command.md、references/input-contract.md、references/spec-to-prototype-map.md、
references/behavior-contract.md、references/prototype-acceptance.md、
references/product-prototype-contract.md 和
references/fallback-design-system.md、references/visual-design-system.md、
references/ux-quality-contract.md、references/execution-preflight-contract.md、
references/host-orchestration.md 和 assets/interaction-state-matrix.md。
Incremental/Revision 额外读取 references/incremental-prototype-rules.md。
阶段性交付（Optional Delivery）
原型生成、微调和阶段性展示统一使用本 Skill、统一写入当前 FEATURE_DIR/prototype/。
不要创建独立的 preview/ 目录、预览副本、预览包或 Preview-ID。
交付方式使用机器标识 Delivery-Mode: Local | User-Selected：
- 默认只生成或更新本地
prototype/，不自动上传、不自动提交 Git，也不自动调用
speckit-version或speckit-publish。 - 用户明确要求上传时，继续使用当前
prototype/目录，按用户指定的目标和方式处理；目标可以是
Git、压缩包、共享目录或其他已提供的上传方式，不假设固定平台、分支或远程路径。 - 阶段性展示不要求
Frozen，也不改变spec、版本状态或正式发布记录。 - 交付结果必须报告
prototype_path、delivery_mode和实际upload_target；未上传时将
upload_target标记为Not-Requested，而不是伪造上传结果。
阶段性上传是原型交付选项，不是独立生命周期、独立目录或独立 Skill。
本 Skill 不得依赖、调用或读取规格编写 Skill 的内部文件。Specify 只是输入契约的
一种生产者，其他工具或人工也可以提供符合契约的 Draft spec。
硬约束
- 只接受本目录
input-contract.md定义的 Draft spec、来源台账和 IA 文件。 - 不得添加 spec 和 IA 中不存在的角色、状态、流程阶段、能力、指标或页面。
- 分开建模
CAP、PAGE、VIEW、ACT和NAV；上下文视图不能自动成为全局路由。 - 独立能力可以共享外壳，但必须保留独立身份并填写
shared_shell_reason。 - 默认
prototype_mode=product。产品界面不得暴露CAP-*、PAGE-*、VIEW-*、
ACT-*、NAV-*、FR-*、TRANS-*、EXEC-*、spec 章节号、回放矩阵、测试断言、
角色切换器、重置演示数据或评审说明；这些内容只能进入 sidecar 证据。 - 原型页面必须用自然业务语言表达规则，不把“证明规则”写成页面内容；内部追踪可用
data-*或 sidecar 关联，但不能成为用户可见文案。 - 配置页面中的字段、人员、角色、候选范围、任务模式、节点操作和版本必须有真实的
编辑/校验/保存/发布路径；不能用静态说明、只读示例或 toast 冒充配置能力。 - 配置结果必须驱动运行时演示。新增或修改的模板、流程节点、负责人、候选范围和任务
模式至少要能在同一原型会话中影响需求提报、任务生成或节点操作；禁止维护一套配置
数据和另一套运行时硬编码数据。 - 生成前后校验 spec digest，拒绝过期原型；拒绝嵌套
.specify状态。 - 先生成并冻结
prototype/prototype-behavior-contract.json，覆盖 P0/P1 行为的预期结果、
禁止结果、持久化和时间触发方式；HTML、测试脚本和证据必须消费该契约，不得反向降低
契约要求。 - 字段密集型需求必须消费根目录
field-contract.json，生成prototype/field-render-map.json，
使用data-field-id建立不可见映射，并运行scripts/validate_field_render_map.py。 - 先选择并记录视觉设计来源，生成并冻结
prototype/visual-plan.json；Greenfield 无外部
设计系统时使用assets/product-ui-v2/，Incremental/Revision 优先沿用已验证基线。 - 产品页面必须消费选定设计系统的 tokens、page patterns 和 state patterns；不能只复制
一个空壳再用临时 CSS 拼页面。
执行流程
- 先运行 Preflight 并将本次状态写入
.specify/work/prototype/<run-id>/preflight.json，同时更新
.specify/current-prototype-run.json指向当前 run 和 source digest。
READY才能继续；澄清、规范变更、输入缺失、能力缺失或外部审批状态必须停止并返回
对应 stop code。中断恢复时重新计算 source digest，过期 run 不得继续使用；完成或阻断时更新
current pointer 的状态。 Full才完整读取独立输入契约和 spec；Patch/Delta先读取 manifest、变更计划和
受影响的 spec/IA/行为片段。提取用户、主要任务、页面主线、配置对象、
运行时行为和验收结果；不能只按 IA 或 UX 章节逐项翻译。- 先建立
prototype/ia-plan.json，再选择视觉基线并建立并冻结prototype/visual-plan.json，
再建立并冻结prototype/prototype-behavior-contract.json，最后建立面向用户的任务路径设计。
IA 只决定页面边界和上下文关系，不决定把内部 ID 或
审计证据放进界面。 - 先完成主线产品体验：列表/详情、配置、提报、当前任务和结果；再补空态、错误、禁用、
保存中、成功和恢复状态。所有演示数据必须能沿同一条数据链流动。 - 按 Delivery-Mode 处理原型；Incremental/Revision 先解析并准备真实 UI baseline，
再执行 lineage 流程。增量原型保留稳定页面/功能定位键，不能凭页面名称猜测基线关系。 - 生成 manifest，明确
prototype_mode=product、routes、entrypoints、CAP/PAGE/VIEW
映射、配置到运行时的关联、behavior_contract和 digest。Incremental/Revision 额外生成
evidence/change-map.json与独立的review/index.html；评审矩阵、回放记录、截图和测试脚本写入旁路
evidence，Change Review 不得注册成产品路由。 - 按行为契约执行正向、负向、持久化、权限、唯一性和时序回放；对定时任务和外部接口
明确区分真实实现、可交互模拟和静态证据，不能在设置规则时伪造已触发结果。 - 运行信息架构、产品原型、视觉系统、行为证据、lineage 和 change-map 校验器，由校验器生成权威的
prototype-validation.json与change-map-validation.json；任何用户可见的内部追踪泄漏、静态伪配置、
契约未覆盖、证据过期或配置/运行时脱节都不得交付。
同时调用speckit-workspace/scripts/validate_prototype_package.py和
speckit-workspace/scripts/index_evidence.py，确保pages/、assets/、evidence/
内部没有错位脚本、备份文件、未登记或重复证据。 - 重新计算受影响对象的 digest，将 Preflight digest、契约 digest、校验结果和未完成项写入
prototype/evidence/executions/<run-id>/receipt.json，并由evidence-manifest.json登记；不修改
spec，也不自动调用 review、version 或 publish。缺少浏览器或截图能力时只能报告
Insufficient，不得伪造完整验收通过。
工作流必须提供可操作的正常、失败、恢复和权限路径。逐节点回放矩阵是 sidecar 证据，
不能替代用户界面，也不能把审计字段直接堆在页面上。页面、按钮或 toast 不能单独证明
业务闭环；业务闭环由真实交互、状态变化、数据一致性和旁路回放共同证明。
版本上下文与 Git 上传（Version Context and Git Delivery）
读取 ../speckit-version/references/version-context-contract.md。原型继承当前 Draft 的
Product-ID、Product-Version、Spec-Revision、Feature-ID 和 Artifact-Key，不自行
分配新的产品版本。prototype-manifest.json 必须保留这些字段及 prototype_digest。
用户明确要求上传 Git 时，使用同一 prototype/ 目录和同一 Artifact-Key；阶段性上传不要求
冻结，也不创建 Preview 目录。Draft 可以重复上传，Frozen 产物不可覆盖。
成品优先检查
生成后先关闭或隐藏所有开发/评审辅助信息，从业务用户视角逐条检查：
- 用户是否能从主入口完成主要任务，不需要理解 spec、CAP、VIEW 或状态机编号；
- 页面是否像同一个真实产品，导航、文案、数据、保存结果和返回路径是否连贯；
- 页面是否使用统一视觉来源、页面范式和 design tokens，而不是通用后台拼装；
- 1440x900 和 1280x720 下是否无遮挡、截断、非预期横向滚动和模板占位文案；
- 配置对象是否真的可创建、编辑、校验、保存、发布，并影响运行时；
- P0/P1 行为是否同时覆盖成功、失败、恢复和禁止副作用；
- 时间、重试、外部接口的模拟是否保留真实触发条件，并在报告中声明边界；
- 关键操作是否有明确的可用/不可用原因、成功反馈和恢复入口；
- 刷新、切换页面或重新进入详情后，演示数据和版本绑定是否保持一致；
- 产品界面是否没有评审矩阵、测试面板、角色切换器、内部 ID 和开发说明。
原型调整分流（Prototype Adjustment Routing）
原型微调默认属于 prototype-presentation 或 prototype-fixture，不回流 spec.md。每次调整在 prototype/prototype-adjustment-ledger.json 记录 adjustment_id、statement、intent_class、target_artifact=prototype、normative=false、source_context=prototype、promotion_status=not-required|pending 和受影响的 PAGE/VIEW/Artifact-Key。
如果调整改变能力、数据源、权限、状态或验收，停止直接改页面并输出 SPEC_CHANGE_CANDIDATE；由 Analyze/Clarify 完成显式提升后再更新 Spec。原型展示效果不能作为 Spec 的反向事实来源。
