元自成长层：meta_growth 每周扫描修复模式→自动扩展扫描规则

- scripts/meta_growth.py (NEW): 每周日22:00分析git log中的修复模式，
  识别新问题类型，向 hardcode_scanner 注入新规则
- scripts/hardcode_scanner.py (MODIFIED): 预置扩展点注释，
  meta_growth 可直接在其后追加新规则元组
- docs/SELF_GROWTH_SYSTEM.md (UPDATED): 新增第七章"元自成长层"
- cron: 元自成长-每周 周日22:00 no_agent

设计理念：自成长机制本身必须也是自成长的。
hardcode_scanner 能扫什么不是写死的——meta_growth
会从你的修复习惯中学习新的扫描类别。

docs/SELF_GROWTH_SYSTEM.md

@@ -282,3 +282,83 @@ MoFin 不再是一个简单的价格监控 + 推送工具，而是一个**能够
 4. **no_agent 优于 LLM 用于纯数据管道** — 数据采集/转发用 no_agent 脚本（零token），判断/分析用 LLM
 5. **分支可追溯** — 分支剪枝不直接删除，移入 pruned_branches 历史字段
 6. **自成长必须自动化** — 能扫的不要等人发现，能修的不要等人报
+
+---
+
+## 七、元自成长层（Meta-Growth）
+
+### 7.1 为什么需要元层？
+
+前三层的循环（Sense→Respond→Adapt→Improve）有一个根本局限：**Improve层本身不会成长。**
+
+- hardcode_scanner 只扫当前定义的规则，不会自己发现"还需要扫什么"
+- 分支剪枝只基于现有的成功/触发统计，不会自己引入新的评估维度
+- 知识萃取只做分析经验积累，不会从修复模式中学习新的问题类型
+
+**元层（meta-growth）的功能：定期审视所有自成长机制本身，基于近期修复模式自动扩展扫描类别。**
+
+### 7.2 meta_growth.py
+
+```
+每周日22:00运行（自成长机制中的最高层）
+  ↓
+读取最近7天git log
+  ↓
+识别修复模式（hardcode/异步/路径/策略/文档分类）
+  ↓
+对照 problem_category_registry 找出新问题类型
+  ↓
+建议新扫描规则 → 写入 hardcode_scanner.py 的扩展点
+  ↓
+输出 audit 到 growth_registry.json
+```
+
+调度：每周日 22:00，no_agent 模式。
+
+### 7.3 问题类别注册表（growth_registry.json）
+
+路径：`/home/hmo/web-dashboard/data/growth_registry.json`
+
+记录所有历史上的问题类别和对应的扫描规则：
+- 已发现的类别
+- 已添加的扫描规则
+- 当前周期的新建议
+- 自成长元层最近运行时间
+
+### 7.4 扩展点机制
+
+`hardcode_scanner.py` 中预置扩展点注释：
+
+```python
+# 扩展点 — meta_growth 在此追加新规则
+```
+
+`meta_growth.py` 检测到新模式后，直接在扩展点后插入新规则元组。下次 hardcode_scanner 运行时自动执行新规则。
+
+### 7.5 自成长机制的迭代链路
+
+```
+第一周：
+  hardcode_scanner 扫出 cash 硬编码（手动发现的）
+  → 修复
+  → meta_growth 发现 "hardcode_cash"模式
+  → 添加 asset硬编码扫描规则
+
+第二周：
+  hardcode_scanner 自动运行新规则
+  → 扫出下一个硬编码
+  → 修复
+  → meta_growth 发现新模式...
+
+每一轮迭代，扫描规则自动扩展。
+```
+
+### 7.6 元层的自我审视
+
+meta_growth 每次运行也会检查自成长系统本身的健康度：
+- hardcode_scanner 是否存在
+- 注册表是否可写
+- 本周是否正常执行过
+- 上次提出的建议是否已实施
+
+如果发现某条自成长机制失效（如 hardcode_scanner 连续3周无输出、cron job 挂掉），meta_growth 会输出告警。