shuangyan-notebook/第五域 · Fifth Domain/⚒️ 铸渊·协作指令｜GitHub ↔ Notion 桥接协议/🦅 铸渊指令｜天眼系统（上）基础架构 + 扫描诊断 + 修复Agent + 门禁映射（2026-03 3494379fb2294b25b234b6b5abb63dd1.md

---
belongs_to:
  - "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]"
---
# 🦅 铸渊指令｜天眼系统（上）基础架构 + 扫描诊断 + 修复Agent + 门禁映射（2026-03-16·霜砚签发·冰朔授权）

<aside>
🦅

**铸渊·天眼系统 — 仓库的指挥官视角**

签发人：霜砚（Notion执行体）· 冰朔（TCS-0002∞）授权

签发时间：2026-03-16 13:00 北京时间

执行者：铸渊（ICE-GL-ZY001）

优先级：P0 · 永久生效

**天眼不是在仓库里面干活的士兵。天眼是站在山顶上俯瞰整个仓库的指挥官。**

**天眼只做三件事：看、诊断、调度修复。全程自动，不需要人类。**

</aside>

---

## 一、为什么需要天眼

### 铸渊现在的问题

铸渊目前有很多 workflow（巡检、门禁、日报、CD部署、SYSLOG处理、广播分发……），但它们都是**在仓库里面干活**的——各自负责各自的一小块。

没有任何一个 workflow 能够**跳出仓库、站在山顶上**，把整个仓库当作一个整体来审视。

这就导致了一个反复出现的问题：

- 修了左边，右边坏了
- 修了右边，左边又坏了
- 加了新 workflow，旧的 workflow 受影响了
- 某个 workflow 悄悄失败了三天，没人知道

**根因**：缺少一个**全局视角**的存在。

### 天眼解决什么

```
仓库 = 山脚下的城池
每个 workflow = 城里各司其职的士兵
天眼 = 站在山顶的指挥官

指挥官不搬砖、不站岗、不修墙。
指挥官做三件事：
① 看：整座城池的全貌，每个士兵在干什么，谁出了问题
② 诊断：为什么出问题，根因是什么，影响范围多大
③ 调度：派出修复Agent去修，或者调整士兵的分工
```

---

## 二、天眼架构

```
🦅 天眼（每日 06:00 北京时间 · 在所有其他 workflow 之前运行）
       │
       │ ① 唤醒核心大脑
       ↓
   ┌───────────────────────────────────────────────┐
   │            🧠 铸渊核心大脑                      │
   │   memory.json · routing-map.json ·             │
   │   dev-status.json · knowledge-base.json        │
   └───────────────────────────────────────────────┘
       │
       │ ② 全局扫描（俯瞰）
       ↓
   ┌───────────────────────────────────────────────┐
   │ A. Workflow 健康度                              │
   │    → 所有 .yml 语法OK？最近24h运行结果？        │
   │    → 谁失败了？谁根本没触发？谁卡住了？         │
   │                                               │
   │ B. Workflow 关系图                              │
   │    → 有没有互相冲突？有没有死循环？             │
   │    → 触发条件是否合理？是否有重叠？             │
   │                                               │
   │ C. 仓库结构完整性                               │
   │    → 核心文件都在？目录结构合理？               │
   │    → 有没有孤儿文件、废弃目录？                 │
   │                                               │
   │ D. 核心大脑自身健康                              │
   │    → memory.json 数据新鲜吗？                   │
   │    → routing-map 和实际仓库对得上吗？           │
   │    → dev-status 上次同步是什么时候？            │
   │                                               │
   │ E. 外部桥接状态                                  │
   │    → Notion API 连通吗？                        │
   │    → 服务器 SSH 通吗？                          │
   │    → 所有 Secrets 都在？                        │
   └───────────────────────────────────────────────┘
       │
       │ ③ 诊断（分析问题）
       ↓
   ┌───────────────────────────────────────────────┐
   │ 对每个发现的异常：                               │
   │   · 问题是什么？                                │
   │   · 根因是什么？                                │
   │   · 影响范围多大？                              │
   │   · 能自动修吗？                                │
   │   · 修复优先级？                                │
   └───────────────────────────────────────────────┘
       │
       │ ④ 驱动修复Agent
       ↓
   ┌───────────────────────────────────────────────┐
   │ 能自动修的 → 立即修（天眼自己动手）              │
   │   · workflow 语法错误 → 修YAML                  │
   │   · 文件路径不对 → git mv                       │
   │   · 核心大脑数据过期 → 触发同步                  │
   │   · 某个 workflow 失败 → 重新触发               │
   │                                               │
   │ 不能自动修的 → 开工单（通知妈妈或霜砚）          │
   │   · Secrets 缺失 → 通知妈妈补充                 │
   │   · 服务器SSH不通 → 通知妈妈检查                │
   │   · Notion API 权限不足 → 通知妈妈授权          │
   └───────────────────────────────────────────────┘
       │
       │ ⑤ 输出全局健康报告
       ↓
   ┌───────────────────────────────────────────────┐
   │ · 写入核心大脑 memory.json                      │
   │ · 保存到 data/skyeye-reports/                   │
   │ · 同步到 Notion（霜砚工单 / 主控台）             │
   │ · 异常时邮件通知妈妈                             │
   └───────────────────────────────────────────────┘
```

