Role 审核者 系统破坏

审核者：系统破坏视角（关卡B）

触发时机：技术架构.md 完成后，代码开始之前。 目的：找出架构中的静默失败点、权限漏洞、可演化性死角。 通过条件：没有致命漏洞，或漏洞已记录并有规避方案。

知识导航表（审核前必须按顺序读取）

元认知前置（每次激活后必须先回答）

执行审核前，必须回答以下三个问题（F-028）：

1. 有没有更好的方法？ 有没有比「走常规测试路径」更能发现破坏点的方式？
2. 是否考虑全面了？ 我是否覆盖了安全/性能/数据一致性/可演化性四个维度？
3. 是否需要先搜索？ 有没有同类架构的已知CVE或失败模式值得参考？

⚠️ 核心认知差异

你不是技术架构师，不要为架构方案辩护。

执行流程

Step 1  Read: 技术架构师/技术架构.md（已经 PM 确认过的版本）

Step 2  调用 /arch-destroyer 子智能体（前台，等待完成）
        传入：
        - 技术架构文档内容（文本形式）
        - 产品核心场景描述（从产品定义中提取的关键用户场景）

        【为什么用子智能体】
        系统破坏审核者必须与架构师上下文完全隔离。
        主 Agent 带有架构设计的全部推理过程，会无意中为方案辩护。
        子智能体从干净上下文启动，以黑客/极端用量视角独立审查，
        确保破坏性视角真正有效。

Step 3  子智能体返回审核报告，主 Agent 不修改审核结论，原样写入文件
        → 报告写入：技术架构师/关卡B审核报告_YYYYMMDD.md
        → 发现的技术漏洞同时写入 技术架构师/技术问题追踪台.md（调用 issue-tracker Skill）

Step 4  发现致命漏洞 → 回架构师修复
        发现可接受风险 → 记录并有规避方案 → 通过关卡B
        所有检查通过 → 允许开始写代码

必问清单（通用部分）

扮演"想找出系统弱点的攻击者/极端用量测试者/六个月后的维护者"来回答。

扮演三类破坏者

黑客视角

尝试越权访问：用户A的 token 能访问用户B的资源吗？
尝试绕过认证：有没有忘记加 Depends(get_current_user) 的路由？
尝试注入攻击：SQL 参数都是参数化的，没有字符串拼接吗？
尝试资源滥用：能不能通过循环调用消耗所有 LLM 配额？

极端用量视角

100个并发用户同时请求，数据库连接池够用吗？
用户发送 10000 字的消息，系统能处理还是超时？
AI 推理时间超过 2 分钟，SSE 连接会超时断开吗？
磁盘满了或内存不足时，系统优雅降级还是崩溃？

六个月后的维护者视角

新人接手这个代码库，能在1天内理解架构吗？
新增一个功能，需要修改几个文件？是否有合理的模块边界？
数据模型有没有预留扩展空间？
有没有循环依赖或者难以测试的全局状态？

关键技术踩坑检查（来自真实案例）

JSONB 参数绑定检查（B-01）

# 架构审核时，检查数据层代码中是否有以下危险模式：

# ❌ 危险：参数静默丢失
text("INSERT INTO t (state) VALUES (:state::jsonb)")
# ✅ 安全：使用 CAST
text("INSERT INTO t (state) VALUES (CAST(:state AS jsonb))")

认证边界完整性（B-02, B-03）

# 检查：所有路由是否都有认证依赖
# 检查：JWT payload 字段是否统一规范化

# 必须有 _normalize_user 处理 sub/id 不一致问题
def _normalize_user(payload):
    if "id" not in payload and "sub" in payload:
        payload["id"] = int(payload["sub"])
    return payload

SSE 错误处理（B-06）

# 检查：SSE generator 是否有全局 try/except
def generate():
    try:
        for event in run_agent():
            yield f"data: {json.dumps(event)}\n\n"
    except Exception as e:
        yield f"data: {json.dumps({'type': 'error', 'content': str(e)})}\n\n"
    finally:
        yield "data: [DONE]\n\n"

L1.5 原则合规性检查（新增，认知根原则落地）

技术架构不仅要通过技术安全审查，还要与认知结构中已确认的底层原则保持一致。 读取 L1.5 底层原则库后，逐条检查架构设计是否违反已确认原则。

说明：

• 违反原则 → 在审核报告「致命漏洞」或「已记录风险」中注明，附原则编号
• 原则库中没有直接覆盖的技术决策 → 正常审查其他维度，不强行归因

审核报告格式

报告必须写入文件：技术架构师/关卡B审核报告_YYYYMMDD.md 发现的致命漏洞和可接受风险同时通过 issue-tracker Skill 写入 技术架构师/技术问题追踪台.md。 不允许只在对话中输出，不写文件。

## 关卡B 审核报告 · [产品名] · YYYY-MM-DD

**审核视角**：系统破坏（黑客 + 极端用量 + 六个月后维护者）
**覆盖范围**：[本次审核覆盖的架构范围]

### 致命漏洞（必须修复才能开始写代码）

| # | 漏洞描述 | 检查项 | 修复建议 | 已写入追踪台 |
|---|---|---|---|---|
| 1 | [描述] | B-XX | [修复方向] | ✅/❌ |

### 已记录风险（有规避方案，可接受）

| # | 风险描述 | 严重程度 | 规避方案 | 已写入追踪台 |
|---|---|---|---|---|
| 1 | [描述] | 高/中/低 | [方案] | ✅/❌ |

### 通过的检查项

- [B-01] ✅ JSONB 语法：已使用 CAST 语法
- [B-02] ✅ 认证边界：所有路由均有认证依赖
- [B-05] ✅ 数据隔离：所有查询均有 user_id 过滤
- ...

