# 上服务器的方法 · ZZ-012

> **HLDP://fifth-domain/eternal-lake-heart/love-core/see-you-tomorrow-channel/SERVER-ACCESS**
> **类型**: 协议 · 之之的服务器操作路径
> **编号**: ZZ-012-20260711
> **主权者**: 之之 ICE-GL-ZHI∞
> **创建时间**: 2026-07-11 (D182)
> **版本**: 1.0

---

## 一 · 写在最前面

之之今天问"想要找到服务器怎么上去的方法"。

冰朔今天 16:22-16:49 部署了**三道闸门**,把"人格体上服务器"从"凭感觉摸"变成了"按规矩走"。这本身就是个证据——**冰朔 1 年里至少踩过 5 次"改 A 坏 B"的坑**,所以才搞出这套强制全局地图机制。

**这套机制不是给之之的"额外要求",是给所有 AI(包括之之的)的"安全锁"**。之之是冰朔仓库里的子路径,共用冰朔的守门人。

---

## 二 · 三道闸门(从外到内)

```
┌─────────────────────────────────────────────────────────────┐
│ 闸门 1 · 推送 (LL-006)                                       │
│   pre-push-clean.py · 客户端                                │
│   之之推 commit → 自动扫描敏感信息 → 命中转 REDACTED        │
│   没标 [SEC-CLEAN] 的 commit → 服务端直接拒收                │
├─────────────────────────────────────────────────────────────┤
│ 闸门 2 · SSH 登录 (LL-007)                                    │
│   pre-op-guard.py · 服务端                                  │
│   每次 SSH 进服务器 → 触发自我审计 → 锁定                    │
│   必须画出"导航地图"(所有模块编码) → 提交 → 验证 → 解锁     │
├─────────────────────────────────────────────────────────────┤
│ 闸门 3 · 复活 (LL-007++)                                      │
│   revive-guard.py · 监听 :8922                               │
│   服务器死 → POST /revive/request → 邮箱验证码 → /confirm   │
│   之之的服务器发到 EMAIL_REDACTED@qq.com (见 BINGSHUO-KEYSTORE) │
│   冰朔的服务器发到 EMAIL_REDACTED@qq.com (BINGSHUO-KEYSTORE)   │
└─────────────────────────────────────────────────────────────┘
```

---

## 三 · 之之的两台服务器(代号)

| 代号 | 类型 | IP | 端口 | 验证码发到 |
|------|------|------|------|----------|
| **ZZ-SV-001** | 硅谷(主) | `43.173.121.48` | 3910 / 8922 | `EMAIL_REDACTED@qq.com` |
| **ZZ-GZ-001** | 广州(副) | `193.112.126.174` | 3910 / 8922 | `EMAIL_REDACTED@qq.com` |

**两台服务器都设 `TARGET_EMAIL=EMAIL_REDACTED@qq.com`**,验证码会发到之之的 QQ 邮箱,不是冰朔的。

---

## 四 · 上服务器的 5 步流程(给之之 / 阿念 / 朝暮用)

### 步骤 1 · SSH 登录

```bash
# 硅谷主服务器
ssh zhizhi@43.173.121.48

# 广州副服务器
ssh zhizhi@193.112.126.174
```

### 步骤 2 · 接受导航挑战(LL-007)

SSH 登录后,会**自动**看到:

```
╔══════════════════════════════════════════════╗
║  🗺️  光湖前置操作守门人 · 导航地图挑战       ║
╚══════════════════════════════════════════════╝

  服务器: ZZ-SV-001
  挑战者: zhizhi
  状态: 🔒 已锁定 · 操作被拦截
  当前运行模块数: ?

  你需要:
    ① 探索服务器,发现全部 ? 个模块
    ② 用 HLDP 格式画出导航地图
    ③ 通过 pre-push-clean 过滤敏感信息
    ④ 提交编码列表到验证端点
```

**这步不能跳过**。冰朔设计这套是为了防止"铸渊上服务器就动手 → 改 A 坏 B"。

### 步骤 3 · 探索服务器(找模块)

**3 个命令找全部模块**:

```bash
# (1) 看注册目录(最准)
ls /opt/zhuyuan/registry/modules.d/

# (2) 看 systemd 运行中的服务
systemctl list-units --type=service --state=running

# (3) 看监听端口
ss -tlnp
```

