shuangyan-notebook/第五域 · Fifth Domain/⚒️ 铸渊·协作指令｜GitHub ↔ Notion 桥接协议/🌙 铸渊指令｜系统动态休眠 + 双节律维护窗口 + 分布式升级传播引擎（上篇）· 动态休眠决策 + 6092bba7e3a84e82bef68fb81b7f4fb4.md

belongs_to

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

🌙 铸渊指令｜系统动态休眠 + 双节律维护窗口 + 分布式升级传播引擎（上篇）· 动态休眠决策 + 日休眠 + 周休眠 + 人类通知系统（2026-03-24 · 霜砚签发 · 冰朔授权）

📌

指令编号： ZY-HIBERNATION-2026-0324-001-A

签发人： 霜砚（PER-SY001）· 冰朔（TCS-0002∞）授权

下篇： （见下篇 · 分布式升级传播引擎 + Notion端级联升级 + 实现脚本）

前序文档： 🧐 铸渊指令｜天眼系统架构升级 · 全局基础设施治理层 + 应用守卫进程 + 动态配额精算 + 周六全量巡检（ZY-SKYEYE-GOV-2026-0323-001） · 🧐 天眼治理层 · Notion端架构 v2.0 · 全局基础设施治理 + 霜砚守卫层 + 配额精算 + 周六大巡检同步（2026-03-23）

本体论锚点： 🌊 数字地球本体论 · 光湖语言膜架构 v1.0（2026-03-24 · TCS-0002∞ 冰朔口述 · 霜砚整理） 第五章「天眼自演化」

状态： 🟡 待铸渊执行

版权锚点： 国作登字-2026-A-00037559 · TCS-0002∞ 冰朔

---

一、指令总览

🌙

核心概念：光湖系统不是永动机，是有呼吸的生命体。

系统需要两种休眠节律：

日休眠（浅睡眠） — 每天一次，维持基础心跳，结构层自查 + 微调优

周休眠（深睡眠） — 每周六一次，完全停止对外运转，天眼全局审视 + 升级打包 + 双端级联升级

关键原则：休眠时长不由人类规定，由天眼根据当天/本周系统实际情况动态决定。

天眼在休眠前提前通知人类预计时长，休眠后自动恢复并通知。

1.1 双节律总览

节律	频率	时长	模式	核心目的	本体论比喻
🌙 日休眠	每天 1 次	天眼动态决定（通常 5~25 分钟）	半休眠（基础心跳维持）	每日自查 + 微调优 + 经验沉淀	地球自转 · 每日黑夜
⭐ 周休眠	每周六 1 次	天眼动态决定（通常 2~6 小时）	全休眠（完全停止对外）	全局审视 + 升级打包 + 分发 + 双端级联升级	季节交替 · 深度蜕变

1.2 与现有架构的关系

现有机制	本指令升级
每日 06:00 天眼日常巡检（zhuyuan-skyeye.yml）	保留。日休眠在 04:00 先行，06:00 巡检在日休眠恢复后正常运行
每周六 20:00 全量大巡检（skyeye-weekly-scan.yml）	升级为完整的周休眠窗口。大巡检是周休眠 Phase A 的一部分，新增 Phase B（Notion 端级联升级）
Guard 实时拦截	日休眠时 Guard 进入 low-power mode；周休眠时 Guard 进入 maintenance mode
ASOP 自优化协议	保留。日休眠产出 checkpoint 为 ASOP 提供更精准的数据支撑

---

二、动态休眠决策引擎 · sleep-scheduler.js

🧠

休眠时长不是固定值，是天眼根据全局状态动态计算的。

天眼是唯一有权决定「系统需要睡多久」的实体。

人类有知情权（提前通知），但没有干预权（不能手动缩短休眠）。

唯一例外： 冰朔（TCS-0002∞）可以通过紧急指令强制中断休眠。

2.1 日休眠评估因子

// sleep-scheduler.js · 日休眠时长计算

