feat(review): add bounded adaptive review delegation

docs/architecture/review-lifecycle.md

@@ -269,11 +269,10 @@ natural-language descriptions are semantically identical.
 Review strength remains controlled by explicit intent. Ordinary Review keeps
 ordinary strength. The current implementation uses one `CodeReview` child for
 bounded targets, while a large or provider-limited target may use bounded
-managed packets without becoming a different user-facing mode. The adopted
-execution target in [deep-review.md](deep-review.md) allows the ordinary primary
-reviewer to request zero to two focused checks for concrete unresolved questions
-and Strict Review to request zero to three; a conditional quality check consumes
-the same allowance. This target does not change Review strength, expose fixed
+managed packets without becoming a different user-facing mode. The primary
+reviewer may request zero to two focused checks for concrete unresolved questions;
+Strict Review may spend up to three spawned calls shared with a conditional
+quality check. This behavior does not change Review strength, expose fixed
 architecture, frontend, performance, product, or security agents as required
 user choices, or turn every available capability into a model call.
 
@@ -414,6 +413,8 @@ evidence:
 - a single-domain ordinary Review does not launch a focused check merely because
   matching capabilities are installed;
 - focused checks cannot read changed files outside their assigned scope;
+- remote Review does not expose a focused-check action until the same scope
+  guarantees are available through remote file access;
 - large-target file packets and review capabilities do not create multiplicative
   fan-out;
 - findings are deduplicated by changed location and root cause instead of being

docs/sdlc-harness/agent-workflow-staged-plan.md

@@ -57,18 +57,18 @@ BitFun 不需要把 dynamic workflow 做成一个新的主产品模式。用户
 |---|---|
 | 本地显式入口 | 用户在普通任务或提交前明确要求 review，可使用 L1 只读快审 |
 | PR/团队入口 | 准备 PR、受保护分支、CODEOWNERS、团队策略或发布路径命中；归入既有 P2 PR/团队治理场景 |
-| 默认执行 | 先固定当前修改或明确 Git range 的 base/head、文件状态和完整度；当前本地显式审查使用一个只读 reviewer，采纳方向允许主审仅为具体未解决问题发起有界专项复核；PR/团队路径按规则给 Review 面板和就绪度摘要 |
+| 默认执行 | 先固定当前修改或明确 Git range 的 base/head、文件状态和完整度；一个只读主审先完成审查，仅为具体未解决问题发起有界补充检查；PR/团队路径按规则给 Review 面板和就绪度摘要 |
 | 风险信号 | 安全、性能、架构、跨模块、关键 UI 流程或验证缺口用于形成具体审核问题，不按标签、文件类型或能力数量机械增加 reviewer |
 | 严格审查条件 | 当前由 `/review strict`、历史 `/DeepReview` alias 或内部显式 strict follow-up 启动；大型 PR、风险标签和团队策略本身不自动触发 |
 | GUI | 一个 Review 面板，按问题优先级合并输出 |
 | 成本 | 严格审查显示更完整覆盖、必要独立复核、通常更长耗时和只读边界；不把内部调用额度作为普通用户概念，不估算底层模型请求或 Token，也不声称提供尚未实现的范围调整 |
 | 完成标准 | 必须修复、建议确认、已覆盖、未覆盖、下一步清楚 |
 | 禁止 | 把 PR 审查压进 P0 默认体验，或把 DeepReview 作为普通 review 默认入口 |
 
-当前基线与采纳方向：
+当前基线：
 
 - 文件变更菜单和命令面板只提供 `Review`，不让用户先选“普通/严格”。
-- 当前 `/review` 启动一个只读 reviewer；当前 `/review strict` 允许最多一个专家和一次条件质量检查，`/DeepReview` 仅保留历史兼容。采纳方向让普通主审按具体问题调用零到两个专项复核、严格主审调用零到三个且质量检查共用额度，同时最多运行两个；这不是静态风险升级规则。
+- 当前 `/review` 启动一个只读主审，并可按具体问题调用零到两个补充检查；`/review strict` 可调用零到三个，条件质量检查占用同一额度，同时最多运行两个。`/DeepReview` 仅保留历史兼容。这不是静态风险升级规则；普通零补充检查路径不加载能力目录。远程工作区禁用自适应补充检查，但保留历史受管文件包的兼容执行。
 - 目标证据先于 Review 决策：当前工作区使用一次有界 `HEAD -> worktree` 取证，但没有 immutable snapshot，因此最终 evidence status 始终为 `limited`；显式 Git range 由目标准备层固定 base/head，完整且无遗漏、workspace binding 为 matching_clean 时 evidence status 才可为 `complete`。Reviewer 不自行猜 ref，缺失、截断或预算耗尽必须进入覆盖说明，但不改写模型 recommendation。
 - 只读 Reviewer 不获得通用 `Git` 或 shell 工具；Git 操作留在目标准备层。Reviewer 只通过有界 `GetFileDiff` 消费目标 diff；只有本地仓库与目标 head 匹配且整个工作区干净时，现有 Read/Grep/Glob/LS 才补充 live context。不做逐工具全仓重验、fetch、checkout 或仓库状态写入。
 - Strict Review 直接启动；运行状态和结果说明范围、实际覆盖、通常更长耗时和只读边界，不显示内部调用额度，也不估算底层模型请求或 token。
@@ -78,7 +78,7 @@ BitFun 不需要把 dynamic workflow 做成一个新的主产品模式。用户
 2026-07-10 合入后产品复盘：
 
 - 统一入口、普通 Review 单 reviewer、显式 Strict Review、只读 Reviewer、独立 ReviewFixer 和同侧栏 follow-up 已形成可用基线，不再新增 Review 执行分支。