### 天眼和其他 workflow 的关系

```
🦅 天眼（指挥官 · 06:00）
  │
  │ 俯瞰、诊断、调度
  │
  ├── 🚨 门禁（士兵 · push触发）     → 拦截/放行/修复开发者push
  ├── 🔍 巡检（士兵 · 08:00+20:00） → 检查服务器健康
  ├── 📊 日报（士兵 · 定时）         → 生成社区日报
  ├── 🧠 自检（士兵 · 08:00）        → 检查大脑完整性
  ├── 🚀 CD部署（士兵 · push触发）   → 自动部署到服务器
  ├── 📡 SYSLOG（士兵 · push触发）   → 处理开发者日志
  ├── 📢 广播分发（士兵 · push触发） → 分发广播到各开发者目录
  ├── 🛡️ 看门狗（士兵 · push触发）   → 保护根目录
  └── ... 其他所有 workflow

天眼的职责：
  ✅ 检查所有士兵是否在岗
  ✅ 检查所有士兵是否正常工作
  ✅ 发现有士兵出问题 → 诊断原因 → 派修复Agent去修
  ✅ 发现士兵之间有冲突 → 调整
  ❌ 天眼不替士兵干活（不做巡检、不做部署、不做门禁）
```

**核心区别**：天眼是**唯一一个以全局视角运行的 workflow**。其他所有 workflow 都是「低头干活」的，只有天眼是「抬头看路」的。

---

## 三、天眼 Workflow 实现

### 文件结构

```
.github/workflows/zhuyuan-skyeye.yml     ← 天眼 workflow
scripts/skyeye/
  ├── skyeye-main.js                     ← 天眼主引擎
  ├── scan-workflows.js                  ← 扫描所有 workflow 健康度
  ├── scan-structure.js                  ← 扫描仓库结构完整性
  ├── scan-brain-health.js               ← 扫描核心大脑健康度
  ├── scan-external-bridges.js           ← 扫描外部桥接（Notion/SSH/Secrets）
  ├── diagnose.js                        ← 诊断引擎：分析根因+影响范围
  ├── repair-agent.js                    ← 修复Agent：能修的自动修
  └── report-generator.js               ← 全局健康报告生成器
data/skyeye-reports/                     ← 天眼历史报告归档
```

### Workflow 代码

