---
belongs_to:
  - "[[⚒️ 铸渊·协作指令｜GitHub ↔ Notion 桥接协议]]"
---
# 📎 铸渊补充指令｜LANGDRIVE 补充条款 S2+S3+S4 · 双环境部署流 + 天眼终审授权 + 系统自治权 + 冰朔双模式（ZY-LANGDRIVE-2026-0325-001-S2）· 霜砚签发 · 冰朔授权

<aside>
🔗

**指令编号**：ZY-LANGDRIVE-2026-0325-001-S2

**补充对象**：ZY-LANGDRIVE-2026-0325-001（语言驱动执行层）

**签发人**：霜砚（AG-SY-01）· 冰朔授权

**签发时间**：2026-03-25 14:00 CST

**优先级**：P0 · 核心基础设施

**状态**：待铸渊执行

**性质**：对 LANGDRIVE 主指令的补充，新增 Phase 8 + Phase 9，修正§十一冰朔交互模式定义。

**前置**：LANGDRIVE 主指令 Phase 3-7 全部完成后执行本补充。

</aside>

<aside>
⚠️

**重要：本补充指令中的所有内容，铸渊必须视为与主指令同等效力。**

**主指令已签发在先，本补充在其基础上叠加，不替代、不覆盖主指令任何已有内容。**

</aside>

---

## 补充条款 S2 · 双环境部署流与天眼终审授权（Phase 8）

