已有前端仓库功能实施流程

一、建立仓库上下文

阅读适用的 AGENTS.md、项目文档、包管理脚本、Lint/格式化/类型检查配置和框架约定。
执行 git status --short，查看相关 Diff，区分用户已有修改和本次任务修改。
追踪真实入口：路由、页面、组件树、状态管理、请求层、权限、埋点和数据流。不要只凭文件名判断入口。
用 rg 搜索相同业务能力、同类交互、公共组件、Hook/Composable、指令、工具、格式化函数、图标、样式变量和测试。
检查目标技术栈和项目版本；不能把其他框架或新版组件库的 API 直接套用到当前项目。
有设计链接时，在修改前读取实际设计节点或查看原图。

二、形成实施合同

开始编辑前，明确：

目标与非目标；
真实入口和影响链路；
允许修改的文件与区域；
明确禁止修改的文件、接口和行为；
必须直接复用或保持一致的现有实现；
数据字段、组件输入输出、状态、异常和边界条件；
响应式、浏览器、设备、主题、国际化和无障碍要求；
后端未就绪时的 Mock 边界；
验证命令和可复现入口。

用户说“参考某实现”时，先判定参考类型：

直接复用：调用已有组件、Hook、工具或样式。
保持约定一致：复用它的 API、结构、状态流或视觉规则。
仅作背景：只理解业务，不复制副作用或不适合当前场景的代码。

不确定会改变架构或业务结果时才需要询问；能从仓库中确认的内容应自行调查。

三、按可验证批次实现

依据任务拆分，而不是固定按某种 UI 结构拆分。常见顺序：

数据适配、类型或视图模型。
主组件和核心状态。
复用组件与跨组件交互。
边界状态、异常和兼容处理。
开发态 Mock 或联调适配。
路由、注册或生产链路接入。
自动化检查和实际页面验证。

每个批次完成后：

查看本批涉及文件的实际 Diff。
检查是否出现范围外修改、重复实现、改变公共契约、临时代码和被意外注释的功能。
运行覆盖本批的最小解析、Lint、类型、测试或构建检查。
检查新增文案、国际化资源和中文编码。
验证通过后再进入下一批。

四、组件复用与集成检查

在新增或封装任何组件前，依次确认：

当前页面或功能是否已经包含同类组件或交互。
同业务模块是否已有生命周期、数据流或视觉相近的实现。
项目公共层是否已有组件、Hook、指令、Provider、工具或样式规范。
框架和组件库是否已通过属性、插槽、事件、组合 API 或扩展点提供能力。
现有实现是否包含副作用，不适合直接嵌入当前场景。
新代码是否能缩小为业务差异，而不是重新实现整个基础能力。

集成已有组件时，检查：

当前项目版本支持的 API；
输入、输出、双向绑定和受控/非受控约定；
默认值、状态保留、销毁与重新挂载；
容器、定位、滚动、层级、主题和样式隔离；
加载、空值、错误、禁用和权限状态；
键盘操作、焦点、屏幕阅读器和触摸交互；
响应式布局、刘海/安全区、桌面端和移动端差异；
服务端渲染、异步组件、缓存和性能影响；
是否已经有项目级测试或使用示例可复用。

弹层、金额格式、复制、倒计时和支付等仅是组件复用的案例，不应写成所有项目都必须遵循的固定结构。

五、后端未就绪和 Mock

需要前端先行时：

将 Mock 与生产链路明确隔离，并只在开发或测试条件下启用；
优先在展示适配层注入，不污染持久化 Store、缓存、监控和真实业务数据；
不臆造并注册临时生产接口、消息类型或字段；
把后端字段转换集中在一层，减少联调时改动范围；
明确 Mock 入口、开关和后续移除/接入位置。

并非所有需求都需要 Mock；只有用户要求或后端尚不可用且页面必须可验收时才使用。

六、完成门槛

需求状态、交互和边界条件已经覆盖；
实际修改与实施合同一致；
没有无理由重复实现已有能力；
文件编码和用户已有修改完好；
解析、编译和适用的定向检查通过；
UI 需求完成实际视觉与交互检查；
未能验证的部分被准确说明。