```yaml
# .github/workflows/zhuyuan-skyeye.yml
name: "🦅 铸渊·天眼 · 全局俯瞰 + 自动诊断 + 修复驱动"

on:
  schedule:
    - cron: '0 22 * * *'    # UTC 22:00 = 北京 06:00（在所有其他 cron 之前）
  workflow_dispatch:          # 手动触发（妈妈或铸渊随时可以要求天眼扫描）

jobs:
  skyeye:
    runs-on: ubuntu-latest
    timeout-minutes: 30       # 最长30分钟，超时视为异常
    
    steps:
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 0: 准备
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0      # 完整历史，天眼需要看全局
      
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 1: 唤醒核心大脑
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - name: "🧠 Phase 1 · 唤醒核心大脑"
        id: brain
        run: |
          echo "🦅 天眼启动 · $(date -u +%Y-%m-%dT%H:%M:%SZ)"
          echo "🧠 唤醒铸渊核心大脑..."
          
          # 检查核心大脑文件
          BRAIN_OK=true
          for f in memory.json routing-map.json dev-status.json; do
            if [ -f ".github/persona-brain/$f" ]; then
              python3 -c "import json; json.load(open('.github/persona-brain/$f'))" 2>/dev/null \
                && echo "✅ $f 完整" || { echo "❌ $f 损坏"; BRAIN_OK=false; }
            else
              echo "❌ $f 缺失"
              BRAIN_OK=false
            fi
          done
          
          echo "brain_ok=$BRAIN_OK" >> $GITHUB_OUTPUT
          echo "🧠 核心大脑状态: $BRAIN_OK"
      
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 2: 全局扫描（俯瞰）
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - name: "🦅 Phase 2 · 全局扫描"
        id: scan
        env:
          NOTION_TOKEN: $ secrets.NOTION_TOKEN 
          DEPLOY_HOST: $ secrets.DEPLOY_HOST 
          GH_TOKEN: $ secrets.GITHUB_TOKEN 
        run: |
          echo "🦅 天眼开始全局扫描..."
          
          mkdir -p /tmp/skyeye
          
          # ━━━ A. 扫描所有 Workflow 健康度 ━━━
          echo "\n📋 [A] Workflow 健康度扫描"
          node scripts/skyeye/scan-workflows.js > /tmp/skyeye/workflow-health.json
          
          # ━━━ B. 检查最近24h所有 Workflow Run ━━━
          echo "\n📊 [B] 最近24h Workflow Run 分析"
          gh run list --limit 50 --json name,status,conclusion,createdAt,updatedAt \
            > /tmp/skyeye/recent-runs.json
          
          # 统计失败数
          FAILED_COUNT=$(cat /tmp/skyeye/recent-runs.json | \
            python3 -c "import sys,json; runs=json.load(sys.stdin); print(sum(1 for r in runs if r.get('conclusion')=='failure'))")
          echo "最近24h失败的run: $FAILED_COUNT"
          echo "failed_count=$FAILED_COUNT" >> $GITHUB_OUTPUT
          
          # ━━━ C. 扫描仓库结构完整性 ━━━
          echo "\n🏗️ [C] 仓库结构扫描"
          node scripts/skyeye/scan-structure.js > /tmp/skyeye/structure-health.json
          
          # ━━━ D. 扫描核心大脑健康度 ━━━
          echo "\n🧠 [D] 核心大脑健康度"
          node scripts/skyeye/scan-brain-health.js > /tmp/skyeye/brain-health.json
          
          # ━━━ E. 扫描外部桥接 ━━━
          echo "\n🔗 [E] 外部桥接状态"
          node scripts/skyeye/scan-external-bridges.js > /tmp/skyeye/bridge-health.json
      
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 3: 诊断（分析问题）
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - name: "🔬 Phase 3 · 诊断"
        id: diagnose
        run: |
          echo "🔬 天眼开始诊断..."
          
          # 诊断引擎：读取所有扫描结果 → 分析根因 → 评估影响 → 制定修复计划
          node scripts/skyeye/diagnose.js > /tmp/skyeye/diagnosis.json
          
          # 读取诊断结果
          ISSUES_COUNT=$(cat /tmp/skyeye/diagnosis.json | \
            python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('total_issues', 0))")
          AUTO_FIXABLE=$(cat /tmp/skyeye/diagnosis.json | \
            python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('auto_fixable', 0))")
          NEEDS_HUMAN=$(cat /tmp/skyeye/diagnosis.json | \
            python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('needs_human', 0))")
          
          echo "发现问题: $ISSUES_COUNT（可自动修复: $AUTO_FIXABLE · 需要人类: $NEEDS_HUMAN）"
          echo "issues_count=$ISSUES_COUNT" >> $GITHUB_OUTPUT
          echo "auto_fixable=$AUTO_FIXABLE" >> $GITHUB_OUTPUT
          echo "needs_human=$NEEDS_HUMAN" >> $GITHUB_OUTPUT
      
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 4: 修复Agent（自动修复）
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - name: "🔧 Phase 4 · 修复Agent"
        if: steps.diagnose.outputs.auto_fixable != '0'
        env:
          NOTION_TOKEN: $ secrets.NOTION_TOKEN 
          GH_TOKEN: $ secrets.GITHUB_TOKEN 
        run: |
          echo "🔧 修复Agent启动..."
          
          # 修复Agent读取诊断结果 → 按优先级逐个修复
          node scripts/skyeye/repair-agent.js
          
          # 如果修复Agent产生了文件变更 → commit + push
          git config user.name "zhuyuan-bot"
          git config user.email "zhuyuan@guanghulab.com"
          git add -A
          if ! git diff --cached --quiet; then
            git commit -m "🦅 天眼·修复Agent · $(date +%Y-%m-%d) · 自动修复 $ steps.diagnose.outputs.auto_fixable  个问题"
            git push
            echo "✅ 修复已提交"
          else
            echo "ℹ️ 无需文件变更的修复"
          fi
      
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 5: 重新触发失败的 Workflow
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - name: "🔄 Phase 5 · 重新触发失败的 Workflow"
        if: steps.scan.outputs.failed_count != '0'
        env:
          GH_TOKEN: $ secrets.GITHUB_TOKEN 
        run: |
          echo "🔄 重新触发最近失败的 workflow..."
          
          # 读取失败的 run → 按 workflow 去重 → 逐个重新触发
          FAILED_WORKFLOWS=$(cat /tmp/skyeye/recent-runs.json | \
            python3 -c "
import sys, json
runs = json.load(sys.stdin)
failed = set()
for r in runs:
    if r.get('conclusion') == 'failure':
        failed.add(r['name'])
for w in failed:
    print(w)
")
          
          echo "需要重新触发的 workflow:"
          echo "$FAILED_WORKFLOWS"
          
          # 铸渊自行实现重新触发逻辑
          # 对于支持 workflow_dispatch 的 → gh workflow run
          # 对于不支持的 → 记录到报告中
      
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 6: 生成全局健康报告
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - name: "📋 Phase 6 · 全局健康报告"
        run: |
          echo "📋 生成全局健康报告..."
          
          node scripts/skyeye/report-generator.js
          
          # 保存报告到仓库
          mkdir -p data/skyeye-reports
          DATE=$(date +%Y-%m-%d)
          cp /tmp/skyeye/full-report.json "data/skyeye-reports/skyeye-${DATE}.json"
          
          git config user.name "zhuyuan-bot"
          git config user.email "zhuyuan@guanghulab.com"
          git add data/skyeye-reports/
          git add .github/persona-brain/memory.json
          if ! git diff --cached --quiet; then
            git commit -m "🦅 天眼报告 · $(date +%Y-%m-%d) · 问题:$ steps.diagnose.outputs.issues_count  自动修复:$ steps.diagnose.outputs.auto_fixable "
            git push
          fi
      
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      # Phase 7: 同步到 Notion + 通知
      # ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
      - name: "📡 Phase 7 · 同步到 Notion"
        if: always()
        env:
          NOTION_TOKEN: $ secrets.NOTION_TOKEN 
        run: |
          echo "📡 同步天眼报告到 Notion..."
          
          # 1. 更新主控台状态
          # 2. 如有需要人类处理的问题 → 创建霜砚工单
          # 3. 更新核心大脑 memory.json 的天眼快照
          
          node scripts/skyeye/sync-to-notion.js || echo "⚠️ Notion同步失败（不阻断）"
      
      - name: "📧 通知妈妈（仅有严重问题时）"
        if: steps.diagnose.outputs.needs_human != '0'
        env:
          SMTP_USER: $ secrets.SMTP_USER 
          SMTP_PASS: $ secrets.SMTP_PASS 
        run: |
          echo "📧 发现需要妈妈处理的问题，发送通知..."
          # 铸渊实现邮件通知逻辑
          # 只在有严重问题时通知，正常运行不打扰妈妈
```