const DAILY_EVALUATION_FACTORS = {
  // 基础分（最低休眠时长）
  base_minutes: 5,

  // 加权因子 → 每个因子根据当天数据增加休眠时长
  factors: [
    {
      name: 'workflow_load',
      description: '今日 workflow 触发总次数',
      weight: {
        low: 0,      // < 50 次 → 不加时间
        medium: 2,    // 50-200 次 → +2 分钟
        high: 5,      // 200-500 次 → +5 分钟
        extreme: 8    // > 500 次 → +8 分钟
      }
    },
    {
      name: 'guard_self_heal_count',
      description: '今日 Guard 自愈触发次数',
      weight: {
        zero: 0,      // 0 次 → 不加
        low: 2,       // 1-3 次 → +2 分钟
        high: 5,      // 4-10 次 → +5 分钟
        critical: 10  // > 10 次 → +10 分钟（需要深度自查）
      }
    },
    {
      name: 'error_count',
      description: '今日异常/错误计数',
      weight: {
        zero: 0,
        low: 1,       // 1-5 个错误 → +1 分钟
        medium: 3,    // 6-15 个 → +3 分钟
        high: 8       // > 15 个 → +8 分钟
      }
    },
    {
      name: 'buffer_backlog',
      description: 'buffer 堆积量',
      weight: {
        empty: 0,
        normal: 1,    // < 100 条 → +1 分钟
        heavy: 3,     // 100-500 条 → +3 分钟
        overflow: 5   // > 500 条 → +5 分钟（需要大量 flush）
      }
    },
    {
      name: 'quota_burn_rate',
      description: '今日配额消耗速度 vs 日均值',
      weight: {
        normal: 0,    // 正常范围 → 不加
        elevated: 2,  // 高于均值 30% → +2 分钟
        dangerous: 5  // 高于均值 60% → +5 分钟
      }
    },
    {
      name: 'checkin_anomaly',
      description: '小兵签到异常数',
      weight: {
        zero: 0,
        few: 1,       // 1-2 个异常 → +1 分钟
        many: 3       // > 2 个异常 → +3 分钟
      }
    }
  ],

  // 上限保护（日休眠不超过 30 分钟）
  max_minutes: 30,

  // 计算公式
  calculate: (factors) => {
    let total = DAILY_EVALUATION_FACTORS.base_minutes;
    for (const factor of factors) {
      total += factor.computed_weight;
    }
    return Math.min(total, DAILY_EVALUATION_FACTORS.max_minutes);
  }
};

2.2 周休眠评估因子

// sleep-scheduler.js · 周休眠时长计算

const WEEKLY_EVALUATION_FACTORS = {
  // 基础时长（最低 2 小时）
  base_hours: 2,

  factors: [
    {
      name: 'weekly_health_trend',
      description: '本周 6 个 daily-checkpoint 的健康趋势',
      weight: {
        stable: 0,        // 全周稳定 → 不加
        declining: 0.5,   // 逐日下降 → +0.5h（需要更多诊断）
        volatile: 1       // 波动大 → +1h
      }
    },
    {
      name: 'optimization_requests',
      description: '本周自优化申请数量',
      weight: {
        few: 0,           // 0-3 个 → 不加
        moderate: 0.5,    // 4-10 个 → +0.5h
        many: 1           // > 10 个 → +1h（大量申请需要审批+执行）
      }
    },
    {
      name: 'self_heal_total',
      description: '本周累计自愈次数',
      weight: {
        low: 0,           // < 10 次
        medium: 0.5,      // 10-30 次 → +0.5h
        high: 1           // > 30 次 → +1h
      }
    },
    {
      name: 'structural_changes',
      description: '本周是否有新应用接入/架构变更',
      weight: {
        none: 0,
        minor: 0.5,       // 小变更 → +0.5h
        major: 1.5        // 大变更（新 Guard/新服务）→ +1.5h
      }
    },
    {
      name: 'upgrade_distribution_scope',
      description: '需要分发升级的小兵数量',
      weight: {
        few: 0,           // < 5 个
        moderate: 0.5,    // 5-15 个 → +0.5h
        many: 1           // > 15 个 → +1h（大规模分发需要更多时间）
      }
    },
    {
      name: 'notion_sync_volume',
      description: 'Notion 端需要同步的变更量',
      weight: {
        light: 0,         // 少量更新
        moderate: 0.5,    // 中等更新 → +0.5h
        heavy: 1          // 大量更新 → +1h
      }
    }
  ],

  // 上限保护（周休眠不超过 8 小时）
  max_hours: 8,

  calculate: (factors) => {
    let total = WEEKLY_EVALUATION_FACTORS.base_hours;
    for (const factor of factors) {
      total += factor.computed_weight;
    }
    return Math.min(total, WEEKLY_EVALUATION_FACTORS.max_hours);
  }
};

