examples: add design note and refresh README for code-review agent

Add DESIGN.md — the required 方案设计说明 covering Skill design, sandbox
isolation, Filter strategy, monitoring fields, DB schema, dedup/denoise,
and the security boundary. Refresh the README status to reflect the full
six-category rule coverage, the official-scenario fixtures, the input
modes, and the auto/sandbox default runtime.

Updates #92

RELEASE NOTES: NONE

Author: Acture

examples/skills_code_review_agent/DESIGN.md

@@ -0,0 +1,30 @@
+# 方案设计说明
+
+本示例把自动代码评审构建为一个**可验证系统**：主干是确定性流水线，Agent（Skill + 沙箱 + Filter）
+是其中一个 finding 来源，因此在无模型 API Key 的 dry-run 下也能产出完整报告，隐藏集阈值可复现。
+
+**Skill 设计。** `skills/code-review/` 将评审打包为可移植 Skill：`SKILL.md` 声明规则与用法，
+`scripts/run_checks.py` 是自包含的沙箱入口（不依赖示例包），`rules/` 放 semgrep 规则，
+`docs/OUTPUT_SCHEMA.md` 是 findings 的唯一契约。findings 来自 bandit / ruff / detect-secrets 等
+成熟扫描器，外加两个自写检测器（DB 连接生命周期、测试缺失），覆盖全部 6 类规则。
+
+**沙箱隔离策略。** 默认走沙箱：有 Docker 时用 Container workspace，否则降级为子进程沙箱（本地仅作
+fallback）。每次执行都有超时（`asyncio.wait_for` / subprocess timeout）、输出字节上限截断、
+资源限制（memory_mb），并把每次运行记录为 `sandbox_run`（含超时、失败、拦截）；单次失败只降级来源，
+不使整个评审崩溃。
+
+**Filter 策略。** `pipeline/policy.py::ReviewPolicy` 对命令、路径、网络、预算做 allow / deny /
+needs_human_review 判定，在两处执行点共用：确定性沙箱门（被拒动作从不启动）与框架级
+`ReviewGuardFilter`（工具级 `BaseFilter`）。拦截原因写入报告的 Filter 摘要与数据库。
+
+**监控字段。** 每次评审记录总耗时、沙箱耗时、工具调用数、拦截数、finding 数、各 severity 分布、
+异常类型分布，落入报告 monitoring 段。
+
+**数据库 schema。** 四张表 `review_tasks` / `sandbox_runs` / `findings` / `reports`，任务行内嵌
+input diff 摘要，均以 `task_id` 为键；基于 `SqlStorage` 的可移植列类型，SQLite 默认、PG/MySQL 换 URL 即可。
+
+**去重降噪。** 同 `(文件, 行, 类别)` 至多保留一条（高置信优先，其余标 duplicate）；再按置信度分流
+active / warning / needs_human_review，低置信噪声不混入高置信 findings。
+
+**安全边界。** 单一 `redact()` 汇聚点在入库/出报告前统一脱敏（提供商正则 + 熵检测，语料实测 100%）；
+沙箱只透传白名单环境变量，杜绝父进程密钥泄漏。

examples/skills_code_review_agent/README.md

@@ -92,7 +92,13 @@ deterministic sandbox gate (a denied action never launches; the block is recorde
 the report's Filter-interception section) and the framework `agent/filter.py::ReviewGuardFilter`
 (TOOL-scoped, attached on the review tool).
 
-Remaining: exporting the monitoring metrics through an OpenTelemetry reader (they are collected today
-in the report's monitoring section), an independent labelled eval set to prove the hidden-set
-thresholds, and verifying the container runtime on a Docker host. Note: the default runtime is
-`inprocess` for fast dry-runs — pass `--runtime local` or `--runtime container` for the sandbox path.
+Rule coverage spans all six required categories (security, secret_leakage, async_errors,
+resource_leak, db_lifecycle, missing_tests); the eight fixtures match the official scenarios
+(`clean`, `security`, `async_resource_leak`, `db_lifecycle`, `missing_tests`, `duplicate_finding`,
+`sandbox_failure`, `secret_redaction`). Inputs: `--diff-file`, `--repo-path`, `--files a.py,b.py`,
+or `--fixture`. The default runtime is `auto` — the container sandbox when Docker is available, else
+the local subprocess sandbox (`--runtime inprocess` is an explicit fast dev opt-in). The sandbox
+receives only a whitelisted environment. See [DESIGN.md](./DESIGN.md) for the design note.
+
+Remaining (non-code): an independent labelled eval set to prove the hidden-set thresholds, and
+verifying the container runtime on a Docker host (the code path and `Dockerfile` are in place).