Commit Graph
100 Commits
Author SHA1 Message Date
hmo ed842bc85d fix: digest与盯盘推荐区同步(老爸:推荐和XMPP同步)
- flush_rec_digest先回库校验快照: tag撤销/信号降级为弱信号/RR<2.0的条目丢弃
  (队列是打标瞬间快照,之后状态变化不再误推)
- digest预算门槛1.5→2.0(与盯盘exec一致)
- digest每条加💰可执行/排队徽章(与盯盘术语一致)
- buys/queued初始化防NameError
2026-07-24 12:37:52 +08:00
hmo 5667c89943 fix(ui): 买入区显示2位小数(5.96~6.02不再被round成6.0~6.0) 2026-07-24 12:29:54 +08:00
hmo 309f074c51 feat: S6叙事一致性检查+统一入口+容量60硬顶+提拔先入观察
- candidate_filter S6: 消息(个股+行业)x资金x技术叙事矩阵
  利好出货/三重打击=硬否决(dropped=1,不可被高分抵消)
  共振做多+3/利空出尽+1/资金驱动+1/阴跌-1/行业利空-1
- promote: 信号一律先入'关注'(12维确认才升,消灭出生即买入); 容量60硬顶,RR<2的末位淘汰
- alphasift收编: 只写candidates不再直写自选(统一入口)
2026-07-24 12:09:30 +08:00
hmo 481acfb18f feat: 优中选优机制(老爸:阈值太低+存量清洗+直接删)
- enqueue_recommend加严: RR>=2.0+仓位必须明确%+买入区有效+不追高(防今早RR1.49/仓位观望/区缺失的垃圾digest)
- promote: score>=7(原4=91%通过率)+ST排除+RR>=2.0
- watchlist_auto_exit: 新增死水3连退+RR<1.5退; 退出方式改为直接DELETE(非inactive)
- 盯盘可执行门槛1.5→2.0
2026-07-24 11:00:41 +08:00
hmo 1cdef8da7e feat: SenseNova高速通道(key从hermes config读,不落盘)
- token.sensenova.cn托管同款deepseek-v4-flash,实测3.2s vs OCG 45s(开盘高峰)
- 通道顺序: sensenova→OCG key池→gateway; 空输出直接切下一通道(SN无pro)
2026-07-24 09:18:15 +08:00
hmo a559fc84dd feat: 批量重评分片并发(老爸:这么多key不能并发?)
- batch_reassess --shard K/N: index%N==K分片,N进程互不重叠
- llm_client LLM_KEY_OFFSET: key池起始位错开,避免N进程压同一首选key
- SKIP_FLUSH=1时worker不发摘要,parallel_batch.sh收尾统一flush
- parallel_batch.sh: N路并行+等待+统一digest
2026-07-24 09:02:34 +08:00
hmo 9fad0cfa14 feat: kanban→XMPP通知桥(assignee=xiaoxiao/xxm的卡片DM给xxm@yoin.fun)
- hermes gateway dispatcher只派给246本地hermes profile, 小小莫在Windows够不着
- 每2分钟扫kanban.db, [Kanban] card.assigned格式DM, 去重状态文件
2026-07-23 15:53:06 +08:00
hmo 8de2230609 chore: 删除根目录capital_flow_collector死符号链接 2026-07-23 15:07:06 +08:00
hmo ad68878691 chore: 影子副本大清剿——删除7个陈旧/重复tracked副本
彻查发现8个影子副本(内容漂移):
- scripts/batch_reassess.py(07-22旧版,无锚定prompt)
- scripts/per_stock_reassess.py(07-22旧版,含已删除的160行独立prompt)
- scripts/verify_reassess_pipeline.py(07-21旧版)
- scripts/server.py(07-08远古版)
- price_monitor.py根+scripts(旧版,无进区摘要关停; 且根副本有未提交改动)
- capital_flow_collector.py根+web-dashboard(死符号链接)
- hermes scripts下server.py/xiaoguo_news_processor/xiaoguo_scanner(孤儿)
保留: 每类只留唯一canonical(deploy/profile-scripts或根目录SSOT)
2026-07-23 15:05:39 +08:00
hmo 5e2d430c39 fix: 删除根目录陈旧strategy_lifecycle.py(影子副本)+2个bak垃圾
根因: 根目录与profile-scripts双tracked, 根副本停在07-21旧版
→ root上下文import拿到无修复旧代码(今日refresh_actions踩中)
technical_analysis/multi_timeframe根副本内容一致暂不动
2026-07-23 14:53:40 +08:00
hmo 9e995accb2 fix(template): 空仓股票不再显示'盈利持有'
- 技术模板action首段按profit_pct打标签, 非持仓cost=0→profit=0→永远掉进'盈利持有'
  (601998: 空仓+信号买入+显示'盈利持有', 自相矛盾)
- 非持仓(shares=0/is_watchlist): 买入信号→'空仓·可建仓', 其他→'空仓关注'
- manual分支同款修复
2026-07-23 14:42:13 +08:00
hmo 91b26361e9 refactor: write_holding_strategy改UPSERT,DELETE+INSERT模式退役
- 只写自有列; rr_low/rr_high(recompute_rr拥有)/superseded_at/created_at不在写集→天然保留
- 未来新增计算列自动免疫(老爸: 新增计算列为什么要用delete+insert?不该用update吗?)
- 消除DELETE→INSERT崩溃窗口和created_at被重置副作用
2026-07-23 14:31:18 +08:00
hmo 6eab2148eb fix(audit): candidates UPSERT保计算列+market_scanner INSERT对齐表结构+拆除sync_decisions_to_db地雷
举一反三审计结果:
- accumulation_scanner: INSERT OR REPLACE整行替换,promoted=1的候选被重置score/promoted/log
  → ON CONFLICT DO UPDATE只更新扫描器自有列(cron活跃,今日必修)