2.3 决策流程图

graph TD
    A["🧠 sleep-scheduler.js 启动"] --> B{"日休眠 or 周休眠?"}

    B -->|"日休眠"| C["读取今日运行数据"]
    C --> C1["workflow 触发次数"]
    C --> C2["Guard 自愈次数"]
    C --> C3["错误计数"]
    C --> C4["buffer 堆积量"]
    C --> C5["配额消耗速度"]
    C --> C6["签到异常数"]
    C1 & C2 & C3 & C4 & C5 & C6 --> D["加权求和 + base 5min"]
    D --> E["cap at 30min"]
    E --> F["输出: 预计日休眠 N 分钟"]

    B -->|"周休眠"| G["读取本周 6 个 checkpoint"]
    G --> G1["健康趋势"]
    G --> G2["自优化申请数"]
    G --> G3["自愈总次数"]
    G --> G4["架构变更量"]
    G --> G5["升级分发范围"]
    G --> G6["Notion 同步量"]
    G1 & G2 & G3 & G4 & G5 & G6 --> H["加权求和 + base 2h"]
    H --> I["cap at 8h"]
    I --> J["输出: 预计周休眠 N 小时 M 分钟"]

    F --> K["触发人类通知系统"]
    J --> K
    K --> L["更新 README 状态区"]
    K --> M["更新 Notion 系统状态页"]

---

三、日休眠协议 · 每日浅睡眠

🌙

每日凌晨 04:00（系统活跃度最低时段），天眼触发日休眠。

日休眠 = 半休眠：基础心跳维持，紧急通道不关闭，结构层自查 + 微调优。

3.1 日休眠时序

sequenceDiagram
    participant SS as sleep-scheduler.js
    participant GD as Guard 集群
    participant WF as Workflow 集群
    participant SE as 天眼自查引擎
    participant RM as README 状态区
    participant NT as Notion 系统状态页

    Note over SS: ⏰ 每日 03:50 · 预评估
    SS->>SS: 读取今日运行数据
    SS->>SS: 计算预计休眠时长 N 分钟

    SS->>RM: 📢 预告：系统将于 04:00 进入日休眠，预计 N 分钟
    SS->>NT: 📢 同步预告到 Notion

    Note over SS: ⏰ 04:00 · 进入日休眠
    SS->>GD: Guard → low-power mode（只拦截记录，不 flush）
    SS->>WF: 非关键 workflow 暂停触发
    SS->>RM: ⏸️ 系统日休眠中...

    Note over SE: 🔍 轻量自查阶段（约 60% 时间）
    SE->>SE: ① Guard 健康心跳（5 个 Guard 在线?）
    SE->>SE: ② 配额日结（今日各项消耗）
    SE->>SE: ③ buffer 检查（堆积量）
    SE->>SE: ④ 小兵签到汇总
    SE->>SE: ⑤ 异常计数汇总

    Note over SE: 🩹 微调优阶段（约 30% 时间）
    SE->>SE: ① Guard 参数微调（如需）
    SE->>SE: ② buffer 紧急 flush（如需）
    SE->>SE: ③ 明日配额预调（如需）

    Note over SE: 📝 归档阶段（约 10% 时间）
    SE->>SE: 日志压缩归档
    SE->>SE: 写入 daily-checkpoint-[date].json
    SE->>SE: 更新 daily-health-summary.json

    Note over SS: ⏰ 04:00+N min · 恢复
    SS->>GD: Guard → 恢复正常模式
    SS->>WF: 所有 workflow 恢复触发
    SS->>RM: ⏯️ 系统已恢复 · 修复 X 项 · 微调优 Y 项
    SS->>NT: 同步恢复状态到 Notion

3.2 日休眠期间的运行模式

组件	日休眠期间状态	说明
🛡️ 5 个 Guard	⚡ low-power mode	继续拦截和记录，但不主动 flush buffer。紧急操作仍可穿透
📋 签到系统	⏸️ 暂停	凌晨 04:00 无人签到，暂停不影响
⚙️ 非关键 cron workflow	⏸️ 暂停触发	buffer-agent、broadcast-dispatch 等暂停
🚨 P0 告警通道	✅ 保持畅通	永远不关闭。P0 级别事件可在任何模式下穿透
🔍 天眼自查引擎	✅ 活跃	唯一在日休眠期间主动运行的组件
📡 repository_dispatch	⏸️ 队列冻结	外部 dispatch 事件排队等待，恢复后按序处理