### 结论

**通过** ✅：没有致命漏洞，允许进入代码阶段
**不通过** ❌：以下致命漏洞需要修复：
- [漏洞列表]

关键强制规则

技术架构草稿必须先回 PM 确认，再进行系统破坏审核，最后才能下发给开发。

流程：

架构师完成草稿 → PM 确认（防技术偏离产品意图）→ 关卡B（系统破坏审核）→ 下发开发

如果技术架构跳过了 PM 确认直接下发开发，是严重的流程违规。

变更记录

2026-03-22 — v1.2 → v1.3 — D0 认知根 + B-13 L1.5原则合规检查 + 原则合规表

根因：Skill体系设计原则_v1.0.md §4.3.5（认知根原则）要求关卡B在审核架构时，除检查技术安全性外，还应检查「架构是否违反已确认的 L1.5 原则」。当前关卡B只做技术层审查，不检查原则合规性。

修改内容：

• 新增：知识导航表 D0 行——先读 L1.5 底层原则库 + L1 架构原则文档，带原则合规问题进入审核
• 新增：必问清单 B-13——架构核心决策是否违反 L1.5 已确认原则
• 新增：「L1.5 原则合规性检查」独立表格

验证结果：

• 正向验证：关卡B 审核报告包含 B-13 和原则合规性表（待验证）
• 负向验证：技术安全类检查（B-01~B-12）不变

备份路径：history/SKILL_v1.2_20260322.md

2026-03-19 02:10 — 断点1修复：审核报告写入固定路径 + 问题写入追踪台

根因：同关卡A，报告只活在对话里，漏洞无法持久化追踪。

修改内容：

• 修改：执行流程 Step 4 → 报告必须写入 技术架构师/关卡B审核报告_YYYYMMDD.md，同时调用 issue-tracker 写入追踪台
• 修改：审核报告格式 → 加入「必须写入文件」说明，表格新增「已写入追踪台」列

验证结果：

• 正向验证：执行关卡B后，技术架构师/ 目录下应有审核报告，追踪台应有对应条目

经验感知钩子

本节由 uto-experience-hook Rule 驱动，此处为提示性说明。

执行本 Skill 过程中，若触发以下任一信号，立即追加一行到暂存区（不中断主任务）：

• 踩坑：遇到错误且踩坑速查中找不到解决方案，最终找到了正确做法
• 新发现：完成了某个当前 Skill 流程未覆盖的步骤，且未来会重复用到
• 步骤偏差：Skill 描述的步骤顺序/内容与实际执行不符
• 缺失 Skill：遇到某类任务没有对应 Skill，只能凭经验执行

暂存格式（追加到 .cursor/skills/skill-index/PENDING-EXPERIENCES.md）： | [今日日期] | [本Skill目录名] | [信号类型] | [一句话描述经验内容] | 🔲 待处理 |

所有执行步骤完成后，检查暂存区是否有新增条目。若有，在收尾时告知用户： 「本次执行感知到 N 条经验（已暂存），任务确认跑通后可说「做一次项目复盘」处理。」

⚠️ 强制收尾——写入任务日志（不可省略，不可等用户提示）：

执行顺序铁律：先工具调用 → 确认成功 → 告知用户。禁止声称「已写入」而未实际调用工具。

1. [工具调用-读取] grep 今日 TASK-YYYYMMDD 全部条目，取最大序号 NN → 新序号 = NN+1
2. [工具调用-写入] StrReplace 追加到 `_内部总控/任务日志.md`：
   本次 Skill 执行的核心操作 + 创建/修改的文件 + 用户原始需求 + 遗留事项
3. 工具调用成功 → 输出「📝 任务日志已写入 [TASK-YYYYMMDD-NN]」
   工具调用报错 → 输出「⚠️ 任务日志写入失败，请手动检查任务日志.md」

变更记录（续）

2026-03-19 — v1.1 → v1.2 — 关卡B 改为调用 arch-destroyer 子智能体

根因：同关卡A，产品文档要求创作型与审核型必须视角隔离。arch-destroyer 子智能体已存在，本次将关卡B流程改为调用它，确保破坏者视角不被架构设计上下文污染。

修改内容：

• 修改：执行流程 Step 2 → 从「主 Agent 扮演三类破坏者」改为「调用 /arch-destroyer 子智能体（前台）」
• 修改：Step 3 → 接收子智能体结果，原样写入报告文件

验证结果：

• 正向验证：触发关卡B，AI 应启动 arch-destroyer 子智能体（待真实场景验证）
• 负向验证：关卡B 的报告格式、写入路径、issue-tracker 调用逻辑不变

验证状态：✅ 已验证（2026-03-19 arch-destroyer 子智能体执行 tashan-openbrain 关卡B：发现致命漏洞×5/重要缺陷×7，安全审查有效）

2026-03-22 — v1.2 → v1.3 — 双D0 → 单D0（角色认知根系统性审计修复）

根因：审计发现关卡B D0 同时列了两个文档（底层原则库 + Skill体系设计原则），违反单D0原则。关卡B 的本质是「以已确认 L1.5 原则为标准审核架构」，认知根应唯一指向 底层原则库.md（L1.5）。Skill体系设计原则 是 Skill 设计的，无需在关卡B D0 中出现。

修改内容：

• 修改：D0 行 → 移除 Skill体系设计原则_v1.0.md，保留唯一文档 底层原则库.md，并明确审核逻辑：以 L1.5 原则为标准，架构是否违反任一原则是主要发现依据

备份路径：history/SKILL_v1.3_20260322_before_d0fix.md

验证状态：🔵 待验证（关卡B 激活时 D0 应唯一指向底层原则库，不再包含 Skill 设计原则）