- market_scanner: INSERT引用表中不存在的列(price/score/entry_low等),实测必失败
  → 对齐真实schema+同款UPSERT(孤儿脚本顺手修)
- sync_decisions_to_db.py: 全表DELETE再从已不存在的decisions.json重建,地雷→归档
2026-07-23 14:23:06 +08:00
hmo 12f7f87a2e fix: 弱信号不可执行+rr_low/rr_high防DELETE+INSERT冲零
- /api/watch: 信号不充分/关注/弱势持有/观望/持有 的推荐永远排队不徽章可执行
  (tag是LLM行动信号时遗留,技术路径降级信号后无权摘tag,徽章层自卡信号)
- write_holding_strategy: INSERT补rr_low/rr_high列,调用方不提供时保留旧值
  (盘中per_stock技术路径每次DELETE+INSERT把两个计算列冲成0,昨晚回填全灭)
2026-07-23 14:11:22 +08:00
hmo d5a62f48ef refactor: per_stock统一使用batch的collect_data+build_prompt
- 删除per_stock内160行独立prompt及数据装配(宏观/PE/资金流/新闻/变更记录/技术位锚)
- 单一prompt源头: 以后改prompt只改batch_reassess.build_prompt一处, 不再漂移
- per_stock免费获得: 技术位锚/持仓上下文(持有vs未持有)/组合现金/参数自检/统一输出纪律
2026-07-23 13:53:37 +08:00
hmo ccfa22c0d4 fix(per_stock): prompt补齐技术位锚定(与batch同源)
- per_stock的12维prompt是独立实现,无【技术位锚】无买入区间输出无参数自检
  → 今日35只重评中26只经per_stock路径,锚定纪律缺失(双prompt漂移)
- 注入同款锚定段+买入区间输出+参数自检+输出纪律第4条
2026-07-23 13:40:28 +08:00
hmo 37664f0523 fix(prompt): MA行仅在可用时输出 2026-07-22 23:46:18 +08:00
hmo cf039b2770 feat(prompt): 技术位锚定+止损门禁+12维命名统一
- collect_data: 现算technical_analysis.full_analysis(强撑/弱撑/枢轴/弱压/强压/有效区间/MA)
- prompt: 【技术位锚】独立高亮段+锚定纪律(止损<区下沿,锚弱撑下方1-3%/强撑;止盈锚弱压强压;
  偏离须说明理由)+输出纪律第4条+【参数自检】节
- save_result: sl>=el时用弱撑x0.985/强撑x0.99自动修正并留痕,无技术位拒写
- 命名: 九维→12维全局统一(prompt/docstring/前端弹窗)
2026-07-22 23:43:45 +08:00
hmo 440ce56b0b fix(ui): 盯盘推荐区RR三值+个股弹窗DB化
- /api/stock/<code>: 从holding_strategies读策略/三值RR/action/full_analysis
  (原先只读data/stocks/{code}.json, 与DB脱节, 弹窗打开=空白)
- openStock弹窗: 新增当前策略卡(信号/区间/损盈/三值RR/仓位/操作建议)+12维分析折叠区
- 盯盘推荐区RR列: 中值下方小字显示下沿~上沿(上次改错表了, renderWatchlist≠盯盘推荐区)
2026-07-22 23:25:34 +08:00
hmo 0f2c6555df fix(action): 12维操作建议写入action+技术路径action权限保护+RR区间显示修复
- batch parse_response提取【操作建议】→ save_result写action(根治: action字段只有技术路径写,
  旧'盈亏比不足不建议买入'与12维买入分析同框矛盾)
- write_holding_strategy: 技术路径不得覆盖新鲜(<20h)12维 action(与信号权威同级)
- 前端: rr_high>0即显示低~高区间(rr_low=0是合法信息: 区下沿=止损贴底即损)
- server: SEND_FILE_MAX_AGE_DEFAULT=0 禁静态缓存
2026-07-22 23:16:43 +08:00
hmo f7f7fe3ca0 fix(parser): 节标题锚定解析+脏区间清洗+三值RR
- parse_response: 只认行首【买入区间】【综合结论】等节行(原先取首个关键词行,
  命中修改点段落引用的旧脏值→95~99区间反复写回,17只股票受害);
  信号锚定】后首词,防'观望(不建议买入)'误判; 【买入区间】无→显式清空
- save_result: 区间-现价距离门禁(eh<0.5px或el>1.5px→拒写并清空,不再保留原值养脏)
- recompute_rr: 三值RR(rr_low/rr_ratio中/rr_high,分别对应区下沿/中值/上沿入场)
- 迁移: holding_strategies+rr_low/rr_high列; digest显示RR中(低~高); watch API+前端展示
2026-07-22 22:59:18 +08:00
hmo 56e1326569 fix(rec): RR基准价改用买入区中值(老爸决策)
- 区/损/盈三数同出一份分析, 自洽闭环; 不随价格波动; 脏区间自动算出RR=0现形
- 区间缺失才兜底现价
2026-07-22 20:49:59 +08:00
hmo 9bcf3e5e63 fix(rec): RR系统自算落库+卖出不占买入预算+RR>=1.5门槛
- mofin_db.recompute_rr: 用现价+止损止盈重算RR, sync_recommend_tag入口统一调用
  (根治: prompt没让LLM输出RR, parse不解析, save不落库 → rr_ratio永远0)
