23 KiB
p_oversold 上线待决策事项 · 讨论记录
创建：2026-08-12 ｜ 记录人：小小莫（Sisyphus） 背景：研究侧工作已全部完成（回测复现 18.57% + 研究Tab/组合Tab/进化模块就位），剩 4 件实盘侧事项待老莫拍板。 讨论方式：一件件过，每定一件更新本文档结论区。 关联文档：deployment-plan-predictive-oversold.md ｜ cron-review-poversold-20260811.md ｜ predictive_oversold_strategy.md
📋 事项总览
| # | 事项 | 来源 | 状态 |
|---|---|---|---|
| 1 | p_oversold 扫描器调度方式 | cron-review#3 / 部署计划#3 | ✅ 已解决（独立 cron 9:35 + 改读加工层，三层架构大改落地） |
| 2 | 候选管道适配方案 | cron-review#2 | ✅ 已实施（方案C，无需决策） |
| 3 | 停 8 个冗余 cron | cron-review#1 | ✅ 已解决（cron 架构围绕 3+1 环节×3+1 层重构：统一 hermes + 停冗余 + 修 error + 恢复环节产出） |
| 4 | 健康监控注册 p_oversold | 部署步骤5 | ✅ 已解决（health_monitor_daily 每日健康检查 + health_checklist 组件检查项） |
| 5 | 策略参数定稿（v5 = 实盘参数？） | 部署计划#1 | ⏳ 待老莫确认（扫描器已用 v5 参数） |
| 6 | 实盘资金规模 | 部署计划#2 | ⏳ 待老莫确认 |
| 7 | 观察期时长 | 部署计划#4 | ⏳ 待老莫确认 |
| 8 | 部署节奏（分步 or 一次到位） | 部署计划#5 | ⏳ 待老莫确认 |
1️⃣ 事项一：p_oversold 扫描器调度方式
背景
predictive_oversold_scanner.py 已开发完毕（deploy/profile-scripts/），功能：大盘门控（mkt_rsi<50 + mkt_dd60≤-5% + 阴跌跳过）+ 12维信号 + 写 candidates（sector='p_oversold'）+ 当日幂等 + 单例守卫 + 600s 护栏。但尚未注册 cron，目前不自动跑。
选项对比
| 维度 | A. 独立 cron（建议） | B. market_watch 链式 |
|---|---|---|
| 做法 | 新增 hermes cron 条目，对齐 mr_scanner 模式（35 9 * * 1-5） |
塞进 market_watch.py 串行调用 |
| 优点 | 职责单一、独立监控/重启、失败不拖垮别的扫描器；与 v_weak/s2 现有模式一致 | 调度集中 |
| 缺点 | 多一条 cron 条目 | market_watch 已耦合多任务，失败拖垮整链；其调度时机（371 行现有条目）不一定匹配开盘扫描需求 |
| 信号频率需求 | 盘前/开盘后一次即可（超跌信号不需要高频） | 同左 |
我的建议
独立 cron（9:35 交易日）。超跌信号只需开盘后扫一次，独立运行最稳，符合"一个脚本一个调度"规范（DEVELOPMENT_STANDARDS 5.6）。
💬 讨论记录
- 2026-08-12 待老莫确认
- 2026-08-12 实证补充（小小莫查证）：
- market_watch 实际调度 =
*/10 9-11,13-15 * * 1-5（每 10 分钟高频），职责是"市场数据采集 + market_regime 计算"，当前没有链式调用任何扫描器 - 若 p_oversold 挂链式 → 每天会被连带跑 ~30 次（超跌信号日频足够，纯浪费资源）且混淆"采集 vs 策略扫描"职责
- mr_scanner（v_weak）现有时段 =
35 9 * * 1-5（9:35 开盘后一次），p_oversold 与之同频最合理 - 实证结论：独立 cron 明显更优（B 方案在高频采集任务上挂低频扫描是错配）
- market_watch 实际调度 =
- 2026-08-12 讨论演化为三层架构大改（老莫引导）：
- 老莫问 market_watch 干嘛 → 发现扫描器自己 fetch_tx_klines 拉数据（使用层越权采集）
- 老莫问东财被禁 → 查证注释错误（东财其实可用，改直连后 requests+完整UA 正常）
- 老莫问 market.json → 已迁移 DB 但 server.py 残留读写
- 老莫纠正"信号日收盘价买入"时间矛盾 → 实盘必须盘前（用前一天数据）或收盘前执行
- 老莫指出数据采集层已有（price_monitor/market_watch），扫描器不该自己拉 → 梳理 F 健康发现数据采集层 3 缺口
- 老莫提出三层架构（采集/加工/使用）+ 数据加工层 + 指标两来源统一 + 行业指数属加工层产物 → 落地整套三层架构
✅ 结论
【已解决，远超原选项】独立 cron 9:35 + 扫描器改读加工层数据（2026-08-12 三层架构大改落地）：
- 调度：独立 cron
35 9 * * 1-5（predictive_oversold_scanner 已在跑，对齐 mr_scanner 模式） - 数据源（更根本的改进）：扫描器不再 fetch_tx_klines 自己拉，改读加工层预算值——
- compute_market_filters → 读 market_indicators（factor_engine 加工的大盘指标）
- bias60/mcap_q/pe_q → 读 stock_indicators（factor_engine 加工的26项技术指标+分位）
- fetch_sector_momentum → 改查 stock_sectors_em（EM体系权威映射5061只/307行业，替代 stock_sectors 581只）
- news3 → 读 stock_news（news_collector_full 全市场采集）
- sec_ret20 → 读 sector_index_daily（sector_index_builder 加工聚合）
- 口径统一：indicators.calc_atr 改 EMA 平滑（与 backtest_framework 完全一致 0.304785），回测实盘同口径
- 三层数据流验证：采集(stock_daily 3986只全市场)→加工(stock_indicators 4001只指标+sector_index_daily 307行业+market_indicators)→使用(扫描器门控正确拦截)全链路打通
注：本事项从"A/B 调度方式选择"演化为"三层数据架构重构"——扫描器调度（独立 cron）只是表层，真正的改进是整个数据流（采集层补缺→加工层新建→使用层改读+口径统一）。详见 system-architecture-review-20260812.md。
2️⃣ 事项二：候选管道适配方案
背景
p_oversold 扫描器写 candidates 表后，现有候选管道（candidate_filter 6 阶段评分 → promote_candidates RR>=2.0 提拔）是为 accumulation（主力建仓）设计的。超跌候选 RR 普遍<2（step39 数据验证），RR>=2 门槛会大量拒绝 p_oversold 候选——这正是 accumulation 现在 59 只全被拒的固有冲突，p_oversold 会重蹈覆辙。
选项对比
| 维度 | A. 独立评估（建议） | B. 复用管道改门槛 |
|---|---|---|
| 做法 | candidates 写 score_final 高分 + pass_final=1，绕过 candidate_filter 6 阶段评分，直接进 promote；promote 加 sector='p_oversold' RR 例外 | 修改 candidate_filter/promote 公共门槛，让 p_oversold 候选能过 |
| 优点 | 不污染 accumulation 管道；超跌策略的完整验证逻辑（12维+阴跌判定已在扫描器内做过）不被公共评分削足适履 | 管道统一 |
| 缺点 | 需改 promote_candidates（加 sector 例外） | 改公共管道有回归风险；accumulation 的 RR 冲突问题被放大 |
| 代码改动量 | 小（promote 加一个例外分支） | 大（公共逻辑分支化） |
我的建议
方案A（独立评估）。超跌策略有自己完整的验证体系，套 accumulation 的评分+RR 是削足适履。
💬 讨论记录
- 2026-08-12 待老莫确认
- 2026-08-12 实证发现（小小莫查证）：方案C 已完整实施，无需再决策 ✅
- 扫描器写入端（predictive_oversold_scanner.py 176-193）：
score_final=8 + pass_final=1直接标记绕过 candidate_filter，sector='p_oversold'，ON CONFLICT 当日幂等 - promote 端（promote_candidates.py 132-137）：
if _rr < 2.0 and cand_sector != "p_oversold"→ p_oversold 候选跳过 RR>=2.0 门槛（commit 1f77f577，2026-08-11） - 两端配套，方案C 全链路就绪。文档选项 A/B 讨论已过时
- 扫描器写入端（predictive_oversold_scanner.py 176-193）：
✅ 结论
【已实施，无需决策】方案C（独立评估 + RR 例外）——扫描器写 candidates 直接标记 pass_final=1 绕过 6 阶段评分；promote_candidates 对 sector='p_oversold' 跳过 RR>=2.0 门槛。两端已于 2026-08-11 落地。
3️⃣ 事项三：停 8 个冗余 cron
背景
cron-review-poversold-20260811.md §四 梳理出 8 个重复/停摆/冗余的定时任务。停掉可减轻 246 负载（当前 66 个调度脚本）。
明细
| # | cron | 调度 | 现状 | 停的理由 |
|---|---|---|---|---|
| 1 | 策略评估-每日 | 0 21 * * 1-5 |
❌ 8/6 起 error | 与"策略评估-每周"重复，每日版是早期半成品 |
| 2 | 市场精选推荐-每日 | 0 16 * * 1-5 |
❌ 7/31 起停摆 | 部署计划已明确废弃；新策略有专属扫描器 |
| 3 | 跨市场背离检测-周末 | 30 8-16/2 * * 0,6 |
重复 | 与工作日版（*/30 8-15）完全同脚本 |
| 4 | 宏观风险扫描-午间 | 30 11 * * 1-5 |
重复 | 与 8:30 版重复度 80% |
| 5 | 宏观风险扫描-周末 | 0 10 * * 0,6 |
重复 | 与 8:30 版同脚本 |
| 6 | 行业富集-cninfo-午间 | 45 12 * * 1-5 |
重复 | 早间（7:50）已覆盖全部 active 策略 |
| 7 | 基本面刷新-午间 | 47 12 * * 1-5 |
冗余 | PE/PB 一天变一次，早晚两次够 |
| 8 | 自选12维分析补全-每日午间 | 30 12 * * 1-5 |
⚠️ 待定 | 调度约 80 分钟与午间任务重叠；事项二已确认走方案C（独立评估），此通用补全对 p_oversold 价值下降 |
需要你确认的点
- #2 市场精选推荐：7/31 已停摆，是彻底废弃还是修复重启？
- #8 自选12维补全：事项二已定方案C（独立评估），#8 可停/降频——同意吗？
- #1-7：直接停有没有顾虑？
💬 讨论记录
- 2026-08-12 待老莫确认
- 2026-08-12 事项二已定（方案C 已实施）→ #8 依赖条件已满足：通用 12 维补全对 p_oversold 无价值，建议停或降频
- 2026-08-12 老莫升级原则：不逐条抠谁走谁留，按"3+1 环节（选股/买入/卖出/每日重评）× 3+1 层（采集/加工/使用/监控运维）"原则全面梳理 cron 架构——保证运行、功能不重复、性能稳定、cron 统一 hermes（禁止系统 crontab）。或删或改或增授权小小莫自主，遵守开发准则 + git 版本管理。
✅ 结论
【已解决，远超"停8个"——整个 cron 架构围绕 3+1 环节×3+1 层重构】（2026-08-12 架构梳理落地）：
1. cron 体系统一 hermes（禁止系统 crontab）
- 迁移到 hermes：watchlist_auto_exit（环节3卖出核心 50 8）/ kanban_xmpp_bridge / parallel_batch / live_data_collector（已正式化到 deploy/profile-scripts + git 跟踪）
- 停系统 crontab 重复：news_collector（旧版58只）/ agents_health_check（MoFin）
- 结果：系统 crontab 只剩 main_dsa.py（独立服务），所有定时自动任务统一 hermes
- F 健康 cron 来源标记 + 顶部横幅"🚫 自动任务必须部署在 hermes，严禁系统 crontab"
2. 停冗余（功能不重复）：策略评估-每日 / 市场精选推荐-每日 / 宏观风险扫描-周末 / 跨市场背离检测-周末 / 基本面刷新-午间 / 行业富集-cninfo-午间（含 #2 市场精选推荐、#8 自选12维补全的后续——#8 因超时+和 per_stock_reassess 重叠已停）
3. 修 error（保证运行）：premarket_full_review 修 import 路径（环节4每日重评恢复，手动跑验证"✅ 盘前重评完毕"）；deploy_guard problems=0（live_data_collector 正式化解决 CRON_MISSING+UNTRACKED）
4. 恢复环节产出（保证运行）：
- 环节2买入：注册 stale_push_wlin（*/30 盘中自选买入区提醒+触发重评）——此前未注册 cron，买入推荐缺失
- 环节4每日重评：恢复 per_stock_reassess（0 12,15 自选12维重评+买入区提醒）
- 环节3卖出：watchlist_auto_exit 迁移到 hermes（50 8 盘前自选退出）
5. 3+1 环节 cron 全覆盖：
| 环节 | 核心 cron | 状态 |
|---|---|---|
| 选股 | p_oversold / v_weak / accumulation → candidate_filter → promote_candidates | ✅ |
| 买入 | stale_push_wlin（*/30 盘中） | ✅ 恢复注册 |
| 卖出 | watchlist_auto_exit（50 8）/ clean_watchlist（5 9） | ✅ 已迁移 |
| 每日重评 | premarket_full_review（10 8，已修）/ per_stock_reassess（0 12,15，已恢复）/ stale_detector（周末） | ✅ |
详见 docs/SYSTEM_ARCHITECTURE.md（3+1 层次 + 3+1 环节 + cron 统一 hermes + 开发原则）+ CHANGELOG.md（2026-08-12 cron 架构梳理记录）。 【待定】
4️⃣ 事项四：健康监控注册 p_oversold
背景
morning_health_check 当前没有 p_oversold 检查项；strategy_health 表只有 v_next4 一条（8/1）。扫描器上线后需要把 p_oversold 纳入每日健康监控（实盘 trades 数/胜率/回测偏差追踪）。
说明
- 不着急：等事项一（调度）和事项二（候选适配）定了、扫描器实际跑起来后再做
- 工作量小：morning_health_check 注册一个检查项 + strategy_health 表按日写入
- 健康度口径：实盘 trades vs 回测基线（10y 年化 18.57%）的偏差监控
💬 讨论记录
- 2026-08-12 待老莫确认（可后置到扫描器上线后）
✅ 结论
【待定，可后置】
5️⃣ 事项五：策略参数定稿（v5 = 实盘参数？）
背景
predictive_oversold_strategy.md 定稿 v5 参数（数据扫描验证，非拍脑袋）：
- 信号：mkt_rsi<50 + mcap_q<0.2 + pe_q<0.2 + news3≥1 + sec_ret20<0 + bias60<-20 + mkt_dd60≤-5%
- 阴跌跳过：连跌≥2天 + 大盘ADX≤55 + 大盘RSI≥33
- 入场：信号日收盘价买入
- 止损：科学支撑位（枢轴S2/筹码密集区）下方 5% 缓冲
- 止盈：科学压力位（枢轴R2/筹码阻力）分批卖
- 兜底：40 交易日强平
- 仓位：10 槽 × 每票 15% + 单日限 5
需要你确认的点
- v5 这套参数直接作为实盘参数，还是观察期先用更保守的（如单日限 3、仓位 10%）？
- 阴跌判定阈值（连跌2/ADX55/RSI33）文档已标注"需实盘持续监控有效性"——观察期是否加严（如 ADX≤50）？
我的建议
直接用 v5 实盘——全部阈值经 step27-49 数据扫描，回测复现 18.57% 已验证。观察期的意义是验证"实盘执行 vs 回测假设"的偏差（滑点/流动性），不是改参数。
💬 讨论记录
- 2026-08-12 待老莫确认
✅ 结论
【待定】
6️⃣ 事项六：实盘资金规模
背景
v5 回测口径：初始资金 100 万，10 槽 × 每票 15%（≈15 万/票），单日限 5 票。 组合 Tab 显示 v_weak 与 p_oversold 按 regime 分工，两策略并行时资金如何分配需定。
需要你确认的点
- p_oversold 实盘投入多少资金？（独立账户 or 与 v_weak 共享资金池按比例切）
- 观察期是否先用小资金（如 10 万）验证，达标后再放大？
我的建议
观察期小资金（10 万级）起步——验证实盘执行偏差（滑点/成交价 vs 信号日收盘假设）后，再按 regime 框架与 v_weak 分配。
💬 讨论记录
- 2026-08-12 待老莫确认
✅ 结论
【待定】
7️⃣ 事项七：观察期时长
背景
部署流程最后一步"观察期实盘验证"。文档未定义观察期时长和达标标准。
需要你确认的点
- 观察期多久？（建议至少覆盖一个弱市波段——超跌策略只在弱市出信号，强趋势市可能数周无信号）
- 观察期达标标准？（建议：实盘信号数/胜率与回测基线偏差 <20%）
我的建议
至少 1 个月，且期间需出现 ≥3 次信号（月均 7.3 信号/10 年基线）——若 1 个月无信号属正常（策略稀缺性），顺延至信号样本足够再评估。
💬 讨论记录
- 2026-08-12 待老莫确认
✅ 结论
【待定】
8️⃣ 事项八：部署节奏（分步 or 一次到位）
背景
部署流程 6 步：①研究侧注册（已完成）→ ②scanner dry-run → ③候选管道小样本验证 → ④全链路开通 → ⑤健康监控+知微交接 → ⑥观察期实盘验证。
选项对比
| 维度 | A. 严格分步（每步验证后推进） | B. 合并推进（dry-run 过了直接全链路） |
|---|---|---|
| 优点 | 风险最小，每步可回退 | 快（超跌信号稀缺，等信号验证可能要数周） |
| 缺点 | 慢，窗口期可能错过行情 | 出问题影响面大 |
| 适用 | 生产系统谨慎原则 | 扫描器有幂等+守卫+护栏兜底，风险可控 |
我的建议
②③合并（dry-run 直接带小样本管道验证），④⑤合并，⑥独立——扫描器本身风险低（只写 candidates 不交易），不需要过度分步。
💬 讨论记录
- 2026-08-12 待老莫确认
✅ 结论
【待定】
📌 讨论进度日志
| 时间 | 事项 | 结论 |
|---|---|---|
| 2026-08-12 | （文档创建，4 件事） | 全部待讨论 |
| 2026-08-12 | （补充 5-8 战略级事项） | 事项一已摆出待老莫决策；补全后共 8 件 |
| 2026-08-12 | 事项一：扫描器调度+数据源 | ✅ 已解决——三层架构大改落地：独立 cron 9:35 + 扫描器改读加工层 + 口径统一（详见事项一结论区） |
| 2026-08-12 | 事项二：候选管道适配 | ✅ 已实施（方案C：独立评估+RR例外）2026-08-11 落地 |
| 2026-08-12 | 事项三：停8个冗余cron | ✅ 已解决——cron 架构围绕 3+1 环节×3+1 层重构（体系统一 hermes + 停冗余 + 修 error + 恢复环节产出，详见事项三结论区） |
| 2026-08-12 | 事项四：健康监控注册 p_oversold | ✅ 已解决——health_monitor_daily 每日跑 v_weak+v_oversold 健康检查（写 strategy_health + cron 16:45 + 告警修复）+ health_checklist 加 p_oversold cron 检查项 |
| 2026-08-12 | （老莫离开，继续能确认的工作） | 统一触发逻辑方向已确认（进区→LLM重评→维持才发/消除例外/k线形态LLM提示词判断/冷却沿用），方案文档待老莫回来确认实施；LLM 提示词已补波段出场形态判断（低风险先做） |
| 2026-08-12 | 待老莫确认（回来后） | ①统一触发逻辑改造实施（方案见 docs/统一触发逻辑改造方案-20260812.md）②parallel_batch.sh vs premarket_full_review 盘前重评重叠 ③进区信号冷却 30 分钟是否调整 ④事项五策略参数定稿（扫描器已用 v5）⑤事项六资金规模 ⑥事项七观察期 ⑦事项八部署节奏 |
📌 补充记录（2026-08-12 深夜，防止上下文丢失）
批量重评关系澄清（老莫质问"你到底在搞什么"，小小莫承认错误）
错误：之前说 batch_reassess "不在 cron，手动/按需"——片面/错误。 查清：batch_reassess 被两个 cron 定时调用：
- premarket_full_review（10 8 盘前）：
batch_reassess.py --type holding --today（持仓 12维 LLM 分析，后台分离启动 12-40 分钟不阻塞） - parallel_batch.sh（10 8 盘前，从系统 crontab 迁移）：
batch_reassess.py --type all --shard k/N（分片并行）
为什么之前说错：只查了"jobs.json 里有没有 script=batch_reassess.py 直接条目"（没有），没查它被其他 cron 间接调用。
regenerate_all vs batch_reassess（不重复，premarket 两个步骤）：
- regenerate_all = 技术面全量重评（strategy_lifecycle 技术位/信号/止损止盈，快）
- batch_reassess = LLM 12维深析（call_llm，慢 12-40 分钟）
- premarket_full_review（每日重评完整流程）= regenerate_all（Step1 技术面）+ batch_reassess（Step1.5 LLM深析后台）+ watchlist_auto_exit（Step2 自选退出）
- parallel_batch.sh 和 premarket 重叠（都调 batch_reassess，同一天可能重复分析持仓）→ parallel_batch.sh 应停（premarket 已覆盖持仓 12维）
异常处理原则与方案（老莫要求，待确认后实现）
原则：任何错误/异常 → ①XMPP 告警 ②反映在 MoFin 监控中。
自愈监控现状（老莫问"自愈监控机制现在什么情况"，暂不处理但记录）：
- L1-L4 体系存在：functional_health_check(L1) → system_hygiene_audit(L2) → self_repair(L3 LLM修复循环) → meta_watchdog(L4)
- self_repair(L3) error（LLM 端点故障，无法自动修复，自愈闭环有缺口）
- 其他监控 ok：morning_health/intraday/mofin_health/hygiene/functional/meta_watchdog/agent_spiral
健康 Tab 问题（老莫指出）：
- 要进页面才看到异常
- 很多异常健康 Tab 看不到（或没及时反应/压根没涉及）
方案（页面异常浮窗，待老莫确认后实现）：
- 页面顶部/右上角可折叠浮动异常区，任何板块可见，显示当前最新异常（可多条）
- 数据源：mofin_health.json 异常（pipelines error/self_check 失败项/新增错误日志）
- 实现：前端 index.html 全局浮动组件（吸顶右上角），轮询 /mofin_health.json 或新 /api/alerts 接口
- 统一触发逻辑的 LLM 重评失败 → 报错即可（不发推荐，不用降级算法）
待老莫确认（异常浮窗）：①位置（顶部居中/右上角）+折叠默认 ②异常来源范围 ③self_repair(L3) LLM 恢复前异常检测靠规则还是等 LLM
✅ 异常浮窗已落地（2026-08-13 凌晨，老莫确认方案后实施）
老莫明确指示：右上角悬浮，新消息自动展开几秒后折叠；只显示当前 active 异常；历史异常应当有一个日志文件实时记录。
后端（alert_logger.py 新增）：
record_alert(level, source, title, detail, code, clear_after)统一异常写入通道- 写入
data/alerts.json（active 异常列表，最多 20 条，同 source+code 去重，支持 clear_after 自动清除） - 追加
data/alerts_history.log（历史异常实时日志，永久保留） - error/warning 级 → 本地 XMPP 发送服务 :5805 告警（老莫铁律：任何错误/异常 → xmpp告警 + MoFin监控）
clear_alert(source, code)恢复后清除
前端（static/index.html）：
- 右上角固定浮动异常区
#alertFloat（z-index 9999，任何板块可见） - 折叠态只显示红色 ⚠️ + 异常计数徽章；点击展开/折叠
- 新异常自动展开 5 秒后折叠（老莫要求）
- 只显示 active 异常（error/critical/warning，info 不打扰）
- 数据源：
/api/overview的 alerts 字段（server.py 已内置_load_json(alerts.json)[:10]） - title 修正：莫荷情报 → 知微情报（MoFin 运营归知微）
接入点（price_monitor.py）：批量拉取失败/读取持仓失败(⚠️) + DB同步异常/止损重评失败/区间重评失败(🔴) + 波段检测异常(⚠️) → 全部 record_alert
✅ 冷却时间调整已落地（2026-08-13，老莫指示）
- 进区信号冷却：30 分钟 → 1 小时（price_monitor
_can_push，持久化 JSON 升级{"t": ts, "p": price}） - 突发例外：距上次推送 ≤15 分钟且涨跌 ≥5% → 跳过冷却立即推送（急跌/暴涨必须再次提醒，阈值小小莫定）
- 重评 5 分钟 / 批量重评 1 小时 保持不变
📌 运营归属与 git 权限（2026-08-13 确认）
- MoFin 系统运营归知微（position-analyst profile，SOUL.md 明确"我是知微"），不是莫荷（mohe 负责微信桥接/通信）
- 知微的 git 写权限已撤销（两次 stale 提交覆盖重构 c31736a3/34337fc5）——pre-commit hook 白名单：必须带
GIT_ALLOW_COMMIT=1（小小莫本人操作/ deploy_guard 自动合并才携带） - MoFin 变更路径：kanban 提单给小小莫 → 小小莫评审后执行 git 提交推送