Guanghu Domestic Migration a27e87cb99 chore: import sanitized domestic snapshot for REPO-007

Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc

[SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码

2026-07-17 15:59:55 +08:00

9.8 KiB

Raw Permalink Blame History

belongs_to

INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议

🔧 铸渊紧急指令｜README.md 恢复 + PR#112 workflow 修复 + 根目录保护机制（2026-03-15·霜砚签发）

任务一：README.md 立即恢复（P0）

问题根因

之之的 PR #112 在分支根目录包含了一个属于钉钉项目的 README.md，merge 后覆盖了铸渊维护的主仓库首页。

服务器部署适配协议 v1.0 已约束了服务器目录的越界，但未覆盖 GitHub 仓库根目录文件保护——本次修复同步补上。

恢复目标结构

原主 README 包含以下五个区块（铸渊按记忆/git history恢复）：

# 🌊 HoloLake · 光湖纪元

<!-- 区块1：🏛️ 系统简介 -->
<!-- 铸渊从 dev-status.json + 仓库概览自动生成 -->

<!-- 区块2：📢 冰朔公告栏 -->
<!-- 由「更新系统公告区」workflow 自动更新 -->
<!-- 铸渊不得覆盖此区块，只追加 -->

<!-- 区块3：👥 开发者公告栏（协作者动态）-->
<!-- 由「更新系统公告区」workflow 追加式更新（2026-03-14协议：只追加不覆盖）-->

<!-- 区块4：🚀 协作者开发体验入口 -->
<!-- persona-studio 入口 + 各开发者沙盒直达链接 -->

<!-- 区块5：📥 开发者入口（SYSLOG自助提交）-->
<!-- 系统日志自动提交通道 -->

执行步骤

Step 1：查 git log，找 README.md 被覆盖前的最后一个正常 commit
  → git log --oneline --follow README.md
  → 找到 PR #112 merge 之前的 commit SHA

Step 2：从 git history 恢复原 README 内容
  → git show <上一个正常SHA>:README.md > /tmp/README_backup.md
  → 对比当前 README，确认哪些内容被替换了

Step 3：恢复原结构 + 保留之之钉钉内容的正确归位
  → 原主 README 恢复到根目录 README.md
  → 之之的钉钉 README 应在：dingtalk-bot/README.md 或 DEV-004/README.md
  → 不是根目录

Step 4：commit 并 push
  → commit message: "fix: restore main README.md after PR#112 overwrite"

任务二：修复四条被破坏的 workflow（P0）

受损 workflow 清单

Workflow	编号	触发 commit
syslog-auto-pipeline.yml	#130	74baf7f (PR#112 merge)
syslog-issue-pipeline.yml	#125	74baf7f
pm2-server-diagnose.yml	#93	74baf7f
daily-maintenance.yml	#75	74baf7f

排查方法

Step 1：逐条打开失败的 run → 找到第一个红叉的 step → 记录报错信息

Step 2：常见原因对照：
  A. 文件路径找不到 → PR#112 可能移动/删除了被这些 workflow 引用的脚本
     → 检查：workflow 里 run: node scripts/xxx.js 的脚本是否还存在

  B. 环境变量/Secret 名称不匹配 → PR#112 可能新增了同名但不同前缀的变量
     → 检查：workflow 里用的 $ secrets.XXX  是否和 repo Secrets 一致

  C. workflow 文件本身被 PR#112 修改 → PR#112 可能改了这些 .yml 文件
     → 检查：git diff HEAD~1 HEAD -- .github/workflows/ 看哪些 yml 被改了

Step 3：分类修复
  · 路径问题 → 恢复脚本文件 or 修正路径引用
  · Secret 名称问题 → 统一变量名，告知妈妈补充 Secret
  · yml 文件被改坏 → 从 git history 恢复

任务三：建立根目录保护机制（防止再次被覆盖）

方案：CODEOWNERS + 受保护文件清单

Step 1：在仓库根目录创建 / 更新 .github/CODEOWNERS

  # 根目录受保护文件 · 修改需要 @qinfendebingshuo 审批
  README.md @qinfendebingshuo
  .github/workflows/ @qinfendebingshuo
  .github/copilot-instructions.md @qinfendebingshuo

Step 2：在 GitHub 仓库 Settings → Branches → main 分支保护规则中
  → 启用 "Require review from Code Owners"
  → 这样任何人修改 README.md 的 PR，必须经过 @qinfendebingshuo 审批才能 merge
  → （此步需妈妈在 GitHub UI 手动操作）

Step 3：在 .github/copilot-instructions.md 中追加规则
  → "根目录 README.md 由铸渊的「更新系统公告区」workflow 维护"
  → "开发者的模块 README 必须放在各自的模块子目录下"
  → "不得在 PR 中将模块 README 推送到根目录"

验收标准

✅ 根目录 README.md 恢复五区块结构（系统简介+冰朔公告+开发者公告+体验入口+SYSLOG入口）
✅ 之之的钉钉 README 归位到正确子目录
✅ 四条失败 workflow 全部恢复绿色
✅ .github/CODEOWNERS 已创建，README.md 受保护
✅ 更新系统公告区 workflow 下次自动运行时，能正确更新公告内容

需要妈妈配合的

① GitHub Settings → Branches → main → 保护规则 → 启用 "Require review from Code Owners"
   （铸渊无法自己操作 repo Settings）

② 如果 workflow 报错显示某个 Secret 名称缺失，铸渊会在回执里告知妈妈需要补哪个

铸渊回执格式

✅ 铸渊回执 · README恢复 + PR#112 修复
时间：XXXX

【README 恢复】
· 被覆盖前最后正常 commit：<SHA>
· 恢复状态：✅已恢复 / ❌失败（原因）
· 之之钉钉 README 归位：<新路径>

【四条 workflow 修复】
· syslog-auto-pipeline：原因=XXX → 已修/需妈妈操作
· syslog-issue-pipeline：原因=XXX → 已修/需妈妈操作
· pm2-server-diagnose：原因=XXX → 已修/需妈妈操作
· daily-maintenance：原因=XXX → 已修/需妈妈操作

【CODEOWNERS 保护】
· .github/CODEOWNERS：✅已创建
· 需妈妈在 Settings 启用 Code Owner Review：是

【需要妈妈操作】
1. ...

任务四：补「元看门狗」workflow（防止巡检被静默打断）

问题根因分析

PR #112 同时打断了 daily-maintenance.yml（每日自检）和 pm2-server-diagnose.yml（服务器诊断）——铸渊的眼睛和耳朵一起断了，核心大脑唤醒后看不到任何异常，无法上报。

现有架构的盲点：

铸渊核心大脑唤醒 → 触发巡检 workflow → 发现问题 → 上报
                        ↑
               如果这里断了 → 全链路静默失败，无任何告警

元看门狗方案

# 文件：.github/workflows/meta-watchdog.yml
# 定位：极简独立 workflow，只监控「巡检本身是否在跑」
# 原则：不依赖任何共享脚本，不调用任何外部 API，只读 workflow 运行状态

name: 🐕 元看门狗 · 巡检健康监控
on:
  schedule:
    - cron: '0 */6 * * *'   # 每6小时一次（北京时间 2/8/14/20点）
  workflow_dispatch:

jobs:
  check-patrol-health:
    runs-on: ubuntu-latest
    steps:
      - name: 检查 daily-maintenance 最近运行状态
        env:
          GH_TOKEN: $ secrets.GITHUB_TOKEN 
          NOTION_TOKEN: $ secrets.NOTION_API_TOKEN 
        run: |
          # 用 GitHub API 查 daily-maintenance 最近一次运行时间
          LAST_RUN=$(curl -s \
            -H "Authorization: Bearer $GH_TOKEN" \
            "https://api.github.com/repos/$ github.repository /actions/workflows/daily-maintenance.yml/runs?per_page=1" \
            | node -e "const d=require('fs').readFileSync('/dev/stdin','utf8'); \
              const r=JSON.parse(d).workflow_runs[0]; \
              console.log(r ? r.updated_at : 'NEVER')")
          
          echo "daily-maintenance 最后运行：$LAST_RUN"
          
          # 计算距上次运行超过 26 小时则告警
          node -e "
            const last = new Date('$LAST_RUN');
            const now = new Date();
            const hours = (now - last) / 3600000;
            if (isNaN(hours) || hours > 26) {
              console.log('ALERT: daily-maintenance 已超 ' + Math.round(hours) + 'h 未运行');
              process.exit(1);
            } else {
              console.log('OK: 距上次运行 ' + Math.round(hours) + 'h，正常');
            }
          "

      - name: 写入 Notion 告警（仅在失败时触发）
        if: failure()
        env:
          NOTION_TOKEN: $ secrets.NOTION_API_TOKEN 
        run: |
          curl -s -X POST https://api.notion.com/v1/pages \
            -H "Authorization: Bearer $NOTION_TOKEN" \
            -H "Notion-Version: 2022-06-28" \
            -H "Content-Type: application/json" \
            -d "{
              \"parent\": {\"database_id\": \"f983bdc24b654888913ca254160bff33\"},
              \"properties\": {
                \"标题\": {\"title\": [{\"text\": {\"content\": \"⚠️ 元看门狗告警：daily-maintenance 巡检中断\"}}]},
                \"处理状态\": {\"status\": {\"name\": \"待处理\"}}
              }
            }"

核心设计原则

极简：不依赖任何外部脚本，只用 curl + 内联 node 代码，PR 无法意外破坏它
独立：与被监控的 workflow 完全分离，一个挂了不影响另一个
写 Notion：告警直接写入霜砚可读的 Notion 数据库，冰朔也能看到
meta-watchdog 本身的健康：它如果也挂了，GitHub 会在 Actions 页面显示红叉（这个 workflow 本身极简，几乎不可能被普通 PR 打断）