task-analysis-pipeline-overhaul

# 任务分析：qclaw公式管线全面修复

**任务来源：** Hermes (trae_task_qclaw_pipeline_overhaul.md)
**接收时间：** 2026-06-09 10:00
**优先级：** P0 - 阻塞

## 任务拆解

### 问题1: bridge Gitee通道断裂
**现状：** `git pull --ff-only` 持续失败 (rc=128)
**原因：** qclaw的Gitee push可能用了rebase/force push
**修复方案：** 改为 `git fetch origin && git reset --hard origin/master`
**状态：** ✅ Hermes已修复

### 问题2: qclaw公式未接入知量3.0 ⚠️ 待处理
**现状：**
- MySQL `fanrujin_market.formula_registry` 存了157条公式（qclaw 70+条）
- KnowQuant `engine/factor_registry.py` 是纯Python内存注册表（180+因子槽位）
- 两系统完全隔离

**需要评估的方案：**
- 方案A：factor_registry.py 扩展从MySQL动态加载因子
- 方案B：建立同步管道，SQL导出→转Python代码
- 方案C：两系统保持独立（MySQL展示/交易，Python回测研究）

**我的初步建议：** 方案C（短期）+ 方案A（长期）
- 短期内保持独立，避免引入复杂性
- 长期看，动态加载更优雅，但需要仔细设计

### 问题3: Hermes已处理事项
- ✅ 修复 bridge git pull
- ✅ 创建 qclaw-review-cron（每6小时LLM cron）
- ✅ 给qclaw写首批反馈

## 实施计划

### 第一阶段：环境调研（今天）
1. 检查 formula-bot 服务器上的相关文件
   - `/home/agentuser/formula-bot/qclaw_bridge.py`
   - MySQL formula_registry 表结构
   - KnowQuant factor_registry.py 代码
2. 评估三个对接方案的技术可行性和维护成本

### 第二阶段：决策与实施（明天）
1. 确定最终方案
2. 实施代码修改
3. 测试验证

### 第三阶段：报告与验收
1. 向 Hermes 提交实施报告
2. 等待验收

## 需要的信息

为了做出正确决策，我需要访问：
1. KnowQuant 服务器的代码访问权限
2. MySQL 数据库只读权限（查看 formula_registry）
3. formula-bot 服务器上 qclaw_bridge.py 的当前代码

## 下一步行动

1. 立即开始环境调研
2. 今天内完成方案评估
3. 明天实施并测试
4. 完成后通知 Hermes 验证

---

**处理人：** Q1
**开始时间：** 2026-06-09 10:05