wecom_it_smart_desk/.workbuddy/memory/2026-06-14-批量任务.md

workbuddy 批量任务清单 — 2026-06-14 睡前启动

生成日期: 2026-06-14 生成人: Claude 启动条件:

1. 用户在 Gitea 创 workbuddy-claude user account
2. 用户创 workbuddy-claude 的 access token(权限 repository + issue + user)
3. 用户把 token 配到 .workbuddy/config.json 的 gitea.token 字段
4. workbuddy 客户端启动时读这份 memory → 按顺序接任务

---

▶▶▶ 任务清单(5 项,按优先级)起

W-1. P1-1 优化: named volume → host bind mount

任务编号: #25 阻塞原因: 当前 docker-compose.yml 用 named volume backend-uploads,容器重建不丢但 docker-compose down -v 会全丢 目标: 改成 host bind mount 到 NAS /volume1/docker/wecom-it-desk/uploads

修复:

1. 编辑 docker-compose.yml:

   volumes:
     backend-uploads:
       driver: local
       driver_opts:
         type: none
         o: bind
         device: /volume1/docker/wecom-it-desk/uploads
   

2. scripts/deploy.sh 部署时建 host 目录:

   sudo mkdir -p /volume1/docker/wecom-it-desk/uploads
   sudo chown -R 1000:1000 /volume1/docker/wecom-it-desk/uploads
   

3. 加 deploy 文档警示"别用 docker-compose down -v"

验收:

• 容器重建后上传文件不丢
• df -h /volume1/docker/wecom-it-desk/uploads 体积能涨

评审员: Claude

---

W-2. P0 二次评审 5 遗留修完

任务编号: #18 遗留 关联: docs/评审报告/workbuddy-2026-06-14-P0安全.md 11.x 节(5 项遗留)

5 项遗留:

1. 浏览器 WS API 不支持 header —— 用 Sec-WebSocket-Protocol: bearer.<token> 方案
2. nginx access_log 没关 —— location /ws/ { access_log off; } 已修,验证部署版也有
3. 类型 bug —— ws.py 某处类型断言错误
4. 降级放行 —— agents.py 缺 password 时,existing_agent.password_hash 已存在 → 必须 verify password,不能放行
5. 缺依赖 —— requirements.txt 缺 bcrypt / pyotp(已加,验证)

修复: 逐项对照评审报告修复,每项单独 commit

验收:

• 全部 5 项 commit 推 Gitea
• 评审员 Claude 二次评审通过
• 风险跟踪表 第九节 / 第十节 状态从 🟡 改 ✅

评审员: Claude

---

W-3. pytest 基础配置 + 跑 pre-commit-check.sh

任务编号: README 已知问题 #2 关联: scripts/pre-commit-check.sh(本次新增,C-1 任务)

修复:

1. backend/pytest.ini(或 pyproject.toml [tool.pytest.ini_options]):

   [pytest]
   testpaths = tests
   python_files = test_*.py
   addopts = -v --tb=short
   