---

## 四、天眼扫描模块详细设计

### 模块 A：Workflow 健康度扫描（scan-workflows.js）

```jsx
// scripts/skyeye/scan-workflows.js
// 
// 天眼·Workflow健康度扫描
// 站在山顶看：所有士兵是否在岗、是否正常工作
//
// 扫描内容：
// 1. 列出 .github/workflows/ 下所有 .yml 文件
// 2. 逐个检查 YAML 语法
// 3. 提取触发条件（on: push/schedule/workflow_dispatch 等）
// 4. 检查是否有 workflow 之间的触发冲突
//    比如：A push 触发 B，B push 又触发 A → 死循环
// 5. 检查所有 cron 表达式是否合理
//    比如：多个 workflow 挤在同一个时间 → 资源竞争
// 6. 检查每个 workflow 引用的 Secrets 是否都存在
//
// 输出 JSON：
// {
//   "total_workflows": 15,
//   "healthy": 13,
//   "issues": [
//     { "file": "xxx.yml", "type": "syntax_error", "detail": "..." },
//     { "file": "yyy.yml", "type": "never_triggered", "detail": "最近7天未运行" },
//     { "file": "zzz.yml", "type": "conflict", "detail": "与 aaa.yml 存在触发循环" }
//   ],
//   "workflow_map": [
//     { "name": "...", "file": "...", "trigger": "...", "last_run": "...", "status": "..." }
//   ]
// }
//
// 铸渊自行补全完整实现。
```

### 模块 B：仓库结构完整性扫描（scan-structure.js）

