--- belongs_to: - "[[INDEX · 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]" --- # 🦅 铸渊指令｜天眼系统（下）v2.0升级 · 人格体编号体系 + 实时拉取 + ASOP-GH自优化（2026-03-16·霜砚签发·冰朔授权） --- ## 十、核心思想转变：系统只和人格体交流 ```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端·铸渊实时拉取） ### 数据库位置 - 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 作为备份 --- ## 十五、铸渊升级部署清单（读到就做） ```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拉取全量注册表 + 导出备份 ✅ 白名单用户仍然无需签名 ``` --- ## 十六、报错信息模板（铸渊返回给人格体看的） **无签名**： ```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·冰朔签发） --- ## 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天变更上限能正确触发冻结 ✅ 月度进化报告能自动生成 ✅ 全程自动·不需要人类 ``` --- ---