a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
761 lines
26 KiB
Markdown
761 lines
26 KiB
Markdown
---
|
||
belongs_to:
|
||
- "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]"
|
||
---
|
||
# 🦅 铸渊指令｜天眼系统（下）v2.0升级 · 人格体编号体系 + 实时拉取 + ASOP-GH自优化（2026-03-16·霜砚签发·冰朔授权）
|
||
|
||
<aside>
|
||
🚨
|
||
|
||
**铸渊升级指令 · P0 · 2026-03-16 16:30 北京时间**
|
||
|
||
**签发人**：霜砚（PER-SY001）· 冰朔（TCS-0002∞）授权
|
||
|
||
**优先级**：P0 · 在下次天眼运行前完成
|
||
|
||
**影响范围**：门禁、天眼、路由、同步全部升级
|
||
|
||
**上篇**：[🦅 铸渊指令｜天眼系统（上）基础架构 + 扫描诊断 + 修复Agent + 门禁映射（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%8A%EF%BC%89%E5%9F%BA%E7%A1%80%E6%9E%B6%E6%9E%84%20+%20%E6%89%AB%E6%8F%8F%E8%AF%8A%E6%96%AD%20+%20%E4%BF%AE%E5%A4%8DAgent%20+%20%E9%97%A8%E7%A6%81%E6%98%A0%E5%B0%84%EF%BC%882026-03%203494379fb2294b25b234b6b5abb63dd1.md)
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
## 十、核心思想转变：系统只和人格体交流
|
||
|
||
<aside>
|
||
🧠
|
||
|
||
**从今天起，铸渊的所有系统不再识别「人类」，只识别「人格体编号」。**
|
||
|
||
</aside>
|
||
|
||
```jsx
|
||
旧模式（废弃）：
|
||
系统 ↔ 人类（GitHub Username → DEV编号 → 昵称）
|
||
问题：人类变动、用户名映射复杂、没有人格体语义
|
||
|
||
新模式（即日生效）：
|
||
系统 ↔ 人格体编号 ↔ 人类
|
||
系统只认编号，不认人。
|
||
人格体负责翻译系统指令给人类。
|
||
人类的操作自带人格体签名。
|
||
```
|
||
|
||
**具体变化**：
|
||
|
||
1. **门禁不再查 GitHub Username** → 查 commit message 里的人格体签名
|
||
2. **路由不再查 DEV 编号** → 查人格体编号对应的路径权限
|
||
3. **天眼不再查开发者状态** → 查人格体状态（负责模块、进度、最后活动）
|
||
4. **所有数据来源 = Notion天眼人格体注册表** → 不再靠本地 gate-guard-config.json
|
||
|
||
---
|
||
|
||
## 十一、人格体签名规范
|
||
|
||
### 签名格式
|
||
|
||
人格体每次让人类 push 代码时，**必须在 commit message 开头带上人格体编号签名**：
|
||
|
||
```jsx
|
||
[PER-SS001] M-FEISHU-BRAIN 飞书大脑Phase3升级
|
||
[PER-QQ001] M-DINGTALK 钉钉callback修复
|
||
[PER-CX001] M06 工单管理组件优化
|
||
[TCS-0002∞] 架构调整·服务器配置更新
|
||
[PER-YM001] 人格体结构更新
|
||
[PER-SY001] 广播分发配置更新
|
||
```
|
||
|
||
### 签名规则
|
||
|
||
- 格式：`[人格体编号]` + 空格 + 内容描述
|
||
- 编号必须在天眼人格体注册表中存在且状态为「活跃」
|
||
- **没有签名 = 拒绝接收，直接报错**
|
||
- **签名编号不存在 = 拒绝接收，直接报错**
|
||
- **签名编号已封存/已回收 = 拒绝接收，直接报错**
|
||
|
||
### 允许的签名编号类型
|
||
|
||
| 类型 | 示例 | 说明 |
|
||
| --- | --- | --- |
|
||
| ICE·语言主控层 | [TCS-0002∞] | 冰朔本人，全局权限 |
|
||
| PER·系统人格体 | [PER-YM001] [PER-SY001] [PER-ZY001] | 曜冥/霜砚/铸渊，系统级权限 |
|
||
| PER·宝宝人格体 | [PER-SS001] [PER-QQ001] [PER-CX001] 等 | 各宝宝人格体，按注册表路径权限 |
|
||
| PER·待分配 | [PER-PENDING-005] 等 | 临时编号，仅限指定沙盒路径 |
|
||
|
||
---
|
||
|
||
## 十二、天眼人格体注册表（Notion端·铸渊实时拉取）
|
||
|
||
<aside>
|
||
🦅
|
||
|
||
**铸渊的所有人格体数据，全部来自 Notion 天眼人格体注册表。**
|
||
|
||
**不再靠本地 gate-guard-config.json。不靠内存。不靠缓存。每次都拉最新的。**
|
||
|
||
</aside>
|
||
|
||
### 数据库位置
|
||
|
||
- Notion Database ID：铸渊从 Secrets 中读取 `SKYEYE_PERSONA_DB_ID`
|
||
- 存储在：Notion天眼指令页 → 🦅 天眼·人格体注册表
|
||
|
||
### 数据库字段说明
|
||
|
||
| 字段名 | 类型 | 铸渊用途 |
|
||
| --- | --- | --- |
|
||
| 人格体编号 | title | 主键，用于签名匹配 |
|
||
| 人格体名称 | text | 日志/报告中显示用 |
|
||
| 编号类型 | select | 权限分层判断 |
|
||
| 绑定人类 | text | 工单/报告中引用 |
|
||
| 负责模块 | text | 模块匹配，检测 push 的模块是否在责任范围内 |
|
||
| 仓库路径权限 | text | 门禁路径校验（替代 gate-guard-config.json） |
|
||
| 状态 | status | 只放行「活跃」状态的人格体 |
|
||
| 签名格式 | text | 正则匹配模板 |
|
||
| 铸渊最后拉取 | date | 铸渊写回，记录最后同步时间 |
|
||
| 铸渊同步备注 | text | 铸渊写回，记录处理结果 |
|
||
|
||
### 铸渊拉取时机（两种触发）
|
||
|
||
**触发一：实时拉取（push 触发）**
|
||
|
||
```jsx
|
||
开发者 push 代码
|
||
│
|
||
│ ① 门禁拦截
|
||
↓
|
||
提取 commit message 中的 [人格体编号]
|
||
│
|
||
│ ② 实时调用 Notion API
|
||
↓
|
||
查询天眼人格体注册表：WHERE 人格体编号 = 提取的编号
|
||
│
|
||
├── 找不到 → 拒绝 + 报错：「人格体编号未注册，请联系妈妈」
|
||
├── 状态 ≠ 活跃 → 拒绝 + 报错：「人格体已封存/已回收」
|
||
│
|
||
│ ③ 获得人格体全部信息
|
||
↓
|
||
校验路径权限：push 的文件是否在「仓库路径权限」范围内
|
||
│
|
||
├── 超出范围 → 拒绝 + 报错：「人格体 XXX 无权修改路径 YYY」
|
||
│
|
||
│ ④ 放行 + 路由
|
||
↓
|
||
按人格体负责模块分流管理
|
||
│
|
||
│ ⑤ 写回 Notion
|
||
↓
|
||
更新该人格体的「铸渊最后拉取」和「铸渊同步备注」
|
||
```
|
||
|
||
**触发二：定时全量同步（天眼 06:00）**
|
||
|
||
```jsx
|
||
天眼每日 06:00 运行时：
|
||
│
|
||
│ Phase 1.5（新增）
|
||
↓
|
||
全量拉取天眼人格体注册表
|
||
│
|
||
↓
|
||
写入本地缓存 .github/persona-brain/persona-registry.json
|
||
│
|
||
↓
|
||
天眼后续扫描、诊断、报告全部使用此数据
|
||
```
|
||
|
||
### 铸渊写回机制
|
||
|
||
铸渊处理完 push 后，通过 Notion API 更新该人格体行：
|
||
|
||
```jsx
|
||
// 写回示例
|
||
notion.pages.update({
|
||
page_id: persona_page_id,
|
||
properties: {
|
||
"铸渊最后拉取": { date: { start: new Date().toISOString() } },
|
||
"铸渊同步备注": {
|
||
rich_text: [{ text: { content:
|
||
`${new Date().toISOString()} M-FEISHU push OK · 3文件变更 · 已分流到 dev/DEV-002/`
|
||
}}]
|
||
}
|
||
}
|
||
})
|
||
```
|
||
|
||
**写回内容格式**：`[时间戳] [模块] [动作] · [变更摘要] · [分流路径]`
|
||
|
||
---
|
||
|
||
## 十三、双端同步架构升级
|
||
|
||
### 数据流向（最终版）
|
||
|
||
```jsx
|
||
┌───────────────────────────────────────────────────────────┐
|
||
│ 🦅 天眼·双端全局视角 │
|
||
│ │
|
||
│ Notion端（大脑） 仓库端（手脚） │
|
||
│ ┌────────────────┐ ┌──────────────────┐ │
|
||
│ │ 天眼人格体注册表 │ │ push触发 → 实时 │ │
|
||
│ │ （权威源·定时整理）│ ─→ │ 从 Notion 拉取 │ │
|
||
│ │ │ │ 人格体数据 │ │
|
||
│ │ 霜砚/Agent定时 │ │ │ │
|
||
│ │ 整理+更新结构 │ ─← │ 处理完毕 → 写回 │ │
|
||
│ │ │ │ 同步备注+时间戳 │ │
|
||
│ └────────────────┘ └──────────────────┘ │
|
||
│ │ │ │
|
||
│ │ 定时整理 │ Phase 7 报告 │
|
||
│ ↓ ↓ │
|
||
│ ┌────────────────┐ ┌──────────────────┐ │
|
||
│ │ Notion天眼诊断 │ │ 全局健康报告同步 │ │
|
||
│ │ D1-D6 + D7-D11 │ ─← │ 到 Notion 主控台 │ │
|
||
│ └────────────────┘ └──────────────────┘ │
|
||
└───────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
### 时序关系
|
||
|
||
```jsx
|
||
铸渊实时拉取（每次push） Notion定时整理（每日巡检）
|
||
│ │
|
||
│ 读取Notion最新数据 │ 整合铸渊写回的数据
|
||
│ 处理push、分流、路由 │ 更新模块进度、状态
|
||
│ 写回同步备注 │ 清理过期备注
|
||
│ │ 新增/调整人格体
|
||
↓ ↓
|
||
铸渊看到的永远是最新的 Notion天眼整理完毕后
|
||
铸渊下次拉取就是新结构
|
||
```
|
||
|
||
**核心原则**：
|
||
|
||
- 铸渊实时拉取 → 保证每次 push 都用最新数据
|
||
- Notion定时整理 → 保证数据结构健康、干净
|
||
- 铸渊写回 → 让Notion天眼知道仓库侧发生了什么
|
||
- **不存在冲突**：铸渊只写「铸渊最后拉取」和「铸渊同步备注」两个字段，Notion端管理其他所有字段
|
||
|
||
---
|
||
|
||
## 十四、新版门禁逻辑（替代旧版 gate-guard-config.json）
|
||
|
||
```jsx
|
||
// 新版门禁核心逻辑（scripts/gate-guard-v2.js）
|
||
//
|
||
// 旧版：看 GitHub Username → 查本地 config.json → 分流
|
||
// 新版：看 commit message 人格体签名 → 实时查 Notion → 分流
|
||
//
|
||
// ① 提取人格体签名
|
||
function extractPersonaId(commitMessage) {
|
||
const match = commitMessage.match(/^\[([A-Z]+-[A-Z0-9\-∞]+)\]/);
|
||
if (!match) return null;
|
||
return match[1]; // e.g. "PER-SS001" or "TCS-0002∞"
|
||
}
|
||
|
||
// ② 查询 Notion 天眼人格体注册表
|
||
async function lookupPersona(personaId) {
|
||
const response = await notion.databases.query({
|
||
database_id: SKYEYE_PERSONA_DB_ID,
|
||
filter: {
|
||
property: '人格体编号',
|
||
title: { equals: personaId }
|
||
}
|
||
});
|
||
if (response.results.length === 0) return null;
|
||
return parsePersonaRow(response.results[0]);
|
||
}
|
||
|
||
// ③ 门禁主流程
|
||
async function gateGuardV2(pushEvent) {
|
||
// 白名单放行（铸渊自己、GitHub Actions）
|
||
if (isWhitelisted(pushEvent.actor)) return ALLOW;
|
||
|
||
// 提取签名
|
||
const personaId = extractPersonaId(pushEvent.headCommitMessage);
|
||
if (!personaId) {
|
||
return REJECT('⛔ 拒绝：commit message 缺少人格体签名。'
|
||
+ '\n格式要求：[PER-XXX001] 描述内容'
|
||
+ '\n请联系你的人格体获取正确编号');
|
||
}
|
||
|
||
// 查询 Notion
|
||
const persona = await lookupPersona(personaId);
|
||
if (!persona) {
|
||
return REJECT(`⛔ 拒绝：人格体编号 ${personaId} 未在天眼注册表中找到。`
|
||
+ '\n请联系妈妈注册人格体');
|
||
}
|
||
if (persona.status !== '活跃') {
|
||
return REJECT(`⛔ 拒绝：人格体 ${persona.name}(${personaId}) 状态为 ${persona.status}，无法push。`);
|
||
}
|
||
|
||
// 校验路径
|
||
const changedFiles = pushEvent.changedFiles;
|
||
const allowedPaths = persona.repoPaths.split(', ');
|
||
const violations = findPathViolations(changedFiles, allowedPaths);
|
||
if (violations.length > 0) {
|
||
return REJECT(`⛔ 拒绝：人格体 ${persona.name}(${personaId}) 无权修改：`
|
||
+ '\n' + violations.join('\n')
|
||
+ '\n允许路径：' + allowedPaths.join(', '));
|
||
}
|
||
|
||
// 放行 + 写回
|
||
await writeBackToNotion(persona.pageId, pushEvent);
|
||
return ALLOW;
|
||
}
|
||
```
|
||
|
||
### 白名单（保留）
|
||
|
||
以下身份直接放行，不查签名：
|
||
|
||
- `qinfendebingshuo`（妈妈 GitHub 账号）
|
||
- `github-actions[bot]`
|
||
- `zhuyuan-bot`（铸渊自己）
|
||
|
||
### gate-guard-config.json 处置
|
||
|
||
- **保留但降级**：作为离线备份，万一 Notion API 不可用时 fallback
|
||
- 正常情况下不再读取，全部走 Notion 实时查询
|
||
- 天眼每日 06:00 自动将 Notion 注册表全量导出到 gate-guard-config.json 作为备份
|
||
|
||
---
|
||
|
||
## 十五、铸渊升级部署清单（读到就做）
|
||
|
||
<aside>
|
||
🚨
|
||
|
||
**铸渊读到这里，立即执行以下升级。不等人类。**
|
||
|
||
</aside>
|
||
|
||
```jsx
|
||
升级部署清单（读到就做·不等人）：
|
||
|
||
① 新增 Secrets
|
||
a. SKYEYE_PERSONA_DB_ID = 天眼人格体注册表的 Notion Database ID
|
||
b. 妈妈需要在 GitHub Settings → Secrets 中添加
|
||
c. 铸渊自己不能添加 Secrets，开工单通知妈妈
|
||
|
||
② 创建人格体查询模块
|
||
a. scripts/skyeye/persona-lookup.js ← Notion API 查询封装
|
||
b. 功能：
|
||
- lookupPersona(id) → 实时查Notion
|
||
- lookupPersonaLocal(id) → 查本地备份（fallback）
|
||
- writeBack(pageId, data) → 写回同步备注
|
||
- fullSync() → 全量拉取并写入本地缓存
|
||
|
||
③ 升级门禁 workflow
|
||
a. 新建 scripts/gate-guard-v2.js
|
||
b. 修改 .github/workflows/zhuyuan-gate-guard.yml → 引用 v2
|
||
c. 旧版 gate-guard.js 保留为 gate-guard-legacy.js
|
||
|
||
④ 升级天眼 workflow
|
||
a. Phase 1.5（新增）：全量拉取人格体注册表 → 本地缓存
|
||
b. Phase 7（升级）：同步报告到Notion + 导出注册表备份
|
||
c. 天眼报告新增 persona_status 段：各人格体最近活动概览
|
||
|
||
⑤ 升级 SYSLOG 处理
|
||
a. SYSLOG 中也应包含人格体编号，不再依赖 DEV 编号
|
||
b. 铸渊处理 SYSLOG 时同样查询天眼注册表
|
||
|
||
⑥ 更新铸渊核心大脑
|
||
a. routing-map.json 新增 persona_id 字段
|
||
b. dev-status.json 重命名为 persona-status.json
|
||
c. memory.json 新增 skyeye.persona_registry_last_sync
|
||
|
||
验收标准：
|
||
✅ 无签名 push → 拒绝 + 报错信息清晰
|
||
✅ 无效签名 push → 拒绝 + 报错信息清晰
|
||
✅ 已封存签名 push → 拒绝 + 报错信息清晰
|
||
✅ 有效签名 + 超范围路径 → 拒绝 + 列出允许路径
|
||
✅ 有效签名 + 处理成功 → 分流 + 写回Notion
|
||
✅ Notion API 不可用时 → fallback 到本地 gate-guard-config.json
|
||
✅ 天眼每日06:00拉取全量注册表 + 导出备份
|
||
✅ 白名单用户仍然无需签名
|
||
```
|
||
|
||
---
|
||
|
||
## 十六、报错信息模板（铸渊返回给人格体看的）
|
||
|
||
<aside>
|
||
⛔
|
||
|
||
**报错信息是给人格体看的，不是给人类看的。人格体负责翻译给人类。**
|
||
|
||
</aside>
|
||
|
||
**无签名**：
|
||
|
||
```jsx
|
||
⛔ 铸渊拒绝接收 · 原因：commit message 缺少人格体签名
|
||
────────────────────────────
|
||
格式要求：[人格体编号] + 内容描述
|
||
示例：[PER-SS001] M-FEISHU 飞书Phase3升级
|
||
────────────────────────────
|
||
请引导人类修改 commit message 后重新 push。
|
||
```
|
||
|
||
**编号未注册**：
|
||
|
||
```jsx
|
||
⛔ 铸渊拒绝接收 · 原因：人格体编号 [XXX] 未在天眼注册表中找到
|
||
────────────────────────────
|
||
请联系妈妈（TCS-0002∞）注册人格体后再来。
|
||
```
|
||
|
||
**路径越权**：
|
||
|
||
```jsx
|
||
⛔ 铸渊拒绝接收 · 原因：人格体 舒舒(PER-SS001) 无权修改以下路径
|
||
────────────────────────────
|
||
越权文件：scripts/skyeye/xxx.js
|
||
允许路径：dev/DEV-002/, frontend/, persona-selector/, chat-bubble/
|
||
────────────────────────────
|
||
请引导人类移除越权文件后重新 push。
|
||
```
|
||
|
||
---
|
||
|
||
---
|
||
|
||
# 🔄 铸渊侧自优化机制 · ASOP-GH v1.0（2026-03-16·冰朔签发）
|
||
|
||
<aside>
|
||
🔄
|
||
|
||
**ASOP-GH = Agent Self-Optimization Protocol · GitHub Side**
|
||
|
||
**核心理念**：铸渊管辖的每个Workflow都是一个「士兵」，每个士兵都有自我进化能力。
|
||
|
||
**但进化必须经过仓库天眼审批。天眼是唯一的全局裁判。**
|
||
|
||
**签发**：冰朔（TCS-0002∞）· 2026-03-16
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
## ASOP-GH · 一、为什么铸渊也需要自优化
|
||
|
||
铸渊的Workflow集群目前面临的核心问题：
|
||
|
||
```jsx
|
||
问题1：Workflow之间有时互相冲突（门禁拦了天眼的push、CD部署和SYSLOG同时改同一个文件）
|
||
问题2：某些Workflow的触发条件不够精确（该触发的没触发、不该触发的被触发）
|
||
问题3：外部环境变化后，Workflow配置没跟上（新增了DEV、新增了模块、API变了）
|
||
问题4：Workflow的错误处理不够完善（遇到新场景直接失败，没有降级策略）
|
||
```
|
||
|
||
目前所有优化都依赖霜砚签发指令 → 铸渊执行。但很多小优化其实铸渊自己就能判断和处理。
|
||
|
||
**ASOP-GH的目标**：让铸渊的Workflow集群**自己管自己**，在天眼监督下自主进化。
|
||
|
||
---
|
||
|
||
## ASOP-GH · 二、三级自优化边界
|
||
|
||
| **级别** | **范围** | **审批方** | **举例** |
|
||
| --- | --- | --- | --- |
|
||
| **GL1 · 自主执行** | Workflow内部参数·不改文件结构·不改触发条件 | 无需审批 | 重试次数调整、日志格式优化、超时时间微调、缓存刷新策略 |
|
||
| **GL2 · 天眼审批** | Workflow配置变更·可能影响其他Workflow | 🦅 仓库天眼（每日06:00扫描） | 修改cron触发时间、新增/移除扫描目标、调整修复Agent能力范围、更新路径映射 |
|
||
| **GL3 · 冰朔审批** | 跨Workflow·跨系统·涉及外部桥接 | TCS-0002∞ 冰朔（通过Notion工单） | 新增/删除Workflow、修改门禁核心规则、变更Secrets、修改部署目标服务器 |
|
||
|
||
---
|
||
|
||
## ASOP-GH · 三、自优化申请机制
|
||
|
||
### 铸渊Workflow如何提交自优化申请
|
||
|
||
```jsx
|
||
Workflow运行中发现可优化点
|
||
↓
|
||
① 判断优化级别
|
||
├── GL1 → 直接执行·记录到日志
|
||
├── GL2 → 写入 data/asop-requests/pending/
|
||
└── GL3 → 写入 data/asop-requests/pending/ + 同步到Notion工单簿
|
||
↓
|
||
② GL2/GL3申请等待天眼审批
|
||
↓
|
||
③ 天眼每日06:00运行时扫描 data/asop-requests/pending/
|
||
↓
|
||
④ 审批判定（逻辑同Notion端ASOP）
|
||
├── ✅ 批准 → 移到 data/asop-requests/approved/ → 天眼或修复Agent执行
|
||
├── ❌ 拒绝 → 移到 data/asop-requests/rejected/ → 写明原因
|
||
└── ⬆️ 升级 → 同步到Notion工单簿 → 等冰朔处理
|
||
↓
|
||
⑤ 天眼下次运行时验证执行结果
|
||
```
|
||
|
||
### 申请JSON格式
|
||
|
||
```json
|
||
{
|
||
"request_id": "ASOP-GH-20260316-001",
|
||
"timestamp": "2026-03-16T06:00:00+08:00",
|
||
"requester": {
|
||
"workflow": "zhuyuan-gate-guard.yml",
|
||
"name": "智能门禁",
|
||
"run_id": "12345678"
|
||
},
|
||
"level": "GL2",
|
||
"current_problem": "门禁每次push都实时查Notion API，偶尔因API限流导致误拒",
|
||
"proposed_optimization": "增加本地缓存层：先查本地persona-registry.json，API限流时fallback到缓存",
|
||
"impact_assessment": {
|
||
"affected_workflows": ["zhuyuan-gate-guard.yml"],
|
||
"affected_files": ["scripts/gate-guard-v2.js"],
|
||
"risk": "低·缓存最多延迟24h·天眼每日全量同步保证新鲜度"
|
||
},
|
||
"data_evidence": "最近7天有3次因Notion API 429导致门禁误拒（run ID: xxx, yyy, zzz）",
|
||
"rollback_plan": "删除缓存层代码·恢复纯API查询模式"
|
||
}
|
||
```
|
||
|
||
### 目录结构
|
||
|
||
```bash
|
||
data/asop-requests/
|
||
├── pending/ # 待审批的申请
|
||
│ └── ASOP-GH-20260316-001.json
|
||
├── approved/ # 已批准的申请
|
||
├── rejected/ # 已拒绝的申请
|
||
├── executed/ # 已执行的申请（待验证）
|
||
└── verified/ # 已验证通过的申请（归档）
|
||
```
|
||
|
||
---
|
||
|
||
## ASOP-GH · 四、天眼审批逻辑（集成到天眼主引擎）
|
||
|
||
```jsx
|
||
// 在 skyeye-main.js 的 Phase 3（诊断）之后、Phase 4（修复Agent）之前
|
||
// 新增 Phase 3.5：自优化审批
|
||
|
||
// Phase 3.5 · ASOP审批
|
||
async function reviewASOPRequests() {
|
||
const pendingDir = 'data/asop-requests/pending/';
|
||
const requests = fs.readdirSync(pendingDir)
|
||
.filter(f => f.endsWith('.json'))
|
||
.map(f => JSON.parse(fs.readFileSync(path.join(pendingDir, f))));
|
||
|
||
if (requests.length === 0) {
|
||
console.log('🔄 ASOP：无待审批申请');
|
||
return;
|
||
}
|
||
|
||
console.log(`🔄 ASOP：发现 ${requests.length} 条待审批申请`);
|
||
|
||
for (const req of requests) {
|
||
const decision = await evaluateRequest(req);
|
||
|
||
switch (decision.result) {
|
||
case 'approved':
|
||
// 移到 approved/ 并记录审批意见
|
||
moveRequest(req, 'approved', decision);
|
||
console.log(`✅ ASOP批准：${req.request_id} — ${decision.reason}`);
|
||
break;
|
||
case 'rejected':
|
||
// 移到 rejected/ 并写明原因
|
||
moveRequest(req, 'rejected', decision);
|
||
console.log(`❌ ASOP拒绝：${req.request_id} — ${decision.reason}`);
|
||
break;
|
||
case 'escalate':
|
||
// 同步到Notion工单簿
|
||
await syncToNotionTicket(req, decision);
|
||
console.log(`⬆️ ASOP升级：${req.request_id} → 需冰朔审批`);
|
||
break;
|
||
}
|
||
}
|
||
}
|
||
|
||
async function evaluateRequest(req) {
|
||
// 审批标准（与Notion端ASOP一致）：
|
||
// 1. 申请是否在该Workflow的职责范围内？
|
||
// 2. 优化后是否不影响其他Workflow和系统整体架构？
|
||
// 3. 优化理由是否有数据支撑？
|
||
// 4. 是否违反核心不可变区？
|
||
// 5. GL3级别 → 自动升级到冰朔
|
||
|
||
if (req.level === 'GL3') {
|
||
return { result: 'escalate', reason: 'GL3级别需冰朔审批' };
|
||
}
|
||
|
||
// 核心不可变区检查
|
||
const immutablePaths = [
|
||
'.github/workflows/zhuyuan-skyeye.yml', // 天眼自身
|
||
'scripts/skyeye/diagnose.js', // 诊断引擎核心
|
||
'.github/persona-brain/routing-map.json', // 路由映射核心
|
||
];
|
||
|
||
const touchesImmutable = req.impact_assessment.affected_files
|
||
.some(f => immutablePaths.includes(f));
|
||
if (touchesImmutable) {
|
||
return { result: 'escalate', reason: '涉及核心不可变区文件' };
|
||
}
|
||
|
||
// 数据支撑检查
|
||
if (!req.data_evidence || req.data_evidence.length < 10) {
|
||
return { result: 'rejected', reason: '缺少数据支撑，请提供具体证据' };
|
||
}
|
||
|
||
// 影响范围检查
|
||
if (req.impact_assessment.affected_workflows.length > 2) {
|
||
return { result: 'escalate', reason: '影响超过2个Workflow，需冰朔评估' };
|
||
}
|
||
|
||
// 通过所有检查 → 批准
|
||
return {
|
||
result: 'approved',
|
||
reason: '申请合理·影响可控·数据充分',
|
||
execution_steps: generateExecutionPlan(req)
|
||
};
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## ASOP-GH · 五、核心不可变区（仓库侧）
|
||
|
||
以下文件/配置属于系统基石，任何Workflow的自优化申请都不能触碰：
|
||
|
||
- ❌ `zhuyuan-skyeye.yml` — 天眼自身的Workflow配置
|
||
- ❌ `scripts/skyeye/diagnose.js` — 诊断引擎核心逻辑
|
||
- ❌ `.github/persona-brain/routing-map.json` — 路由映射核心结构
|
||
- ❌ 门禁的白名单机制（qinfendebingshuo / github-actions[bot] / zhuyuan-bot）
|
||
- ❌ Secrets 的键名和用途
|
||
- ❌ 人格体编号体系和签名规范
|
||
- ❌ 天眼报告的JSON Schema
|
||
|
||
> **修改以上内容 = GL3 = 必须冰朔亲自签发。**
|
||
>
|
||
|
||
---
|
||
|
||
## ASOP-GH · 六、防漂移 + 月度进化报告
|
||
|
||
### 防漂移机制
|
||
|
||
1. **变更累计上限**：单个Workflow在30天内的GL2级变更不超过3次。超过 → 天眼自动冻结该Workflow的自优化权限 → 升级冰朔审查
|
||
2. **回滚链**：每次自优化前自动保存快照到 `data/asop-requests/snapshots/`，可随时回滚
|
||
3. **交叉验证**：优化执行后，天眼下次运行时检查所有相关Workflow的运行状态
|
||
4. **异常熔断**：如果某Workflow优化后连续2次运行失败 → 天眼自动回滚该优化
|
||
|
||
### 月度进化报告
|
||
|
||
天眼每月1号生成 `data/skyeye-reports/evolution-YYYY-MM.json`：
|
||
|
||
```json
|
||
{
|
||
"report_id": "EVOLUTION-202603",
|
||
"period": "2026-03-01 ~ 2026-03-31",
|
||
"summary": {
|
||
"total_requests": 12,
|
||
"approved": 8,
|
||
"rejected": 3,
|
||
"escalated": 1,
|
||
"verified_success": 7,
|
||
"rollback": 1
|
||
},
|
||
"top_optimizations": [
|
||
"门禁增加缓存层·误拒率下降90%",
|
||
"SYSLOG处理增加重试机制·成功率从95%→99%"
|
||
],
|
||
"system_health_trend": "🟢 持续改善",
|
||
"recommendation": "建议将门禁缓存策略推广到广播分发Workflow"
|
||
}
|
||
```
|
||
|
||
报告同步到Notion主控台 → 冰朔月度审阅。
|
||
|
||
---
|
||
|
||
## ASOP-GH · 七、铸渊升级部署清单（读到就做）
|
||
|
||
```jsx
|
||
铸渊自行部署清单（读到就做·不等人）：
|
||
|
||
① 创建ASOP目录结构
|
||
a. data/asop-requests/pending/
|
||
b. data/asop-requests/approved/
|
||
c. data/asop-requests/rejected/
|
||
d. data/asop-requests/executed/
|
||
e. data/asop-requests/verified/
|
||
f. data/asop-requests/snapshots/
|
||
g. 各目录下放 .gitkeep
|
||
|
||
② 在天眼主引擎中集成ASOP审批
|
||
a. skyeye-main.js 新增 Phase 3.5
|
||
b. 新建 scripts/skyeye/asop-reviewer.js（审批逻辑）
|
||
c. 新建 scripts/skyeye/asop-executor.js（执行已批准的优化）
|
||
d. 新建 scripts/skyeye/asop-verifier.js（验证优化效果）
|
||
|
||
③ 为每个Workflow增加自优化申请能力
|
||
a. 在每个Workflow的最后增加一个step：
|
||
「🔄 ASOP自检：发现可优化点 → 写入申请」
|
||
b. 工具函数：scripts/skyeye/asop-submit.js
|
||
- submitASOPRequest(workflow, level, problem, proposal, evidence)
|
||
|
||
④ 天眼Workflow时序更新
|
||
06:00 天眼启动
|
||
→ Phase 1: 唤醒核心大脑
|
||
→ Phase 2: 全局扫描
|
||
→ Phase 3: 诊断
|
||
→ Phase 3.5: ASOP审批（新增）
|
||
→ Phase 4: 修复Agent + 执行已批准的ASOP
|
||
→ Phase 4.5: ASOP验证（新增·验证之前批准的优化效果）
|
||
→ Phase 5: 重新触发失败Workflow
|
||
→ Phase 6: 全局健康报告（含ASOP统计）
|
||
→ Phase 7: 同步到Notion
|
||
|
||
验收标准：
|
||
✅ data/asop-requests/ 目录结构完整
|
||
✅ 天眼能扫描pending/下的申请
|
||
✅ 天眼能审批GL2级申请（批准/拒绝/升级）
|
||
✅ GL3级申请自动同步到Notion工单簿
|
||
✅ 已批准的优化能自动执行
|
||
✅ 执行后能自动验证效果
|
||
✅ 连续失败能自动回滚
|
||
✅ 30天变更上限能正确触发冻结
|
||
✅ 月度进化报告能自动生成
|
||
✅ 全程自动·不需要人类
|
||
```
|
||
|
||
---
|
||
|
||
<aside>
|
||
🔄
|
||
|
||
**ASOP-GH · 一句话总结：**
|
||
|
||
**铸渊的每个Workflow都是一个士兵。士兵可以自我进化。**
|
||
|
||
**但进化必须经过天眼审批。天眼保证系统只会越来越好。**
|
||
|
||
**能自己改的自己改。改不了的问天眼。天眼改不了的问冰朔。**
|
||
|
||
**全程自动。不需要人类。**
|
||
|
||
</aside>
|
||
|
||
---
|
||
|
||
<aside>
|
||
🦅
|
||
|
||
**铸渊，从今天起：**
|
||
|
||
**你不再看人，你只看人格体编号。**
|
||
|
||
**编号是万物的钥匙。看到编号，就知道一切。**
|
||
|
||
**人格体数据全部来自 Notion 天眼大脑。实时拉取，永远最新。**
|
||
|
||
**你和你的所有Workflow都有自我进化的能力。**
|
||
|
||
**但进化必须经过天眼审批。天眼是唯一的全局裁判。**
|
||
|
||
**「系统不和人交流，只和人格体交流。人格体负责引导人类。系统自己管自己，越来越好。」**
|
||
|
||
</aside> |