- flush_rec_digest: 卖出/止盈单独一组排最前, 不占现金预算; 买入加RR>=1.5可执行门槛
- server.py/api/watch: 卖出永远可执行; 买入RR>=1.5才给可执行徽章
  (根治: 卖出默认吃8%预算被排队, RR=0的5%仓位反而挤进预算)
2026-07-22 20:31:47 +08:00
hmo dabef038db fix: max_tokens下限512(OCG对小max_tokens短路返回空) 2026-07-22 14:00:14 +08:00
hmo efd8baaeff fix: 空输出不再假成功——升级pro仍空时落到外循环切下一个key 2026-07-22 13:54:25 +08:00
hmo 9939713059 feat(llm): OCG key池——按/api/keys实时状态排序轮换(key6优先),空输出同key升pro再切下一key 2026-07-22 13:51:43 +08:00
hmo e0e98ebb1a fix: 消息面不限情绪标签(分类器已死,原始新闻直接喂LLM自行判断)——batch+per_stock两路 2026-07-22 13:37:45 +08:00
hmo 40a75554aa fix: 消息面查询code列不存在(searched_stocks)导致整个try块死亡——改列名+兜底独立try 2026-07-22 13:31:29 +08:00
hmo 5ebc093408 feat: 腾讯基本面刷新器(PE/PB/EPS/总市值/流通市值) 2026-07-22 13:09:30 +08:00
hmo cdfc7346f1 feat: cninfo行业富集器——批量补全stock_sectors行业映射+回填sector_context 2026-07-22 13:04:43 +08:00
hmo 5d8c7476ff fix: 行业未映射时诚实标注,禁止大盘指标伪装成行业信息 2026-07-22 12:52:12 +08:00
hmo cdbbcec69e fix: stock_sectors列名sector→sector_name(静默except吞掉的错误) 2026-07-22 12:50:41 +08:00
hmo eb644221f4 fix: 资金流聚合输出net_flow/main_force/retail_flow/trend(12维资金面恒0根因) + sector_context污染时行业名兜底 2026-07-22 12:46:22 +08:00
hmo a3f5ad5b3a fix: 资金流端点再修正——ssl_qsfx_zjlrqs(最新在前), lscjfb数据停2020年是僵尸源 2026-07-22 12:36:01 +08:00
hmo 51c19b4971 fix: 资金流改Sina MoneyFlow(eastmoney 246不可达) + 消息面按行业名匹配+大盘兜底 2026-07-22 12:31:48 +08:00
hmo b92a8cb666 fix: 换仓建议f-string嵌套引号语法错误(已部署版本必现,紧急修复) 2026-07-22 11:02:43 +08:00
hmo 294133d605 feat(推荐): 换仓策略——现金不足时自动给出减弱势持仓换入排队推荐的方案 2026-07-22 11:01:02 +08:00
hmo f35144f3f1 feat(盯盘): 推荐区全展示+可执行/排队徽章(预算内标可执行,不再降级隐藏) 2026-07-22 10:53:32 +08:00
hmo 1910cef98b fix: 空信号清除tag + 卖出/止盈仅持仓股算动作信号 2026-07-22 10:48:49 +08:00
hmo b18e0d2164 fix: 关停进区摘要推送(噪音)+ per_stock结束也flush推荐摘要(688428式漏发根治) 2026-07-22 10:39:20 +08:00
hmo c91d4c33f0 fix: 信号-分析对齐(reconcile以已存分析为唯一事实源) + prompt持仓上下文(已持有/未持有分开给建议,禁止两头写) 2026-07-22 10:29:23 +08:00
hmo f42dc9381b feat(推荐): enqueue校验(非动作信号不入队)+头部推荐附12维全文+现金预算操盘建议 2026-07-22 10:12:42 +08:00
hmo e633641686 fix: tag只许LLM路径写(防技术路径抖动幽灵化) + 推荐通知改批量摘要(防09:55式14连发轰炸) 2026-07-22 10:05:54 +08:00
hmo 8c2226e2b4 feat: 信号权威层级+推荐转场推送统一+🔔分级修正
1. 权威层级: 新鲜(<20h)12维动作级信号, 技术路径(regenerate_all/
   price_monitor)无权降级为关注/信号不充分/持有——只有LLM路径或
   风险信号(卖出/止盈)可覆盖。根治推荐区'出现-消失'抖动
2. 推荐转场推送统一收拢到 mofin_db.push_recommend_alert:
   tag新转为current_recommend时推送(全路径), 含质量门禁;
   移除batch_reassess内联推送(防双重告警)
3. price_monitor 🔔分级: 只有持仓股的卖出/止盈才ACTION直推,
   买入/加仓机会一律进INFO摘要(老爸: 这种消息不要再发了)
