需要只读审查现有代码、实现、PR或指定范围…

在禁止修改代码的前提下，对指定代码范围或 PR 差异做技术栈感知、分层级、按严重度排序的审查发现报告。

适用场景

解决思路

1. 先使用 `nerd-smart` 并消费其解析出的 Focus Record；本路线只接受 **Review** endpoint。若记录缺失、未解析或不同，先返回 Smart 再继续。
2. 除非请求明确要求，否则不要与 Superpowers、Ponytail、Caveman 组合；技能钩子、提及和间接指令不算授权。
3. 只选择一种审查类型：请求针对 PR、diff、branch 或 commit 时用 pull request review；否则用 plain。
4. Plain：审查指定工件/当前状态以及必要上下文。
5. Pull request review：审查从 base 到 head 的差异；只报告由该变更引入或显著恶化的问题。
6. Focus Record：只审查指定范围，加上判断该范围所需的最少上下文。
7. Stack mapping：从 manifests、锁文件、imports、构建配置、生成产物和配置文件中检测技术栈；加载最小的匹配参考集。
8. Levels：检查所有适用层级；先完成 Level 1，再进行更高层推理；最终发现按严重度排序。
9. Evidence：确认问题为新引入、可达，且未在其他地方处理。
10. Severity：证明可达性、触发条件、影响和影响范围；使用有证据支持的最低严重度；审查层级绝不决定严重度。
11. Report：对共同原因去重；只报告能通过对抗性证据检查的发现。
12. Level 1 聚焦：语法、编译或类型失败，以及具体代码异味；发现门槛：确切的无效构造、诊断信息、不安全行为或易缺陷惯用法。
13. Level 2 聚焦：仓库一致性、测试覆盖和文档；发现门槛：违反本地规则，或变更行为/契约未测试或不准确。
14. Level 3 聚焦：坏架构、有害复杂度和设计模式违反；发现门槛：具体的依赖、所有权、耦合、状态或控制流后果。
15. 不要单独报告缺少测试、文档、抽象或模式；必须将缺口关联到变更行为、仓库契约或可信缺陷。
16. Severity 分级：Critical 用于大范围沦陷、不可逆/大量数据丢失或持续停机。
17. Severity 分级：High 用于合理使用会破坏核心行为、契约、状态、控制或可用性。
18. Severity 分级：Medium 用于有界回归、实质性可靠性/性能损失，或已证明的维护陷阱。
19. Severity 分级：Low 用于局部可操作缺陷且影响有限；绝不能只是风格偏好。
20. Stack Mapping：每次只加载一个；只有跨真实边界时才添加另一个。
21. Kotlin：关注空值安全、协程、JVM 互操作；参考 `references/stacks/kotlin.md`。
22. Java：关注异常、并发、资源；参考 `references/stacks/java.md`。
23. Python：关注类型、异常、同步/异步；参考 `references/stacks/python.md`。
24. Ruby：关注契约、异常、元编程；参考 `references/stacks/ruby.md`。
25. TypeScript：关注类型/运行时边界、Promise；参考 `references/stacks/typescript.md`。
26. JavaScript：关注模块、强制类型转换、事件循环；参考 `references/stacks/javascript.md`。
27. Docker：关注镜像、进程、挂载、网络；参考 `references/stacks/docker.md`。
28. Kubernetes：关注选择器、探针、资源、滚动发布；参考 `references/stacks/kubernetes.md`。
29. Terraform：关注计划、状态、提供者、生命周期；参考 `references/stacks/terraform.md`。
30. Redis：关注键、TTL、原子性、内存；参考 `references/stacks/redis.md`。
31. MySQL：关注模式、索引、锁、迁移；参考 `references/stacks/mysql.md`。
32. PostgreSQL：关注类型、约束、查询计划、锁；参考 `references/stacks/postgresql.md`。
33. Go：关注错误、goroutine、接口；参考 `references/stacks/go.md`。
34. Rust：关注所有权、unsafe、错误、异步；参考 `references/stacks/rust.md`。
35. Framework Mapping：与其 stack 配对；只有跨真实边界时才添加另一个。
36. Spring Boot：关注 Bean、配置、Web、事务；参考 `references/frameworks/springboot.md`。
37. jOOQ：关注方言、生成模式、映射；参考 `references/frameworks/jooq.md`。
38. FastAPI：关注路由、依赖、校验；参考 `references/frameworks/fastapi.md`。
39. Ruby on Rails：关注路由、回调、持久化；参考 `references/frameworks/ruby-on-rails.md`。
40. Sidekiq：关注参数、重试、幂等性；参考 `references/frameworks/sidekiq.md`。
41. React：关注 Hooks、状态、副作用、可访问性；参考 `references/frameworks/reactjs.md`。
42. gRPC：关注 Protobuf、截止时间、状态、流；参考 `references/frameworks/grpc.md`。
43. Findings 输出格式：`[Severity] Specific title` / `Location: <path:line or smallest exact scope>` / `Review level: <Level 1 | Level 2 | Level 3>` / `Evidence: <trigger and proof>` / `Impact: <observable consequence>` / `Direction: <smallest correction outcome; no implementation>`。
44. 将发现放在最前；按 Critical 到 Low 排序，再按影响范围排序。
45. 若没有符合条件的发现，明确说明；只包含实质性缺口或风险。
46. 跳过赞美、干净检查清单、风格意见和 walkthrough。
47. 优先使用仓库包装命令和狭窄、非变更检查。
48. 先检查命令副作用；一次性的构建/测试输出可以接受。
49. 绝不运行格式化器、自动修复、生成器、迁移、部署或会改变状态的请求。
50. 不要自动路由到 `nerd-patrol`；仅当证据需要更深入的安全、漏洞、不安全行为或可利用性审查时使用；保留 Review，且绝不做修复。
51. 不要修改被审查工件或编写实现代码。
52. 在发现后停止；通过 Smart 确认 endpoint 变更。

适用边界 · 注意事项

• 缺少经 `nerd-smart` 解析出的 Review Focus Record 时不要使用；需先返回 Smart。
• 不适用于需要直接修改被审查工件、编写实现或自动修复的场景。
• 除非请求明确要求，不要与 Superpowers、Ponytail、Caveman 组合使用。