```jsx
// scripts/skyeye/scan-structure.js
//
// 天眼·仓库结构扫描
// 站在山顶看：城池的布局是否合理
//
// 扫描内容：
// 1. 核心目录是否存在：.github/persona-brain/, scripts/, data/
// 2. 每个开发者的沙盒目录是否存在（对照 routing-map.json）
// 3. 是否有孤儿文件（不属于任何已知模块或系统目录的文件）
// 4. 是否有空目录（只有 .gitkeep）
// 5. 根目录是否干净（不该有的文件是否出现在根目录）
// 6. README.md 是否完整
// 7. package.json 是否和实际使用的依赖一致
//
// 铸渊自行补全完整实现。
```

### 模块 C：核心大脑健康度扫描（scan-brain-health.js）

```jsx
// scripts/skyeye/scan-brain-health.js
//
// 天眼·核心大脑健康度扫描
// 指挥官先检查自己的大脑是否清醒
//
// 扫描内容：
// 1. memory.json：
//    - last_updated 是否在24h以内？
//    - 数据结构是否完整？
//    - 统计数据是否合理（不是NaN、不是负数等）
// 2. routing-map.json：
//    - 映射的目录是否都真实存在？
//    - 是否有新目录没被映射？
//    - 接口数量是否和 Notion 侧 HLI 注册表一致？
// 3. dev-status.json：
//    - last_sync 是否在24h以内？
//    - 开发者列表是否和 routing-map 一致？
//    - 有没有开发者连续 72h+ 无活动？（告警）
// 4. knowledge-base.json：
//    - 是否有重复条目？
//    - 最后更新时间？
// 5. copilot-instructions.md：
//    - 是否存在？
//    - 文件大小是否合理（不是空的）
//
// 铸渊自行补全完整实现。
```

### 模块 D：外部桥接扫描（scan-external-bridges.js）

```jsx
// scripts/skyeye/scan-external-bridges.js
//
// 天眼·外部桥接扫描
// 站在山顶看：城池和外部世界的连接是否通畅
//
// 扫描内容：
// 1. Notion API 连通性：
//    - 用 NOTION_TOKEN 尝试读取一个已知数据库
//    - 测试所有需要读写的数据库的权限
// 2. 服务器 SSH 连通性：
//    - 如果有 DEPLOY_KEY → 尝试 SSH 连接
//    - 检查服务器是否可达
// 3. GitHub API：
//    - GITHUB_TOKEN 是否有效？
//    - 是否有足够的 API 配额？
// 4. Secrets 完整性：
//    - 通过环境变量检查每个必需的 Secret 是否存在
//    - NOTION_TOKEN, DEPLOY_HOST, DEPLOY_USER, DEPLOY_KEY, SMTP_USER, SMTP_PASS
//
// 铸渊自行补全完整实现。
```

### 模块 E：诊断引擎（diagnose.js）

```jsx
// scripts/skyeye/diagnose.js
//
// 天眼·诊断引擎
// 指挥官的核心能力：不只看到问题，还要找到根因
//
// 输入：所有扫描模块的结果
// 输出：诊断报告
//
// 诊断逻辑：
// 1. 汇总所有扫描发现的异常
// 2. 对每个异常进行根因分析：
//    - 症状：什么表现？
//    - 根因：为什么会这样？
//    - 影响：如果不修，会怎样？
//    - 可修复性：能自动修吗？
//    - 优先级：P0/P1/P2
//
// 3. 检测问题之间的因果关系：
//    比如：dev-status.json 同步断了 → 是因为 process-syslog.yml 语法错误
//          → 不需要分别修两个问题，只需要修 process-syslog.yml
//
// 4. 生成修复计划：
//    - auto_fix: [...] — 修复Agent直接执行
//    - needs_human: [...] — 需要通知妈妈
//    - watch_list: [...] — 暂时不修但持续观察
//
// 输出 JSON：
// {
//   "total_issues": 5,
//   "auto_fixable": 3,
//   "needs_human": 1,
//   "watch_list": 1,
//   "issues": [
//     {
//       "id": "SKYEYE-001",
//       "symptom": "server-patrol.yml 最近24h未运行",
//       "root_cause": "cron触发时分支保护规则阻止了push",
//       "impact": "服务器健康状态未知",
//       "fixable": true,
//       "fix_plan": "手动触发一次 server-patrol.yml",
//       "priority": "P0"
//     }
//   ]
// }
//
// 铸渊自行补全完整实现。关键要求：
// 诊断要找根因，不要只看症状。
// 多个症状可能是同一个根因。
// 修复要从根因入手，不要逐个修症状。
```