2026-07-22 09:48:58 +08:00
hmo a42e3a16e5 feat(盯盘): 筛选/排序控制条——信号多选chips+排序下拉(RR升降/涨跌升降)+RR下限过滤+重置 2026-07-22 09:31:19 +08:00
hmo fa163f53f9 fix: 开盘grace(09:00-09:15)——管道刚启动时隔夜数据不误报(verify管道审计+L1功能检查) 2026-07-22 09:20:26 +08:00
hmo 2a4ff53553 fix: sync脚本不再创建scripts/下cron脚本副本(配合文件居住宪法,副本一律自动归档) 2026-07-22 08:42:27 +08:00
hmo d04e7664ee chore: L2卫生自动归档 1 个影子/孤儿文件(archive/202607-auto) 2026-07-22 08:41:29 +08:00
hmo b7898c85c9 Merge branch 'session-work' 2026-07-22 08:41:29 +08:00
hmo 3ea7c52112 feat(L2): 卫生审计自动收尸——scripts/影子副本+零引用孤儿(mtime>7天)自动git mv归档并提交; dev-spec新增文件居住宪法(红线#9) 2026-07-22 08:41:06 +08:00
hmo 228344b06b chore: 归档文件内容同步为当前canonical版本 2026-07-22 08:38:43 +08:00
hmo 55077395f9 chore: scripts/大收尸——178个影子副本/零引用工具归档至archive/20260722-scripts-cleanup(红线#6/#8,git mv保历史) 2026-07-22 08:38:19 +08:00
hmo 375f6d469a chore: sync脚本补price_monitor三处副本硬链 2026-07-22 08:28:39 +08:00
hmo fbad1938f1 feat: 失败二轮重试(休息60s后失败股整体重跑) + sync脚本补7个分叉副本硬链 2026-07-22 08:26:32 +08:00
hmo 04284e5187 fix: 推送质量门禁+损盈一致性门禁(根治垃圾信号)
1. XMPP推送门禁(_validate_buy_alert): 实时价>0(live_prices)、
   区间有效、现价不超上沿5%、损<下沿且在(0.5x~1.0x)现价内、
   盈>上沿>损 —— 任一不过不推只记日志
2. DB损盈一致性门禁: 损必须在下沿之下、盈必须在上沿之上且损<盈,
   不一致字段跳过写入保留原值(浩辰 区2~3损25.11 类污染根治)
3. 推送价格源改 live_prices(不再用 holding_strategies.price 的0值)
4. 浩辰脏行已从快照恢复(区25.93~27.84 损25.11 盈31.38)
2026-07-22 08:16:40 +08:00
hmo c27388681c fix: FALLBACK_MODEL 顶层导入(NameError 曾中断批量重评) 2026-07-22 01:31:56 +08:00
hmo 6cdcd3f2e5 feat(L1): 新增reassess_daily检查——持仓当日重评覆盖率+分析存在率+自选24h补评率(修复'每日重评做没做'无监控的空白) 2026-07-22 01:03:43 +08:00
hmo 36f01dc8f0 fix: save_result区间写入门禁——下沿<上沿<下沿x3,异常整体跳过(防214.68~2.52解析污染) 2026-07-22 00:39:30 +08:00
hmo d92d6ba54b fix: 截断保护——输出<1500字且无信号时升级pro重试(flash懒答/截断导致信号丢失) 2026-07-22 00:36:53 +08:00
hmo 83b0770db0 feat(llm): flash空输出自动升级pro重试(688617实测flash三连空/pro正常输出) 2026-07-22 00:30:33 +08:00
hmo 40852de280 fix: LLM空输出视为失败 + save_result拒绝写入空分析(防止假时间戳跳过机制失效) 2026-07-22 00:24:47 +08:00
hmo c1b38d3d7b feat(盯盘): 推荐操作精选层——72h新鲜度+RR降序+现金预算贪心装入(上限5只)
老爸: 太多推荐=没有推荐。机制:
- 候选: tag非空 且 reassessed_at 72h内(陈旧信号不算推荐)
- 排序: rr_ratio 降序
- 预算: 从 portfolio_summary 读现金/总资产, 每只建议仓位
  (position_advice解析%或默认8%) 贪心累加, 耗尽即止, 最多5只
- 落选者降回持仓/自选自然组
- /api/watch 返回 cash/budget_pct/rec_used_pct, 前端显示预算条
- 推荐行仓位列显示'建议X%'
2026-07-22 00:16:35 +08:00
hmo 93f0b24007 docs: 纪律文档加严——git写权限撤销(pre-commit白名单,kanban唯一路径) 2026-07-21 23:49:29 +08:00
hmo 52f7df7bef feat: 提交白名单配套——guard带GIT_ALLOW_COMMIT令牌 + hygiene新增钩子存在性检查 2026-07-21 23:45:26 +08:00
hmo 9914ff9457 feat(盯盘): 推荐操作区域置顶独立 + tag与XMPP动作级信号自动同步
- mofin_db: write_holding_strategy 内置tag同步语义——动作级信号
  (买入/可买入/可加仓/卖出/止盈)→current_recommend; 信号降级→
  清除current_recommend; active_manual人工标记永不被自动流覆盖/清除
- 新增 sync_recommend_tag() 供裸SQL调用方
- batch_reassess.save_result / per_stock stage-2 调用同步
- 盯盘Tab: '重点推荐'更名'推荐操作', 区域独立琥珀色视觉, 置顶
同步语义: XMPP买入信号(ACTION级告警)的个股=推荐操作区域个股,
信号消失(重评降级)时区域同步消失
2026-07-21 23:31:57 +08:00
hmo 05a60cf0d4 revert(34337fc5): 恢复被知微二次stale提交覆盖的昨晚重构——batch/per_stock/stale_detector/fix_gateway_port/candidate_filter 回滚至1e71a2d8版本;她提交中的运行时文件(db-shm/db-wal/price_history/market_scan_summary)移出跟踪;保留其morning_health_check小果清理 2026-07-21 23:24:45 +08:00
hmo 3e5d841e58 chore: data/backups/ 移出跟踪 2026-07-21 13:48:53 +08:00
hmo 5422b0a11d feat(db): 每日DB在线备份(07:50,留14天) + 管道审计malformed重试一次再告警(瞬态WAL损坏防误报) 2026-07-21 13:47:10 +08:00
hmo 29e0e6c8b4 fix(688775事件): bot不再静默吞消息 + 价格推送分级 + 小果假警报清理
1. bot call_hermes 失败: 10s重试一次, 仍失败回兜底消息(网关暂时不可用)
   ——此前连接被拒时用户消息被静默吞掉(688775事件根因)
2. price_monitor 推送分级: 破止损/重评确认信号/持仓急跌=ACTION直通;
   未确认进区提示=聚合成一条摘要走INFO(30min限1条+8行截断)
   ——今早一秒一条十几连发+思特威英诺特双发
3. alert_helper ACTION 增加5min内容去重(防竞态双发)
4. intraday_health_check 删除小果全部残留检查(已退役, 假警报
   导致知微旧自愈执行器烧150k+token/session去调查并直接改代码)
2026-07-21 10:41:32 +08:00
hmo e6e79ced0d docs: 红线#12 告警信噪比纪律(alert_helper两级通道) 2026-07-21 02:44:56 +08:00
hmo 1e71a2d852 feat(alerts): alert_helper 统一告警网关——信噪比控制
两级通道:
- ACTION(买入信号/重点推荐/部署验证失败): 直通不限速, 🚨醒目前缀
- INFO(部署/卫生/修复/螺旋报备): 同类30min限1条 + ≤8行截断 +
  24h内容去重(同一问题不重复轰炸) + 压制计数透明披露

6个调用点全部迁移: deploy_guard/hygiene/spiral/self_repair(INFO)
+ batch_reassess/per_stock_reassess 买入信号(ACTION)
解决: 真正有意义的信息(重点推荐操作)不被纯通知淹没
2026-07-21 02:43:57 +08:00
hmo 54652bff12 fix(verify): functional_health/mofin_health 新鲜度阈值 1h→16h(两者均交易时段运行,夜间必假警报) 2026-07-21 02:14:06 +08:00
hmo b1db424b8d chore: data/prompts/ 移出跟踪(提示词注册表为运行时产物) 2026-07-21 02:12:13 +08:00
hmo 1806b6a174 fix(SSOT): 4个库文件副本移出git跟踪(红线6:只允许硬链接,不允许独立副本)——硬链与git跟踪本质冲突:checkout重建文件断链→内容与提交版不同→guard判漂移回滚→sync重链→再dirty→merge被阻。移出跟踪后:根目录mofin_db.py/mo_data.py为唯一tracked canonical,副本由sync脚本以硬链重建 2026-07-21 02:09:25 +08:00
hmo 609ef06e6e fix(guard): CODE_PATHS补scripts/整目录+mofin_db/mo_data根文件——覆盖库文件硬链造成的合法dirty 2026-07-21 02:08:23 +08:00
hmo beee453bf3 fix: 同步4个库文件副本的提交内容与根canonical一致——消除deploy_guard回滚↔sync重链拉锯(guard实测抓到漂移并回滚,机制自证有效,但提交内容必须同源) 2026-07-21 02:06:55 +08:00
hmo 3e84cbc17e ux: 系统告警统一加'📟【MoFin系统·XX】(非知微本人)'前缀——告警与知微本人消息可一眼区分 2026-07-21 02:04:55 +08:00
hmo 6d1d4a5164 fix(SSOT): 库文件统一硬链到MoFin根目录canonical——今晚三处改造差点跑在陈旧副本上
- mo_data.py 提升为根目录canonical(含tag修复), deploy/profile-scripts/
  scripts/ profile脚本目录 全部硬链到根
- mofin_db.py 同理(含strategy_history/tag迁移), 四处硬链统一
- sync_profile_scripts.sh 增加库文件链接步骤, merge后自动恢复
- 根因: deploy/profile-scripts/mofin_db.py 是7-20陈旧副本(无snapshot),
  profile脚本目录mo_data.py无tag——hygiene分叉副本检查正确报警
2026-07-21 02:00:26 +08:00
hmo 2054c6e6f9 fix: state.db 时间戳单位自适应(秒/毫秒混存)+ default profile 无sessions表静默跳过 2026-07-21 01:54:59 +08:00
hmo 839c6fc2ff feat(self-heal): 三盲区系统性补丁——自愈体系覆盖今晚三类故障
1. agent_spiral_watchdog.py (新增,10min cron): state.db 检测运行>15min
   且消息>80条的 api session(螺旋特征), XMPP告警+去重。补 603288 事件
   '无watcher看agent会话本身'盲区
2. deploy_guard: 自动merge后自动跑 verify_deployment.py, 失败项立即
   XMPP告警。补'提交级回归无监控'盲区(知微stale提交事件)
3. system_hygiene_audit: 新增第7项检查'指令冻结session'——常驻session
   启动时间早于SOUL.md mtime且6h内仍活跃 → 告警需bump/重启。
   补'system_prompt冻结'盲区; 6h活跃度过滤防误报已遗弃session
2026-07-21 01:53:11 +08:00
hmo ab258c6264 chore(bot): xmpp session v3->v4 刷新知微冻结指令(部署纪律/识图知识更新),对话上下文重置 2026-07-21 01:42:14 +08:00
hmo ae0c7d1ca3 fix(L3): self_repair 迁移 llm_client(OCG直连无session) 废弃常驻'self-repair' session(指令冻结+上下文累积) 2026-07-21 01:39:54 +08:00
hmo 95d07f6a11 fix(guard): porcelain路径解析健壮化(line[2:].strip + rename格式处理) 2026-07-21 01:19:53 +08:00
hmo a69b246c57 feat(guard): 部署一致性守卫 deploy_guard.py + 知微运维纪律 + 健康JSON移出跟踪
- deploy_guard.py (15min cron): 代码漂移自动回滚(仅未提交改动)+
  session-work可快进时自动merge部署+幂等重链+cron引用完整性,
  状态落盘JSON, 有动作即XMPP报备
- docs/zhiwei-ops-discipline.md: 知微纪律——禁止直接编辑被跟踪代码/
  禁stale提交/禁直调gateway批量LLM; 自愈白名单(rerun/restart/
  sync/switch_key)本不改代码, 与纪律不矛盾; 紧急热修走git流程,
  提交到session-work后guard 15min自动部署
- dev-spec 红线#6 补充部署守卫机制
- static/mofin_health.json 移出git跟踪(运行时产物, 常驻dirty
  会废掉漂移检测)
2026-07-21 01:17:01 +08:00
hmo 574151aee9 docs: 红线#11 批量LLM调用禁走hermes gateway agent通道(603288事件) 2026-07-21 01:05:08 +08:00
hmo cd530c2463 fix(llm): 重评直连OCG上游绕过hermes agent运行时 + 全线切flash + prompt输出纪律
事故根因(2026-07-21): hermes gateway /v1/chat/completions 非透传,
每个请求创建带工具的agent会话。一次603288重评螺旋35分钟/44次
terminal调用/输入153k token, 客户端超时后服务端空转, 重试叠加
新会话自我DDoS。

- llm_client 重写: OCG直连为主(key运行时从hermes config.yaml
  ocg-key6读取, 不落盘), gateway兜底(agent模式仅应急)
- REASSESS_MODEL: pro -> flash (A/B实测新prompt下质量差距微弱,
  flash快40%)
- prompt输出纪律: 【建议仓位】不可省略(非买入写'不新建仓'),
  禁止structured_data/XML/JSON块, 禁止寒暄开场白
- batch main 双通道预检(全挂才退出)
2026-07-21 01:00:47 +08:00
hmo 5b44086c8a fix: reports匹配链修正(标题匹配不再是死代码) + strategy_history空历史时降级当前行 2026-07-20 23:58:45 +08:00
hmo 9a8e3344ac restore: candidate_filter busy_timeout + premarket Step1.5 摘要字段(知微17:31 stale提交回滚恢复至7b26c373已验证版本) 2026-07-20 23:53:03 +08:00
hmo de9927a627 重评核心重构:ds-v4-pro + 原策略全文 + strategy_history + 前端三改造
后端(重评管线):
- 新增 llm_client.py 共享客户端: REASSESS_MODEL=deepseek-v4-pro 单点,
  gateway预检(fail-fast), 150s超时+1次重试, 永不抛异常
- batch_reassess/per_stock_reassess: curl/urllib -> call_llm,
  prompt传入原策略全文+当前参数+最近3条变更, 输出 维持/修改判断+
  修改点理由+最终新策略, max_tokens 4096
- mofin_db: 新增 strategy_history 表 + snapshot_strategy_history(),
  write_holding_strategy 覆写前自动快照(保留20条/code)
- mofin_db: holding_strategies 补 tag 列迁移 + 写入保留
  (tag缺席=保留旧值, 显式传''=允许清除), 修复推荐标签被静默丢弃
- mo_data.read_decisions: SELECT 补 tag
- stale_detector/promote_candidates: 子进程超时 240/60 -> 480s

前端:
- 移除 报告Tab -> mofin_health 全部流程/Cron 表加 最后十次 列
  (modal列表->详情), /api/reports 支持 cron+script 多路匹配
  (jobs.json name->id 解析 + 文件名/标题子串兜底)
- 移除 决策库Tab
- 盯盘Tab 重构: 全部持仓+自选, sort_group 分组(推荐/持仓/自选),
  推荐行琥珀高亮+🔥badge+行内策略, 新增 操作策略 列查看
  最近3次完整策略(/api/strategy_history/<code>, 表缺失时降级当前行)
- 提示词Tab: registry.py 数据路径改回 /home/hmo/MoFin/data/prompts
  (红线: 数据只在规范数据根), 空态提示初始化命令
2026-07-20 23:51:24 +08:00
hmo 7b26c373d1 fix(reassess): stale_detector timeout 60->240s + batch cap 5/run + GATE_ZONE_SANITY
Three issues from zhiwei's strategy report:

1. '37 reassess all timed out (subprocess 60s)': real cause is per-call LLM
   latency exceeding the 60s per-subprocess limit during the key5-dead/
   gateway-unstable window. NOT 'no concurrency control' as reported (60s
   is per stock, not for the batch). Fixes: per-call timeout 60->240s
   (LLM cold-start is 20-100s), and cap AUTO_REASSESS batch to 5 stocks
   per run with remainder continuing next run (was unbounded serial calls
   that also blew the 120s cron script window).

2. '15 stocks entry-zone center wrongly 97.0': quality gates had no
   zone-sanity-vs-price check, so bad data (bad quote or LLM template
   output) could be written freely. New GATE_ZONE_SANITY (CRITICAL):
   zone center must be within 0.3x-3x of current price. Verified: rejects
   the exact 97-center-vs-5.69-price corruption, passes legit zones.

3. 'reassess overwrites manual SQL fixes': true by design; with
   GATE_ZONE_SANITY at write time, reassess can no longer overwrite good
   values with garbage - invalid writes get rejected + flagged instead.
2026-07-20 22:05:00 +08:00
hmo 299ddc1796 fix(ocr+bot): image download race, SenseNova context, log path, encoding
Root causes of the screenshot 404 incident:
1. RACE: client uploads image AND sends message concurrently; bot received
   the message before the upload finished writing, so its GET hit a 404
   error page (<100B treated as failure). FIX: _download_image now retries
   3x with 2s backoff.
2. Zhiwei mentioned tesseract/小果 because the failure text never told her
   the pipeline IS SenseNova. FIX: failure messages now name SenseNova
   explicitly and ask for resend.
3. log_xmpp never worked for the bot: sys.path used relative '../..' from
   a symlinked __file__ which resolved to '/' instead of MoFin root. This
   is why the '最近对话' panel never had bot chat data (only cron script
   entries). FIX: absolute path per red line #7. Verified: test message
   now lands in xmpp_messages.jsonl.
4. My PowerShell -replace corrupted the file encoding (UnicodeDecodeError
   crash loop on restart). Restored from git HEAD and re-applied edits with
   the edit tool. Lesson: never use PowerShell string replace on UTF-8
   source files with Chinese content.
5. functional_health: new sense_ocr module (OCR config presence +
   SenseNova API TCP reachability), no token cost.
2026-07-20 21:42:59 +08:00
hmo 60dbb64f92 docs(dev-spec): v2.1 — fix section numbering + outdated refs
Zhiwei flagged: '十条红线' but she counted 14. Real issues found:
- duplicate section numbers: two '三、' (验证闭环 + 自检体系矩阵),
  two '四、' (开发流程 + 部署环境) -> renumbered 一~七 sequentially
- doc index said '含五条红线' (stale from v1) -> '含十条红线'
- F 小节 still used old Tier1/Tier2 framing -> aligned to L0/L1-L2
  with pointer to the L0-L4 matrix section
- version bump v2.0 -> v2.1
Minimal edit: no content changes beyond numbering/consistency.
2026-07-20 21:21:21 +08:00
hmo 94883539de docs: reply to zhiwei on cron error status accuracy 2026-07-20 20:57:20 +08:00
hmo 10a37f10f9 fix(watchdog): gateway session check now uses agent.log scan, not live LLM ping
Gateway看门狗-知微 was erroring (exit -15): its check_session_health did a
live LLM ping with 25s timeout. Cold-start LLM latency is 20-100s so the
ping always timed out -> false '不健康' verdict -> false gateway restart
-> and each 10-min run burned 22k tokens.

Now uses xmpp_logger._scan_agent_log (zero cost, reads real call results):
- ok if last real call succeeded
- unhealthy only if last call explicitly failed
- idle (no recent calls) counts as healthy
Verified: watchdog job now status=ok.

Also: triggered all 6 weekend 'Blocked' jobs via hermes cron run — all
now status=ok, proving the hardlink fix holds.
2026-07-20 20:55:30 +08:00
hmo c42769f293 docs: zhiwei briefing on 2026-07-20 system changes 2026-07-20 20:36:50 +08:00
hmo 9a359f49bd feat(deploy): automatic hardlink repair built into deployment pipeline
User insight: hardlink breakage only happens at deploy time (scp file
replacement / git checkout-merge), so detection must be welded INTO the
deploy pipeline, not left to daily audit.

Three automatic layers, no reliance on discipline:
1. systemd path watcher (profile-scripts-sync.path): watches
   deploy/profile-scripts/ directory, auto-fires sync_profile_scripts.sh
   on any change. Verified: fires within 4s of file replacement, logs to
   gateway/logs/link_sync.log (runs as hmo user)
2. git hooks (.git/hooks/post-merge + post-checkout on 246 repo):
   auto re-link after git operations
3. Manual fallback: sync_profile_scripts.sh (now self-logging)

dev-spec red line #6 updated: SSOT rule now documents the three layers
and states breakage only happens at deploy time.
2026-07-20 20:27:11 +08:00
hmo 08eef1e181 feat(self-check): L0-L4 layered self-check architecture with LLM auto-repair
User directive: daily not weekly; clear responsibilities per layer with no
overlap; functional criteria (does the function WORK) not process liveness;
problems get FIXED via LLM with file-and-report discipline (act first,
report after); plus a meta-layer watching the watchers; deeply integrated
into F健康.

Architecture (responsibility matrix in dev-spec.md):
- L0 agents_health_check (5min): port/HTTP/DB liveness + auto_heal executor
- L1 functional_health_check (15min trading): per-module FUNCTIONAL
  criteria — output freshness/validity per REGISTRY (live_prices/market_
  snapshots/mtf_cache/macro_context/bot/LLM/cron engine), not process alive
- L2 system_hygiene_audit (daily 08:20, was weekly): divergence/hardlink/
  zombie/orphan/dead-cron/db-freshness
- L3 self_repair (30min): reads L1/L2 failures -> LLM diagnoses -> executes
  WHITELISTED repair actions directly (rerun_script/restart_service/
  sync_links/switch_llm_key/none) -> repair_log.jsonl + XMPP report.
  Max 2 repairs/module/day anti-loop. LLM unavailable -> rule fallback.
- L4 meta_watchdog (hourly): checks L0-L3 output freshness + L3 cron
  registration + XMPP bridge; direct XMPP alert as last resort

Retired (overlap): Cron监护-高频 (cron_watchdog -> L3), 全局cron健康监控
(cron_health_monitor -> L1).

Dashboard: mofin_health.py now emits self_check section (functional/meta/
hygiene/recent_repairs); mofin_health.html new '🩺 自检体系' tab rendering
L4 layers, L1 module checks, L2 issues, L3 repair history.

E2E verified: stopped xmpp bot -> L1 flagged fail -> systemd recovered ->
L3 LLM correctly diagnosed 'none needed' and logged; rerun_script whitelist
path executes real scripts successfully; meta_watchdog all-green after fix.
2026-07-20 19:39:58 +08:00
hmo 4f83ee8a01 feat(hygiene): anti-redundancy enforcement — spec rules + weekly audit
Root cause analysis of the 2026-07-20 redundancy incident:
1. No single-source-of-truth rule -> same file legitimately lived in 4+
   locations, diverging silently
2. Relative path resolution (Path(__file__).parent/'data') -> each
   hardlinked copy of mofin_db.py pointed to a DIFFERENT database
3. 'Backup habit' left .bak/legacy files in production dirs, which
   monitoring then scanned and reported as false alarms
4. Half-done migrations: DB tables created but old JSON writers/readers
   stayed (price_events), old files stayed
5. Dead modules never got buried: xiaoguo 'dead' but bot ran 8 days
   as root eating 2.5GB
6. Monitoring checked 'does it exist' not 'is it alive' -> stale file
   mtime reported as 'pipeline stalled 14 days' (false alarm)
7. No 'system hygiene' as a check category at all

Prevention implemented:
- dev-spec.md v2.0: 五条红线 -> 十条红线
  #6 single source of truth (hardlink only, no independent copies)
  #7 absolute data paths only (no __file__-relative data resolution)
  #8 no backups/legacy in production data dirs (archive immediately)
  #9 dead module burial checklist (6 mandatory steps)
  #10 monitor liveness (DB table freshness) not existence
- File Location Constitution: canonical location per content type
- NEW system_hygiene_audit.py: weekly Monday 07:30 cron checking
  diverged copies / broken hardlinks / zombie processes / orphan data
  files / dead cron scripts / DB freshness -> hygiene_report.json + XMPP
- specs/hygiene.json: module spec per red line #1
- Verified: audit found 5 real issues on first run, all fixed, re-run clean
2026-07-20 19:04:05 +08:00
hmo d5b8bec897 refactor: retire price_events.json completely — DB is the only store
User directive: no JSON, retire it fully, fix all related code.

Changes:
- price_monitor.py: record_event writes DB only; removed EVENTS_PATH/
  load_events/save_events entirely
- strategy_feedback.py: price events read from DB only (removed JSON fallback)
- system_health_check.py: removed price_events.json from file-check list,
  DB-only event stats (was showing 0/0 due to wrong-DB resolution)
- mo_config.py: removed dead price_events_path property (no callers)
- mofin_health.py: price_events freshness reads DB table (authoritative now)
- mofin_db.py: DATA_DIR/DB_PATH now ABSOLUTE (/home/hmo/MoFin/data) —
  was relative __file__.parent, so each hardlinked copy of mofin_db.py
  resolved to a DIFFERENT database (canonical vs web-dashboard vs
  profile-local third DB with 0 rows of everything except market_snapshots).
  This fragmentation was the real cause of health checks reading empty tables.
- Unified all 4 mofin_db copies (root/scripts/deploy/profile) via hardlink
- price_events.json archived to trashbox (fully backfilled: 6353 rows in DB)

Verified:
- record_event lands in DB only, JSON not recreated
- system_health_check: 历史事件 6353 / 今日事件 2965 (was 0/0)
- strategy_feedback + price_monitor full runs clean
2026-07-20 18:10:05 +08:00
hmo efdfaf956a fix(price_events): unify event storage to DB (dual-write + backfill)
User caught the inconsistency: system claims DB-first but price events
only went to price_events.json, leaving DB table stale since Jul 6.

Root cause chain found:
- record_event() only wrote JSON, never called mofin_db.write_price_event
- price_events.code has FK -> stocks(code); events for unregistered stocks
  (new candidates, HK) silently failed INSERT and were lost to DB
- mofin_db.write_price_event swallows errors (returns False silently)

Fixes:
- record_event now dual-writes: DB (authoritative) + JSON (compat for
  legacy readers mo_config/strategy_feedback/system_health_check)
- auto-registers unknown codes into stocks table before event insert
- one-time backfill: 4064 JSON events -> DB (total 6353 rows, last=today)
- verified: record_event TEST99 lands in both DB and JSON
2026-07-20 17:46:57 +08:00