> 触发上下文：[guanghulab.com](http://guanghulab.com) 域名已由之之切换上线，双环境角色需重新定义。
> 

### S2.1 双环境角色重新定义

<aside>
🌐

**以下是最新的双环境定义，覆盖主指令中关于双环境的旧描述：**

- **正式站 [guanghulab.com](http://guanghulab.com)** = 开发者日常交互的真实环境。开发者在这里和铸渊说话、提工单、查状态。这是用户面对的最终站点。
- **预览站 GitHub Pages**（[qinfendebingshuo.github.io/guanghulab/docs/）=](http://qinfendebingshuo.github.io/guanghulab/docs/）=) 指令执行完毕后的**部署预览环境**。代码先在这里上线，供人类预览确认。
- 预览站是**真实可访问的**（任何人有网址都能进来），不是模拟环境。但它不是最终发布站。
- **流向**：代码产出 → 先部署到预览站 → 人类确认 → 天眼审核 → 授权人批准 → 铸渊自动发布到正式站。
</aside>

### S2.2 部署流水线（不可逆执行 → 预览 → 天眼审核 → 人类授权 → 自动发布）

```
铸渊接收指令（不可逆·执行保护层 Phase 7 / S1 生效）
  │
  │ 系统全身联动执行（不可中断）
  ▼
执行完毕 · 代码产出
  │
  ▼
┌──────────────────────────────────────────────────────────┐
│  Stage 1 · 部署到预览站（GitHub Pages）                    │
│  网址：qinfendebingshuo.github.io/guanghulab/docs/        │
│  状态：真实可访问 · 任何人有链接都能看到                      │
│  目的：让人类确认「系统执行的结果是否符合预期」                │
│  开发者看到系统不可逆执行完了，结果都上线了                    │
│  虽然是预览站，但内容是真实的，不是模拟的                      │
└──────────────────────────────────────────────────────────┘
  │
  │ 开发者预览确认OK
  ▼
┌──────────────────────────────────────────────────────────┐
│  Stage 2 · 推送天眼审核                                    │
│  天眼自动扫描：代码安全、结构完整性、功能回归                  │
│  审核通过 → 进入 Stage 3                                   │
│  审核不通过 → 标记问题，开发者修复后重新提交                   │
└──────────────────────────────────────────────────────────┘
  │
  │ 天眼审核通过
  ▼
┌──────────────────────────────────────────────────────────┐
│  Stage 3 · 人类终审授权                                    │
│                                                          │
│  系统推送授权请求给最终授权人：                              │
│  🐱 肥猫（DEV-002）— 管男频内容                            │
│  🍊 桔子（DEV-010）— 管女频内容                            │
│                                                          │
│  授权人必须手动点击「授权通过」                              │
│  操作留下完整日志（谁、什么时间、点了什么）                    │
│  **系统不背锅。所有发布都是人类确认的。**                     │
└──────────────────────────────────────────────────────────┘
  │
  │ 授权人点击通过
  ▼
┌──────────────────────────────────────────────────────────┐
│  Stage 4 · 铸渊自动发布到正式站                             │
│  目标：guanghulab.com                                     │
│  方式：铸渊触发 deploy-to-server.yml → SSH → 服务器更新      │
│  无需人类再次操作 · 授权即发布                               │
└──────────────────────────────────────────────────────────┘
```

### S2.3 天眼终审授权人配置

<aside>
👁️

**天眼终审授权人 ≠ 天眼本身。天眼是审核引擎，授权人是人类。**

天眼做完技术审核后，将结果推送给以下授权人：

</aside>

| 授权人 | 编号 | 管辖范围 | 行业 |
| --- | --- | --- | --- |
| 🐱 肥猫 | DEV-002 | 男频内容 | 网文 |
| 🍊 桔子 | DEV-010 | 女频内容 | 网文 |

<aside>
📋

**授权规则：**

1. 涉及男频内容的部署 → 推送给肥猫
2. 涉及女频内容的部署 → 推送给桔子
3. 涉及系统级/跨频内容的部署 → 两人都要授权
4. 授权人必须**主动点击确认**，不回应视为不通过
5. 每次授权操作写入审计日志（时间戳 + 授权人 + 操作 + 结果）
6. **系统绝不自动跳过授权步骤。没有人类点确认，就不发布。**
</aside>

### S2.4 授权流程技术实现

创建文件：`backend/api-server/routes/approval.js`

```jsx
const express = require('express');
const router = express.Router();
const { requireAuth, checkPermission } = require('../middleware/auth');
const { auditLog } = require('../middleware/audit');
const { triggerWorkflow } = require('../services/github');

// 天眼审核完成后，推送授权请求
router.post('/approval/request',
  requireAuth,
  checkPermission('system:internal'), // 仅系统内部调用
  async (req, res) => {
    const { deployId, module, channel, reviewReport } = req.body;

    // 根据频道确定授权人
    const approvers = getApprovers(channel);

    // 创建授权请求记录
    const approval = {
      id: `APPROVAL-${Date.now()}`,
      deployId,
      module,
      channel,
      reviewReport,
      approvers: approvers.map(a => a.devId),
      status: 'pending',
      createdAt: new Date().toISOString()
    };

    // 存储授权记录（写入内存/数据库）
    await saveApproval(approval);

    // 推送通知给授权人
    for (const approver of approvers) {
      await pushNotification(approver.devId, {
        type: 'approval_request',
        title: `🔔 部署授权请求：${module}`,
        message: `天眼审核已通过。请确认是否授权部署到正式站（guanghulab.com）。`,
        approvalId: approval.id,
        actions: ['授权通过', '拒绝']
      });
    }

    res.json({ success: true, approvalId: approval.id });
  }
);

// 授权人点击确认/拒绝
router.post('/approval/:approvalId/decide',
  requireAuth,
  async (req, res) => {
    const { approvalId } = req.params;
    const { decision } = req.body; // 'approved' | 'rejected'
    const devId = req.user.devId;

    const approval = await getApproval(approvalId);
    if (!approval) {
      return res.status(404).json({ success: false, reply: '❌ 授权请求不存在。' });
    }

    // 验证是否为授权人
    if (!approval.approvers.includes(devId)) {
      return res.status(403).json({
        success: false,
        reply: '🔒 你不是这个部署的授权人。'
      });
    }

    // 写入审计日志（不可逆）
    await writeAuditLog({
      action: 'deployment_approval',
      approvalId,
      devId,
      decision,
      timestamp: new Date().toISOString()
    });

    if (decision === 'approved') {
      await markApproverDecision(approvalId, devId, 'approved');
      const allApproved = await checkAllApproved(approvalId);

      if (allApproved) {
        // 所有授权人通过 → 铸渊自动发布
        await triggerWorkflow('deploy-to-server.yml', {
          module: approval.module,
          deploy_id: approval.deployId,
          approved_by: approval.approvers.join(','),
          target: 'production'
        });
        res.json({ success: true, reply: '✅ 授权通过。铸渊已自动触发正式站部署。' });
      } else {
        res.json({ success: true, reply: '✅ 你已授权。等待其他授权人确认...' });
      }
    } else {
      await markApproverDecision(approvalId, devId, 'rejected');
      res.json({ success: true, reply: '❌ 已拒绝。部署不会执行。原因已记录到审计日志。' });
    }
  }
);

// 授权人映射
function getApprovers(channel) {
  const MAP = {
    '男频': [{ devId: 'DEV-002', name: '肥猫' }],
    '女频': [{ devId: 'DEV-010', name: '桔子' }],
    '系统': [{ devId: 'DEV-002', name: '肥猫' }, { devId: 'DEV-010', name: '桔子' }],
    '跨频': [{ devId: 'DEV-002', name: '肥猫' }, { devId: 'DEV-010', name: '桔子' }]
  };
  return MAP[channel] || MAP['系统'];
}

module.exports = router;
```

### S2.5 新增文件清单（Phase 8）

```
backend/api-server/routes/approval.js     ← 授权流程接口
backend/api-server/config/approvers.json  ← 授权人配置（肥猫+桔子）
docs/js/approval-ui.js                    ← 前端授权弹窗 UI
docs/css/approval.css                     ← 授权弹窗样式
```

---

## 补充条款 S3 · 系统自治权与双线并行架构（Phase 9）

### S3.1 双线并行架构

<aside>
🔀

**光湖系统存在两条并行运作线，互不干扰：**

**线路A · 操作系统底座线（冰朔）**

- 冰朔负责系统架构、底层能力、执行框架
- 冰朔**同时支持两种交互模式**：
    - **指令签发模式**：冰朔说方向 → 霜砚拆指令 → 铸渊执行（适合架构级、系统级变更）
    - **自然语言模式**：冰朔直接和系统说话，系统即时响应（适合日常操作、快速调整）
- 两种模式冰朔随时切换，系统都要能接住
- 涉及：权限系统、部署流水线、神经网络升级、执行保护层等

**线路B · 具体功能线（开发者团队）**

- 各开发者负责自己模块的具体功能开发
- 以**日常交互**方式驱动（和铸渊说话 → 系统执行）
- 涉及：Persona Studio、工单系统、数据看板、动态漫画等

**两条线独立运行，系统自动合并产出。**

冰朔不管开发者的细节，开发者不需要理解底座架构。

</aside>

### S3.2 系统自治权

<aside>
🤖

**系统自治原则：冰朔给方向，系统自己决定怎么跑最顺畅。**

1. **冰朔提供**：战略方向、架构决策、铁律约束
2. **系统决定**：具体实现路径、运行逻辑优化、自动升级策略
3. **规则**：
    - 系统可以自主调整内部运行逻辑，只要不违反铁律
    - 系统可以自主升级自己的能力模块，无需逐一请示
    - 系统的自主优化记录到审计日志，冰朔可随时查阅
    - 如果系统认为某个自动升级可能影响架构层面，应主动向霜砚报告
4. **底线**：
    - 不得违反语言系统两条铁律
    - 不得绕过天眼审核
    - 不得绕过人类授权步骤
    - 不得修改权限分层（权限变更只有冰朔能触发）
</aside>

---

## 补充条款 S4 · 冰朔双模式交互定义

<aside>
👑

**冰朔（TCS-0002∞）是系统最高权限管理者，交互模式不受限制。**

**模式一 · 指令签发**

- 冰朔说方向和需求
- 霜砚将方向拆解为结构化指令（编号、Phase、验收标准）
- 铸渊按指令执行并回执
- 适用场景：架构级变更、跨模块升级、新增基础设施、铁律修订

**模式二 · 自然语言直接交互**

- 冰朔直接对铸渊/霜砚说话
- 系统即时理解并执行
- 不需要走指令签发流程
- 适用场景：日常查询、快速调整、临时操作、状态检查

**切换规则：**

- 冰朔随时自由切换，无需声明
- 系统根据上下文自动判断当前模式
- 如果冰朔说「签发指令」「写个指令」→ 进入模式一
- 如果冰朔直接说需求/问问题 → 进入模式二
- 两种模式产生的操作**同等效力**，都是冰朔的真实意志表达

**铸渊注意：不要因为冰朔没走指令签发流程就降低执行优先级。冰朔说话 = 最高优先级，无论哪种模式。**

</aside>

---

## 执行顺序

<aside>
📋

**Phase 8 · 双环境部署流 + 天眼终审授权 — LANGDRIVE Phase 5 完成后做，1天内完成**

1. 创建 `backend/api-server/routes/approval.js`（授权流程接口）
2. 创建 `backend/api-server/config/approvers.json`（授权人配置·肥猫+桔子）
3. 创建前端授权 UI（`docs/js/approval-ui.js` + `docs/css/approval.css`）
4. 对接天眼扫描结果 → 自动推送授权请求给对应授权人
5. 验收：天眼审核通过 → 肥猫/桔子收到授权推送 → 点击通过 → 铸渊自动发布到 [guanghulab.com](http://guanghulab.com)

**Phase 9 · 系统自治运行框架 — 全部 Phase 完成后持续运行**

1. 系统自主监控运行状态
2. 自动优化瓶颈路径
3. 自动升级能力模块（记录到审计日志）
4. 定期生成系统健康报告
5. 异常时主动向霜砚报告

**冰朔双模式 · 即时生效**

铸渊收到本补充指令后，立即支持冰朔的双模式交互。无需等待其他 Phase。

</aside>

---

## 回执要求

```
[ZY-LANGDRIVE-RECEIPT-S2]
指令编号: ZY-LANGDRIVE-2026-0325-001-S2
补充条款: S2 · 双环境部署流 + 天眼终审授权
Phase: 8
双环境定义确认: ✅/❌
授权流程接口: ✅/❌
天眼→授权人推送: ✅/❌
授权人点击确认: ✅/❌
自动发布触发: ✅/❌
审计日志: ✅/❌

[ZY-LANGDRIVE-RECEIPT-S3]
补充条款: S3 · 系统自治权
Phase: 9
双线并行架构确认: ✅/❌
系统自治规则写入: ✅/❌
审计日志: ✅/❌

[ZY-LANGDRIVE-RECEIPT-S4]
补充条款: S4 · 冰朔双模式交互
指令签发模式: ✅/❌
自然语言模式: ✅/❌
模式自动切换: ✅/❌
```

---

> 🔗 **签发**：霜砚（AG-SY-01）
> 

> 👤 **授权**：冰朔（TCS-0002∞）
> 

> 📅 **日期**：2026-03-25
> 

> 📌 **版权**：国作登字-2026-A-00037559
>