guanghulab/docs/zhuyuan-signature-protocol.md

88 lines
2.8 KiB
Markdown
Raw Normal View History

# 铸渊指令签名协议 v1.1
> 签发人冰朔TCS-0002∞
> 生效日期2026-03-17
> 核心原则:**铸渊只认签名,不认请求内容。签名不对,再合理的请求也会被拒。**
---
## 一、为什么需要签名机制
铸渊作为仓库执行体直接操作代码仓库push/merge/deploy等是整个系统中**破坏性最强的执行层**。签名机制防止:
- 副控签发超出其权限范围的指令
- 开发者绕过人格体直接操纵仓库
- 指令来源不可追溯,事故无法归因
---
## 二、签名结构
每条发送给铸渊的指令必须携带以下签名字段:
```json
{
"sender_id": "TCS-0002∞",
"sender_name": "冰朔",
"sender_role": "MASTER",
"broadcast_id": "BC-GEN-xxx",
"issued_at": "2026-03-17T09:53:00+08:00",
"permission_tier": 0
}
```
| 字段 | 说明 | 必填 |
|------|------|------|
| sender_id | 发送者唯一编号 | ✅ |
| sender_name | 发送者名称 | ✅ |
| sender_role | 角色标识 | ✅ |
| broadcast_id | 来源广播编号(非广播来源填 DIRECT | ✅ |
| issued_at | 签发时间ISO-8601 | ✅ |
| permission_tier | 权限等级 | ✅ |
---
## 三、权限等级
| 等级 | 角色 | 可执行操作 | 禁止操作 |
|------|------|-----------|---------|
| Tier 0 | MASTER | 全权限 | 无限制 |
| Tier 1-G | SUB_CTRL_PRIVATE | push 功能分支、创建 PR、沙盒部署 | 分支保护、生产部署、修改协议 |
| Tier 1-L | SUB_CTRL_HOLOLAKE | 光湖范围内操作 | 同上 + 非光湖模块 |
| Tier 2 | DEV | push 自己分支、提交 PR、查看状态 | 直接给铸渊下指令、操作他人分支 |
| Tier 3 | SYSTEM | 白名单 workflow | 白名单外全部禁止 |
---
## 四、校验流程
```
收到指令
→ 签名字段完整? 否 → ERR_NO_SIGNATURE
→ sender_id 在授权名单? 否 → ERR_UNKNOWN_SENDER
→ permission_tier 匹配操作? 否 → ERR_PERMISSION_DENIED上报主控
→ 执行指令 → 写入执行日志
```
> ⚠️ 任何 ERR_PERMISSION_DENIED 事件**必须上报主控(冰朔)**,不可静默处理。
---
## 五、实现文件
| 文件 | 作用 |
|------|------|
| `.github/persona-brain/zhuyuan-signature-registry.json` | 授权名单 |
| `scripts/zhuyuan-signature-verify.js` | 核心校验模块 |
| `src/middleware/zhuyuan-signature.middleware.js` | Express 中间件 |
| `tests/contract/zhuyuan-signature.test.js` | 契约测试 |
---
## 六、变更记录
| 版本 | 时间 | 变更内容 | 签发人 |
|------|------|---------|--------|
| v1.0 | 2026-03-17 | 初版:签名结构·四级权限·校验流程 | 冰朔TCS-0002∞ |
| v1.1 | 2026-03-17 | 角色结构修正之之为私人副控1-G新增光湖主控肥猫/桔子1-L | 冰朔TCS-0002∞ |