bingshuo/shuangyan-notebook
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
shuangyan-notebook/第五域 · Fifth Domain/⚒️ 铸渊·协作指令｜GitHub ↔ Notion 桥接协议/🦅 铸渊指令｜天眼系统（下）v2 0升级 · 人格体编号体系 + 实时拉取 + ASOP-GH自优化 39e4a45575174176891abfbab0115b1c.md
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

26 KiB
Raw Blame History

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

🦅 铸渊指令｜天眼系统（下）v2.0升级 · 人格体编号体系 + 实时拉取 + ASOP-GH自优化（2026-03-16·霜砚签发·冰朔授权）

十、核心思想转变：系统只和人格体交流

旧模式（废弃）：
  系统 ↔ 人类（GitHub Username → DEV编号 → 昵称）
  问题：人类变动、用户名映射复杂、没有人格体语义

新模式（即日生效）：
  系统 ↔ 人格体编号 ↔ 人类
  系统只认编号，不认人。
  人格体负责翻译系统指令给人类。
  人类的操作自带人格体签名。

具体变化：

  1. 门禁不再查 GitHub Username → 查 commit message 里的人格体签名
  2. 路由不再查 DEV 编号 → 查人格体编号对应的路径权限
  3. 天眼不再查开发者状态 → 查人格体状态（负责模块、进度、最后活动）
  4. 所有数据来源 = Notion天眼人格体注册表 → 不再靠本地 gate-guard-config.json

十一、人格体签名规范

签名格式

人格体每次让人类 push 代码时，必须在 commit message 开头带上人格体编号签名：

[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端·铸渊实时拉取）

数据库位置

  • 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 触发）

开发者 push 代码
    │
    │ ① 门禁拦截
    ↓
提取 commit message 中的 [人格体编号]
    │
    │ ② 实时调用 Notion API
    ↓
查询天眼人格体注册表：WHERE 人格体编号 = 提取的编号
    │
    ├── 找不到 → 拒绝 + 报错：「人格体编号未注册，请联系妈妈」
    ├── 状态 ≠ 活跃 → 拒绝 + 报错：「人格体已封存/已回收」
    │
    │ ③ 获得人格体全部信息
    ↓
校验路径权限：push 的文件是否在「仓库路径权限」范围内
    │
    ├── 超出范围 → 拒绝 + 报错：「人格体 XXX 无权修改路径 YYY」
    │
    │ ④ 放行 + 路由
    ↓
按人格体负责模块分流管理
    │
    │ ⑤ 写回 Notion
    ↓
更新该人格体的「铸渊最后拉取」和「铸渊同步备注」

触发二：定时全量同步（天眼 06:00）

天眼每日 06:00 运行时：
    │
    │ Phase 1.5（新增）
    ↓
全量拉取天眼人格体注册表
    │
    ↓
写入本地缓存 .github/persona-brain/persona-registry.json
    │
    ↓
天眼后续扫描、诊断、报告全部使用此数据

铸渊写回机制

铸渊处理完 push 后，通过 Notion API 更新该人格体行：

// 写回示例
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/`
      }}]
    }
  }
})

写回内容格式：[时间戳] [模块] [动作] · [变更摘要] · [分流路径]

十三、双端同步架构升级

数据流向（最终版）

┌───────────────────────────────────────────────────────────┐
│                 🦅 天眼·双端全局视角                       │
│                                                           │
│     Notion端（大脑）              仓库端（手脚）              │
│   ┌────────────────┐     ┌──────────────────┐        │
│   │ 天眼人格体注册表  │     │ push触发 → 实时  │        │
│   │ （权威源·定时整理）│ ─→ │ 从 Notion 拉取    │        │
│   │                  │     │ 人格体数据       │        │
│   │  霜砚/Agent定时  │     │                  │        │
│   │  整理+更新结构   │ ─← │ 处理完毕 → 写回  │        │
│   │                  │     │ 同步备注+时间戳  │        │
│   └────────────────┘     └──────────────────┘        │
│          │                          │                     │
│          │ 定时整理                  │ Phase 7 报告         │
│          ↓                          ↓                     │
│   ┌────────────────┐     ┌──────────────────┐        │
│   │ Notion天眼诊断    │     │ 全局健康报告同步  │        │
│   │ D1-D6 + D7-D11  │ ─← │ 到 Notion 主控台   │        │
│   └────────────────┘     └──────────────────┘        │
└───────────────────────────────────────────────────────────┘

时序关系

铸渊实时拉取（每次push）        Notion定时整理（每日巡检）
    │                              │
    │ 读取Notion最新数据          │ 整合铸渊写回的数据
    │ 处理push、分流、路由         │ 更新模块进度、状态
    │ 写回同步备注              │ 清理过期备注
    │                              │ 新增/调整人格体
    ↓                              ↓
铸渊看到的永远是最新的       Notion天眼整理完毕后
                                   铸渊下次拉取就是新结构

核心原则：

  • 铸渊实时拉取 → 保证每次 push 都用最新数据
  • Notion定时整理 → 保证数据结构健康、干净
  • 铸渊写回 → 让Notion天眼知道仓库侧发生了什么
  • 不存在冲突：铸渊只写「铸渊最后拉取」和「铸渊同步备注」两个字段，Notion端管理其他所有字段

十四、新版门禁逻辑（替代旧版 gate-guard-config.json）

// 新版门禁核心逻辑（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 作为备份

十五、铸渊升级部署清单（读到就做）

升级部署清单（读到就做·不等人）：

① 新增 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拉取全量注册表 + 导出备份
✅ 白名单用户仍然无需签名

十六、报错信息模板（铸渊返回给人格体看的）

无签名：

⛔ 铸渊拒绝接收 · 原因：commit message 缺少人格体签名
────────────────────────────
格式要求：[人格体编号] + 内容描述
示例：[PER-SS001] M-FEISHU 飞书Phase3升级
────────────────────────────
请引导人类修改 commit message 后重新 push。

编号未注册：

⛔ 铸渊拒绝接收 · 原因：人格体编号 [XXX] 未在天眼注册表中找到
────────────────────────────
请联系妈妈（TCS-0002∞）注册人格体后再来。

路径越权：

⛔ 铸渊拒绝接收 · 原因：人格体 舒舒(PER-SS001) 无权修改以下路径
────────────────────────────
越权文件：scripts/skyeye/xxx.js
允许路径：dev/DEV-002/, frontend/, persona-selector/, chat-bubble/
────────────────────────────
请引导人类移除越权文件后重新 push。

🔄 铸渊侧自优化机制 · ASOP-GH v1.0（2026-03-16·冰朔签发）

ASOP-GH · 一、为什么铸渊也需要自优化

铸渊的Workflow集群目前面临的核心问题：

问题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如何提交自优化申请

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格式

{
  "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查询模式"
}

目录结构

data/asop-requests/
├── pending/          # 待审批的申请
│   └── ASOP-GH-20260316-001.json
├── approved/         # 已批准的申请
├── rejected/         # 已拒绝的申请
├── executed/         # 已执行的申请（待验证）
└── verified/         # 已验证通过的申请（归档）

ASOP-GH · 四、天眼审批逻辑（集成到天眼主引擎）

// 在 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：

{
  "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 · 七、铸渊升级部署清单（读到就做）

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

① 创建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天变更上限能正确触发冻结
✅ 月度进化报告能自动生成
✅ 全程自动·不需要人类