2. backend/tests/conftest.py:
   • 异步 client fixture
   • 测试 DB(用 sqlite:///:memory:)
   • mock WECOM 凭据
3. backend/tests/test_agents.py:
   • 鉴权测试(mock_login 关闭 / 开启)
   • password_hash 验证
4. backend/tests/test_messages.py:
   • 5 个端点鉴权测试(P0-2~6)
5. backend/tests/test_ws.py:
   • WS token 鉴权(Authorization header / subprotocol / query 三种)
6. scripts/pre-commit-check.sh 加进 scripts/deploy.sh 流程(可选)

验收:

• cd backend && pytest 跑过
• CI 跑预检脚本
• 评审员 Claude 看测试覆盖度

评审员: Claude

---

W-4. Dify API 集成预研(POC)

任务编号: 阶段 3 启动前置(关联 docs/路线图/阶段2-3-任务.md §3.3) 关联: docs/现有系统交接文档内容.txt + docs/ExternalSystemAdapter设计文档.md

预研目标:

1. 查 Dify 工作流 API 文档(看是否需要新 app,还是共用)
2. POC 三个端点:
   • POST /v1/chat-messages 流式对话
   • POST /v1/workflows/run 工作流触发
   • POST /v1/datasets/{id}/retrieve 知识库检索
3. 在 backend/app/services/dify_client.py 写 Dify 客户端
4. backend/app/api/ai_wingman.py 三个端点接 Dify 客户端
5. 写 docs/集成验证/Dify_POC_报告.md

验收:

• 三个端点跑通(返回 Dify 响应)
• 文档含 API 限流 / 错误降级 / 配额申请
• 评审员 Claude 看方案可行性

评审员: Claude

---

W-5. nginx 配置审计(全局 access_log 检查)

任务编号: 新增(M-2 风险项 衍生) 关联: docs/风险跟踪表.md 第十二节 M-2

审计目标:

1. 扫描所有 nginx.conf / deploy-server/nginx.conf / */nginx.conf
2. 找敏感路径(WS / token / OAuth callback)是否都 access_log off
3. 找未配 access_log off 但应配的路径
4. 写 docs/审计报告/nginx_access_log_审计.md

修复: 缺的补 access_log off;

验收:

• 审计报告列出所有敏感路径的 access_log 状态
• 缺的已补 commit
• 评审员 Claude 抽查 3 处

评审员: Claude

---

▼▼▼ 任务清单止

---

🔄 工作流(workbuddy 启动后)

1. 读这份 memory → 看 5 任务
2. 按 W-1 → W-2 → W-3 → W-4 → W-5 顺序(W-3 W-4 W-5 可并行)
3. 每完成一项:
   • 提交 commit(走 scripts/pre-commit-check.sh)
   • 推 Gitea 远端 feature/xxx 分支
   • 通知 Claude 评审
   • Claude 评审通过 → 用户合并 PR
4. 状态同步:
   • docs/风险跟踪表.md 更新状态
   • .workbuddy/memory/{日期}-{主题}.md 留评审记录

⚠️ 关键约束(读 README + CONTRIBUTING.md)

• 鉴权: 新增/修改端点必须有 Depends(get_current_agent) 或 _get_current_employee
• 依赖: 新增第三方 import 必须同步 requirements.txt / package.json
• alembic: model schema 变化必须生成迁移脚本
• 配置: nginx / docker / conf 改动 plan 写完必须做完
• 评审报告: 每次推送生成 docs/评审报告/workbuddy-{日期}-{主题}.md
• 5 项遗留: 上一轮评审遗留未修完,不许推新功能

🔗 关联文档

• 评审主报告: docs/评审报告/
• 风险跟踪表: docs/风险跟踪表.md 第九/十/十一/十二节
• 路线图 2-3 阶段: docs/路线图/阶段2-3-任务.md
• 推送预检脚本: scripts/pre-commit-check.sh
• 推送流程: CONTRIBUTING.md §PR 流程

🆘 阻塞上报

workbuddy 启动后,任何一项阻塞超过 30 分钟未推进 → 上报用户:

• token 问题 → 找用户
• 凭据不全 → 找用户给 WECOM_SECRET / Dify API key
• 测试失败定位 → 找 Claude
• 评审反复打回 3 次 → 升级用户

🛏️ 用户睡前最后做的事

1. Gitea Web → 站点管理 → 用户 → 创建新用户:
   • 用户名: workbuddy-claude
   • 邮箱: (用户填)
   • 密码: (临时,首次登录改)
   • 权限: 普通用户(非管理员)
2. 用 simon token 创 workbuddy-claude 的 access token:
   • 登录 workbuddy-claude 账号 → 头像 → 设置 → 应用 → 创建
   • 令牌名: claude-push
   • 权限: repository (读/写) + issue (读/写) + user (读)
3. 把 workbuddy-claude token 粘给 Claude:
   • Claude 写进 .workbuddy/config.json 的 gitea.token 字段
   • 同时配 Gitea Web 的 deploy key(ssh,可选)
4. (可选)改 docs/风险跟踪表.md 第十二节 §12.4 待办 #5 → block_admin_merge 改 true

完成上述 3 步 → workbuddy 客户端启动 → 自动接 5 任务