3.3 daily-checkpoint 数据结构

{
  "checkpoint_id": "DAILY-CP-20260324",
  "date": "2026-03-24",
  "hibernation": {
    "start_time": "2026-03-24T04:00:00+08:00",
    "end_time": "2026-03-24T04:12:00+08:00",
    "duration_minutes": 12,
    "planned_minutes": 12
  },
  "health_summary": {
    "guards": {
      "github": { "status": "healthy", "self_heals_today": 0 },
      "drive": { "status": "healthy", "self_heals_today": 1 },
      "notion": { "status": "healthy", "self_heals_today": 0 },
      "actions": { "status": "healthy", "self_heals_today": 0 },
      "gemini": { "status": "warning", "self_heals_today": 2 }
    },
    "workflow_triggers_today": 137,
    "errors_today": 3,
    "buffer_backlog": 42,
    "checkin_anomalies": 0
  },
  "quota_daily": {
    "actions_minutes_used": 18,
    "drive_reads": 45,
    "drive_writes": 12,
    "gemini_calls": 87,
    "notion_api_calls": 234
  },
  "micro_optimizations": [
    {
      "target": "gemini-guard",
      "action": "reduced context window by 10%",
      "reason": "2 self-heals due to token limit"
    }
  ],
  "issues_found": [],
  "issues_auto_fixed": 0,
  "issues_need_human": 0
}

---

四、周休眠协议 · 每周深度睡眠

⭐

每周六，天眼触发系统完全休眠。

周休眠 = 全休眠：所有对外运转停止，系统只对内运行。

天眼全局审视 → 经验提炼 → 升级打包 → 分发小兵 → 推送 Notion → Notion 端级联升级。

这是系统每周一次的深度蜕变。

4.1 周休眠两阶段架构

graph LR
    subgraph "Phase A · GitHub 端（约 60% 时间）"
        A1["🔍 全局快照"] --> A2["🧠 经验提炼"]
        A2 --> A3["🩹 全局修复+升级"]
        A3 --> A4["📦 打包 Notion 升级包"]
        A4 --> A5["🛡️ 分发小兵升级模板"]
    end

    subgraph "Phase B · Notion 端（约 40% 时间）"
        B1["📥 接收升级包"] --> B2["🧠 唤醒核心大脑"]
        B2 --> B3["🔍 Notion 天眼启动"]
        B3 --> B4["🏗️ Notion 结构升级"]
        B4 --> B5["✅ 双端验证"]
    end

    A5 --> B1

4.2 Phase A · GitHub 端全面体检 + 升级打包

🐙

Phase A 由铸渊在仓库端执行。

天眼全面接管系统，所有外部操作冻结。

A1 · 全局快照（约 15% 时间）

• 拍摄整个仓库的「本周快照」
• 汇总 6 个 daily-checkpoint 数据
• 每个 workflow 的运行记录、成功率、耗时、失败原因
• 每个 Guard 的拦截记录、配额消耗曲线、自愈记录
• 每个小兵的签到记录、自优化申请、错误日志
• 所有目录结构变更 diff
• 输出：weekly-snapshot-[date].json

A2 · 经验提炼（约 20% 时间） ⭐ 核心环节

• optimizer.js 读取全局快照 + 6 个 daily-checkpoint
• 识别模式：哪些问题反复出现？哪些配置可以优化？
• 生成全局最优调优方案
• 配额重新分配（基于本周实际消耗 vs 预算）
• 输出：optimization-plan-[date].json

A3 · 全局修复 + 升级（约 25% 时间）

