@@ -17,6 +17,78 @@
---
## 2026-08-26 运行中自主扩图提案留在编排层
- 背景：`agent-runtime-orchestration` 已能构造和调度动态 DAG，但 LLM 在执行中发现缺少步骤时没有通用的安全扩图合同。
- 决策：新增严格 serde 的 `GraphProposal` （ `TaskProposal` + `GraphEdge` ）和 `GraphLimits` ，由 `TaskGraph::apply_proposal` / `expand_with_proposal` 在内存中构造不可变候选图；新节点默认 `Pending` ，边方向为前置 `from` → 依赖方 `to` 。
- 安全与一致性：所有 Agent、端点、重复引用、环、节点/边/深度/扇出预算在候选返回前一次校验；边只能指向新节点，禁止给已运行任务原地追加依赖。任一失败保留旧图。成功后的 epoch、基图版本、proposal 幂等和持久化由宿主负责，crate 不调用 LLM/Provider/ToolHost/Runner，也不写 `.agent/runtime/**` 。
- 验证：非游戏 conformance 覆盖有效扩图、ready/wave 重算、未知 Agent/端点、重复边、已有任务修改、环、预算、严格 JSON 和原子失败；关联文档为 `docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md` V1.55。
## 2026-08-26 通用多 Agent DAG 编排与执行内核分层
- 背景：`agent-runtime-core` 已承接 catalog、run/action 生命周期、lane、宿主 ToolHost、spawn/all-join 和 Provider 契约，但动态任务图的 ready 选择、依赖波次与返工下游闭包仍混在 `platform-agent::game_creation` ，其它产品无法复用且非法环会被合并成伪 wave。
- 决策：新增纯 Rust `agent-runtime-orchestration` ，依赖方向固定为 `agent-runtime-orchestration -> agent-runtime-core` 。公共层只持有任务 ID、Agent ID、通用状态和依赖边，统一负责构图校验、ready、active/satisfied 波次、下游闭包和全量/返工选择；动态构图仍必须是 DAG，跨轮循环通过新的 pass / epoch 表达。
- 产品边界：16 个游戏任务、六组角色、产物/验收条件、Evaluator Markdown 和中文语义路由继续留在 `platform-agent` ；AGC 组合根使用公共层校验任务图与 `AgentCatalog` 。Runtime store、Runner、Provider、权限、ToolHost、委派 journal、isolated write scope 和 `.agent/runtime/**` 不迁移、不双写。
- 验证方式：非游戏 conformance 覆盖并行分支、汇合、repair closure、AgentCatalog 和非法图失败关闭；`platform-agent` 锁定种子 DAG 与现役波次/返工顺序，并验证环拒绝和 catalog 注入。根检查脚本必须执行新 crate 测试。
- 关联文档：`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md` V1.54。
## 2026-08-27 `plan.submit_gdd` 拒绝无审批决定的 `user_revision`
- 背景：结构校验允许 `round=0 + user_revision + confirmed` ，提交闸原先只做结构、身份和 Session CAS。Provider 可在首次 collecting、澄清续跑或提交前质量返工里把未确认项标成用户审批修改，审批卡显示「已确认」。
- 决策：新版本 create 时，payload 含 `user_revision` 则当前 session 的 `lastDecisionRef.action` 必须是 `revise` 或 `reject` ；否则 `PLAN_INVALID_REQUEST` 。同 `submissionId` replay 不重判。不恢复 session 前缀逐项相等，不把 `user_revision` 与审批意见正文对齐，也不在这次处理 `round≥1` 的 `user_option` 伪造。
- 影响范围：`planning_submit.rs` 提交闸；Fast GDD 技术方案第 5.1 / 8.2 / 12 节。
- 验证方式：首次 collecting 带 invented-confirmation 必须拒绝且不落 GDD； `user_revision` 的 v2 仍成功。
- 关联文档：`docs/technical/【技术方案】立项策划Agent（ ） 。
## 2026-08-28 planning continuation 必须沿当前 delivery 游标推进
- 背景：`lastDecisionRef.action=revise/reject` 在用户修订后的质量返工中必须继续有效，但仅凭该历史指针无法证明当前 `agent.delegate` 选择的是本次 planning session 的当前分支。
- 决策：不新增用户修订授权字段，也不在 `plan.submit_gdd` 重复遍历 approval receipt/GDD lineage。已有 planning session 创建新 child 时，`repairOfDelegationId` 必须直接等于旧 session 的 `latestDelegationId` ；不一致即在 Provider 启动前以 `PLAN_NEEDS_RECONCILIATION` 拒绝。合法用户修订及其后质量返工继续保留 `lastDecisionRef` ，成功提交新的 GDD 后仍由 submit successor 清理该指针。
- 影响范围：`planning_coordinator.rs` continuation 投影门；Fast GDD 技术方案第 8.2 节和提交步骤；不改变静态委派通用返工合同或 `PlanSessionV1` schema。
- 验证方式：新增当前游标 continuation 正向/旧 delivery 负向回归；CI 继续验证首次伪造 `user_revision` 拒绝、用户修订后质量返工提交成功及现有澄清/返工 lineage。
- 关联文档：`docs/technical/【技术方案】立项策划Agent（ ） 、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_coordinator.rs` 。
## 2026-08-27 退款 emergency spool 容量溢出保持可恢复
## 2026-08-27 退款 emergency spool 容量溢出保持可恢复
- 背景：本机 emergency spool 仅作为 SpacetimeDB 完全不可达时的最后恢复路径，原有 `MAX_BYTES` 分支会直接返回 `Dropped` ，导致扣费已经完成但没有可重放记录。
- 决策：达到普通 outbox `MAX_BYTES` 时，将退款记录写入同一持久目录的 `refund-overflow-*` 文件；该文件与普通 pending 文件一样由启动恢复和后台 worker 重放到 SpacetimeDB，且按 refund ledger id 保持幂等。溢出文件不计入普通阈值，但必须触发容量告警；底层磁盘写入失败仍进入关键退款人工补偿流程。
- 影响范围：api-server wallet refund emergency spool、资产失败退款日志、loadtest / 预览 Compose 持久卷、后端架构与开发运维文档。
- 验证方式：运行 api-server `wallet_refund_outbox` 定向测试，确认超限写入并保留 overflow 文件；运行 SpacetimeDB profile 测试、Compose 配置校验、编码和 diff 门禁。
## 2026-08-27 短期认证状态进入共享 typed projection
- 背景：短信验证码和微信 OAuth state 仍只存在 API 进程内 HashMap，多节点请求或 API 重启会直接丢失，无法满足无粘性会话的鉴权恢复要求。
- 决策：`AuthStoreProjectionView` 增加 `phone_codes` 与 `wechat_states` typed 字段，由 `auth_store_projection_meta` 以 JSON 投影持久化；启动恢复、CAS 同步和失败后的权威刷新都覆盖这两类短期状态。验证码哈希使用部署级稳定盐（当前复用 `GENARRATIVE_JWT_SECRET` ），各 API 节点必须一致；发码前先刷新权威投影并用占位验证码记录做一次 projection CAS，只有占用成功才调用短信 provider，避免跨节点冷却竞态；认证 handler 在发码、消费验证码、创建/消费微信 state 后都要完成 projection sync，失败即返回服务错误；所有会读取或变更本机认证工作集的认证主链路（登录、刷新、`/me` 、会话管理、密码、绑定和微信 state）在领域操作前先从正式投影做一次受 CAS 保护的只读刷新，受保护 Bearer 中间件也会在进入业务 handler 前执行同样的刷新，刷新失败时 fail closed，不能依赖粘性会话；同步遇到 CAS 冲突时，若本次尝试期间没有新的本地变更则恢复正式快照，若仍有待同步 revision 则由后续认证请求重试，避免节点永久卡在 pending。微信 OAuth state 设置有界活动数量，避免单个 JSON 投影无界膨胀。短期状态仍由 `module-auth` 内存工作集执行领域校验，但不再把本机 HashMap 当作持久化或跨节点真相。
- 影响范围：`module-auth` projection、`spacetime-module` auth schema/procedure、`spacetime-client` bindings/facade、api-server 手机号 / 微信 handler、认证架构与运维文档。
- 验证方式：运行 module-auth projection roundtrip（验证码可跨恢复校验、微信 state 可跨恢复消费）、SpacetimeDB schema/runtime/DDD 门禁、api-server 定向测试、编码和 diff 检查。
---
## 2026-08-27 外部生成历史采用受控保留清理
- 背景：`external_generation_job` 、`external_generation_job_summary` 与 `external_generation_job_event` 都是持久化表；摘要和 payload 边界收紧后，已确认的终态历史仍会继续占用 SpacetimeDB 常驻内存，且事件审计链会随任务数量增长。
- 决策：新增仅 migration operator 可调用的 `prune_external_generation_job_history_and_return` 。默认按 `source_module=editor-canvas` 、30 天保留期和 `job_id` 游标分批运行；只删除主任务与摘要状态一致、属于 completed / failed / cancelled、摘要已有 `notification_acknowledged_at` 且终态时间达到 cutoff 的任务。事件、摘要和主任务仍按同一事务顺序删除，但每次事务最多删除 256 条事件；事件未删完时保留任务与摘要并返回同一个 job cursor，维护脚本下一次继续，避免单个任务形成无界事务写集。默认 dry-run，必须固定 dry-run 返回的 cutoff 后再 apply；
- 影响范围：`server-rs/crates/spacetime-module/src/external_generation.rs` 、外部生成事件 job_id 单列索引、SpacetimeDB 生成 bindings、`scripts/spacetime-maintain-external-generation-jobs.mjs` 、架构与生产运维文档。
- 验证方式：覆盖终态 / 活跃态 / 已确认与未确认摘要、状态或身份不一致、cutoff 边界测试；运行 SpacetimeDB module tests/check、bindings 生成、schema/encoding/diff 门禁，并在维护窗口先 dry-run 再 apply。
- 关联文档：`docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md` 、`docs/【开发运维】本地开发验证与生产运维-2026-05-15.md` 、PR #203 。
## 2026-08-27 SpacetimeDB 工具链统一升级到 2.8.3
- 背景：SpacetimeDB 2.8.0 引入 TypeScript submodule 与调度延迟观测，2.8.1 修复 v1 WebSocket 订阅移除死锁、TypeScript SDK `array<u8>` 读缓存别名和 Rust string 默认值支持，2.8.2 修复 table accessor 改名自动迁移，2.8.3 修复 scheduled function 从实际执行时间重排导致的长期漂移。仓库若继续锁定 2.7.0，会保留这些已知运行时与 SDK 问题。
- 决策：`server-rs/Cargo.toml` 的 `spacetimedb` 、`spacetimedb-sdk` 、`spacetimedb-lib` 精确锁定 2.8.3；本地 CLI / standalone、Rust bindings、worker smoke 本地镜像、官方容器压测镜像和生产 provision 下载根同步对齐 `v2.8.3` ， `8e410d28...` 。2.8.3 不再使用 2.7.0 的 hotfix3 特殊资产标签口径，但同版本 commit 校验继续保留。
- 影响范围：Rust workspace lockfile、SpacetimeDB bindings、本地 dev 版本门禁、容器 smoke / loadtest、server provision Jenkins 与项目 SpacetimeDB skills / 文档；现役 module 未使用 submodule，本次不修改 schema 或 migration。
- 验证方式：核对 CLI 版本和 commit，重新生成 Rust bindings，运行 `npm run check:spacetime-schema` 、相关 Cargo check / tests、server provision 工具测试、dev 调度测试、encoding 和 diff 门禁。
- 关联文档：`docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md` 、`docs/【开发运维】本地开发验证与生产运维-2026-05-15.md` 。
## 2026-08-26 Fast GDD 修订后先取证再允许再次委派
- **现象 ** ：GDD v1 经用户选择“修改”后，策划子 Agent 正确提交 v2，但 plan 根 Supervisor 的 `Delegated` 阶段仍同时广告 `agent.delegate` 与审批前置工具；模型可能在 Acceptance Graph 重新取证前重复创建修订 delivery，随后被 `PLAN_PROVIDER_USAGE_DEFERRED` 拦停。
- **决策 ** ： `AwaitingAcceptanceEvidence` 状态。当前根最新 GDD 无 approval receipt/pending、session `latestSubmittedRef` 精确指向该提交、delivery 已由根认领且 Acceptance Graph 返回 `NeedsEvidence` 时，只广告 `file.read` 、`agent.acceptance_update` 、`agent.run_status` ；只有用户真正对最新审批卡选择修改/退回后，才恢复 `agent.delegate` 。
- **边界 ** ：不放宽 Provider usage 门禁，不重构 delegation/repair lineage，不自动生成证据或审批 pending；审批 pending 仍只由既有 acceptance gate 在 `agent.acceptance_update` 成功后创建。
- **验证 ** ：新增一条阶段工具面回归，并通过 15 条 M1C-2a acceptance gate 定向测试、plan root 原生工具目录测试、`cargo check --all-targets` 、格式与 diff 检查。
- **锁边界修正（2026-08-27） ** ：阶段判定拆为 `plan_root_supervisor_stage_at_locked` 与负责取得一次项目锁的外层入口；Provider tool-plan builder 已持有项目锁时直接复用 locked 入口。Acceptance Evidence 判据和阶段工具面不变，禁止在持锁调用链中再次获取 `.agent/project.lock` 。
- **回归验证 ** ： `cargo check` 与 `cargo fmt --check` 通过。
## 2026-08-24 AGC Direct 媒体能力只通过客户端语义工具开放
- 背景：资源页已经补齐视频、角色动画、音效和背景音乐的 create/derive 能力，但 Direct Codex 只能准备标准美术包，无法查询已登记源资源或表达新增媒体意图。直接开放 Tauri invoke 会把项目路径、revision、operation、幂等键、登录态和事务权力交给模型。
@@ -1298,8 +1370,8 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
- OSS 固定恢复入口为 `<prefix>/<database>/latest.json` 。CAS 文件和 full/history catalog 保持不可变；latest pointer 只保存最新 full catalog 与已发布 history catalog 的 object key、长度和 SHA，不包含主机绝对路径或文件内容。每次 state 变化先验真全部引用 catalog，再覆盖上传并 HEAD 验真 latest pointer，成功后才落本地 state；
- dev 带宽不足时，允许把已冻结的 dev 基线经 `10.2.0.10 -> 10.2.4.16` 内网 rsync 到 release 独立 staging，再用 release 出口上传 dev bucket； `/stdb` ，不得停止或修改 release 服务，传输凭据必须临时创建并在演练后移除。catalog 不记录 staging 绝对路径，files state 可回传 dev 继续 history。
- 恢复边界：恢复时默认从 OSS `latest.json` 自动定位 full catalog，创建目录并按相对路径下载每个对象、逐文件校验长度与 SHA；本地 state 只用于备份续跑，不再是异机恢复前置条件。远程 dev 已完成真实 OSS、清理、重启和异机隔离恢复演练；release timer 与 publish 前备份继续保持原行为。
- systemd 接线：主 service 保持 `archive-full` 。Server-Provision 新增默认值为 `archive-full` 的 `DATABASE_BACKUP_PROFILE` ； 或 release 显式选择 `files-history` 时 ，必须为各自主机 指定独立 work-dir， ，并删除现场手写旧 drop-in。切回默认 profile 必须删除所有 history 覆盖 。
- 影响范围：`scripts/database-backup-to-oss.mjs` 、备份门禁、生产 env 示例、systemd 模板、Server-Provision、SpacetimeDB 运维与恢复流程；release timer 可在独立 baseline 验证后显式选择 profile ，publish 前备份是否切换仍需单独决策。
- systemd 接线：主 service 保持 `archive-full` 。Server-Provision 新增默认值为 `archive-full` 的 `DATABASE_BACKUP_PROFILE` ； elopment 可 显式选择 `files-history` ，必须指定独立 work-dir 并先用 current release 脚本执行 history dry-run，确认已有 full state 后才安装仓库托管 drop-in； `files-history` ，直到流式 catalog 改造完成，以免大目录扫描再次触发 Node 内存峰值。切回默认 profile 必须删除所有 history 覆盖；备份 unit 同时设置 Node heap 与 systemd memory 上限，避免备份异常拖垮业务主机 。
- 影响范围：`scripts/database-backup-to-oss.mjs` 、备份门禁、生产 env 示例、systemd 模板、Server-Provision、SpacetimeDB 运维与恢复流程；release timer 固定使用 archive-full ，publish 前备份是否切换仍需单独决策。
- 验证方式：`npm run check:database-backup` 、`npm run check:production-ops` 、`npm run check:encoding` 、`git diff --check` ；dev 现场必须完成逐文件 full catalog、重复 full 零 PUT、history dry-run、上传后清理、STDB 重启和按 catalog 隔离恢复 roundtrip。
- 关联：<https://github.com/clockworklabs/SpacetimeDB/issues/5542#issuecomment -4981566448>。
@@ -2166,13 +2238,15 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
- 验证方式：微信小程序首点登录仍打开原生登录页；小程序支付仍跳转 `/pages/wechat-pay/index` 并保留 hash 回灌确认；订阅授权仍跳转 `/pages/subscribe-message/index` 且返回不阻断生成；普通浏览器分享、H5 支付和 Native 二维码支付不受影响。前端验证运行 HostBridge、auth、payment、分享、订阅和个人中心充值相关定向测试，并执行 `npm run typecheck` 、`npm run check:encoding` 。
- 关联文档：`docs/【前端架构】宿主壳能力统一协议-2026-06-17.md` 。
## 2026-06-15 SpacetimeDB 本地 skills 只保留 CLI / Concepts / Rust
## 2026-06-15 SpacetimeDB 本地 skills 范围（已由 2026-08-27 决策覆盖）
> 2026-08-27 覆盖说明：本节记录的“三个本地 skill”方案已收敛为单一项目适配层；当前口径见下方“SpacetimeDB 项目 skill 与官方插件职责收敛”。
- 背景：本仓库的 SpacetimeDB 接入已固定为 `server-rs + Axum + SpacetimeDB` ，本地 skill 需要从上游 SpacetimeDB `skills/` 更新到 2.5 口径，同时避免继续维护当前项目不使用的 TypeScript server/client、C# 和 Unity 专用 skill。
- 决策：`.codex/skills/` 下只保留 `spacetimedb-cli` 、 `spacetimedb-concepts` 、 `spacetimedb-rust` 三个本地 SpacetimeDB skill；删除 `spacetimedb-typescript` 、 `spacetimedb-csharp` 、 `spacetimedb-unity` 。前端 / Node 侧如需处理 SpacetimeDB 订阅或绑定，按当前生成绑定、项目代码和官方文档核对，不再依赖仓库内单独 TypeScript skill 。
- 影响范围：`AGENTS.md` 的 SpacetimeDB skill 清单、 `.codex/skills/` 本地 skill 维护范围、后续 SpacetimeDB 设计 / CLI / Rust module 开发协作口径 。
- 验证方式：用上游 `clockworklabs/SpacetimeDB@master` 的 `skills/` 目录对照，运行本地 skill 校验、删除引用扫描、 `git diff --check -- .codex/skills AGENTS.md .hermes/shared-memory/decision-log.md` 和 `npm run check:encoding`
- 关联文档：`AGENTS.md` 、`.codex/skills/spacetimedb-cli/SKILL.md` 、 `.codex/skills/ spacetimedb-concepts /SKILL.md``.codex/skills/spacetimedb-rust/SKILL .md` 。
- 决策：当时仅在仓库内维护与当前后端路线相关的 SpacetimeDB skill，通用 SDK/CLI 内容按上游资料核对；该历史范围已由 2026-08-27 的项目适配层方案替代 。
- 影响范围：当时的 `AGENTS.md` SpacetimeDB skill 清单和本地 skill 维护范围；当前范围以新的项目适配层及官方插件路由为准 。
- 验证方式：保留当时的上游 skill 对照、本地 skill 校验、删除引用扫描、diff 和编码检查记录 。
- 关联文档：`AGENTS.md` 、`.codex/skills/genarrative- spacetimedb/SKILL.md` 、`docs/【协作规范】Agent工作入口与执行准则-2026-06-22 .md` 。
## 2026-06-13 图片大图预览统一为黑底全屏查看器
@@ -3387,9 +3461,9 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
- 背景：新增玩法的创作工具如果默认复制既有玩法的聊天式 Agent、轻输入 Agent 或专属素材模型，平台会不断复制出不可控分支，后续接入、测试和恢复语义都会漂移。
- 决策：新增玩法创作工具统一收敛为平台级 SOP：默认使用表单/图片输入创作工作台；单图资产统一通过 `CreativeImageInputPanel` ；系列素材统一走批量规划、sheet 生图、后端切图、透明化、OSS 持久化和局部重生成流水线；不把任一玩法专属素材模型当平台通用模型。
- 影响范围：`CONTEXT.md` 、`docs/【玩法创作】平台入口与玩法链路-2026-05-15.md` 、`.codex/skills/genarrative-play-type-integration/SKILL.md` 、`.hermes/skills/genarrative-play-type-integration/SKILL.md` 、 后续新增玩法 PRD 和工程实现。
- 影响范围：`CONTEXT.md` 、`docs/【玩法创作】平台入口与玩法链路-2026-05-15.md` 、`.codex/skills/genarrative-play-type-integration/SKILL.md` 、后续新增玩法 PRD 和工程实现。
- 验证方式：新增玩法 PRD 必须显式声明单图资产槽位和系列素材槽位；新增工作台测试确认没有默认聊天式 Agent 输入；skill 通过 `quick_validate.py` 。
- 关联文档：`docs/【玩法创作】平台入口与玩法链路-2026-05-15.md` 、`.codex/skills/genarrative-play-type-integration/SKILL.md` 、 `.hermes/skills/genarrative-play-type-integration/SKILL.md`
- 关联文档：`docs/【玩法创作】平台入口与玩法链路-2026-05-15.md` 、`.codex/skills/genarrative-play-type-integration/SKILL.md` 。
## 2026-05-20 敲木鱼玩法按完整平台纵切接入
@@ -3964,13 +4038,13 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
- 验证方式：VN 定向前端测试、`npm run typecheck` 、`npm run check:encoding` 、`cargo test -p api-server visual_novel` 、`cargo test -p api-server creation_agent_document_input` 。
- 关联文档：`docs/prd/AI_NATIVE_VISUAL_NOVEL_TEMPLATE_PRD_2026-05-05.md` 。
## 2026-05-04 在仓库 `.hermes/` 中建立团队共享记忆
## 2026-05-04 建立仓库级项目知识与工具边界
- 背景：团队有 3 名开发人员，均在各自本地安装 Hermes，并 需要独立拉取仓库、修改代码、 本地测试；团队希望形成共享的长期项目记忆 。
- 决策：不共享个人 `~/.hermes` ，先在 Genarrative 仓库内使用 `.hermes /` 保存可 Git 同步的团队共享记忆、计划和未来 skills 。
- 影响范围：`AGENTS.md` 、`.hermes /README.md` 、`docs/project-memory/shared-memory/` 。
- 验证方式：任一开发者拉取仓库后，在项目根目录启动 Hermes，均可 读取同一套 `docs/project-memory/shared-memory/` 文件 。
- 关联文档：`.hermes /README.md` 、`docs/project-memory/shared-memory/team-conventions.md` 。
- 背景：团队有 3 名开发人员，需要独立拉取仓库、修改代码和 本地测试，同时共享稳定的项目知识与工具约定 。
- 决策：长期项目知识统一保存在 `docs/project-memory/` ； `.codex /` 仅 保存可 Git 同步的 Codex skills、插件资源、hooks 和配置模板；个人 `~/.codex` 始终保持本机私有 。
- 影响范围：`AGENTS.md` 、`.codex /README.md` 、`docs/project-memory/shared-memory/` 。
- 验证方式：任一开发者拉取仓库后，先读 `AGENTS.md` ，即可按入口 读取同一套 `docs/project-memory/shared-memory/` 和 `.codex/skills/`
- 关联文档：`.codex /README.md` 、`docs/project-memory/shared-memory/team-conventions.md` 。
## 2026-04-25 后端唯一落地口径固定为 Rust / SpacetimeDB
@@ -5843,7 +5917,7 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
- 决策：Linux `command.exec / command.start / project.verify` 的安全事实源从固定 program / argv 白名单或平行 npm spawn 升级为同一个 bubblewrap OS sandbox launcher。approval policy 继续决定是否确认，sandbox 独立限制文件系统和网络；普通 confirm 永远不能扩大 sandbox。
- 决策：Linux 只允许受信任系统 bubblewrap，缺失、权限异常或 namespace setup 失败必须在项目命令执行前失败关闭，不用裸 userns、代理变量或宿主全权限回退。当前机器 bubblewrap 0.11.1 已通过真实 namespace smoke，裸 userns 因 AppArmor uid_map 限制不可作为可靠 fallback。
- 决策：项目根可写，`.git / .agents / .codex / .hermes ` 只读，`.agent` 隐藏且不可写，项目外普通用户文件不挂载，network namespace 默认隔离；HOME / TMP / cache 使用 sandbox 私有目录，所有 shell、PTY 和后代继承同一边界。
- 决策：项目根可写，`.git / .agents / .codex` 只读，`.agent` 隐藏且不可写，项目外普通用户文件不挂载，network namespace 默认隔离；HOME / TMP / cache 使用 sandbox 私有目录，所有 shell、PTY 和后代继承同一边界。
- 决策：Linux sandbox 生效后，program 扩展为受信任 PATH 中的裸可执行名，argv 仅保留结构长度与控制字符门禁，允许 shell 管道和项目脚本；Windows 在等价原生 sandbox 落地前继续使用 V1.10 固定白名单与 Job Object，不能宣称通用命令或 Codex CLI 级隔离。
- 验收门禁：项目内构建 / 测试 / Git 读取成功；项目外读写、控制目录写入和网络访问失败；子进程与 PTY 会话继承相同边界；bubblewrap 不可用时零项目命令执行。真实 Provider 还需在无固定命令配方下自行发现并运行项目命令。
- 审计与发布：process record v2 保存 launch 当时的 backend / mode / network / profile，后续 process 工具从 durable/live 身份读取，preflight 失败使用 unavailable / not-established，不能按平台静态宣称已建立。共享 `os-workspace-sandbox` capability 只标记 Linux；
@@ -7717,6 +7791,20 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
- 安全：DirectProject 使用真实 `game/` writable root、`approvalPolicy=never` ，原生命令网络保持关闭，联网资料继续走受控 `agc_web_search` ； `OPENAI_API_KEY` 登录态时，真实 provider 凭据只留在 AGC 本地代理；前者仍走已配置上游，后者只走 OpenAI 官方 API，Codex 仅获得连接级随机代理令牌。无法安全代理的 OAuth `auth.json` 继续关闭原生 shell/unified exec。app-server 使用隔离 `CODEX_HOME` ， `shell_environment_policy` glob 排除 provider key、proxy、loopback bridge 和受控开关。
- 上下文：Direct 系统提示词只保留身份、cwd、边界和 Skill 索引；不再预注入项目源码快照、项目提示词或 Skill 正文。浏览器工具回传结构化事实，不强制固定三次整改循环；Codex 自行解释证据并决定是否继续。sandbox writableRoots 不提供 deny-read， `.agent` /`../assets` 的不可读约束需靠行为合同和真实 smoke 验证。
## 2026-08-27 GDD 修改后历史 receipt 不得污染当前审批恢复
- 现象：GDD“修改”已成功生成下一版本且当前 pending 身份正确，但 hydrate 持续返回 `recoveryPending=true` ，审批卡显示“审批状态正在恢复”。
- 原因：恢复扫描会重放全部历史 approval receipt；旧版本 receipt 仍拿当前单例 approval pending 做 identity 比对。修改后当前 pending 已属于新版本，旧 receipt 的 identity 不同是正常状态，却被误记为投影缺口。
- 决策：receipt 的 index、Markdown、audit、submit observation、session 等投影继续允许全量恢复；approval pending 只由 lineage 最新 GDD 的 receipt 读取、更新和清理。历史 receipt 不得检查或改写当前 pending，也不得因此提升 `recoveryPending` 。
- 审批意见消息按 receipt 的 `rootRunId` 解析到原 Supervisor task 所属会话恢复；不会按当前 active session 重新路由。已存在于归档会话的幂等消息允许重放且不新增消息，缺失消息仍保持恢复失败，不静默写入其他会话。
- 验证：沿用现有审批恢复与 planning submit 定向测试；未新增独立测试，避免为非代表性 fixture 引入额外状态构造。
## 2026-08-27 审批修订以最新用户意见更新 GDD 决定快照
- `decisions` 表示当前 GDD 版本的决定快照，不再作为新提交必须逐项复制的 session 历史前缀。审批修订可以修改、推翻、删除或新增决定；Runtime 只校验结构、身份、CAS、版本和原型验证项双射，不做自然语言修改范围门禁。
- 新增 `answerSource=user_revision` ，用于标记来自审批修改意见的当前决定，按 `round=0` 记录；`default` 仍只表示未提问的默认建议，澄清来源仍使用 `user_option` / `user_freeform` 。
- planning Prompt 约束为：以当前 GDD 为基线，仅修改用户意见明确涉及的内容及保持内部一致性所必需的派生内容，未涉及内容保持不变；意见与旧决定冲突时以最新意见为准。
## 2026-08-24 AGC UI 原型桥接与自主 UI workflow
- 决策：`ui-prototype` 图片与 `UI` JSON 编辑资源保持两种正式类型。Agent 通过受控 `ui.workflow.run` 按 `prepare -> recognize -> status -> finalize` 创建页面资源、关联源图、持久化 UI State 和 manifest 阶段；`recognize` 直接复用 UI Editor 的 provider-backed 结构识别、多树合并与组件绑定命令，按 `reference-ready -> structure-ready -> merge-ready -> binding-ready` 逐阶段写入并推进项目 revision。页面可显式关联已登记图片/图标和字体，图片/图标按 5 项一批绑定，字体安全元数据进入绑定上下文且未知引用失败关闭。Runtime 回执携带 `revisionAdvanceCount` ；Provider 未配置、请求失败、工具调用缺失、结果不匹配、未产出可渲染组件或仍有待审节点时保留最近真实阶段，禁止用 deterministic seed 冒充语义处理完成。
@@ -7760,3 +7848,9 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
- 决策：新增 `PlatformBackActionButton` canonical 返回动作组件，统一 compact / regular 尺寸、返回图标和 platform / editorDark surface； `src/components/common/PlatformBackActionButton.tsx` 仅保留兼容出口。
- 迁移：`LoginScreen` 、`BindPhoneScreen` 、`CustomWorldEntityCatalog` 将已有共享 `Platform*` chrome 直接从 `@genarrative/shared/components` 引入；展示页新增返回动作示例并保留整行开关示例。
- 边界：媒体、上传、资源换签、业务弹窗等带副作用组件继续留在网站业务层。
## 2026-08-28 AGC 自主构建放开编排约束
- `autonomous-game-build` 中，manifest `dependencies` 只作为上下文，不阻塞 ready；代码、设计、美术、音频和发布任务允许并行启动，child 不依赖固定回执顺序或固定 run 身份才能推进。
- 任务最终状态不再提前绑定平台画布、preview、static smoke 或发布产物检查；这些内容不参与该档位的完成判定，也不会因缺失而重置已完成任务。父 run 在任务图进入终态后直接收束并回复。
- 本档位仍沿用现有项目根和工具权限边界；本次调整只解除流程编排与平台产物验收前置，不新增第二套任务系统。
