文档：统一 V1 独立验证与扩展边界

明确 failed 和 inconclusive 不存在 override 接受入口，V1 不定义独立 EvidenceReader，证据读取通过只读工具与引用完成；同步 capability 权限、批量异常隔离和 Host legacy adapter 的最新实现。

Agent框架任务规划与独立验证技术方案.md

@@ -88,7 +88,7 @@ Agent Framework 不 import、不读取、不假设任何业务项目的内部代
 - 业务侧的验收条件；
 - 人工审批和发布动作。
 
-当前代码与这个目标边界还有一处历史偏差：`trace/run_api.py` 会动态加载 `examples.{project_name}.run`。这属于旧的项目启动兼容入口，不应继续留在通用 orchestration 内核。V1 应把它迁移到 Host bootstrap 或 legacy adapter；框架内核不得 import `examples` 或任何业务包。
+旧的 `examples.{project_name}.run` 动态加载已从 `trace/run_api.py` 迁移到 Host 侧 legacy adapter；框架内核只依赖 `ProjectEnvironmentResolver` 端口。具体项目启动方式和旧内容评分器都由 Host 组装，框架内核不 import `examples` 或任何业务包。
 
 ## 三、当前框架真实能力
 
@@ -290,7 +290,7 @@ flowchart TD
 
     Host -.注入.-> Tools[Business Tools]
     Host -.注入.-> ArtifactPort[Artifact Port]
-    Host -.注入.-> EvidencePort[Evidence Port]
+    Host -.V2 注入.-> EvidencePort[V2 Evidence Port]
 ```
 
 这套架构中：
@@ -611,7 +611,7 @@ Validation error / stopped / expired
 
 `needs_replan` 专指“执行或评审链路没有形成有效结论，需要主 Agent决定重新执行、重新验证、修改任务或阻塞”。
 
-普通 accept 不能推翻 failed 或 inconclusive。如果某些业务允许主 Agent在特殊情况下越过评审结论，框架应提供独立的 `accept_override`，并要求 Host Policy 明确允许、记录理由和审批信息。它不能伪装成普通 accept。
+普通 accept 不能推翻 failed 或 inconclusive。V1 不提供任何 override 通道；需要例外审批的业务必须把人工复核建模为新 Task 或由 Host 在框架之外处理，不得把 failed/inconclusive 标记为已通过。
 
 ## 十、标准运行流程
 
@@ -696,7 +696,6 @@ Validator 可以附带自然语言分析，但不能只返回一段无法解析
 | Decision | 框架动作 |
 |---|---|
 | accept | 在有效 passed Validation 基础上接受本次输出，Task 完成 |
-| accept_override | Host Policy 特批后越过 failed/inconclusive，必须记录理由和审批 |
 | repair | 同 Task、同版本创建新 Attempt，可有限续用原 Worker Trace 上下文 |
 | retry | 创建新 Attempt，并创建新 Worker Trace |
 | revalidate | 对当前未变化的 Attempt Snapshot 创建新 Validation |
@@ -785,9 +784,7 @@ Planner 可以：
 - 读取评估报告；
 - 提交 Planner Decision。
 
-Planner 是否拥有业务写工具，由 Host Application 配置，但框架自身的状态修改必须经过 Coordinator。
-
-默认情况下，Planner 只拥有编排写权限和业务只读权限。业务写工具需要 Host Application 显式授权并留下审计记录，避免“唯一 Planner”退化为主 Agent绕过 Worker 直接执行全部工作。
+V1 中 Planner 只拥有编排写权限和业务只读权限，不允许直接使用业务写工具。框架自身的状态修改必须经过 Coordinator，避免“唯一 Planner”退化为主 Agent绕过 Worker 直接执行全部工作。
 
 ### 14.2 Worker 权限
 
@@ -817,7 +814,9 @@ Validator 可以使用只读查询和安全检查工具。
 
 ### 14.4 权限计算规则
 
-工具权限不能再使用简单并集，建议采用：
+工具权限不再只依赖工具名称。ToolRegistry 为 explicit 模式的每个工具记录安全 capability：`read`、`write`、`agent_spawn`、`external_send`、`task_control`、`attempt_submit`、`validation_submit`。未声明 capability 的工具在 explicit 模式中默认拒绝。
+
+有效工具采用：
 
 ```text
 effective_tools
@@ -826,9 +825,10 @@ effective_tools
 ∩ host_policy.allowed_tools
 − preset.denied_tools
 − host_policy.denied_tools
+∩ role.allowed_capabilities
 ```
 
-当某层没有显式 requested tools 时，表示“不进一步缩小”，不是“允许全部”。
+当某层没有显式 requested tools 时，表示“不进一步缩小”，不是“允许全部”。Schema 过滤和执行前授权使用同一份 capability 结果。
 
 ## 十五、通用扩展接口
 
@@ -844,9 +844,9 @@ effective_tools
 
 框架只认识 Artifact Reference，不认识具体内容结构。
 
-### 15.3 Evidence Port
+### 15.3 Evidence Port（V2 扩展）
 
-负责向 Validator 提供业务证据查询能力。
+负责向 Validator 提供业务证据查询能力。V1 不定义独立证据读取端口；证据使用 ArtifactRef/EvidenceRef 和经 capability 授权的只读工具提供。
 
 实际实现可以是 ToolRegistry 中注册的只读工具，也可以是业务提供的适配器。
 
@@ -945,7 +945,7 @@ Worker → Validator → Planner Decision
 
 第一版可以继续使用现有 `await` 模式，不需要立即引入分布式队列。
 
-多个互不依赖的 Task 可以继续使用现有并行 Sub-Trace 能力。
+多个互不依赖的 Task 可以继续使用现有并行 Sub-Trace 能力。批量预约 Attempt 和执行周期都必须逐 Task 隔离异常：单个 Task 冲突、Store 或 Artifact 异常只返回该分支错误，其他 Task 继续执行，返回顺序与输入一致。
 
 ### 17.2 后续增加后台任务接口
 
@@ -1043,7 +1043,7 @@ agent/agent/tools/builtin/
 - Validator 默认新 Trace；
 - Planner、Worker、Validator 工具权限隔离；
 - 定义最小 TaskStore Protocol，并提供文件系统默认实现；
-- 定义最小 ArtifactSnapshot、EvidenceReader 和 ToolPolicy 协议及默认实现；
+- 定义最小 ArtifactStore、AgentExecutor、ToolPolicy 和 EventSink 协议及默认实现；
 - 使用不可变 Output Snapshot；
 - 提供单进程幂等键，防止同一请求重复创建 Attempt、Validation 或 Decision；
 - orchestration 内核不再动态 import examples 或业务包；
@@ -1111,7 +1111,7 @@ agent/agent/tools/builtin/
 - 只有主 Agent accept 后，Task 才能 completed；
 - Validator Run Status=error 与 Verdict=failed 必须分开；
 - 普通 accept 必须绑定当前版本的 passed Validation；
-- accept_override 必须经过 Host Policy 并记录理由。
+- failed 和 inconclusive 均不存在 override 接受入口。
 
 ### 21.2 重新规划