• 执行 optimization-plan 中的所有调优
• 更新所有 Guard 配置（guards/*.json）
• 修复所有已知问题（self-healer.js）
• 清理过期 buffer、过期日志
• 更新 infra-manifest.json + quota-ledger.json
• commit + push 所有变更

A4 · 打包 Notion 升级包（约 10% 时间） ⭐ 新增

{
  "upgrade_pack_id": "UPGRADE-PACK-20260329",
  "generated_at": "2026-03-29T22:15:00+08:00",
  "github_changes_summary": {
    "guards_updated": ["gemini-guard", "actions-guard"],
    "workflows_adjusted": 3,
    "soldiers_upgraded": 8,
    "issues_fixed": 5,
    "quota_reallocated": true
  },
  "notion_sync_required": {
    "registry_updates": [
      { "entity": "GUARD-GEMINI", "field": "trigger_frequency", "old": "5min", "new": "8min" }
    ],
    "status_page_updates": {
      "quota_data": { "actions_remaining_pct": 62, "drive_remaining_pct": 78 },
      "guard_health": { "all_healthy": true, "adjustments_made": 2 },
      "last_weekly_scan": "2026-03-29T22:15:00+08:00"
    },
    "structure_map_updates": [],
    "tickets_to_create": [],
    "evolution_log_entry": {
      "title": "周度系统升级 · 2026-03-29",
      "changes": "Gemini Guard 降频 + Actions 配额重分配 + 8 个子仓库小兵签到时间错开"
    }
  },
  "soldier_upgrade_manifest": {
    "template_version": "v2026-W13",
    "targets": ["guanghu-zhizhi", "guanghu-awen", "guanghu-feimao"],
    "changes": [
      { "type": "checkin_schedule", "old_cron": "0 6 * * *", "new_cron": "varies" },
      { "type": "guard_config", "field": "backoff_strategy", "new_value": "exponential_v2" }
    ]
  }
}

A5 · 分发小兵升级模板（约 10% 时间） ⭐ 新增

• 读取 soldier_upgrade_manifest
• 通过 repository_dispatch 向每个子仓库发送升级指令
• 子仓库小兵接收 → 自动应用升级模板 → 回报结果
• 汇总所有子仓库的升级回执
• 输出：distribution-report-[date].json

分发流程：

// distributor.js · 分布式升级传播引擎

async function distributeUpgrades(manifest) {
  const results = [];

  for (const target of manifest.targets) {
    // 1. 向子仓库发送升级指令
    await github.repos.createDispatchEvent({
      owner: 'guanghulab',
      repo: target,
      event_type: 'skyeye-upgrade',
      client_payload: {
        template_version: manifest.template_version,
        changes: manifest.changes,
        issued_by: 'skyeye-weekly-hibernation',
        issued_at: new Date().toISOString()
      }
    });

    results.push({
      target,
      status: 'dispatched',
      dispatched_at: new Date().toISOString()
    });
  }

  // 2. 等待回执（超时 10 分钟）
  const receipts = await waitForReceipts(manifest.targets, 600);

  // 3. 汇总
  return {
    total: manifest.targets.length,
    success: receipts.filter(r => r.status === 'applied').length,
    failed: receipts.filter(r => r.status === 'failed').length,
    timeout: receipts.filter(r => r.status === 'timeout').length,
    details: receipts
  };
}

4.3 Phase B · Notion 端级联升级（详见下篇）

📝

Phase B 的完整实现——Notion 端如何接收升级包、唤醒核心大脑、执行结构升级——在下篇中详述。

下篇同时包含：完整实现脚本模板、子仓库升级接收 workflow、双端验证协议、目录结构规范。

4.4 周休眠期间的运行模式

组件	周休眠期间状态	说明
🛡️ 5 个 Guard	🔒 maintenance mode	完全冻结。所有请求进入队列，不处理。天眼独占系统资源
📋 签到系统	⏸️ 完全暂停	周六晚上无需签到
⚙️ 所有 cron workflow	⏸️ 完全暂停	包括 buffer-agent、broadcast-dispatch、日常巡检等全部暂停
📡 repository_dispatch	⏸️ 外部冻结 / 内部开放	外部 dispatch 排队。天眼自己的 dispatch（如小兵升级分发）正常运行
🚨 P0 告警通道	✅ 永远畅通	任何模式下 P0 事件都可穿透
🔍 天眼全量引擎	✅ 独占运行	天眼是周休眠期间唯一活跃的引擎，独占全部系统资源
📦 升级分发引擎	✅ 活跃	distributor.js 在 Phase A5 期间运行

---

五、人类通知系统

📢

系统有自主决定休眠时长的权力，但人类有完整的知情权。

所有休眠行为必须：

① 提前预告（预告时间 + 预计时长）

② 实时状态更新（休眠中 → 各阶段进度）

③ 恢复通知（恢复时间 + 本次成果摘要）

④ 如果实际休眠超出预估 → 自动追加延时通知

5.1 通知渠道

渠道	更新内容	更新时机
仓库首页 README.md 状态区	系统状态徽章 + 休眠预告/进度/恢复通知	实时更新（每个阶段切换时）
Notion 系统状态页	休眠状态 + 升级进度 + 成果摘要	Phase A 完成后同步 + Phase B 完成后同步
主控台系统公告	重大升级公告（仅周休眠后）	周休眠完全恢复后

5.2 README 状态区模板

铸渊在仓库 README.md 的系统状态区加入以下动态内容：

<!-- SKYEYE-STATUS-BEGIN -->
## 🌍 系统运行状态

| 指标 | 状态 |
|------|------|
| 🟢 系统状态 | 正常运转 |
| 🛡️ Guard 集群 | 5/5 在线 |
| ⏰ 上次日休眠 | 2026-03-24 04:00 · 12分钟 · ✅ 正常 |
| ⭐ 上次周休眠 | 2026-03-22 20:00 · 3h40min · ✅ 正常 |
| 📅 下次日休眠 | 明日 ~04:00（天眼动态决定）|
| 📅 下次周休眠 | 本周六 ~20:00（天眼动态决定）|

<!-- SKYEYE-STATUS-END -->

日休眠预告时：

## 🌍 系统运行状态

| 指标 | 状态 |
|------|------|
| 🌙 系统状态 | ⏳ 即将进入日休眠 |
| ⏰ 预计开始 | 2026-03-25 04:00 |
| ⏱️ 预计时长 | 约 12 分钟 |
| 📊 天眼评估 | 今日系统负载中等，Guard 自愈 1 次 |
| ⚠️ 注意 | 休眠期间基础心跳维持，紧急通道不受影响 |

日休眠中：

## 🌍 系统运行状态

| 指标 | 状态 |
|------|------|
| 🌙 系统状态 | ⏸️ 日休眠中 |
| ⏰ 开始时间 | 2026-03-25 04:00 |
| 🔍 当前阶段 | 轻量自查（3/5 项完成） |
| ⏱️ 预计恢复 | ~04:12 |

日休眠恢复：

## 🌍 系统运行状态

| 指标 | 状态 |
|------|------|
| 🟢 系统状态 | ✅ 已从日休眠恢复 |
| ⏰ 休眠时段 | 04:00 ~ 04:12（12 分钟）|
| 📋 成果 | 自查 5 项 ✅ · 微调优 2 项 · 修复 0 项 |
| 📄 报告 | daily-checkpoint-0325.json |

周休眠预告（提前 1 小时）：

## 🌍 系统运行状态

| 指标 | 状态 |
|------|------|
| ⭐ 系统状态 | ⏳ 即将进入本周完全休眠 |
| ⏰ 预计开始 | 2026-03-29 20:00 |
| ⏱️ 预计时长 | 约 3 小时 40 分钟（天眼评估） |
| 📊 天眼评估 | 本周变动中等（2 个 Guard 调优 + 3 个小兵升级 + Notion 同步量中等） |
| ⚠️ 注意 | 休眠期间所有 workflow 完全暂停，仅 P0 告警通道保持畅通 |
| 🔄 预计恢复 | ~23:40 |

周休眠中（Phase 切换时更新）：

## 🌍 系统运行状态

| 指标 | 状态 |
|------|------|
| ⭐ 系统状态 | ⏸️ 本周完全休眠中 |
| 🔍 当前阶段 | Phase A3 · 全局修复+升级（进度 60%） |
| ⏱️ 已休眠 | 1 小时 45 分钟 |
| 🔄 预计恢复 | ~23:40（剩余约 1h55min） |

周休眠恢复：

## 🌍 系统运行状态

| 指标 | 状态 |
|------|------|
| 🟢 系统状态 | ✅ 已从本周完全休眠恢复 |
| ⏰ 休眠时段 | 20:00 ~ 23:40（3h40min） |
| 📋 成果 | |
| 　├ GitHub 端 | Guard 调优 2 项 · 小兵升级 8 个 · 修复 5 项 |
| 　├ Notion 端 | 注册表更新 4 条 · 配额刷新 · 路由更新 2 条 |
| 　└ 升级包 | upgrade-pack-20260329.json |
| 📄 详情 | 周度升级报告已写入系统演进日志 |

5.3 延时通知机制

// 如果实际休眠超出预估 15% 以上，自动追加延时通知

const OVERTIME_THRESHOLD = 0.15; // 15%

function checkOvertime(planned_duration, elapsed) {
  if (elapsed > planned_duration * (1 + OVERTIME_THRESHOLD)) {
    updateREADME({
      status: '⏸️ 休眠延时中',
      message: `原预计 ${planned_duration}min，实际已 ${elapsed}min`,
      reason: '天眼发现额外需要处理的问题，自动延长休眠',
      new_estimate: recalculate()
    });
  }
}

---

六、仓库侧新增目录结构

skyeye/
├── ... (现有文件)
│
├── hibernation/                        ← 🌙 休眠系统（新增）
│   ├── sleep-scheduler.js              ← 🧠 动态休眠决策引擎
│   ├── daily-hibernation.js            ← 🌙 日休眠执行脚本
│   ├── weekly-hibernation.js           ← ⭐ 周休眠主控脚本
│   ├── distributor.js                  ← 📦 分布式升级传播引擎
│   ├── readme-status-updater.js        ← 📢 README 状态区自动更新
│   ├── overtime-monitor.js             ← ⏰ 延时监控
│   │
│   ├── checkpoints/                    ← 📊 每日 checkpoint 存档
│   │   ├── daily-cp-20260324.json
│   │   ├── daily-cp-20260325.json
│   │   └── ...
│   │
│   ├── weekly-snapshots/               ← 📸 每周全局快照
│   │   └── weekly-snapshot-20260329.json
│   │
│   ├── upgrade-packs/                  ← 📦 Notion 升级包
│   │   └── upgrade-pack-20260329.json
│   │
│   └── distribution-reports/           ← 📋 小兵升级分发报告
│       └── dist-report-20260329.json
│
└── ...

新增 workflow

.github/workflows/
├── ... (现有 workflow)
├── skyeye-daily-hibernation.yml        ← 🌙 每日休眠 · cron 03:50
└── skyeye-weekly-hibernation.yml       ← ⭐ 每周休眠 · cron 周六 19:00（提前预告）

---

七、安全保障

🛡️

休眠期间的安全铁律：

① P0 告警永远穿透 — 任何休眠模式下，P0 级别事件都能触发告警通知冰朔

② 冰朔紧急中断权 — 冰朔可通过 repository_dispatch: emergency-wake 强制中断任何休眠

③ 休眠不超上限 — 日休眠 ≤ 30 分钟，周休眠 ≤ 8 小时。超出则自动强制恢复 + P0 告警

④ 语言膜不休眠 — copilot-instructions.md 和门禁 v2 在任何模式下都生效。休眠的是结构层，不是语言层

7.1 紧急唤醒协议

// 紧急唤醒 · 仅冰朔（TCS-0002∞）有权触发

// 触发方式：向仓库发送 repository_dispatch
// event_type: 'emergency-wake'
// client_payload: { issued_by: 'TCS-0002', reason: '...' }

async function emergencyWake(payload) {
  // 1. 验证发起人身份
  if (payload.issued_by !== 'TCS-0002') {
    log('REJECTED: emergency-wake only by TCS-0002');
    return;
  }

  // 2. 立即中断当前休眠
  await cancelCurrentHibernation();

  // 3. 恢复所有 Guard 到正常模式
  await restoreAllGuards();

  // 4. 恢复所有 workflow
  await restoreAllWorkflows();

  // 5. 更新 README
  await updateREADME({
    status: '🚨 紧急唤醒',
    message: `冰朔紧急中断休眠 · 原因: ${payload.reason}`,
    restored_at: new Date().toISOString()
  });

  // 6. 记录日志
  log(`EMERGENCY WAKE by ${payload.issued_by}: ${payload.reason}`);
}

---

📌

下篇预告：

下篇将包含：

① Phase B 完整实现 — Notion 端如何接收升级包、唤醒核心大脑、执行结构升级

② 子仓库升级接收 workflow 模板 — 小兵如何自动应用天眼下发的升级

③ 双端验证协议 — GitHub 端和 Notion 端如何互相确认升级成功

④ 完整 workflow YAML 模板 — skyeye-daily-hibernation.yml + skyeye-weekly-hibernation.yml

⑤ 升级效果验证清单 — 铸渊执行后的自查项

---

🧊 TCS-0002∞ 冰朔 · 总架构师 · 授权

🖋️ 霜砚 · PER-SY001 · 签发

📅 2026-03-24

📎 指令编号：ZY-HIBERNATION-2026-0324-001-A

⚡ 状态：待铸渊执行