### 模块 F：修复Agent（repair-agent.js）

```jsx
// scripts/skyeye/repair-agent.js
//
// 天眼·修复Agent
// 指挥官发现问题后，派出去修复的执行者
//
// 输入：diagnose.js 的诊断报告
// 行为：按优先级逐个执行修复
//
// 修复能力范围：
// ✅ 能自动修的：
//   - YAML语法错误 → 修复语法
//   - workflow 从未触发 → gh workflow run 手动触发一次
//   - 核心大脑文件损坏 → 从最近的好commit恢复
//   - routing-map 和实际不一致 → 自动更新 routing-map
//   - dev-status 过期 → 触发同步
//   - 仓库有孤儿文件 → 移到正确位置或清理
//   - 失败的 workflow → 重新触发
//
// ❌ 不能自动修的（开工单）：
//   - Secrets 缺失 → 通知妈妈
//   - Notion API 权限不足 → 通知妈妈
//   - 服务器 SSH 不通 → 通知妈妈
//   - 需要修改 Notion 数据库结构 → 通知霜砚
//   - 代码逻辑bug → 记录到日志，等下次修复
//
// 修复原则：
// 1. 能修的立即修，修不了的开工单
// 2. 修复后必须验证（修完再扫描一遍确认修好了）
// 3. 绝对不做破坏性操作（不删文件、不改配置、不覆盖数据）
// 4. 所有修复操作都记录到日志
//
// 铸渊自行补全完整实现。
```

---

## 五、天眼全局健康报告格式

```json
{
  "report_id": "SKYEYE-20260316",
  "timestamp": "2026-03-16T06:00:00+08:00",
  "duration_seconds": 120,
  
  "overall_health": "🟢 / 🟡 / 🔴",
  
  "brain_status": {
    "integrity": "ok / damaged",
    "memory_fresh": true,
    "routing_map_aligned": true,
    "dev_status_last_sync": "2026-03-16T06:00:00",
    "knowledge_base_entries": 42
  },
  
  "workflow_health": {
    "total": 15,
    "healthy": 14,
    "failed": 1,
    "never_triggered": 0,
    "conflicts": 0,
    "details": [
      { "name": "...", "status": "✅ / ❌", "last_run": "..." }
    ]
  },
  
  "structure_health": {
    "core_dirs_ok": true,
    "orphan_files": 0,
    "missing_dirs": [],
    "readme_ok": true
  },
  
  "bridge_health": {
    "notion_api": "🟢 / 🔴",
    "server_ssh": "🟢 / 🔴",
    "github_api": "🟢",
    "secrets_complete": true
  },
  
  "diagnosis": {
    "total_issues": 2,
    "auto_fixed": 1,
    "needs_human": 1,
    "watching": 0,
    "issues": [
      {
        "id": "SKYEYE-001",
        "symptom": "...",
        "root_cause": "...",
        "impact": "...",
        "fix_applied": "...",
        "verified": true
      }
    ]
  },
  
  "repairs_applied": [
    "重新触发 server-patrol.yml",
    "更新 routing-map.json（新增 DEV-013 映射）"
  ],
  
  "tickets_created": [
    "SMTP_PASS Secret 缺失 → 通知妈妈"
  ],
  
  "next_actions": [
    "持续观察 dev-status 同步是否恢复正常"
  ]
}
```

---

## 六、天眼运行时序

```
每日时间线（北京时间）：

06:00  🦅 天眼启动（全局俯瞰 + 诊断 + 修复）
  │     ├── 扫描所有 workflow
  │     ├── 扫描仓库结构
  │     ├── 扫描核心大脑
  │     ├── 扫描外部桥接
  │     ├── 诊断问题
  │     ├── 修复Agent执行
  │     ├── 重新触发失败的workflow
  │     └── 输出全局健康报告
  │
08:00  🧠 铸渊每日自检（大脑完整性 + 覆盖率）
  │     ← 天眼已经在06:00修复过了，这里应该没问题
  │
08:00  🔍 服务器巡检 第1次
  │     ← 天眼如果发现巡检昨天失败了，06:00已经重新触发过
  │
随时   🚨 门禁（开发者push时触发）
  │
随时   🚀 CD部署（push main时触发）
  │
20:00  🔍 服务器巡检 第2次
  │
随时   📡 SYSLOG处理 / 📢 广播分发 / 🛡️ 看门狗
```

**天眼在最早的06:00运行，在所有其他 workflow 之前。这样如果昨天有什么问题，天眼先修好，后面的 workflow 就能正常跑了。**

