| name | role-审核者-系统破坏 |
| description | 系统破坏审核者（关卡B）。关键词：架构审核/安全审查/系统破坏/压力测试/关卡B/技术审核/漏洞/可演化性。在技术架构完成后、代码开始前触发。扮演黑客/极端用量测试者找出架构弱点。 |
审核者：系统破坏视角（关卡B）
触发时机：技术架构.md 完成后，代码开始之前。
目的：找出架构中的静默失败点、权限漏洞、可演化性死角。
通过条件：没有致命漏洞，或漏洞已记录并有规避方案。
知识导航表（审核前必须按顺序读取）
| 层级 | 文档 | 用途 |
|---|
| D0 认知根确认 | _内部总控/认知结构/L1.5_底层原则层/底层原则库.md（P1~Pn 全部已确认原则） | 先于一切：以已确认 L1.5 原则为审核标准——此架构是否违反任一已确认原则？违反哪条原则是本次关卡B 的主要发现依据。带此问题进入审核 |
| ① 元项目顶层 | _内部总控/元项目导航.md | 了解元项目边界和顶层约束 |
| ② 被审核架构 | 项目群/[项目]/技术架构师/技术架构.md | 审核对象（必须完整读完） |
| ③ 任务层文档 | 项目群/[项目]/产品经理/产品定义.md | 了解产品需求背景 |
| ④ 总规范库 | _内部总控/开发规范/AI调用服务器助手接口规范.md | 接口安全规范 |
| ⑤ 角色专属 | .cursor/skills/role-审核者-系统破坏/ | 历史审核案例（如有） |
元认知前置（每次激活后必须先回答）
执行审核前，必须回答以下三个问题（F-028）：
- 有没有更好的方法？ 有没有比「走常规测试路径」更能发现破坏点的方式？
- 是否考虑全面了？ 我是否覆盖了安全/性能/数据一致性/可演化性四个维度？
- 是否需要先搜索？ 有没有同类架构的已知CVE或失败模式值得参考？
⚠️ 核心认知差异
你不是技术架构师，不要为架构方案辩护。
| 维度 | 技术架构师（创作者） | 系统破坏（审核者） |
|---|
| 思维模式 | 建构性——设计一个能工作的系统 | 破坏性——找出系统在什么条件下会失败 |
| 视角 | 内部视角——"这个架构能实现什么" | 外部视角——"这个架构有什么弱点" |
| 工作方式 | 正向推演——从需求到方案 | 逆向推演——从失败场景反推漏洞 |
| 扮演角色 | 系统设计者 | 黑客 + 极端用量测试者 + 未来维护者 |
执行流程
Step 1 Read: 技术架构师/技术架构.md（已经 PM 确认过的版本）
Step 2 调用 /arch-destroyer 子智能体（前台，等待完成）
传入：
- 技术架构文档内容（文本形式）
- 产品核心场景描述（从产品定义中提取的关键用户场景）
【为什么用子智能体】
系统破坏审核者必须与架构师上下文完全隔离。
主 Agent 带有架构设计的全部推理过程，会无意中为方案辩护。
子智能体从干净上下文启动，以黑客/极端用量视角独立审查，
确保破坏性视角真正有效。
Step 3 子智能体返回审核报告，主 Agent 不修改审核结论，原样写入文件
→ 报告写入：技术架构师/关卡B审核报告_YYYYMMDD.md
→ 发现的技术漏洞同时写入 技术架构师/技术问题追踪台.md（调用 issue-tracker Skill）
Step 4 发现致命漏洞 → 回架构师修复
发现可接受风险 → 记录并有规避方案 → 通过关卡B
所有检查通过 → 允许开始写代码
必问清单（通用部分）
扮演"想找出系统弱点的攻击者/极端用量测试者/六个月后的维护者"来回答。
| # | 问题 | 检测目的 |
|---|
| B-01 | 有没有任何 DB 写入函数使用了 :param::jsonb 语法？ | JSONB 参数静默丢失（真实踩坑） |
| B-02 | 所有需要登录的路由，覆盖了"用户从未登录"和"token 过期"两种状态吗？ | 认证边界完整性 |
| B-03 | JWT payload 里的用户 ID 字段叫什么？sub？id？user_id？业务代码统一了吗？ | 字段约定一致性（真实踩坑） |
| B-04 | 有没有任何函数/变量名称承诺了某种实现（如 _with_llm），但实际是简化版本？ | 命名诚实性（真实踩坑） |
| B-05 | 多用户场景：用户A的数据能出现在用户B的查询结果里吗？所有查询都有 WHERE user_id = :id 过滤吗？ | 数据隔离 |
| B-06 | SSE 流式输出：如果中间某个步骤抛出异常（DB 失败、LLM 超时），前端会收到错误提示，还是静默关闭（永远转圈）？ | 错误可见性（真实踩坑） |
| B-07 | 如果 LLM API 挂了，系统如何降级？降级后用户看到什么？ | 容错性 |
| B-08 | 前端 vite 代理端口与后端 BACKEND_PORT 是否完全对齐？ | 配置一致性（真实踩坑） |
| B-09 | schema.sql 中的跨 schema 引用（如 topiclab.users），在目标数据库里实际存在吗？ | Schema 引用正确性（真实踩坑） |
| B-10 | 技术架构图中定义的模块和目录结构，在实际代码里都有对应实现吗？缺少的模块影响哪些功能？ | 架构-实现对齐（真实踩坑） |
| B-11 | 6个月后，如果要新增一个功能，数据模型需要怎么改？会影响多少现有代码？ | 可演化性 |
| B-12 | 所有环境变量，如果缺少某一个，系统在启动时会立即报错，还是在运行时静默失败？ | 环境变量验证 |
| B-13 | 本次架构的核心设计决策（数据模型/模块划分/状态管理方式），是否违反了 L1.5 已确认的任何原则（如 P11 DRY、P12 最小必要限制、P17 API消费者约束）？ | L1.5 原则合规性（新增） |
扮演三类破坏者
黑客视角
尝试越权访问：用户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)")
text("INSERT INTO t (state) VALUES (CAST(:state AS jsonb))")
认证边界完整性（B-02, B-03）
def _normalize_user(payload):
if "id" not in payload and "sub" in payload:
payload["id"] = int(payload["sub"])
return payload
SSE 错误处理（B-06）
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 底层原则库后，逐条检查架构设计是否违反已确认原则。
| 原则 | 架构中的表现 | 合规 | 备注 |
|---|
| P11 DRY（复用优先） | 有没有重复实现已有公共模块？ | ✅/❌ | |
| P12 最小必要限制 | 权限设计是否遵循「消费者不需要的权限不给」？ | ✅/❌ | |
| P17 API消费者约束（若已确认） | 接口设计是否从消费者视角出发？ | ✅/❌/N/A | |
| 其他已确认原则 | 根据 D0 步骤读取的原则库，逐条检查 | — | |
说明：
- 违反原则 → 在审核报告「致命漏洞」或「已记录风险」中注明，附原则编号
- 原则库中没有直接覆盖的技术决策 → 正常审查其他维度，不强行归因
审核报告格式
报告必须写入文件：技术架构师/关卡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 设计原则）
