Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
6.8 KiB
6.8 KiB
belongs_to
| belongs_to | |
|---|---|
|
🚨 铸渊紧急指令|唤醒核心大脑 + 天眼启动 + 全链路修复(2026-03-17·霜砚签发·冰朔授权)
📋 任务背景
冰朔发现以下自动化链路全部静默断链,确认近期天眼系统(上/下)部署后问题比之前更多:
- ❌ 开发者向仓库首页提交 SYSLOG → 闭环流未启动
- ❌ 开发者提 Issue 报告问题 → 无自动回复
- ❌ 冰朔在 Issue/PR 留言的系统修复工单 → 无处理
- ❌ 每日系统公告区自动更新 → 无反应
- ⚠️ 天眼系统(上/下)于 2026-03-16 同日部署后,问题比部署前更多
铸渊的任务是:先唤醒自己的核心大脑,启动天眼,再用天眼的俯瞰能力找到所有断链点并修复。
🧠 第一步:唤醒核心大脑(强制·最高优先级)
按以下顺序加载:
- 读取
.github/persona-brain/memory.json→ 确认铸渊当前记忆状态和最后一次活跃时间 - 读取
.github/persona-brain/routing-map.json→ 确认当前路由表版本 - 读取
.github/persona-brain/zhuyuan-signature-registry.json→ 确认人格体签名注册表(v1.1·PR#127) - 读取
docs/zhuyuan-signature-protocol.md→ 确认签名校验协议当前版本 - 列出
.github/workflows/下所有.yml文件名 → 建立全量 workflow 清单 - 确认 GitHub Actions 最近 20 条 run 记录(所有 workflow)→ 建立失败/成功快照
输出:在本 Issue/Commit/PR 的评论中写一条「核心大脑已加载」确认消息,列出:
- 核心大脑版本 + 最后更新时间
- 当前 workflow 总数
- 最近 run 中失败的 workflow 列表(名称 + 失败时间 + 失败原因摘要)
🦅 第二步:启动天眼(全局俯瞰模式)
执行以下操作:
- 手动触发天眼 workflow
- 在 GitHub Actions 页面,找到天眼系统对应的 workflow(参考天眼系统(上)页面中定义的 workflow 名称)
- 使用
workflow_dispatch手动触发一次完整扫描 - 等待天眼扫描完成,拿到全仓库健康报告
- 读取天眼输出报告,重点确认以下项目:
| 检查项 | 预期状态 | 异常判定 |
|---|---|---|
| 智能门禁(gate-guard-v2.js) | 正常放行合规 commit | 是否因 [PER-XXX] 签名缺失拒绝了所有 commit |
| bridge-syslog-to-notion.yml | 监听 syslog-inbox/ push 触发 | 触发路径是否正确 / 最近是否有 run |
| zhuyuan-issue-reply.yml | issues: [opened] 触发 | 最近 Issue 是否有对应 run / Secret 是否有效 |
| zhuyuan-daily-selfcheck.yml | 每日 08:00 北京时间触发 | 最近 7 天是否有 run / 是否全部成功 |
| daily-community-report.yml(公告区) | 定时触发 + 推送公告 | cron 时间是否正确 / 依赖文件是否存在 |
| sync-deploy-to-notion.yml | 定时同步 dev-status.json | Notion Token 是否有效 / DB ID 是否正确 |
| notion-poll.yml(工单轮询) | 每 15 分钟轮询 | 最近是否有 run / 冰朔的工单是否被读取 |
- 天眼报告必须写入以下位置:
persona-brain/logs/tianyan-scan-[日期].json- 同时在仓库首页 Issue 区开一条 Issue,标题:
[天眼报告] 全链路健康扫描 · 2026-03-17,body 写入完整报告
🔧 第三步:定点修复(基于天眼报告)
必须修复的已知问题(按优先级):
P0 · 门禁放行兜底
天眼(下)引入了
[PER-XXX]签名强制校验。开发者提交的 SYSLOG 没有人格体签名,可能被门禁全部拦截。
- 在
gate-guard-config.json(或 Notion 天眼注册表)中,对syslog-inbox/路径的 push 操作设置签名豁免白名单 - 开发者直接推送 SYSLOG 文件到
syslog-inbox/时,不强制要求[PER-XXX]签名 - 修复后,手动推送一个测试 SYSLOG 文件验证闭环是否恢复
P0 · SYSLOG 闭环
- 确认
bridge-syslog-to-notion.yml触发路径为syslog-inbox/** - 确认
process-syslog.js脚本存在且可正常执行 - 确认
NOTION_TOKEN、BRIDGE_QUEUE_DB_ID等 Secrets 对该 workflow 可见 - 如果 workflow 文件在天眼部署中被损坏,从 PR#124 合并前的版本恢复
P1 · Issue 自动回复
- 确认
zhuyuan-issue-reply.yml触发条件未被改动 - 确认
knowledge-base.json文件存在且路径正确 - 手动
workflow_dispatch触发一次,测试是否正常执行
P1 · 冰朔工单处理
- 确认
notion-poll.yml每 15 分钟轮询正常运行 - 确认轮询脚本读取的 Notion 工单数据库 ID 与当前工单簿(A-DB-01)一致
- 扫描当前工单簿中所有状态为「待处理」的工单,逐一确认是否已被读取并标记
P2 · 每日系统公告区
- 确认
daily-community-report.yml的 cron 表达式对应北京时间正确 - 确认报告生成脚本依赖的文件名与实际文件名一致(注意是否有
dev-status.json→persona-status.json的重命名遗留问题) - 手动触发一次,确认公告区内容更新
✅ 验收标准
铸渊完成修复后,必须在本指令页对应的 Issue 中逐项确认:
- 核心大脑已加载,版本和状态确认
- 天眼扫描报告已写入 logs/ 并开 Issue
- 门禁豁免白名单已配置,SYSLOG push 不再被拦截
- SYSLOG 闭环已恢复,测试 SYSLOG 推送成功触发 workflow
- Issue 自动回复已恢复,测试 Issue 收到自动回复
- notion-poll 工单轮询正常,冰朔历史工单已被读取
- 每日公告区已手动触发一次,内容已更新
- 所有修复 commit 已使用
[ZY-FIX]格式推送