设计原型输入约定
本目录存放页面原型，作为生成用户故事清单和交互清单的一次性输入物。 原型回答"页面上有什么"；"该怎样表现"的权威始终是交互清单，不是原型。
一、定位与边界
- 原型的唯一用途：让 agent 据图枚举页面、控件和用户可见动作，产出 IX 总表草稿，避免凭空发明界面或漏项。
- 行为权威是交互清单：加载、空态、错误、权限、确认等行为以 IX 条目为准；原型与清单冲突时，以清单和需求为准，或先对齐再动手。
- 原型不定义需求范围：原型里出现、但需求未收录的功能，不能因为"图上有"就实现。
- 禁止把原型代码直接复制进生产实现：原型没有组件抽象、状态管理和可访问性实现，实现时按架构设计的组件边界重写。
二、默认形态：单文件 HTML 原型
- 一个页面一个
.html文件，按路由或页面名命名，例如【items-list】.html、【login】.html。 - CSS / JS 全部内联，零构建依赖，双击即可在浏览器打开。
- 低保真优先：结构和控件齐全即可，不追求视觉完成度。
- 使用语义化标签（
button、form、table、dialog、nav），标签本身就是控件清单。 - 数据一律用假数据，页面顶部放固定横幅标注：
PROTOTYPE - 仅供枚举交互，非实现依据。 - 需要演示空态、加载、错误等状态时，可用少量内联 JS 做状态切换按钮，对应交互清单状态表的行。
三、替代形态：SVG / 手绘草图
布局说不清、画得快时，可用 SVG（Excalidraw、Penpot、Figma 导出）代替：
- 文字必须保留为真文本（
<text>元素），不要导出为轮廓路径，否则 agent 读不到按钮文案。 - 分组 / 图层使用语义命名。
- 静态图只能表达一帧，状态与异常仍须在交互清单里逐项约定。
四、工作流
- 用一两句话描述页面：有哪些区块、控件和主要动作。
- AI 生成低保真原型（HTML 或 SVG），存入本目录。
- 人工在浏览器查看并调整，直到布局与控件集合认可。
- AI 据原型产出交互清单的 IX 总表草稿，状态全部标【待确认】。
- 人工逐条确认行为决策（优先级、状态与异常、无障碍），P0 交互按详情模板展开。
- 对应 IX 条目在「关联原型」字段引用本目录文件；原型更新后检查受影响的 IX 条目。
五、生命周期与维护规则
原型是一次性输入物，生命周期是"开工前生成 → 显著改版时重新生成 → 实现后过期"。不建立"每模块常备原型库"，也不承担与实现持续同步的义务。
- 开工门槛（一次性）：P0 的 UI 模块首次实现前应有原型；没有就先生成原型、人工确认后再拆任务。
- 触发式重新生成：新需求显著改变某页面的布局或控件集合时，把"重新生成该页原型 → 更新 IX 草稿"作为该任务的第一步。判断标准只有一条：这次变更是否让 agent 需要重新"看图"才能枚举交互。换文案、加字段等小改动只改 IX 条目，不碰原型。
- 实现后即过期：页面实现后，原型自动视为过期，不回头修补；实现后的视觉事实由任务文件
## 执行记录中的真实截图或可运行验证承担。 - 需要新原型时整页重新生成，不逐次修补旧文件。
- 已无对应页面或已完成使命的原型可以删除；删除前确认没有 IX 条目仍在引用。
- 本目录不放业务敏感数据、真实用户数据或生产接口地址。