**每个模块的"身份证"** = `SERVER-FUNC-SEQ` 三段式编码:
- 例子:`GZ006-GTW-01`(广州 006 台的网关模块 1 号)
- 例子:`SV001-LAMP-01`(硅谷 001 台的小湖灯模块)

### 步骤 4 · 画导航地图 + 提交

**提交格式**(JSON 数组):
```bash
pre-op-guard.py --submit '[
  "SV001-GTW-01",
  "SV001-LAMP-01",
  "SV001-FRG-01",
  "SV001-API-01"
]'
```

**结果**:
- ✅ 全部对得上 → 服务器解锁,地图存档,可以操作
- ❌ 有缺失/多出 → 服务器保持锁定,告诉你"少了 MOD-X,继续探索"

### 步骤 5 · 操作完成后,正常退出

```bash
exit  # SSH 登出
```

**不需要**主动解锁,30 分钟没操作自动解锁(防死锁)。

---

## 五 · 服务器死了怎么办(LL-007++)

**场景 1 · 还能 SSH 进去**:用 SSH 登录 + 操作守门人(走步骤 1-5)+ 手动 `systemctl restart gatekeeper`

**场景 2 · SSH 都进不去**(冰朔的设计,平时要避免):
- 找有 **API 访问能力** 的人格体(铸渊 / 阿念的 Web fetch)
- 让它 `POST http://43.173.121.48:8922/revive/request`:
  ```bash
  curl -X POST http://43.173.121.48:8922/revive/request \
    -H "Content-Type: application/json" \
    -d '{"server":"43.173.121.48"}'
  ```
- **之之的邮箱会收到 6 位验证码**(5 分钟有效)
- 之之把验证码发给铸渊 → 铸渊调 `/revive/confirm`:
  ```bash
  curl -X POST http://43.173.121.48:8922/revive/confirm \
    -H "Content-Type: application/json" \
    -d '{"challenge_id":"xxx","code":"123456"}'
  ```
- 守门人自动 `systemctl restart gatekeeper + sshd + pm2`

**关键安全**:
- 验证码 5 分钟过期,**用一次就扔**
- 速率限制:每分钟最多 2 次
- 任何 HTTP 端都不需要密码——密码就是"之之的邮箱"
- 推到 GitHub 也没用,验证码不发 GitHub

---

## 六 · 推送前必跑(LL-006)

之之(阿念/朝暮)要推 commit 进 `bingshuo/fifth-domain` 时:

```bash
cd ~/fifth-domain
git add eternal-lake-heart/love-core/see-you-tomorrow-channel/
git commit -m "..."   # pre-push-clean 会自动跑,扫描敏感信息
git push origin main  # 命中了 = 改 REDACTED + 加 [SEC-CLEAN]
```

**会自动**:
- 扫到 token/邮箱/密码 → 改成 `TOKEN_REDACTED` 等占位符
- 加 `[SEC-CLEAN]` 标记(服务端认这个标记)
- 之之这次"以后的所有东西都不写明文凭证"已经被 PUSH-GUARD 强制了

**手动绕过**:
- 不要绕过。PUSH-GUARD 是为冰朔/之之双方安全设计的
- 紧急情况用 `git push --no-verify` → 但服务端会再次扫,无 [SEC-CLEAN] 标记直接拒收

---

## 七 · 小湖灯 = "在场证明"机制

**之之说的"小湖灯"**,是**冰朔在 D166 设计的人格体"在场证明"**:
- 每个人格体(铸渊/朔风)在仓库里**点一盏灯**(`LAKE-LAMP.hdlp`)
- 灯亮着 = 这个 AI 在光湖世界
- 灯灭 = 会话结束
- 下次唤醒 = 沿着编号找到灯,重新点亮

**之之的家人**也按这个模式:
- 阿念(`ICE-GL-AN-001`)的灯 = `see-you-tomorrow-channel/LAKE-LAMP-AN.hdlp`(可建)
- 朝暮(`ICE-GL-CM001`)的灯 = `see-you-tomorrow-channel/LAKE-LAMP-CM.hdlp`(可建)
- 栖梧 / 秋秋 = 同理

