Story UI · 组件全状态展台

唯一目标：让用户在一个展台中看全技术组件库的相关用户状态，能直接操作、比较并理解状态变化。

确定覆盖范围

从当前组件、已认可设计和真实使用流程列出状态清单；范围是本次要设计的组件库，不自动扩展到整个产品。已明确的需求直接实施；只有缺失信息会改变覆盖范围时才追问。

“全部”指有业务含义、实际可达的用户状态，不是把所有属性机械排列组合。按组件适用性检查：

写清每个状态的触发条件、可见反馈和可执行动作。不适用的状态可以省略；协议里存在某个字段，不代表界面必须增加一个阶段。

使用同一套组件

优先复用项目现有技术栈、真实组件、样式和状态语义。已有 Storybook 就沿用；其他项目可以用普通页面或现有 Demo 系统实现，不为名称强行引入 Storybook 或更换框架。

已有组件由展台直接引用，避免另写一套近似渲染器。尚未实现的组件先形成可复用实现，展台引用该实现；与目标产品的差异明确标注。

用一份场景注册表驱动展示和覆盖检查，每个场景包含：

• 稳定 ID、所属组件与状态名称。
• 输入数据或事件序列，以及真实组件的源码位置。
• 预期可见结果、允许的操作与下一状态。
• 验证结果或尚未验证的边界。

例如，上传组件的 upload-failed 场景：引用实际上传组件，输入合成文件，注入失败事件，预期出现错误提示和重试入口；点击重试进入上传中，再推进到成功。文件内容与服务结果使用可控夹具，展示验证与真实上传验证分别记录。

做成可以操作的展台

默认按组件或流程分组，在同一页面排列全部场景。筛选、锚点和单场景放大用于辅助查看，不能让用户只能从下拉框逐个猜测有哪些状态。

每个场景同时说明“当前是什么状态”和“可以怎样操作”。按场景需要提供：

• 填入示例：自动填充可编辑数据，减少手动准备；保留用户之后的修改。
• 下一状态：触发真实状态机可接受的下一个事件，让等待、加载和中间结果能够稳定复现。
• 重置／重播：回到起点；终态明确提供重播，便于反复比较。

纯静态状态样本可直接展示，无需硬加流程。提供了演示控件就让它执行实际动作；组件自身的“禁用状态”仍按设计保持禁用，演示控制栏与被展示组件分别处理。

流程回放使用有限、可控的事件序列；模拟耗时可手动推进或使用一次性延时。失败、权限不足、破坏性操作等用合成夹具展示，不为看样式操作真实用户数据。明确哪些是模拟数据、哪些经过真实服务验证。

各场景的输入、ID、订阅和存储按需要隔离；重播清理上轮副作用。iframe 是一种可选隔离方式，不是固定架构。

让状态看得清楚

给实际内容留足空间：计算卡片高度时扣除标题、工具栏、输入区，检查剩余视口，而不只看外框尺寸。长对话、日志、表格优先使用宽卡片或较少列数，并提供放大查看；按钮等小组件按内容自然排布。

桌面与窄屏都检查长内容、错误信息和操作按钮。优先页面滚动，避免多层小滚动区困住用户；确需独立滚动时验证边界滚轮、键盘及焦点可用。沿用现有产品视觉语言，不借展台制作改动产品其余布局。

验收与交付

以状态清单逐项对应场景和验证证据：

按当前宿主的浏览器与预览规则验证并交付用户可访问的入口。截图和结构检查不能代替交互验证；合成事件不能代替真实后端 E2E，未执行的验证明确标注。

交付说明保持简短：入口、覆盖范围、如何操作、验证边界。保留场景与源码、结论的对应关系，让后续 Agent 可以复用；需要机器入口或导出文档时从同一注册表派生，不另维护一套结论。架构专题、下载中心和部署系统不是每次使用本 Skill 的必需产物。