-- 当前闭合 workspace / Git range / provider PR 三类目标证据，但仍只有一套 Review 执行链路。采纳方向不新增长期目标数据库、合成 diff 引用、跨 reviewer 内容缓存、Finding 生命周期、自动评论或结果动作。
+- 当前闭合 workspace / Git range / provider PR 三类目标证据，并保持一套 Review 执行链路。按问题协作不新增长期目标数据库、合成 diff 引用、跨 reviewer 内容缓存、Finding 生命周期、自动评论或结果动作。
 - 性能与质量先使用固定回放集和现有日志离线比较；没有稳定基准证明收益前，不新增 Review 专用遥测平台或默认执行分支。
 - PR 自动审查、跨 Review 增量对照、反馈学习、完整远程 checkout 和大规模任务控制台均不进入当前采纳范围；后续决策先看目标正确率、覆盖缺口和用户决策时间。
 
@@ -126,12 +126,12 @@ BitFun 不需要把 dynamic workflow 做成一个新的主产品模式。用户
 | 强度 | 用户表达 | 默认触发 | 成本倾向 |
 |---|---|---|---|
 | L0（后续探索） | 快速检查 | 等待 Verify evidence 设计，不在当前生产策略中触发 | 默认最低成本 |
-| L1 | 独立审查 | 普通 `/review`、提交前或 PR 前检查 | 当前为一个只读 reviewer；目标行为仅按具体问题使用零到两个专项复核 |
+| L1 | 独立审查 | 普通 `/review`、提交前或 PR 前检查 | 当前为一个只读 reviewer；目标行为仅按具体问题使用零到两个补充检查 |
 | L3 | 严格审查 | `/review strict`、`/DeepReview` 兼容输入或内部显式 strict follow-up | 更完整覆盖、必要独立复核、通常更长耗时和只读边界 |
 
 原则：
 
-- 默认任务不启动 reviewer；显式 Review 固定为 L1。L2 只保留历史 manifest 兼容，不产生新启动；L3 只服务当前可识别的显式 strict 意图。团队策略只能提示，不自动启动，静态风险也不能直接增加专项复核。
+- 默认任务不启动 reviewer；显式 Review 固定为 L1。L2 只保留历史 manifest 兼容，不产生新启动；L3 只服务当前可识别的显式 strict 意图。团队策略只能提示，不自动启动，静态风险也不能直接增加补充检查。
 - reviewer 默认只读；修复必须进入用户批准的执行阶段。
 - 两轮审查没有新增有效问题时，应建议停止或保留核心检查。
 - 缺少上下文或 oracle 时，先提问或诊断，不启动 L3。
@@ -141,7 +141,7 @@ BitFun 不需要把 dynamic workflow 做成一个新的主产品模式。用户
 | 决策点 | 默认倾向 |
 |---|---|
 | 小任务 | 优先首个有用结果时间，牺牲部分覆盖但明确未验证项 |
-| 中风险任务 | 优先一个 L1 主审和最近验证；只有具体未解决问题才使用有界专项复核 |
+| 中风险任务 | 优先一个 L1 主审和最近验证；只有具体未解决问题才使用有界补充检查 |
 | 多失败任务 | 优先失败聚类和可运行 oracle，再决定是否队列化 |
 | 大规模任务 | 优先样本成功率和可收敛性，再考虑并发 |
 | 预算不足 | 优先高风险/高价值 item，跳过低风险二次审查 |

docs/sdlc-harness/implementation-plan.md

@@ -216,7 +216,7 @@ P-1 是内部跑道，不应作为用户可见“新能力”发布。它的价
 
 ### 8.4 Review 演进边界
 
-Review 继续使用同一套目标准备和只读执行链路。已合入能力与已采纳但尚未实现的设计必须分开陈述，避免把未来生命周期描述为当前产品事实。
+Review 继续使用同一套目标准备和只读执行链路。当前按问题有界协作与尚未实现的版本化生命周期必须分开陈述，避免把未来记录、修订和恢复能力描述为当前产品事实。
 
 #### 已合入基线：目标证据正确
 
@@ -231,6 +231,10 @@ Review 继续使用同一套目标准备和只读执行链路。已合入能力
 | 验证 | Rust contract/tool policy tests；真实临时 Git 仓库的新增/删除/rename-with-edit/超限/分页/预算测试；`targetResolver` 当前修改/range/remote/显式文件和目录测试；越界路径不可达、fail-closed 报告、uncertain launch、普通 Agent 隔离测试；Web type-check 与 i18n audit |
 | 回退 | 目标不能证明时回退为明确的 `partial`/`unknown` 并阻止完整覆盖文案；不得回退到 Reviewer 猜 ref，也不得把既有 Git 当作 prepared target 的替代证据 |
 
+#### 当前实现：按问题有界协作
+
+权威执行设计见 [../architecture/deep-review.md](../architecture/deep-review.md)。普通主审最多请求两个补充检查，严格主审最多花费三个共享调用额度；条件质量检查使用同一额度，最多两个补充检查并发。能力目录复用现有 Skill 与只读审核代理注册表，完整指引只在精确 key、正文指纹和目标范围通过准入后加载。补充检查 worker 不能读取未分配的改动文件，不能再委派或自动重试；远程工作区当前不暴露该能力。大目标继续复用既有受管文件包，不按审核维度复制文件包，也不新增 Review 专用遥测、缓存或调度运行时。
+
 #### 已采纳设计、尚未实现：版本化 Review 生命周期
 
 权威设计见 [../architecture/review-lifecycle.md](../architecture/review-lifecycle.md)。它把用户可见的 Review 记录放在现有 child 执行之上，不新增 Review 运行时、目标解析器或数据面。