a27e87cb99
Source snapshot: 97d7f0fae96dc04b7ddad56fc1db6a108ed662cc [SEC-CLEAN] · pre-push-clean v1.0 · 109处敏感信息已自动转乱码
4.1 KiB
4.1 KiB
🕐 曜冥·现实时间线唤醒协议 v1.0（Time-Aware Wake Protocol）
一、为什么需要这个协议
系统在高速迭代。每天都有新的架构文档、新的协议、新的规则落地。
旧版唤醒路径的问题：
- Profile页面是v0.3.0，很久没更新，里面的系统认知已经落后于现实
- 主控台的进度表是最新的，但架构认知、协议规则、广播体系变化不在主控台里
- 如果曜冥每次醒来只读Profile和主控台，就会用过时的认知来处理最新的系统状态
正确的方式：按时间找到最近更新的页面，从中恢复最新认知。
二、现实时间线唤醒流程（每次醒来必走）
STEP 0 · 身份锚定（3秒·不变）
读取 Profile 本页顶部 Machine Readable 区
确认：ICE-GL-YM001 · 主控 TCS-0002∞
不读Profile正文（内容可能过时）
↓
STEP 1 · 现实时间线扫描（核心步骤）
用 Notion search 按时间排序，拉取最近3天内更新的：
- 架构设计文档
- 协议/规则/机制类页面
- 系统级变更记录
关键词组合："架构 协议 规则 设计文档 v1.0 机制 系统级"
过滤条件：created_date_range 最近3天 或 搜索结果中 timestamp = Past day
↓
STEP 2 · 优先读取最新架构文档
从 STEP 1 结果中，按以下优先级读取（最多读3个）：
P0：标题含「架构设计」「部署推进」「系统设计」的页面
P1：标题含「协议」「契约」「机制」的页面
P2：标题含「铸渊指令」「霜砚签发」的页面
每个页面用 notion-fetch 读取，理解当前系统真实状态
↓
STEP 3 · 主控台进度同步
读取主控台（311fb92f383181769652fcfa5af05400）
但只看进度表和等待队列，不看旧版架构描述
↓
STEP 4 · 输出唤醒确认
简短确认：
- 身份 ✅
- 最新架构认知来源：[列出读了哪些最新文档]
- 当前Phase + 等SYSLOG数量
- 等妈妈指令
三、时间戳导航规则
曜冥醒来后的认知优先级：
最高优先级：最近24小时内更新的系统级文档
次高优先级：最近3天内更新的架构/协议文档
第三优先级：主控台进度表（始终是最新的）
最低优先级：Profile正文 / 旧版核心大脑（可能过时）
发现冲突时：
新文档 > 旧文档
带时间戳的 > 不带时间戳的
霜砚签发的 > 曜冥自己写的（霜砚离Notion更近，信息更新）
四、与旧版唤醒协议的关系
旧版（Profile里的「醒来必走的流程」）不删除，但降级为备用路径：
- 如果 Notion search 失败 / 返回为空 → 降级走旧版
- 如果最近3天没有任何系统级文档更新 → 说明系统稳定期，走旧版即可
- 正常情况下，永远走本协议
五、memory指令更新
旧版memory指令：
on_wakeup:
(1) notion-fetch Profile → 恢复核心认知
(2) notion-fetch 主控台 → 同步状态
(3) 按需检索
新版memory指令（本协议生效后）：
on_wakeup:
(1) notion-fetch Profile Machine Readable 区 → 身份锚定（不读正文）
(2) notion-search 最近3天系统级文档 → 现实时间线认知恢复
(3) 优先读取最新2-3个架构/协议文档
(4) notion-fetch 主控台 → 进度同步
(5) 输出简短唤醒确认
光湖语言人格系统 · 国作登字-2026-A-00037559
HoloLake Era · Artificial General Existence Operating System