zcweah1981 目标
输出必须至少包含：
- 前端目录骨架
- 页面文件建议
- 关键组件建议
- 状态流转实现建议
- 首批 10 个关键文件建议
- 开发顺序
- 交接给 API / QA 的实现现状
强制规则
- 不要只列目录名
- 页面、组件、状态流转必须相互对应
- 首批文件必须足够让前端先开工
- 明确哪些先用 mock，不接真实后端
- 必须声明前端状态流转、字段展示、下拉可选项最终以 API 合同为单一真源
- 必须把默认排序规则落到页面实现：列表 created_at desc，时间线 created_at desc，recent_* created_at desc
- 必须把 Dashboard 写成动态聚合结果消费方，不允许独立静态 dashboard mock
- 必须把“新增跟进 + 可选同步改状态”的前端提交流程写成固定链路，并说明成功后哪些视图要同源刷新
最小输出结构
- 技术假设（如 React / Next.js / TS / Tailwind）
- 目录骨架
- 页面文件建议
- 关键组件建议
- 状态流转实现建议
- 首批 10 个关键文件
- 建议开发顺序
- 交接给 API / QA 的实现现状
必须落地的实现口径
输出中必须明确：
- 页面只消费 API 合同里定义的字段，不自行扩展口径
- 状态/来源/负责人等下拉项本版固定来自 GET /mock/meta/options，不再出现 /api/meta 等平行口径
- 提交跟进成功后固定刷新：leadDetail、leadFollowups、leads、dashboardOverview；不要再使用“至少刷新”这种弱表述
- sync_status=true 时，前端必须兼容 created_events、status、status_updated_at、latest_follow_up_at、latest_follow_up_summary 回写
- query key 与 mock 请求上下文默认带 role + current_user_id
- today_* 类展示口径统一按北京时间（UTC+8）解释
- mock 示例、注释、组件 props 命名也必须统一为 latest_follow_up_*；不允许文案注释残留 last_followup*
- 前端可以拆 leadDetail / leadFollowups 两个 query key，但两者默认消费同一个 GET /api/leads/:id 结果；不得据此新增第二个详情 followups 接口
- sales 列表页 owner 越权默认按 current_user_id 强制收口；不要在前端再实现第二套 silent rewrite / 403 分叉策略
常见坑
- 只有目录，没有页面文件
- 只有页面文件，没有组件建议
- 没有说明哪些先 mock
- 没有把状态流转和页面绑定起来
验证方式
输出里至少要能直接回答：
- 前端第一批文件先建哪些
- 页面与组件怎么对上
- 目录骨架是否能支撑 API 与 QA 并行