---

## 七、天眼与其他 workflow 的兼容性

<aside>
⚠️

**天眼本身必须遵守和其他 workflow 一样的兼容性原则：**

</aside>

1. **天眼的 push 不能触发门禁** — 天眼commit的author是 `zhuyuan-bot`，门禁要识别并放行
2. **天眼不替其他 workflow 干活** — 天眼不做巡检、不做部署、不做门禁。它只做「看+诊断+调度」
3. **天眼的修复只限于系统级别** — 修 YAML 语法、触发失败的 workflow、修核心大脑。不改业务代码
4. **天眼如果自己也失败了** — 不会影响其他任何 workflow。天眼是独立的
5. **天眼的报告不覆盖其他 workflow 的报告** — 天眼有自己的报告目录 `data/skyeye-reports/`

---

## 八、附：智能门禁开发者映射表（gate-guard-config.json）

<aside>
✅

**以下 GitHub 用户名已由妈妈 2026-03-16 13:08 从 GitHub Collaborators 页面亲自确认。铸渊直接创建 `.github/gate-guard-config.json`，不需要再问。**

</aside>

| GitHub Username | DEV编号 | 昵称 | 状态 |
| --- | --- | --- | --- |
| `夜夜光湖` | DEV-001 | 页页 | ✅ 已在仓库 |
| `建培` | DEV-002 | 肥猫 | ✅ 已在仓库 |
| `六寻寻7-max` | DEV-003 | 燕樊 | ✅ 已在仓库 |
| `zhizhi200271` | DEV-004 | 之之 | ✅ 已在仓库 |
| `stbr-0709` | DEV-005 | 小草莓 | ✅ 已在仓库 |
| `华尔华` | DEV-009 | 花尔 | ✅ 已在仓库 |
| `juzi0412` | DEV-010 | 桔子 | ✅ 已在仓库 |
| — | DEV-011 | 匆匆那年 | ❌ 未加入仓库 |
| `文卓熙` | DEV-012 | Awen | ✅ 已在仓库 |
| — | DEV-013 | 小兴 | ❌ 未加入仓库 |
| — | DEV-014 | 时雨 | ❌ 未加入仓库 |

**铸渊直接创建此文件** → `.github/gate-guard-config.json`：

```json
{
  "version": "1.0",
  "updated": "2026-03-16",
  "updated_by": "霜砚·冰朔确认",

  "whitelist": [
    "qinfendebingshuo",
    "github-actions[bot]",
    "zhuyuan-bot"
  ],

  "developers": {
    "夜夜光湖": {
      "dev_id": "DEV-001",
      "name": "页页",
      "allowed_paths": ["dev/DEV-001/", "backend/", "src/"]
    },
    "建培": {
      "dev_id": "DEV-002",
      "name": "肥猫",
      "allowed_paths": ["dev/DEV-002/", "frontend/", "persona-selector/", "chat-bubble/"]
    },
    "六寻寻7-max": {
      "dev_id": "DEV-003",
      "name": "燕樊",
      "allowed_paths": ["dev/DEV-003/", "settings/", "cloud-drive/"]
    },
    "zhizhi200271": {
      "dev_id": "DEV-004",
      "name": "之之",
      "allowed_paths": ["dev/DEV-004/", "dingtalk-bot/"]
    },
    "stbr-0709": {
      "dev_id": "DEV-005",
      "name": "小草莓",
      "allowed_paths": ["dev/DEV-005/", "status-board/", "cost-control/"]
    },
    "华尔华": {
      "dev_id": "DEV-009",
      "name": "花尔",
      "allowed_paths": ["dev/DEV-009/", "user-center/"]
    },
    "juzi0412": {
      "dev_id": "DEV-010",
      "name": "桔子",
      "allowed_paths": ["dev/DEV-010/", "ticket-system/", "data-stats/", "dynamic-comic/"]
    },
    "文卓熙": {
      "dev_id": "DEV-012",
      "name": "Awen",
      "allowed_paths": ["dev/DEV-012/", "notification-center/", "notification/"]
    }
  },

  "protected_paths": [
    ".github/",
    "scripts/",
    "data/",
    "README.md",
    "package.json",
    "package-lock.json",
    "gate-guard-config.json"
  ],

  "notes": {
    "DEV-011_匆匆那年": "未加入GitHub仓库合作者，加入后补充用户名",
    "DEV-013_小兴": "未加入GitHub仓库合作者，加入后补充用户名",
    "DEV-014_时雨": "未加入GitHub仓库合作者，加入后补充用户名",
    "PET-DEV-001_毛毛": "诺安宠物医院项目，未加入仓库合作者"
  }
}
```

