用途：在提交重大改动前，让 qc-code 以资深工程师视角审查代码。它默认审查自 base 起的 git diff（或用户指定文件/目录），不默认扫描整个代码库。触发方式为“review code”“soi code”“chấm điểm code”，也可作为 /orca-workflow 中 verify-before-commit 之前的可选步骤。
主要能力：围绕四个项目审查——security（SQL 注入、XSS、密钥泄露、输入校验、授权/IDOR）、performance（N+1 查询、嵌套循环、内存泄漏，并列出最慢的三处及优化方向）、naming & readability（命名是否表意、风格一致性，并给出改名表）、logic & bug（边界条件、off-by-one、竞态等）。每个项目给出评分/10、最严重错误和修复方法；每个逻辑 bug 会生成一个红色复现测试，命名为 qc-<slug-bug>，放入项目既有测试目录（tests/、test/、tests/ 或 _test.py、.spec.ts、*.test.js），使用项目现有 runner（pytest/vitest/jest），不新建测试框架。
使用方式：确定审查范围（git diff <base>..HEAD --stat 或用户指定文件）后，按四项目打分；对每个逻辑 bug 生成红色测试；结论为 PASS 或 CẦN SỬA（列出必须修复项，优先 security 与带红测的 logic，其次 naming）；同时写出 harness/out/qc-verdict.json，包含 decision、claim、reason、required_evidence。可手动校验命令：python3 harness/scripts/grounding-check.py --check <file.json>，exit 0 为有效、exit 2 为无效需重写。测试可经 python3 harness/scripts/qc-regression.py --run 自动运行（确定性、0 token），通常在 verify-before-commit 触发，也可按需增加 PostToolUse；无 qc-* 测试时 fail-open。
限制：结论为 advisory，不阻断提交，真正硬性门槛是确定性测试（红→绿）。它不做静态安全扫描（对应 /orca-sec-scans），不处理已发生事故（对应 /orca-issue），不替代内置的通用 /code-review。范围不明确时需先澄清，不应默认全库；项目无标准测试目录时测试放在源文件旁并说明，不猜测结构。依赖尚未确定的信息时记录到 unknown 台账而非断言。资料未提供收费、价格、平台与性能数据。