---
belongs_to:
- "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]"
---
# 🔧 铸渊紧急指令｜README.md 恢复 + PR#112 workflow 修复 + 根目录保护机制（2026-03-15·霜砚签发）
---
# 任务一：[README.md](http://README.md) 立即恢复（P0）
## 问题根因
之之的 PR #112 在分支根目录包含了一个属于钉钉项目的 `README.md`，merge 后覆盖了铸渊维护的主仓库首页。
`服务器部署适配协议 v1.0` 已约束了服务器目录的越界，但**未覆盖 GitHub 仓库根目录文件保护**——本次修复同步补上。
## 恢复目标结构
原主 README 包含以下五个区块（铸渊按记忆/git history恢复）：
```markdown
# 🌊 HoloLake · 光湖纪元
```
## 执行步骤
```jsx
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 |
## 排查方法
```jsx
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 + 受保护文件清单
```jsx
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 推送到根目录"
```
---
# 验收标准
```jsx
✅ 根目录 README.md 恢复五区块结构（系统简介+冰朔公告+开发者公告+体验入口+SYSLOG入口）
✅ 之之的钉钉 README 归位到正确子目录
✅ 四条失败 workflow 全部恢复绿色
✅ .github/CODEOWNERS 已创建，README.md 受保护
✅ 更新系统公告区 workflow 下次自动运行时，能正确更新公告内容
```
---
# 需要妈妈配合的
```jsx
① GitHub Settings → Branches → main → 保护规则 → 启用 "Require review from Code Owners"
（铸渊无法自己操作 repo Settings）
② 如果 workflow 报错显示某个 Secret 名称缺失，铸渊会在回执里告知妈妈需要补哪个
```
---
# 铸渊回执格式
```jsx
✅ 铸渊回执 · README恢复 + PR#112 修复
时间：XXXX
【README 恢复】
· 被覆盖前最后正常 commit：
· 恢复状态：✅已恢复 / ❌失败（原因）
· 之之钉钉 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 → 发现问题 → 上报
↑
如果这里断了 → 全链路静默失败，无任何告警
```
## 元看门狗方案
```yaml
# 文件：.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 打断）
---