Merge remote-tracking branch 'origin/codex/ai-game-creator-app' into ai-game-creator-app-home-sidebar
This commit is contained in:
@@ -15,6 +15,7 @@
|
||||
"agent-run": "node scripts/run-cli-with-config.mjs --agent-run",
|
||||
"agent-run:smoke": "node scripts/smoke-agent-run-local-provider.mjs",
|
||||
"agent-runtime:real-e2e": "node scripts/agent-runtime-real-e2e.mjs",
|
||||
"agent-runtime:supervisor-swarm-transient-retry-real-e2e": "node scripts/agent-runtime-real-e2e.mjs --suite supervisor-swarm-transient-retry",
|
||||
"agent-runtime:steer-real-e2e": "node scripts/agent-runtime-steer-real-e2e.mjs",
|
||||
"agent-runtime:steer-runner-kill-real-e2e": "node scripts/agent-runtime-real-e2e.mjs --suite steer-runner-kill",
|
||||
"typecheck": "node ../../node_modules/typescript/bin/tsc -p tsconfig.json --noEmit && node scripts/check-config.mjs"
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -460,7 +460,7 @@ fn runtime_tool_description(tool: &str) -> &'static str {
|
||||
"agent.spawn_isolated" => "创建最多三个写范围互不重叠的隔离子 Agent。",
|
||||
"agent.schedule_ready" => "调度依赖已完成的 ready manifest 任务。",
|
||||
"agent.action_history" => "查询当前 Agent 的持久终态动作历史。",
|
||||
"agent.run_status" => "读取自己或其他 Agent 的 Runtime 状态摘要。",
|
||||
"agent.run_status" => "读取自己或其他 Agent 的 Runtime 状态摘要；Project Supervisor 可按 delegationId 取回已认领的权威返工合同。",
|
||||
_ => "执行一个受 Runtime 白名单和项目策略保护的工具动作。",
|
||||
}
|
||||
}
|
||||
@@ -713,10 +713,11 @@ fn runtime_tool_input_schema(tool: &str) -> Value {
|
||||
}
|
||||
}),
|
||||
"agent.run_status" => json!({
|
||||
"type": "object", "required": ["agentId", "scope"], "additionalProperties": false,
|
||||
"type": "object", "required": ["agentId", "scope", "delegationId"], "additionalProperties": false,
|
||||
"properties": {
|
||||
"agentId": { "type": ["string", "null"] },
|
||||
"scope": { "type": "string", "enum": ["self", "all"] }
|
||||
"scope": { "type": "string", "enum": ["self", "all"] },
|
||||
"delegationId": { "type": ["string", "null"] }
|
||||
}
|
||||
}),
|
||||
_ => empty_input_schema(),
|
||||
|
||||
@@ -922,19 +922,23 @@ pub(crate) fn suppress_static_delegate_deliveries_for_parent_terminal_at(
|
||||
Ok(())
|
||||
}
|
||||
|
||||
pub(crate) fn claimed_static_delegate_receipt_count_at(
|
||||
pub(crate) fn claimed_static_delegate_deliveries_at(
|
||||
root: &Path,
|
||||
parent_agent_id: &str,
|
||||
parent_run_id: &str,
|
||||
) -> Result<usize, String> {
|
||||
Ok(list_static_delegate_deliveries_at(root)?
|
||||
) -> Result<Vec<StaticDelegateDeliveryRecord>, String> {
|
||||
validate_static_delegate_id(parent_agent_id, "parentAgentId", 96)?;
|
||||
validate_static_delegate_id(parent_run_id, "parentRunId", 160)?;
|
||||
let mut deliveries = list_static_delegate_deliveries_at(root)?
|
||||
.into_iter()
|
||||
.filter(|delivery| {
|
||||
delivery.parent_agent_id == parent_agent_id
|
||||
&& delivery.parent_run_id == parent_run_id
|
||||
&& delivery.status == StaticDelegateDeliveryStatus::ClaimedByParent
|
||||
})
|
||||
.count())
|
||||
.collect::<Vec<_>>();
|
||||
deliveries.sort_by(|left, right| left.delegation_id.cmp(&right.delegation_id));
|
||||
Ok(deliveries)
|
||||
}
|
||||
|
||||
pub(crate) fn static_delegate_claim_exists_at(
|
||||
|
||||
@@ -289,8 +289,8 @@ pub(crate) fn start_local_game_preview_for_project(
|
||||
));
|
||||
}
|
||||
|
||||
let listener =
|
||||
TcpListener::bind(("127.0.0.1", 0)).map_err(|error| format!("启动预览失败：{error}"))?;
|
||||
let listener = bind_loopback_listener_with_linux_fallback(root.to_string_lossy().as_ref())
|
||||
.map_err(|error| format!("启动预览失败：{error}"))?;
|
||||
let port = listener
|
||||
.local_addr()
|
||||
.map_err(|error| format!("读取预览端口失败：{error}"))?
|
||||
|
||||
@@ -3009,18 +3009,18 @@ fn read_external_agent_runner_linux_fallback_ports(boot_id: &str) -> Option<Vec<
|
||||
))
|
||||
}
|
||||
|
||||
fn bind_external_agent_runner_listener(boot_id: &str) -> io::Result<TcpListener> {
|
||||
pub(crate) fn bind_loopback_listener_with_linux_fallback(seed: &str) -> io::Result<TcpListener> {
|
||||
#[cfg(target_os = "linux")]
|
||||
{
|
||||
return bind_external_agent_runner_listener_with(
|
||||
|| read_external_agent_runner_linux_fallback_ports(boot_id).unwrap_or_default(),
|
||||
|| read_external_agent_runner_linux_fallback_ports(seed).unwrap_or_default(),
|
||||
|port| TcpListener::bind(SocketAddrV4::new(Ipv4Addr::LOCALHOST, port)),
|
||||
);
|
||||
}
|
||||
|
||||
#[cfg(not(target_os = "linux"))]
|
||||
{
|
||||
let _ = boot_id;
|
||||
let _ = seed;
|
||||
TcpListener::bind(SocketAddrV4::new(Ipv4Addr::LOCALHOST, 0))
|
||||
}
|
||||
}
|
||||
@@ -3038,7 +3038,7 @@ pub(crate) fn run_external_agent_runner_server(config_dir: impl AsRef<Path>) ->
|
||||
&external_agent_runner_lock_path(&config_dir),
|
||||
&boot_id,
|
||||
)?;
|
||||
let listener = bind_external_agent_runner_listener(&boot_id)
|
||||
let listener = bind_loopback_listener_with_linux_fallback(&boot_id)
|
||||
.map_err(|error| format!("绑定 Agent Runner loopback 端口失败：{error}"))?;
|
||||
listener
|
||||
.set_nonblocking(true)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -16,6 +16,15 @@
|
||||
|
||||
---
|
||||
|
||||
## 2026-07-17 AI 游戏创作 Swarm 显式重试必须使用受控真实故障门禁
|
||||
|
||||
- 背景：V1.28 `supervisor-swarm` 正式报告的 46 个 Provider request 全部 completed；确定性测试和条件式 E2E validator 虽覆盖 retry 契约，但 `failed=0 / retry=0` 仍可 PASS，不能证明真实 Provider Swarm 进入过显式重试链。
|
||||
- 决策：保留正常 `supervisor-swarm` 作为合同委派/repair/恢复协议门禁，另设 `supervisor-swarm-transient-retry`。新 suite 用 sentinel 管理的隔离 AppData 只覆盖一个专业 Agent 的 `baseUrl / maxRetries / retryBackoffMs`；本地 loopback 代理在首个 POST 转发正文前断线，后继请求先暂停。暂停期间必须证明唯一 `started -> failed`、唯一 retry audit、不同 request identity、稳定 `-transient-1` slot和相同逻辑身份，同时 action、receipt、目标 Agent 子委派、claim、assistant、pending、project revision、目标产物和 upstream forwarding 全为 0，之后才允许真实 Provider 请求继续。
|
||||
- 安全：代理不记录或返回 upstream URL、headers、Authorization、请求/响应正文或凭据，只公开计数与布尔状态；只接受 loopback origin-form POST 和原 base path，redirect 原样返回而不跟随。E2E 启动 CLI/Runner 时必须合并并同时覆盖 `NO_PROXY / no_proxy`，显式加入 `127.0.0.1 / localhost / ::1`，避免继承的系统 HTTP 代理先接触发往故障代理的凭据和正文。端口 0 耗尽时使用有界 loopback fallback，stop 必须幂等关闭全部上下游连接。隔离 AppData 创建在正式目录同级，source-dir guard 禁止本 suite 前缀进入源目录或留下残留项；源配置私有副本逐字校验，正式 Runner endpoint 身份保持不变，临时合并配置与 overlay 为 `0600` 并由 sentinel 删除。并发正式 Runner 的 heartbeat 可改变目录 mtime/ctime，不得据此把外部写入误归因给 suite。完整链后续失败时，partial report 仍必须回填已经取得的 retry checkpoint 和零副作用证据。
|
||||
- 验证：最终加强版正式 `openai_chat / gpt-5.5` 报告为 46 个 request identity、46 started/terminal、45 completed、1 failed、1 retry；受控重试前所有副作用计数为 0。代理观察到的 10 个目标 Agent 请求与该 Agent lifecycle 数量一致，其中 1 个注入失败、1 个暂停、9 个转发。放行后双专业 Agent 真重叠、2 初始 + 1 repair delivery、2 个 Observed claim、targeted contract read、pidfd Runner 强杀恢复、唯一 Supervisor assistant 和 3 条内部专业 assistant 全部成立；27/27 成功计划与 14/14 repair 全为原生工具协议，源 AppData 未被写入，重复、残留和敏感泄漏均为 0，代理、隔离 Runner/AppData/项目全部清理。
|
||||
- 范围：该门禁证明“显式重试可与既有 Swarm 完整链组合”，不证明 Supervisor 已在无 Agent ID、同轮或 repair 次数提示时自主选择编排。自主 suite、真实 `--swarm-chat`、static+isolated all-join 组合和 Tauri 宿主 E2E 保留为后续完成项。
|
||||
- 关联文档：`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`、`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`。
|
||||
|
||||
## 2026-07-16 AI 游戏创作 Agent Runtime V1.28 Supervisor 合同委派与单回复收束
|
||||
|
||||
- 背景：V1.16 已建立 Supervisor 的 durable static delivery/claim 和同一父 run 唯一回复，但旧 `agent.delegate` 只描述目标与任务，Runtime 只能确认子任务终态，不能持久证明预期产物、验证证据或返工关系；实施计划中也仍有普通用户进入单 Agent 对话的旧表述。
|
||||
@@ -24,11 +33,14 @@
|
||||
- 对话与配置边界：legacy `.agent/conversations/project.jsonl` 只作有界兼容读取，正式 Runtime user/流式草稿/final assistant 不再由 React 双写到 legacy 项目对话，规范消息只归属 Supervisor Session。正式项目页缺少 LLM/AppData 配置时只显示 Runtime 错误，由单窗口壳全局“配置”入口处理，不自动弹开发配置框。
|
||||
- 合同：新 native `agent.delegate` 的 strict schema 固定携带 `agentId / task / acceptanceCriteria / expectedArtifacts / repairOfDelegationId / runId`，六个字段均必填，后两者可为 `null`。`acceptanceCriteria` 为 1-8 项；`expectedArtifacts` 为 0-16 个精确项目内非私有相对文件，不接受 glob。旧持久 action 缺字段按空合同恢复，不迁移已有 pending/delivery/claim sidecar。
|
||||
- 交付与门禁：durable delivery、ready receipt 和 claim 快照原样保存合同及 `structuredResult`；结构化结果包含 `contractStatus=evidence-ready|needs-repair`、artifact path/SHA-256、`missingExpectedArtifacts`、`verificationRequired`、`verifiedRevision`、安全 `evidence/error`。Runtime 只在 child completed、预期产物齐全、必要 verification passed 时判 evidence-ready；语义是否满足仍由 Supervisor 按 acceptance criteria、摘要和证据裁决。
|
||||
- 返工：Supervisor 只有在同一父 run 已认领原 delivery 后，才能为 needs-repair 或语义未通过发出 `repairOfDelegationId=<原 delegationId>` 的新委派。repair 必须完整继承原合同并交回原专业 Agent，深度固定为 1，同一原 delivery 同时最多一个非 suppressed repair；相同 durable action 重放幂等复用，不同重复或并发竞争拒绝。`suppressed` repair 不算完成，同一 action 可在无终态字段时原地恢复；若该 action 已持久失败，新 action 只可在所有既有 repair 均 suppressed 时重做基础设施投递。repair 继续在原父 Session/run 收束，不产生第二条用户回复。
|
||||
- 返工：Supervisor 只有在同一父 run 已认领原 delivery 后，才能为 needs-repair 或语义未通过发出 `repairOfDelegationId=<原 delegationId>` 的新委派。repair 必须完整继承原合同并交回原专业 Agent，深度固定为 1，同一原 delivery 同时最多一个非 suppressed repair；相同 durable action 重放幂等复用，不同重复或并发竞争拒绝。`suppressed` repair 不算完成，同一 action 可在无终态字段时原地恢复；若该 action 已持久失败，新 action 只可在所有既有 repair 均 suppressed 时重做基础设施投递。repair 继续在原父 Session/run 收束，不产生第二条用户回复。首次 repair 被合同继承门禁拒绝时，失败 observation 返回同一 durable delivery 的完整权威合同，Supervisor 可据此直接逐项修正；字段缺失或身份不确定时再按 `delegationId` 定向重读。
|
||||
- Prompt 与完成：专业 Agent task prompt 必须携带完整合同并明确只交内部回执；Supervisor prompt 明确不得把 evidence-ready 自动当作语义通过，也不得忽略 needs-repair。无法自行裁决的问题统一通过既有 `user.input_request` 汇总询问用户。所有必要 delivery/claim/repair、结构化计划、verification、确认、用户输入及其它既有 blocker 清零后，才允许原 Supervisor finalization 写唯一 assistant。
|
||||
- 计划推进：单独 `update_agent_plan` 只用于步骤或状态真实变化；当前 `in_progress` 步骤已具备事实、权限和合同后必须在同一响应附带具体 action，格式修复不能把可执行动作退化为 explanation-only checkpoint。未完成计划 blocker 和 prompt 必须明确该规则，避免 Supervisor 理解了下一步却持续空转。
|
||||
- 多 action 原批次：Provider 同轮返回 2-3 个 action 时，Runtime 先持久化绑定完整 planning 身份与稳定 actionId 的私有批次，再对整批完成策略/MCP preflight。任一拒绝保证零工具执行；所有确认收齐后才从 action 0 按原顺序 dispatch。cursor 只在 observation、投影、receipt、Agent DB 与 context 全部落盘后推进；Runner 重启按原 cursor 补投影，steer、仓库漂移或非 ok observation 会持久作废剩余后缀。批次 sidecar 清理前，空 action 收束与 finalization 都必须阻断。
|
||||
- Provider 瞬态失败显式重试：`agentLlm.<agent>.maxRetries / retryBackoffMs` 由 Runtime 解释为独立物理尝试及其有界指数退避，不得在单 lifecycle 内恢复 `LlmClient` 隐式 HTTP 重放。每次尝试都重建禁用自动重试的 client，并形成自己唯一的单次 lifecycle；首次 request slot 不变，第 `N` 次重试稳定使用 `-transient-N` 后缀。只有 `timeout / connectivity / transport` 可进入重试；工具协议无效继续使用独立 `repair-N` 格式修复，其它错误与重试耗尽按原失败路径收束。退避后必须重新检查 Goal、steer、cancel、task/run 和 orphan lifecycle，控制请求可阻止下一次尝试；Runner 强杀后无可信终态的 `started` 仍进入 reconciliation，不能自动补发。重试发生在解析与副作用之前，不创建 action、pending、receipt、delivery、assistant 或 revision；既有控制、Runner、orphan、finalization 和隐私边界不放宽，公共审计不得保存 Provider 正文、arguments、凭据或绝对路径。
|
||||
- 影响范围：AI 游戏创作 Agent Runtime 的 native tool schema、静态委派 delivery/claim/receipt、恢复与 finalization、Supervisor/专业 Agent prompt、正式用户对话入口、确定性测试和真实 Provider E2E；编码级细节以 Runtime V1.28 章节为准。
|
||||
- 验证方式：确定性回归覆盖 strict schema、旧 action 空合同恢复且 sidecar 不迁移、合同跨 Runner 重启、artifact/verification 客观门禁、语义验收边界、单层唯一 repair、并发幂等和 final barrier。真实 `gpt-5.5` swarm 必须证明同一 Supervisor run 下两个专业 Agent 真并行、一份弱交付恰好触发一次 repair、唯一 Supervisor assistant、重复 action/receipt/message 为 0、敏感信息泄漏为 0。
|
||||
- 当前状态：Runtime 当前实现切片及其定向本地回归已完成。`project_supervisor_` 30/30 与 native 合同 parser→executor→delivery 1/1 PASS，覆盖真实 SHA/verification、旧 sidecar 字节不迁移、双线程 repair 唯一活跃投递、suppressed repair 阻断与同 action/新 action 基础设施恢复、父 lane 忙时损坏证据持续重试 reconciliation、规范字段和别名空合同拒绝及唯一 Supervisor assistant/completed；正式 GUI 接入后的 `appSurface.test.ts` 当前为 279/279 PASS。这不代表完整 V1.28 验收清单已通过：Runner 强杀恢复仍未验收；修正隔离测试驱动后，真实 `openai_chat / gpt-5.5` 在 Supervisor 首轮 planning 即发生 transport failure 且未创建 delivery，因此“双专业 Agent 真并行、一次弱交付恰好一次 repair、Runner 强杀恢复、唯一最终回复”的真实门禁仍未通过，V1.28 整体保持 NOT PASS。
|
||||
- 当前状态：PASS。2026-07-17 正式 `openai_chat / gpt-5.5` `supervisor-swarm` 已证明同一 native 批次双专业委派、真实 Provider 重叠、2 份初始 delivery、1 次 targeted contract read、唯一 repair、pidfd Runner 强杀/boot 恢复、同一父 Session/run、唯一 Supervisor assistant 和专业回复仅内部可见。报告为 46/46 Provider lifecycle 闭合且 completed，成功计划 24/24、格式修复 20/20 全为原生工具协议；重复、残留 sidecar、正文/凭据/绝对路径/报告泄漏均为 0。真实门禁同时发现并修复 `agent.message` 公共审计保存绝对 conversation path 的缺陷，现统一保存 `.agent/conversations/...` 项目相对路径并有定向回归。
|
||||
- 关联文档：`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`、`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`。
|
||||
|
||||
## 2026-07-16 AI 游戏创作 Agent Runtime 只并行持久只读批次
|
||||
@@ -155,6 +167,7 @@
|
||||
- 影响范围：`api-server` assets / external assets / admin 路由、后台资源查询图片放大和音视频预览、OSS 读取契约与安全测试。
|
||||
- 验证方式：定向测试覆盖 curated `legacyPublicPath` 可匿名签名、任意未登记 `objectKey` 拒绝、`PublicRead` 可读、owner 私有对象仅本人可读、External 跨 owner 拒绝、Admin endpoint 仅管理员可用，以及 `read-bytes` 与 `read-url` 同授权。
|
||||
- 关联文档：`docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md`。
|
||||
|
||||
## 2026-07-09 角色动作视频生成背景色统一为多色自动决策 + 阿里云抠帧
|
||||
|
||||
- 背景：角色动作视频抽帧过去固定 legacy `#00FF00` 绿幕 + 本地 `editor_green_screen`，与生图链路的多色自动决策不一致；实测出现背景色与前景 / 皮肤撞色（蓝撞蓝、桃 / 黄撞肤色）以及图生视频背景变白的问题。
|
||||
@@ -4464,6 +4477,7 @@
|
||||
- 权威查询：`asset_object` 不进入 client 长期订阅。API 通过仅 runtime service identity 可调用的 procedure，按主键或 `(bucket, object_key)` 服务端索引读取事务内 metadata；只有位置查询明确返回不存在时才允许进入 legacy curated 前缀兼容，procedure 失败、超时或重复位置一律失败关闭。
|
||||
- 一致性：隐藏、删除或取消发布提交后，后续读取 procedure 的事务快照立即按新状态判断，不等待任意池连接追上订阅水位。公开派生授权、`PublicRead` 和 legacy 兼容读取签名 URL 的有效期最多 600 秒，因此该能力仍不是对既有签名的瞬时吊销机制；owner / admin 读取保持原有效期口径。
|
||||
- 验证方式：公开可见作品的正式资产可匿名读取；未选候选图、参考图、跨 owner 伪造 key 仍返回不存在；隐藏、删除或取消发布后新的读取请求立即拒绝，再恢复公开可见时新的读取请求立即恢复；超长公开 `expireSeconds` 被截断为 600 秒。
|
||||
|
||||
## 2026-07-13 AI 游戏创作 Agent Runtime V1.4 Git 工作树审阅
|
||||
|
||||
- 决策：新增一等只读 `git.inspect`，共享 command id 为 `project.git_inspect`且默认 `auto`。工具只接受 `includeDiff / maxFiles / maxChars`，返回精确 Git top-level 的 HEAD / branch、staged / unstaged / untracked 安全路径和有界 staged / unstaged unified diff；不改项目 revision 或 verification gate。
|
||||
|
||||
@@ -92,6 +92,18 @@ npm run ai-game-creator-shell:typecheck
|
||||
|
||||
第一条覆盖固定程序 / argv 拒绝规则、输出清洗、超时和源码改写检测；第二条覆盖全局 / per-Agent 配置继承，第三条覆盖 `default / low / medium / high` 到 Provider 请求的映射；后两条覆盖共享 `confirm` 契约、配置结构和发布默认 `high`。模块级定向验证通过后，再按改动范围运行 `npm run ai-game-creator-shell:check`、`npm run check:encoding` 和 `git diff --check`。
|
||||
|
||||
### AI 游戏创作 Swarm 显式重试真实复验
|
||||
|
||||
正常 `supervisor-swarm` 全部 completed 不能替代真实 retry 证据。修改 Runtime 显式重试、Provider lifecycle、隔离 AppData 或 Swarm 验收器后，先跑代理夹具和静态门禁，再运行独立真实 suite：
|
||||
|
||||
```bash
|
||||
npm run test -- apps/ai-game-creator-shell/tests/llmTransientFaultProxy.test.ts
|
||||
npm run ai-game-creator-shell:typecheck
|
||||
npm run ai-game-creator-shell:agent-runtime:supervisor-swarm-transient-retry-real-e2e -- --config-dir <AppData>
|
||||
```
|
||||
|
||||
真实 PASS 必须恰好包含 1 个 failed lifecycle、1 条 retry audit 和 1 个 `-transient-1` 后继 identity；forwarding gate 放行前 action、receipt、目标 Agent 子委派、claim、assistant、pending、project revision 与 upstream forwarding 全为 0。放行后仍须完成双专业 Agent 重叠、唯一 repair、Runner 强杀恢复、唯一 Supervisor assistant 和零重复/残留/泄漏。suite 只能读正式 AppData，在其同级目录写入 sentinel 管理的 `0600` 私有副本和 overlay；启动 CLI/Runner 时须把 loopback 合并进大小写两套 no-proxy 环境，防止系统 HTTP 代理绕过本地故障门禁；source-dir guard 必须证明本 suite 前缀未进入源目录，源配置和 endpoint 身份保持不变，报告不得保存 Provider URL、headers、正文、凭据或绝对配置路径。若后续 repair/恢复/终局失败，partial report 仍应保留已经取得的 retry checkpoint。
|
||||
|
||||
### AI 游戏创作 Runtime V1.10 持久进程定向复验
|
||||
|
||||
V1.10 的 PTY 只通过四个 Runner-owned 工具开放；不要把 V1.2 `command.exec` 改成长驻入口。最小工具输入保持结构化：
|
||||
|
||||
@@ -14,6 +14,14 @@
|
||||
- 关联：相关文件、文档、提交或 Issue
|
||||
```
|
||||
|
||||
## Provider 全成功的真实报告不能证明显式重试可用
|
||||
|
||||
- 现象：真实 Swarm 报告显示全部 Provider lifecycle completed，E2E 的 retry validator 也没有报错，于是文档把“支持瞬态重试”一并写成已真实验收。
|
||||
- 原因：validator 只在实际出现 failed lifecycle 时校验 retry audit；`failed=0 / retry=0` 会自然通过。随机等待外部网络故障既不可重复，也无法在故障和重试之间证明副作用仍为 0。
|
||||
- 处理：为重试单独建立 fail-first loopback proxy。在正式 AppData 同级创建 sentinel 管理的一次性目录，只覆盖其中一个目标 Agent 的 base URL 和重试配置；首个 POST 在正文进入 upstream 前断线，第二个请求由 forwarding gate 暂停。gate 内交叉检查 failed lifecycle、retry audit、request slot/identity、action、pending、receipt、delivery、claim、assistant、project revision 和目标产物，再显式放行真实 Provider。代理不能记录 URL、headers 或正文，不能跟随 redirect，必须可幂等清理；启动 CLI/Runner 时同时设置合并后的 `NO_PROXY / no_proxy` 并显式加入 loopback，不能假设开发机已正确配置代理绕过；source-dir guard 禁止本 suite 前缀进入源目录，配置和 endpoint 身份保持只读并逐字复核。不要用源目录 mtime/ctime 归因，正式 Runner heartbeat 会并发改变它。完整链在 checkpoint 后失败时，partial report 也要保留已取得的 identity、slot 和零副作用证据，不能退回模板默认值。
|
||||
- 验证：`npm run test -- apps/ai-game-creator-shell/tests/llmTransientFaultProxy.test.ts` 覆盖故障、暂停、base path、流式转发、fallback、隐私和清理；`npm run ai-game-creator-shell:agent-runtime:supervisor-swarm-transient-retry-real-e2e -- --config-dir <AppData>` 必须得到恰好 1 failed/1 retry、重试前副作用全 0，并继续通过完整 Swarm/Runner 恢复和零泄漏门禁。
|
||||
- 关联：`apps/ai-game-creator-shell/scripts/llm-transient-fault-proxy.mjs`、`apps/ai-game-creator-shell/scripts/agent-runtime-real-e2e.mjs`、`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`。
|
||||
|
||||
## Agent 真实验收的阶段等待必须同步观察 Runtime 终态
|
||||
|
||||
- 现象：真实 Provider 已因 transport、格式修复或其它不可恢复错误把 task/Runtime 写成 failed，专项验收仍在等待某个 pending action、observation 或 receipt，直到 30 分钟总超时才返回。
|
||||
@@ -3162,11 +3170,11 @@
|
||||
|
||||
## loopback port 0 也会被临时端口池耗尽阻断
|
||||
|
||||
- 现象：旧 Runner 已停止、endpoint 连接拒绝，但新 Runner 在 `TcpListener::bind(127.0.0.1:0)` 直接返回 `Address already in use`，所有 Agent 写命令随后报“Runner 在就绪前退出”。
|
||||
- 现象：旧 Runner 已停止、endpoint 连接拒绝，但新 Runner 在 `TcpListener::bind(127.0.0.1:0)` 直接返回 `Address already in use`，所有 Agent 写命令随后报“Runner 在就绪前退出”；同一主机上的本地预览和 Node HTTP 测试夹具也会以相同方式失败。
|
||||
- 原因：port 0 仍需要内核从 `ip_local_port_range` 分配监听端口；本机 api-server 与 SpacetimeDB 的约 2.8 万双向连接占满 32768-60999 后，即使目标端口不是旧 endpoint 端口，自动分配也会失败。只看 `ss -ltn` 会漏掉占用本地端口的 established client socket。
|
||||
- 处理：先保留 port 0 正常路径；Linux 只在 `AddrInUse` 后懒读取 `ip_local_port_range / ip_unprivileged_port_start / ip_local_reserved_ports`，把候选限制在 61000-65535 高位段并排除临时范围、实际特权范围和 reserved ranges，再按随机起点尝试。不要停止用户 dev 栈，不要扫描常见服务低端口，不要使用非 loopback fallback，也不要用固定公开端口或无 token 协议绕过。
|
||||
- 验证：除纯 bind 回退、懒加载、非默认特权起点、reserved ranges、候选耗尽和范围解析单测外，还要在端口池真实耗尽的主机上启动 Runner，确认 endpoint 端口位于临时范围外、heartbeat 可读，并完成真实 Provider 任务。
|
||||
- 关联：`apps/ai-game-creator-shell/src-tauri/src/runner.rs`、`agent-runtime-real-e2e.mjs`、`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`。
|
||||
- 处理：先保留 port 0 正常路径；Linux 只在 `AddrInUse` 后懒读取 `ip_local_port_range / ip_unprivileged_port_start / ip_local_reserved_ports`，把候选限制在 61000-65535 高位段并排除临时范围、实际特权范围和 reserved ranges，再按随机起点尝试。Runner 与本地预览复用同一 loopback binder；必须交给外部测试进程监听时，先用有同等回退能力的测试 listener 预留端口并有限重试交接。不要停止用户 dev 栈，不要扫描常见服务低端口，不要使用非 loopback fallback，也不要用固定公开端口或无 token 协议绕过。
|
||||
- 验证：除纯 bind 回退、懒加载、非默认特权起点、reserved ranges、候选耗尽和范围解析单测外，还要在端口池真实耗尽的主机上启动 Runner 和本地预览，确认监听端口位于临时范围外、heartbeat 与预览内容可读，并完成真实 Provider 任务及 MCP HTTP fixture 全量回归。
|
||||
- 关联：`apps/ai-game-creator-shell/src-tauri/src/runner.rs`、`preview.rs`、`tests.rs`、`agent-runtime-real-e2e.mjs`、`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`。
|
||||
|
||||
## 旧 process record 惰性迁移不能替代 resume 主动投影
|
||||
|
||||
@@ -3217,6 +3225,9 @@
|
||||
- 原因：开发 CLI 直接序列化 `AgentRuntimeResult`，把仅供 Tauri/App 定位本地 sidecar 的 `sessionPath / eventPath / taskPath` 一并写进 `runtimeJson`。后续 confirm、steer 和 resume 复用同一结果结构，也会重复暴露。
|
||||
- 处理：保持 Tauri 内部契约不变，只在 CLI JSON 输出视图递归删除三个存储路径；`state`、task queue、events、tasks、run/session/action 身份和 steer 状态继续保留，验收器仍能解析必要证据。不要靠 E2E 忽略 CLI stdout，也不要笼统删除所有 `path` 字段破坏安全相对产物证据。
|
||||
- 验证：CLI serializer 单测覆盖顶层、嵌套和数组结果；真实 `--agent-runtime-status` 输出对 disposable 项目路径命中为 0，后续完整 `llm-runtime` 报告的 `projectPathTranscriptLeakCount / projectPathReportLeakCount` 必须同时为 0。
|
||||
- 补充现象：`agent.message` 已把正文安全写入目标 Agent 的私有 tool 会话，但 `.agent/agent.db` 的 `agent.runtime.agent.message.path` 直接复用了 conversation 返回的绝对路径，导致真实 Supervisor swarm 的公共路径门禁失败。
|
||||
- 补充处理：会话文件仍由项目内部 API 创建，写公共审计前必须再用项目根做 `strip_prefix`、路径分隔统一和相对路径规范化，只保存 `.agent/conversations/agents/<agentId>.jsonl`；不能通过 E2E 忽略该 record，也不能笼统删除所有相对 `path` 证据。
|
||||
- 补充验证：`background_agent_runtime_can_write_blackboard_and_message_other_agent` 同时证明 tool 消息可读、`agent.runtime.agent.message` 唯一存在、path 等于规范项目相对路径且 `Path::is_absolute=false`；正式 `supervisor-swarm` 的 Agent DB 项目路径泄漏计数必须为 0。
|
||||
|
||||
### 把模型修复上下文写入公共审计会泄露正文
|
||||
|
||||
|
||||
@@ -1021,7 +1021,7 @@ V1.27 在 V1.26 一次最多三个原生 action 的基础上，让同一 Agent
|
||||
|
||||
V1.28 收紧 V1.16 的静态专业 Agent 协作协议：`project-supervisor` 是正式用户唯一默认对话 Agent，也是唯一可以向正式用户提交最终回复的 Agent；静态专业 Agent 与 isolated child 只向父 run 交付内部回执、摘要和证据。开发窗口仍可直调单个专业 Agent，`agc:swarm` 仍可显式指定其它父 Agent 做调试，但这些入口不构成正式用户对话或第二条用户回复。若本节与 V1.16 或实施计划中的旧表述冲突，以本节为准。
|
||||
|
||||
**状态：合同委派、结构化回执、单层 repair 和 Supervisor finalization 门禁已进入 Runtime；正式用户 GUI 已把项目开发页的普通主聊天接入 `project-supervisor` active Session，当前实现切片与前端定向回归已通过。但 Runner 强杀恢复和真实 `gpt-5.5` 双 Agent swarm 加恰好一次 repair 尚未完成验收，因此 V1.28 整体仍为 NOT PASS。**
|
||||
**状态：PASS。合同委派、结构化回执、单层 repair、Supervisor finalization、正式用户 GUI 接入和 Runtime 显式瞬时重试均已落地；2026-07-17 正式 `openai_chat / gpt-5.5` `supervisor-swarm` 已完成双专业 Agent 真并行、唯一 repair、pidfd Runner 强杀恢复、唯一 Supervisor assistant、零重复与零泄漏的完整验收。**
|
||||
|
||||
### 正式 GUI 接入边界
|
||||
|
||||
@@ -1081,21 +1081,52 @@ Supervisor 只有在同一父 run 已认领原 delivery，且原回执为 `needs
|
||||
|
||||
repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `suppressed` repair。相同 durable action/身份重放必须幂等复用已预留或已创建的 repair；不同 action 的重复或并发竞争必须在 delivery 锁内发现既有非 suppressed repair 后拒绝，不能创建第二个活跃目标 run、第二份可认领回执或 `-dup-*` repair。repair 结果继续唤醒、认领并收束到原 Supervisor Session/run；它不能创建第二条面向用户的 assistant。repair 再次 `needs-repair` 时不得继续嵌套委派，Supervisor 只能基于现有证据裁决或走用户输入门禁。`suppressed` repair 不视为已完成返工，原 `repairRequired` 门禁必须继续阻断 finalization；同一 durable action 可以在无终态字段时把原 delivery 恢复为 `dispatched`，若该 action 已持久失败，新 action 也只可在既有 repair 全部 suppressed 时创建替代的基础设施投递，不能形成第二轮语义返工。
|
||||
|
||||
Supervisor 认领回执后必须能够再次从 durable delivery 取回权威返工合同，不能依赖首次 `agent.run_status` observation 或模型记忆。普通 `agent.run_status` 要返回有界的 `claimedDelegateContracts` 目录，至少包含 `delegationId / targetAgentId / repairOfDelegationId / contractStatus / acceptanceCriteriaCount / expectedArtifactsCount`；带可选 `delegationId` 查询时，只允许原 `project-supervisor` 父 run 读取属于自己且已 `claimed-by-parent` 的 delivery，并返回未截断的 `delegationId / targetAgentId / acceptanceCriteria / expectedArtifacts / repairOfDelegationId / deliveryStatus / terminalStatus / contractStatus`。该查询是只读、可幂等重放的私有 observation，不返回 task 正文、Provider payload、凭据或绝对路径；合同超过明确有界输出上限时失败关闭，不能截断后让模型猜测。返工被“合同未完整继承”拒绝时，失败 observation 必须携带同一 durable delivery 的完整 `claimedDelegateContract` 权威快照，Supervisor 可直接逐字段据此修正；该字段缺失或身份不确定时才必须按原 `delegationId` 重读，不得重复无目标地轮询状态或从 action history 的摘要反推。
|
||||
|
||||
### Prompt 与完成门禁
|
||||
|
||||
- 专业 Agent 的 task prompt 必须带完整委派合同：`delegationId / task / acceptanceCriteria / expectedArtifacts / repairOfDelegationId`，以及当前 Agent/Session/run 与父 Supervisor 身份；同时明确它只提交内部回执和证据，不直接回答正式用户。
|
||||
- 结构化计划 checkpoint 只有在步骤或状态真实变化时才允许单独提交。当前 `in_progress` 步骤所需事实、权限和合同已经齐全时，Agent 必须在同一 Provider 响应附带具体 action；格式修复也必须保留原本可执行的动作意图，不能连续只改 `explanation` 或反复只调用 `update_agent_plan`。Runtime 的未完成计划 observation 和 `nextStep` 使用同一口径，真实 E2E 对 repair 创建另设有界父 loop 门禁。
|
||||
- Supervisor prompt 必须明确：不得把 `evidence-ready` 当作自动语义通过，不得忽略或吞掉 `needs-repair`；对无法自行裁决的冲突、缺失决策或用户偏好，只能汇总后通过既有 `user.input_request` 向用户提问，专业 Agent 与 child 不得各自直达用户。
|
||||
- finalization 在项目锁内必须确认所有必要 static delivery 已终态、ready 已认领、claim 已 Observed、允许的单次 repair 已收束；同时要求结构化计划全部完成，并清零 verification、pending confirmation、`user.input_request`、process/reconciliation、isolated join、Goal/steer 等既有 blocker。只有原 `project-supervisor` Session/run 可以随后写入唯一正式用户 assistant 和 completed 投影。
|
||||
|
||||
### Provider 多 action 原批次门禁
|
||||
|
||||
为了让 Supervisor 在同一原生 planning 中提交两个专业委派，同时保持确认顺序和崩溃恢复，Provider 一轮返回 `2-3` 个 action 时必须先建立私有 durable action batch，再允许任何成员产生工具副作用。批次绑定 project、Agent、task、Session、run、loop、steer cursor、完整计划、项目 revision、仓库上下文指纹及全部稳定 actionId；不能在恢复时重新请求 Provider 或重建新身份。
|
||||
|
||||
- Runtime 必须先对整批 action 完成本地策略和 MCP policy preflight。任一成员被拒绝时整批进入 `aborted`，所有成员保持零工具执行，只投影一份稳定拒绝 observation；存在确认成员时整批进入 `waiting-confirmation`，收集完全部精确确认之前，位于确认动作前后的 auto 成员都不得执行。
|
||||
- 全部确认完成后批次进入 `ready`，从 `nextActionIndex=0` 按 Provider 顺序执行。连续安全只读成员仍可复用 V1.27 parallel-read batch；两个 `agent.delegate` 虽按顺序完成 durable dispatch，但 child lane 可在第二个 dispatch 后并行运行。任一成员返回非 `ok`、same-run steer 或仓库上下文漂移时，剩余后缀先持久标记为 `superseded`，不得继续执行。
|
||||
- cursor 只能在成员的 observation、公共投影、receipt、Agent DB 和 context bundle 全部持久化后推进。Runner 重启必须分别恢复缺失的 confirmation sidecar、尚未首次 dispatch 的 `ready` 批次，以及“cursor 已推进但 observed pending 尚未删除”的窗口；相同 actionId 的恢复只补缺失投影，不增加物理副作用、receipt 或 action event。
|
||||
- `waiting-confirmation / ready / aborted / superseded / completed` sidecar 未完成幂等收束前，空 action 完成分支和 finalization 都必须由 `runtime.provider_action_batch` blocker 阻断。Goal pause/resume 不得把 `ready` 批次降级成普通 `planning`，而要保留原 loop、steer 与 action cursor 并投影 `provider-action-batch`。
|
||||
|
||||
### Provider 瞬态失败显式重试
|
||||
|
||||
真实 Swarm 会同时放大多个长 tool-plan 请求，上游连接在尚未返回任何可解析响应时可能出现 timeout、connectivity 或 transport 失败。Runtime 不得把 `LlmClient.maxRetries` 恢复成单 lifecycle 内部的隐式 HTTP 重放；已有 `agentLlm.<agent>.maxRetries / retryBackoffMs` 改由 Runtime 解释为可审计的物理请求重试上限和基础退避。
|
||||
|
||||
- 每个物理尝试继续使用单次请求 client，并写自己唯一的 `started -> completed | failed | interrupted` Provider lifecycle。首次 slot 保持原值；第 `N` 次瞬态重试使用稳定后缀 `-transient-N`，因此 requestId、slot 和 lifecycle 都可区分，不能把两次物理请求伪装成同一条 lifecycle，也不能覆盖失败终态。
|
||||
- 只允许 `timeout / connectivity / transport` 进入显式重试。Provider 已返回但工具协议格式无效时继续走既有 `repair-N` 请求；HTTP 业务错误、配置错误、非法请求、反序列化、空回复和重试耗尽仍按当前 run 失败。重试发生在响应被解析和任何工具副作用之前，不创建 action、pending、receipt、delivery、conversation assistant 或项目 revision。
|
||||
- 每次重试前重新构建无自动重试的 LLM client，按 `retryBackoffMs * 2^(N-1)` 有界等待；等待结束后重新经过 Provider snapshot 的 Goal、steer、cancel、task/run 和 orphan lifecycle 门禁。期间收到控制请求时不得启动下一次物理请求；Runner 强杀后只有 `started` 无可信终态仍进入 reconciliation，不因配置了重试而自动补发。
|
||||
- 公共重试审计只保存 Agent/task/Session/run、request kind、原 request slot、重试序号、最大次数、错误 kind、错误指纹和字符数，不保存 URL、请求/响应正文、function arguments、凭据或绝对路径。验收必须逐 requestId 证明 lifecycle 无重复、全部已终态，并把失败物理尝试与 retry audit 一一对应；最终成功允许此前存在已闭合的瞬态失败，但不允许孤立 `started`、同 requestId 双终态或副作用重放。
|
||||
|
||||
### 验收口径
|
||||
|
||||
确定性测试至少覆盖 strict native schema、路径与数量边界、旧 action 空合同恢复且 sidecar 字节不迁移、合同字段跨 Runner 重启保持、客观 `evidence-ready / needs-repair` 判定、artifact SHA-256、verificationRequired、claim 快照、语义不自动通过、单层 repair、同原 delivery 并发 repair 幂等/拒绝、repair 后 final barrier，以及专业 Agent/child 无用户 assistant。
|
||||
|
||||
真实 `gpt-5.5` swarm 验收必须在无固定工具顺序和修复配方的任务中，由同一 `project-supervisor` 父 run 并行委派两个专业 Agent；其中一份弱交付必须形成可解释的 `needs-repair` 或被 Supervisor 判为语义不满足，并恰好触发一次 repair。验收期间强杀并重启 Runner，证明合同、delivery/claim/repair 身份和原父 Session/run 不丢失；最终正式用户 conversation 只有一条由 `project-supervisor` 写入的 assistant。全量 task/event/action/delivery/claim/receipt/conversation/Provider lifecycle 交叉检查必须得到重复 action、receipt、message 均为 `0`，且凭据、私有正文、绝对路径、诱饵和 Provider payload 泄漏均为 `0`。
|
||||
|
||||
2026-07-16 本地确定性回归已完成当前实现切片：`project_supervisor_` 30/30 PASS，另有 native `agent.delegate` 合同从 function call parser 到执行器和 durable delivery 的贯通测试 1/1 PASS。覆盖真实 artifact SHA-256、缺失产物与 verification gate、旧 Ready sidecar 字节不迁移、同原 delivery 双线程 repair 竞争只产生一个活跃 delivery/task/audit、错误目标与 repair-of-repair 拒绝、`suppressed` repair 持续阻断且同 action/新 action 基础设施恢复、父 lane 忙时损坏 verification 持续重试并在释放后进入 reconciliation、规范字段和别名的显式空合同执行器拒绝，以及 repair 前零 assistant、repair 后唯一 Supervisor assistant/completed。正式 GUI 接入后的 `appSurface.test.ts` 当前为 279/279 PASS，覆盖首页首条需求只投递 active Supervisor Session、已有项目恢复、非终态 run same-run steer、专业 Agent 只读状态、开发入口隔离、legacy 项目对话零新增双写和唯一终态 assistant。Runner 重启扫描会再次发布终态 child 并重新挂接 reconciliation 重试，但本轮尚未完成强杀验收。
|
||||
2026-07-16 本地确定性回归已完成当前实现切片：`project_supervisor_` 30/30、`provider_action_batch_` 12/12、`parallel_read_batch_` 8/8、终态 receipt reconciliation 1/1 PASS，另有 native `agent.delegate` 合同从 function call parser 到执行器和 durable delivery 的贯通测试 1/1 PASS。覆盖真实 artifact SHA-256、缺失产物与 verification gate、旧 Ready sidecar 字节不迁移、同原 delivery 双线程 repair 竞争只产生一个活跃 delivery/task/audit、错误目标与 repair-of-repair 拒绝、`suppressed` repair 持续阻断且同 action/新 action 基础设施恢复、父 lane 忙时损坏 verification 持续重试并在释放后进入 reconciliation、多 action 整批预检、零副作用拒绝、确认聚合、修改后验证 gate 滚动、稳定 cursor 恢复、Agent DB 终态先于 cursor 推进、steer 作废后缀及 Goal resume 不回退 cursor、规范字段和别名的显式空合同执行器拒绝，以及 repair 前零 assistant、repair 后唯一 Supervisor assistant/completed。正式 GUI 接入后的 `appSurface.test.ts` 当前为 280/280 PASS，覆盖首页首条需求只投递 active Supervisor Session、已有项目恢复、非终态 run same-run steer、专业 Agent 只读状态、开发入口隔离、legacy 项目对话零新增双写和唯一终态 assistant。Runner 重启扫描会再次发布终态 child 并重新挂接 reconciliation 重试，但本轮尚未完成强杀验收。
|
||||
|
||||
同日真实 Provider 验收未通过。第一次隔离运行的测试驱动误把多行任务拆成多个 steer，不能作为并行结论；修正为单条输入并移除逐个确认后，正式 `openai_chat / gpt-5.5` 在 Supervisor 首轮 planning 即返回 transport failure，尚未创建 delivery。此前那次较长运行也以同类 transport failure 终止，且只形成一个专业委派。因此当前没有“双专业 Agent 真并行、一次弱交付恰好一次 repair、Runner 强杀恢复、唯一最终回复”的真实证据，不得记录 V1.28 PASS。
|
||||
2026-07-17 正式 `openai_chat / gpt-5.5` `supervisor-swarm` 完整 PASS：同一 native Provider 批次产生 2 个初始 `agent.delegate`，design/quality 两个专业 Agent 的物理 Provider 区间真实重叠；2 份初始 delivery 经 1 个 Observed claim 的 2 条 receipt 认领，质量弱交付经 1 次 targeted contract read 创建唯一继承原合同的 repair，repair 再由第二个 Observed claim 的 1 条 receipt 认领。repair 待确认动作前后完成 Linux pidfd Runner 强杀、boot 变化、恢复扫描和同一父 Session/run 身份保持；最终只有 1 条 `project-supervisor` 用户 assistant，3 条专业 assistant 只留在内部 Session。
|
||||
|
||||
正式报告包含 46 个 Provider request identity，`46 started / 46 terminal / 46 completed / 0 failed`；成功计划 `24/24`、格式修复 `20/20` 均使用 `native_runtime_tools`，wrapper/text fallback 为 `0`。父计划 5 步全部 completed，2 个公开项目文件通过宿主验证；4 个 run 共 16 个 finalization stage。delivery、message、action lifecycle、executing action、receipt、Provider lifecycle 的重复计数均为 `0`，pending/batch/finalization/confirmation/user-input sidecar 均为 `0`，steer、Provider payload、私有正文、API Key、项目绝对路径、正式配置路径、报告、secret 和 lure 泄漏均为 `0`。suite 只使用 sentinel 管理的隔离 AppData，正式配置 CLI 调用为 `0`，源 Runner endpoint 未变化，隔离 Runner/AppData 已清理。
|
||||
|
||||
## V1.29 Project Supervisor 受控瞬态重试真实门禁
|
||||
|
||||
2026-07-17 新增独立 `supervisor-swarm-transient-retry` 真实门禁，补足上述 `0 failed` 报告未触发显式重试的证据缺口。suite 在正式 AppData 的同级目录创建 sentinel 管理的一次性 AppData，只把 `design-director` 配置指向本地回环 fail-first 代理，并把该 Agent 设为 `maxRetries=1 / retryBackoffMs=100`；正式 AppData 目录和文件只读，其他 Agent 保留源配置。代理在首个 POST 向真实 upstream 转发正文前主动断开，第二个请求先停在 forwarding gate；验收器在放行前交叉读取 lifecycle、retry audit、action、pending、receipt、delivery、claim、conversation、project revision 和目标产物，随后才让同一重试请求进入真实 Provider。代理只保留计数，不保存或输出 upstream URL、headers、Authorization、请求/响应正文或凭据；E2E 启动 CLI/Runner 时把 `127.0.0.1 / localhost / ::1` 合并进 `NO_PROXY` 和 `no_proxy`，防止继承的系统 HTTP 代理先接触凭据或正文。源配置副本和临时 overlay 均为 `0600`，source-dir guard 必须证明源目录未出现本 suite 前缀的事件或残留项，配置 inode/内容和 Runner endpoint 身份保持不变，并由 sentinel 清理隔离目录。源目录 mtime/ctime 不能作为归因证据，因为并发正式 Runner 会合法刷新 endpoint heartbeat。
|
||||
|
||||
最终加强版正式 `openai_chat / gpt-5.5` 复验 PASS：46 个 Provider request identity 全部形成唯一终态，`46 started / 46 terminal / 45 completed / 1 failed`，恰好 1 条 retry audit；失败 attempt 与后继 `-transient-1` 使用不同 request identity，Agent/task/Session/run/source/request kind 保持一致。forwarding gate 放行前 action、receipt、专业子委派、claim、assistant、pending、project revision 和 upstream forwarding 均为 `0`。代理观察到的 10 个目标 Agent 请求与该 Agent lifecycle 数量一致，其中 1 个注入失败、1 个暂停、9 个转发。放行后仍完成 2 个初始专业 Agent 真重叠、2+1 delivery、2 个 Observed claim、1 次 targeted contract read、唯一 repair、pidfd Runner 强杀/boot 恢复、5 步父计划、唯一 Supervisor assistant 与 3 条内部专业 assistant；27/27 成功计划和 14/14 repair 均为 `native_runtime_tools`。重复、残留 sidecar、Provider payload、私有正文、API Key、项目/正式配置路径、报告、secret 与 lure 泄漏均为 `0`；source-dir suite-prefix guard 与 `sourceAppDataDirectoryUntouched` 证明正式 AppData 未被写入，物理请求/lifecycle 一一对应和失败 partial checkpoint 门禁均通过，代理、隔离 Runner/AppData/项目全部清理。
|
||||
|
||||
该受控 suite 是 V1.28 协议与恢复的故障注入门禁，不替代后续自主 Swarm 验收。现有 fixture 明确给出两个专业方向、同轮要求和一次 repair 上限；“Supervisor 在不提供 Agent ID、并行配方或 repair 次数时自主选择编排”仍需独立 `supervisor-swarm-autonomous` 真实 suite 证明。真实 `--swarm-chat`、同一 run 的 static delivery + isolated all-join 组合以及 Tauri/WebView 宿主级 Supervisor GUI 也仍是单独完成项。
|
||||
|
||||
## 验收命令
|
||||
|
||||
@@ -1104,6 +1135,7 @@ repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `sup
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml goal_context_bundle_v4_migrates_v3_and_v2_then_rejects_plan_mismatch -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml response_stream_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml mcp_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml provider_action_batch_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml parallel_read_batch_ -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml swarm_cli::tests -- --nocapture`
|
||||
- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml typed_goal_pause_and_cancel_require_durable_intent_and_keep_exact_run -- --nocapture`
|
||||
@@ -1123,6 +1155,8 @@ repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `sup
|
||||
- `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite scoped-agents`
|
||||
- `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite project-skill`
|
||||
- `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite parallel-read`
|
||||
- `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite supervisor-swarm`
|
||||
- `npm run ai-game-creator-shell:agent-runtime:supervisor-swarm-transient-retry-real-e2e -- --config-dir <AppData>`
|
||||
- `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite full`
|
||||
- `npm run check:encoding`
|
||||
- `git diff --check`
|
||||
|
||||
@@ -584,5 +584,7 @@ game-project/
|
||||
- V1.28 的新 native `agent.delegate` 必须同时携带 `agentId / task / acceptanceCriteria / expectedArtifacts / repairOfDelegationId / runId`，其中 `acceptanceCriteria` 为 1-8 项，`expectedArtifacts` 为 0-16 个精确项目内非私有相对文件，两个引用字段可为 `null`。旧持久 action 缺字段只按空合同恢复，已有 pending/delivery/claim sidecar 不迁移。durable delivery 与 claim receipt 原样保存合同和 `structuredResult`，后者包含 `evidence-ready | needs-repair`、artifact path/SHA-256、缺失产物、验证要求与 revision、安全 evidence/error。
|
||||
- Runtime 只按 child completed、预期产物齐全和必要 verification passed 判定 `evidence-ready`；Supervisor 仍须按 `acceptanceCriteria` 结合摘要与证据做语义验收，不能把 evidence-ready 自动视为通过，也不能忽略 needs-repair。专业 Agent prompt 带完整合同；无法自行裁决的问题由 Supervisor 汇总后通过 `user.input_request` 向用户提问。
|
||||
- Supervisor 认领原 delivery 后可为 needs-repair 或语义未通过创建一个 `repairOfDelegationId=<原 delegationId>` 的新委派。repair 必须完整继承原合同并交回原专业 Agent，只能留在同一父 run、深度为 1、同一原 delivery 同时最多一个非 suppressed 投递；相同重放幂等复用，不同重复/并发请求拒绝。`suppressed` repair 继续阻断，同一 action 可原地恢复；该 action 已持久失败时，新 action 只可在全部既有 repair 均 suppressed 时重做基础设施投递。所有必要 delivery/claim/repair、结构化计划、verification、确认、用户输入和其它既有 blocker 清零后，原 Supervisor run 才能写唯一用户回复。
|
||||
- V1.28 Runtime 当前实现切片及其定向本地回归已完成：`project_supervisor_` 30/30、native 合同 parser→executor→delivery 1/1 PASS，覆盖合同证据、旧 sidecar 不迁移、双线程 repair 唯一活跃投递、suppressed repair 阻断与同 action/新 action 基础设施恢复、父 lane 忙时证据损坏持续重试 reconciliation、规范字段和别名空合同拒绝及唯一 Supervisor assistant/completed；正式 GUI 接入后的 `appSurface.test.ts` 当前为 279/279 PASS，覆盖 active Supervisor Session、已有项目恢复、same-run steer、专业 Agent 只读状态、开发入口隔离和 legacy 零新增双写。这不代表完整 V1.28 验收清单已通过：Runner 强杀恢复仍未验收；真实 `gpt-5.5` 隔离复测在修正测试驱动后于 Supervisor 首轮 planning 发生 transport failure，未创建 delivery。两个专业 Agent 真并行、一份弱交付恰好一次 repair、零重复与零泄漏的真实门禁仍未通过，V1.28 整体保持 NOT PASS。
|
||||
- V1.28 对 Provider 瞬态失败采用 Runtime 显式重试：`agentLlm.<agent>.maxRetries / retryBackoffMs` 表示独立物理尝试及其有界指数退避，不得恢复为 `LlmClient` 在单 lifecycle 内隐式重放。每次尝试都重建禁用自动重试的 client，并写独立单次 lifecycle；首次 request slot 不变，第 `N` 次重试稳定使用 `-transient-N` 后缀。只有 `timeout / connectivity / transport` 可重试；工具协议无效仍进入独立 `repair-N` 格式修复，其他错误与重试耗尽按原失败路径收束。重试前必须重新检查 Goal、steer、cancel、task/run 与 orphan 门禁；控制请求可阻止下一次尝试，Runner 强杀后无可信终态的 `started` 仍进入 reconciliation，不能自动补发。重试发生在解析和副作用之前，不创建 action、pending、receipt、delivery、assistant 或 revision；既有 Runner、orphan、finalization 和隐私边界均不放宽，公共审计不得保存请求/响应正文、arguments、凭据或绝对路径。
|
||||
- V1.28 已于 2026-07-17 完成正式 `openai_chat / gpt-5.5` `supervisor-swarm` PASS：同一 native 批次双专业委派、真实 Provider 重叠、2 份初始 delivery、1 次 targeted contract read、1 份唯一 repair、pidfd Runner 强杀/boot 恢复、同一父 Session/run、唯一 Supervisor assistant 和 3 条内部专业 assistant 全部成立。报告包含 46/46 闭合且 completed 的 Provider lifecycle，成功计划 24/24、格式修复 20/20 全为原生工具协议；重复、残留 sidecar、Provider payload、私有正文、API Key、项目/正式配置绝对路径、报告、secret 与 lure 泄漏均为 0。正式 AppData 零 CLI 调用且源 Runner endpoint 未变化；规范复验命令为 `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite supervisor-swarm`。
|
||||
- 2026-07-17 追加 `supervisor-swarm-transient-retry` 受控故障门禁：一次性本地回环代理只让 `design-director` 首个请求在正文转发前断线，并暂停后继请求，直到验收器确认唯一 failed lifecycle、唯一 retry audit、新 `-transient-1` identity，以及 action/receipt/子委派/claim/assistant/pending/revision/upstream forwarding 全为 0。E2E 启动 CLI/Runner 时会把 loopback 合并进 `NO_PROXY / no_proxy`，避免继承的系统 HTTP 代理接触故障门禁请求中的凭据和正文。最终加强版正式 `gpt-5.5` 报告为 46/46 lifecycle 闭合、45 completed/1 failed/1 retry；代理观察到的 10 个目标 Agent 请求与该 Agent lifecycle 数量一致，放行后完整双 Agent、唯一 repair、Runner 强杀恢复、唯一 Supervisor assistant、零重复/残留/泄漏继续 PASS。隔离 AppData 创建在正式目录同级，source-dir guard 与 `sourceAppDataDirectoryUntouched` 证明正式 AppData 未被写入，源配置与 endpoint 身份保持只读，失败 partial report 保留已取得的 retry checkpoint，代理与隔离现场全部清理。该 suite 只证明显式重试和既有协作链可组合，不把预置双 Agent fixture 扩大解释为自主编排；无 Agent ID/并行/repair 配方的自主 suite、真实 `agc:chat`、static+isolated 组合和 Tauri 宿主 E2E 仍待单独验收。
|
||||
- 开发模式可通过本地项目文件面板执行 `file.list/read/write/delete`，普通用户界面不暴露文件面板。
|
||||
|
||||
@@ -146,6 +146,7 @@
|
||||
"ai-game-creator-shell:agent-run": "npm --prefix apps/ai-game-creator-shell run agent-run --",
|
||||
"ai-game-creator-shell:agent-run:smoke": "npm --prefix apps/ai-game-creator-shell run agent-run:smoke",
|
||||
"ai-game-creator-shell:agent-runtime:real-e2e": "npm --prefix apps/ai-game-creator-shell run agent-runtime:real-e2e --",
|
||||
"ai-game-creator-shell:agent-runtime:supervisor-swarm-transient-retry-real-e2e": "npm --prefix apps/ai-game-creator-shell run agent-runtime:supervisor-swarm-transient-retry-real-e2e --",
|
||||
"ai-game-creator-shell:agent-runtime:steer-real-e2e": "npm --prefix apps/ai-game-creator-shell run agent-runtime:steer-real-e2e --",
|
||||
"ai-game-creator-shell:agent-runtime:steer-runner-kill-real-e2e": "npm --prefix apps/ai-game-creator-shell run agent-runtime:steer-runner-kill-real-e2e --",
|
||||
"ai-game-creator-shell:typecheck": "npm --prefix apps/ai-game-creator-shell run typecheck",
|
||||
|
||||
Reference in New Issue
Block a user