企业版Review Gate机制

这是一页制度规则页，负责定义 review gate 的规则与边界。
它不负责具体模板；模板与执行细节应以下列页面为准： How to Implement Review Flow in Multica、Review Issue Template。

核心目的

企业版知识库不能让所有候选内容直接进入 canonical wiki。

必须有一层 Review Gate，负责判断：

• 这条内容值不值得长期保留
• 这条内容是否足够稳定
• 这条内容是否需要被重写、合并或拒绝

Review Gate 的位置

当前推荐链路（docs-as-code 落地后）：

Task output / Comment / Chat / mem0 candidate
-> wiki-compile → /opt/wiki-vault/drafts/<file>.md
-> Multica 评审 UI（评论 / AI 改 / Approve|Revise|Reject）
-> Approve 触发 promote.sh
-> /opt/wiki-vault/canon/ + git push origin main
-> Hermes 5 容器 ro 挂载 + VitePress 渲染

历史链路（飞书发布层时代）见 飞书发布同步机制，已 superseded。

物理实现

• drafts 区：/opt/wiki-vault/drafts/，仅 hermes-admin 容器读写挂载
• canon 区：/opt/wiki-vault/canon/，Hermes 全员只读、promote.sh 才能写
• 唯一升级通道：/opt/wiki-tools/promote.sh，由 Multica 审批通过事件触发
• 真相源：GitHub daishiyu1991-hub/wiki-vault main 分支

详见 Docs-as-Code 发布架构。

默认角色

1. 提交者

可以是：

• 执行 Agent
• 知识编译 Agent
• 人类同事

2. 编译者

推荐：

• hermes-linjun

3. 审核者

推荐：

• admin
• 或对应领域 owner

审核标准

一条候选知识必须至少满足：

1. 稳定
2. 可复用
3. 对未来人类或 Agent 有价值
4. 不只是一次性执行噪音

三种审核结果

Approve

由 Multica 审批通过事件触发 promote.sh： 草稿从 drafts/ 移到 canon/，commit 后 push 回 GitHub main， 随后被 ECS cron 拉回、Hermes 共享读取、VitePress 渲染上线 wiki.86lux.net。

Revise

需要重写、补充、去重或收缩范围后重新提交。

Reject

不进入 wiki。
它可以留在：

• Chat
• Comment
• mem0

但不进入长期知识层。

为什么企业版一定要有 review gate

如果没有 review gate，最后的结果几乎一定会是：

• 噪音进入 wiki
• 重复页面增多
• 稳定知识和临时结论混在一起
• 团队越来越不信任知识库

最终规则

企业版 wiki 只能收“经过筛选和审核的高价值知识”，不能直接收原始产物。

关联

• 企业版自动化运行架构
• 企业版Source进入规则
• Docs-as-Code 发布架构 — 本 gate 的物理实现载体
• Where Review Happens and How Bots Trigger It
• Feishu as Publishing Layer — 已 superseded