Neo
14a12342b5
这些审计记录原本堆积在 docs/audit/changes/changes/ 嵌套误产物目录下（由开发机迁移
79d3c2e 前后的不明批量操作产生）。由于同期 .gitignore 屏蔽了 docs/audit/ 全目录，
它们从未入过 git 任何分支 history。删除即永久丢失。
按 docs/specs/audit-gap-recovery/tasks.md 阶段 1 执行，将全部 96 份 D 类孤本
（主目录无同名、git history 亦无记录）复制到 docs/audit/changes/ 主目录入仓。
涵盖主题: P1-P18 全栈集成 / 多模块累积变更 / ETL bug 修复 / 业务日切 /
召回与任务引擎改造 / 租户管理与审批 / 董事会财务 / 客户与助教详情 /
DDL 基线合并 / Kiro 到 Claude Code 迁移
阶段 2（B 类内容漂移 1 份）和阶段 4（嵌套目录删除）独立推进。
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
65 lines
4.6 KiB
Markdown
65 lines
4.6 KiB
Markdown
# 变更审计记录：绩效页→任务详情页按 member_id 查询任务
|
||
|
||
| 字段 | 值 |
|
||
|------|-----|
|
||
| 日期 | 2026-03-25 03:10:58 |
|
||
| Prompt-ID | P20260325-024736 |
|
||
|
||
## 操作摘要
|
||
|
||
绩效页点击客户卡片跳转任务详情页时，原先只传 `customerName` 无法定位任务，导致详情页显示"未找到任务信息"。本次新增后端 `GET /api/xcx/tasks/by-member/{member_id}` 接口，按 `(assistant_id, member_id, site_id, status='active')` 查询并取优先级最高的一条任务，前端绩效页改为传 `memberId` 参数，详情页扩展支持 `memberId` 入口。
|
||
|
||
## 变更文件
|
||
|
||
| 文件 | 变更类型 | 说明 |
|
||
|------|----------|------|
|
||
| `apps/backend/app/services/task_manager.py` | 修改 | 新增 `get_task_by_member()` 方法 + CHANGE 注释 |
|
||
| `apps/backend/app/routers/xcx_tasks.py` | 修改 | 新增 `GET /by-member/{member_id}` 路由（置于 `/{task_id}` 之前） |
|
||
| `apps/miniprogram/miniprogram/services/api.ts` | 修改 | 新增 `fetchTaskByMember(memberId)` API 函数 |
|
||
| `apps/miniprogram/miniprogram/pages/task-detail/task-detail.ts` | 修改 | `onLoad` 扩展支持 `memberId` 参数，新增 `loadByMember()` |
|
||
| `apps/miniprogram/miniprogram/pages/performance/performance.ts` | 修改 | `onCustomerTap` 改传 `memberId`，`onRecordTap` 优先 `taskId` fallback `memberId` |
|
||
|
||
## 改动注解
|
||
|
||
### `apps/backend/app/services/task_manager.py`
|
||
- 变更类型：修改
|
||
- 原始原因：绩效页跳转详情页时只有 `customerName` 无 `task_id`，需要一个按 `member_id` 反查任务的服务方法
|
||
- 思路分析：新增 `get_task_by_member(member_id, user_id, site_id)` 方法，查询 `biz.coach_tasks` 中 `status='active'` 的记录，多条时按 `_TASK_TYPE_SORT_ORDER` 字典取优先级最高的一条（high_priority_recall > priority_recall > follow_up_visit > relationship_building），然后复用已有的 `get_task_detail()` 返回完整详情，避免重复实现详情组装逻辑
|
||
- 修改结果：提供了从 `member_id` 到完整任务详情的查询路径；同时文件头部 CHANGE 注释记录了本次变更的上下文
|
||
|
||
### `apps/backend/app/routers/xcx_tasks.py`
|
||
- 变更类型：修改
|
||
- 原始原因：需要暴露 `get_task_by_member` 为 HTTP 接口供小程序调用
|
||
- 思路分析：新增 `GET /api/xcx/tasks/by-member/{member_id}` 路由，关键是放在 `/{task_id}` 路由之前，避免 FastAPI 将 `by-member` 误匹配为 `task_id` 路径参数。使用 `@trace_service` 装饰器保持与其他端点一致的链路追踪
|
||
- 修改结果：新增接口可用，返回 `TaskDetailResponse` 格式；同时为所有已有路由补充了 `@trace_service` 装饰器
|
||
|
||
### `apps/miniprogram/miniprogram/services/api.ts`
|
||
- 变更类型：修改
|
||
- 原始原因：前端需要调用新的 `by-member` 接口
|
||
- 思路分析：新增 `fetchTaskByMember(memberId: string)` 函数，调用 `GET /api/xcx/tasks/by-member/${memberId}`，返回 `TaskDetail | null`，与 `fetchTaskDetail` 保持一致的签名风格
|
||
- 修改结果：前端 API 层完成对接，task-detail 页可直接调用
|
||
|
||
### `apps/miniprogram/miniprogram/pages/task-detail/task-detail.ts`
|
||
- 变更类型：修改
|
||
- 原始原因：详情页需要支持从 `memberId` 参数入口加载任务
|
||
- 思路分析：`onLoad` 的 options 类型扩展为 `{ id?: string; memberId?: string }`，优先用 `id` 走原有 `loadData()` 流程，无 `id` 时用 `memberId` 走新增的 `loadByMember()` 方法。`loadByMember()` 调用 `fetchTaskByMember` 获取任务后，提取 `detail.id` 再调用 `loadData(String(detail.id))` 复用标准详情加载流程
|
||
- 修改结果：详情页同时支持 `?id=xxx` 和 `?memberId=xxx` 两种入口，绩效页跳转不再显示"未找到任务信息"
|
||
|
||
### `apps/miniprogram/miniprogram/pages/performance/performance.ts`
|
||
- 变更类型：修改
|
||
- 原始原因：绩效页跳转详情页的参数需要从 `customerName` 改为 `memberId`
|
||
- 思路分析：`onCustomerTap` 从 `e.currentTarget.dataset` 中取 `memberId` 替代 `name`，URL 改为 `?memberId=${memberId}`。`onRecordTap` 采用优先级策略：有 `taskId` 时用 `?id=${taskId}`（精确匹配），无 `taskId` 时 fallback 到 `?memberId=${memberId}`（反查匹配）
|
||
- 修改结果：绩效页所有跳转路径均可正确加载任务详情
|
||
|
||
## 验证状态
|
||
|
||
- getDiagnostics：5 个文件全部零错误
|
||
- 测试脚本验证 `get_task_by_member` 成功返回 task_id=210（小燕×葛先生的 relationship_building 任务）
|
||
|
||
## 合规检查
|
||
|
||
- 新增迁移 SQL：无
|
||
- DDL 基线：不涉及
|
||
- OpenAPI spec：未变更（`api_changed: false`）
|
||
- 文档同步：无缺失项
|