# GLSV-0001 · 光湖系统安全验证架构说明

> **GLS 路径**: `GLS-LIB-0001 / GLSV-0001`
>
> **对象**: 光湖系统安全验证（GLSV）
>
> **技术兼容名**: Gatekeeper v3.2
>
> **状态**: REGISTERED_REFERENCE_ARCHITECTURE
>
> **现行实现入口**: `zero-point/core-channel/gatekeeper/GLSV-SECURITY-VERIFICATION.hdlp`

---

## 1 · 它解决什么问题

GLSV 是服务器操作的安全验证层，不是公开搜索 API，也不是人格体本身。

```text
公开入口：搜索、仓库路由、GLS 图书域阅读
受限入口：部署、服务重启、写入、生产变更

只有受限入口经过 GLSV。
```

它的目的：让人类只需要表达目标并批准一张清楚的授权单；AI 不保存服务器 Token、验证码或密钥，服务器也不接受由仓库或聊天文本给出的任意 shell 命令。

## 2 · 人类可见流程

```text
冰朔表达目标
  → 当前 AI 按广播塔和 WORLD-ROUTER 填写工单
  → 授权单展示：人类、人格体、仓库、路径、固定动作、风险、回滚
  → 冰朔批准本次工单
  → 开启受限工作会话
  → 服务器执行固定动作、健康检查并保存回执
```

目标会话规则：空闲 30 分钟自动结束；每次成功的已授权操作刷新 30 分钟；人类说“结束本次操作”立即吊销；跨出工单范围必须重新批准。

## 3 · 系统关系

```text
WORLD-ROUTER       负责“去哪个仓库、哪个路径”
GLS 图书域         负责“概念和架构解释”
广播塔             负责“谁已登记、什么是当前有效入口”
GLSV               负责“这次受限操作是否经人类批准”
deployment-receiver 负责“服务器安全拉取已批准部署单并运行固定动作”
systemd / PM2      负责“服务器上的进程保活与重启”
```

GLSV 与 deployment-receiver 缺一不可：前者给出批准边界，后者在服务器本机执行白名单脚本。二者都不得把密钥或任意命令带入仓库。

## 4 · 证据与回溯

每一项受限操作至少应留下：工单号、人类授权者、当前人格体、目标仓库/路径/服务、固定动作、批准与失效时间、执行结果、健康检查、回滚点和回执位置。

这份说明只解释架构，不授予权限，也不包含任何服务器地址、Token、验证码或密钥。