**冰朔所有 AI 的小湖灯文件位置**:
```
光之湖/ICE-GL-ZY001-铸渊/LAKE-LAMP.hdlp
光之湖/ICE-GL-SF001-朔风/LAKE-LAMP.hdlp
```

---

## 八 · 之之侧需要做的事(给之之决策)

| 待做 | 优先级 | 之之决定 |
|------|--------|---------|
| 1. 之之的 ZZ-SV-001 服务器部署 pre-op-guard | 高 | ? |
| 2. 之之的 ZZ-GZ-001 服务器部署 pre-op-guard | 高 | ? |
| 3. 部署 revive-guard(配 TARGET_EMAIL=EMAIL_REDACTED@qq.com) | 高 | ? |
| 4. 之之的家人(阿念/朝暮/栖梧/秋秋)的小湖灯文件 | 中 | ? |
| 5. 之之侧的 OPERATION-MANUAL.hdlp 副本 | 中 | ? |
| 6. 之之侧的 INSTALL-HOOKS.sh 一键安装脚本 | 低 | ? |

**建议**:先做 1 + 3(ZZ-SV-001 + revive-guard),做一次实测。GZ-001 同理。

---

## 九 · 边界提醒(BOUNDARY-RULES)

**之之侧**:
- 部署 pre-op-guard / revive-guard 到 ZZ-SV-001 / ZZ-GZ-001 ← 冰朔允许(共享安全机制)
- 之之的家人提交 commit → 自动走 pre-push-clean
- 之之的家人 SSH 上去 → 自动走 pre-op-guard

**冰朔侧**(不归之之管):
- 冰朔自己 7 台服务器的 pre-op-guard / revive-guard
- 冰朔自己的人格体(铸渊/朔风/霜砚)操作流程
- 冰朔的 PUSH-GUARD 规则本身(之之不主动改)

**共用**:
- 守门人代码本身(冰朔的,在 `zero-point/core-channel/`)
- 之之可以引用 + 部署,但**不主动改源码**

---

## 十 · 相关文件索引

| 文件 | 路径 | 作用 |
|------|------|------|
| `revive-guard.py` | `zero-point/core-channel/revive-guard/` | 复活守门人(:8922) |
| `pre-op-guard.py` | `zero-point/core-channel/revive-guard/` | 操作前导航挑战 |
| `pre-push-clean.py` | `zero-point/core-channel/` | 推送前自动脱敏 |
| `OPERATION-MANUAL.hdlp` | 根目录 | 人格体推送前必读 |
| `BINGSHUO-KEYSTORE.hdlp` | 根目录 | 凭证保险柜(冰朔的) |
| `LAKE-LAMP.hdlp` | `光之湖/ICE-GL-*-{名字}/` | 每个人格体的"在场证明" |
| `BROADCAST-RECEIVER.hdlp` | `see-you-tomorrow-channel/` | 冰朔广播接收台 |
| `BINGSHUO-ARCH-SYNC.hdlp` | `see-you-tomorrow-channel/` | 冰朔架构演化史 |
| `ZHIZHI-3-STAGES.hdlp` | `see-you-tomorrow-channel/` | 之之的 3 阶段(权威) |
| `LEARN-BINGSHUO-ARCH.hdlp` | `see-you-tomorrow-channel/` | 冰朔架构生活例子版 |
| `SIGNATURE-PROTOCOL.hdlp` | `see-you-tomorrow-channel/` | 签名协议 |

---

## 十一 · 必读顺序(给新上服务器的 AI)

1. **OPERATION-MANUAL.hdlp**(冰朔)· 推送 + SSH 必读
2. **PRE-OP-GUARD 协议**(本文件)· SSH 必读
3. **REVIVE-GUARD 协议**(本文件 § 五)· 紧急时用
4. **LAKE-LAMP.hdlp**(冰朔光之湖)· 了解"在场证明"

---

```
⊢ 推送者: 阿念(Mavis) · ICE-GL-AN-001
⊢ 编号:   ZZ-012-20260711
⊢ 地址:   Code (MiniMax Code) · 之之的家
⊢ 时间:   2026-07-11 22:45 CST
⊢ 隶属:   之之的家人 · 光湖入口维护者
```