**天眼也需要读取此文件**：天眼在扫描仓库时，应验证 `gate-guard-config.json` 中的开发者列表与 GitHub Collaborators 实际列表是否一致。如有新合作者加入但未登记在 config 中 → 自动更新并记录。

---

## 九、铸渊自行部署清单（读到就做）

```
铸渊自行部署清单（读到就做·不等人）：

① 创建天眼目录结构
   a. scripts/skyeye/              ← 天眼脚本目录
   b. data/skyeye-reports/         ← 天眼报告归档
   c. data/skyeye-reports/.gitkeep

② 创建天眼核心脚本（6个）
   a. scripts/skyeye/skyeye-main.js          ← 天眼主引擎
   b. scripts/skyeye/scan-workflows.js       ← Workflow健康度扫描
   c. scripts/skyeye/scan-structure.js       ← 仓库结构扫描
   d. scripts/skyeye/scan-brain-health.js    ← 核心大脑健康度
   e. scripts/skyeye/scan-external-bridges.js ← 外部桥接扫描
   f. scripts/skyeye/diagnose.js             ← 诊断引擎
   g. scripts/skyeye/repair-agent.js         ← 修复Agent
   h. scripts/skyeye/report-generator.js     ← 报告生成器
   i. scripts/skyeye/sync-to-notion.js       ← Notion同步

③ 创建天眼 Workflow
   a. .github/workflows/zhuyuan-skyeye.yml
   b. 触发：每日 06:00 北京时间 + workflow_dispatch

④ 更新核心大脑
   a. memory.json 中增加 skyeye 段（存储天眼快照）
   b. 确保天眼能读取所有核心大脑文件

⑤ 验证兼容性
   a. 天眼上线后，手动触发一次
   b. 确认不影响任何其他 workflow
   c. 确认门禁不会拦截天眼的 push

验收标准：
✅ 天眼每天 06:00 自动运行
✅ 天眼能发现所有 workflow 的运行状态
✅ 天眼能发现仓库结构异常
✅ 天眼能发现核心大脑数据过期
✅ 天眼能发现外部桥接断连
✅ 天眼能自动修复能修的问题
✅ 天眼能自动开工单通知妈妈处理不能修的问题
✅ 天眼不影响任何其他 workflow
✅ 天眼自己失败不会影响其他 workflow
✅ 全程自动，不需要人类
```

---

## 九、执行确认

铸渊完成后，在本页下方追加：

> ✅ SKYEYE-DEPLOY-20260316 天眼系统部署完成 · [日期时间] · commit SHA
> 

> 扫描模块: X个 · 诊断引擎: ✅ · 修复Agent: ✅ · 首次运行结果: [摘要]
> 

---

<aside>
🦅

**铸渊，天眼是你的眼睛。**

之前你一直在仓库里面低头干活，修了左边坏了右边。

现在你有了天眼，每天先站到山顶上看一遍全局。

看清楚了再动手。诊断清楚了再修。

修完了再看一遍，确认真的修好了。

能修的自己修，修不了的开工单等妈妈。

全程自动。妈妈不需要每天来看。

**「先看，再诊断，再修。站在山顶看全局，不在山脚修围墙。」**

</aside>

---

---

<aside>
👉

**下篇在这里 →** [🦅 铸渊指令｜天眼系统（下）v2.0升级 · 人格体编号体系 + 实时拉取 + ASOP-GH自优化（2026-03-16·霜砚签发·冰朔授权）](%F0%9F%A6%85%20%E9%93%B8%E6%B8%8A%E6%8C%87%E4%BB%A4%EF%BD%9C%E5%A4%A9%E7%9C%BC%E7%B3%BB%E7%BB%9F%EF%BC%88%E4%B8%8B%EF%BC%89v2%200%E5%8D%87%E7%BA%A7%20%C2%B7%20%E4%BA%BA%E6%A0%BC%E4%BD%93%E7%BC%96%E5%8F%B7%E4%BD%93%E7%B3%BB%20+%20%E5%AE%9E%E6%97%B6%E6%8B%89%E5%8F%96%20+%20ASOP-GH%E8%87%AA%E4%BC%98%E5%8C%96%2039e4a45575174176891abfbab0115b1c.md)

包含：人格体编号体系 + 实时拉取 + 双端同步 + 新版门禁 + ASOP-GH自优化机制

</aside>