2243 Commits

Author	SHA1	Message	Date
lhk229	ca6a3cd4cd	修复M1策划链路可靠性 ... 阻止人工核对中的策划根写入审批回执 在投影恢复前校验项目身份并使用唯一项目ID 增加策划能力停用门禁与既有sidecar只读行为 拒绝非法plan与自主构建档位组合并收紧消费者 补齐前后端回归测试与M1技术决策记录	2026-08-19 09:13:43 +00:00
lhk229	6d5afd9f6d	修正M1首页立项入口 ... 仅让首页做方案进入立项策划 恢复做游戏和做素材的直接构建路径 同步入口合同与回归测试	2026-08-19 05:27:53 +00:00
lhk229	7eee259cea	Merge branch 'feat/five_min_design' into codex/genarrative-isolated	2026-08-18 14:22:00 +00:00
lhk229	e3d318bf45	完成M1E提交拒绝有界收束 ... 为 Fast GDD 提交拒绝新增持久化次数上限与恢复收束。 将既有权威事实的超限和版本边界转入 reconciliation。 同步 M1E 技术方案与项目决策记录。	2026-08-18 14:20:23 +00:00
lhk229	4687807dc1	在hydrate调用点写明投影修复先于身份校验的前提 ... 裁决为不修，并把改动前提与非重入锁陷阱留在代码旁 第 18.3 节要求身份校验（第 3 步）先于 session 前滚（第 5 步）与 index/pending 重建（第 6 步），而 hydrate 的实际顺序相反。本次裁决为不修，理由与前提写进注释： 现在没有后果，是因为那道比对恒过——App 的全部 init/import 调用点都传同一个常量 seedManifest.projectId（local-project-draft），本机每个项目的 manifest 写的都是它， projectId 分辨不出任意两个项目。该常量不属本工作包管辖。 触发后的后果也已复核为可忽略：命令仍正确返回 PLAN_PROJECT_ID_MISMATCH，前端拿不 到错数据；报错前写入的 pending/session/index 均为幂等或可重建投影，usage fold 有 按 fact 比对的幂等守卫，session.previous.json 是改名而非删除且只在 primary 缺失时 发生（即本来就该做的恢复）。 一旦 projectId 改成每项目唯一，这道校验才真正开始工作，届时顺序必须一起改，否则 hydrate 会先对一棵属于别的项目的 planning 树做完投影修复才发现认错人。注释里连同 陷阱一并写明：不能把 reconcile 直接挪到 hydrate 取锁之后——它自取项目锁，而 .agent/project.lock 是 create_new(true) 非重入的，调用方持锁再进去会死等满重试预算 然后失败；可行路径是锁外 projectId 预检，或把 reconcile 拆成薄壳 + _at_locked 由 hydrate 在自己的锁内调用（同型拆法见 observe_agent_runtime_agent_delegate）。 把提醒放在代码旁而不是只留在 decision-log，是因为真正会改 projectId 方案的人不在 本领域，不会来读这份文档。 cargo fmt --check、check:encoding 通过；纯注释与文档，无行为改动。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:45:46 +00:00
lhk229	d44f930d1f	收口design组展示名，改为设计实现Agent ... 分组字典、manifest默认名与分组头像字一并改掉 个体Agent名兜底跟进，玩法策划Agent与内部id不动 跟改16处由label派生的断言 第 18.2 节要求 design 组用户名称改为「设计实现组」，与新阶段「立项策划」区分。 bf2185fba 只改了 taskGroupLabels 一本字典，另两本同概念字典没动，于是同一个 design 组在开发者面板/文本汇总里叫「设计实现组」、在工作台状态栏里叫 「策划 Agent」——这个语义不一致是该提交引进来的。 先更正一条此前的判断：曾把这条的严重度建立在「新项目默认主路径上『立项策划』 与『策划 Agent』同屏共存」上。该说法未经验证且不成立——用 appSurface harness 实测策划路径，子 Agent 状态栏根本不渲染，策划 Agent 出现 0 次。结构上二者确在 launcherView === 'project-development' 分支的同一棵树里，但未能把用例驱动到该 分支，故不作为事实主张。若真会撞，也是批准后进入完整制作那一段，比原描述窄 得多。改这条的理由与撞不撞名无关，只是第 18.2 节的要求 + 上述不一致。 口径取最小方案：保持兄弟项的「X Agent」体系，design 取「设计实现 Agent」。 不把 taskGroupLabels 直接塞进 groupConfigs——两本字典命名体系不同（「X组」对 「X Agent」，且音乐组/音频 Agent、运营组/发布 Agent 连词都不一样），直接替换 会连带改掉另外五个分组名；消灭重复字典属视觉改版，单独立项。 改动：agentPresentation.ts 的 groupConfigs、view/project-development/index.tsx 的 summarizeAgent 默认名与同文件分组头像字（策→设）、model.ts 中 agentId.includes('design') 的个体名兜底（design-director 走这里）。 design-foundation 的「玩法策划 Agent」单列在前，不变；内部 agent id 与 design 分组键均未动。 测试量原估「3 处断言」严重低估，实跑发现 project-development.suite.ts 有 16 处 派生断言需跟改——「X 文本回执」由 App.tsx 的 `${candidate.label} 文本回执` 拼出、 「历史成果 · X」由 resourceProjectionModel.ts 拼出、dock 的 article accessible name 亦然。替换用后行否定守住「玩法策划 Agent」（它含「策划 Agent」子串）， 替换前后该串恒为 6 处。agentRuntimeModel.test.ts 与 projectResourceProjectionModel.test.ts 里剩余 4 处是测试自造的输入 fixture、 不由字典派生，保持不动。 验证：appSurface.test.ts 383 passed / 0 failed；agentRuntimeModel、 agentTraceSummary、projectResourceProjectionModel、projectResourceLiveUpdateModel 合计 39 passed；agc:typecheck、ESLint --max-warnings 0、check:encoding、 git diff --check 通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 12:20:01 +00:00
lhk229	7ca82ba7aa	修复M1D审查发现的锁错误脱敏与澄清轮次口径 ... 审批卡链路的三处项目锁错误改为脱敏后再进typed错误 阶段进度按等待状态显示真实轮次，不再透传0-indexed值 去掉reconcile错误的重复code拼接 补一条Rust脱敏回归与两条前端轮次回归 锁错误脱敏（方案 §18.3「返回值不包含绝对路径……或内部诊断」）： acquire_project_write_lock 的 Err 内嵌 .agent/project.lock 真实绝对路径。补 redact_agent_runtime_project_paths 的三处是前端审批卡真正会显示的那条链—— reconcile_plan_gdd_approval_projections_at（hydrate 在取自己的锁之前调它）、 hydrate 自己的锁、decide_plan_gdd_at（其错误与 hydrate 的错误渲染在同一个 错误区）。planning 另有 14 个取锁点沿用未脱敏写法，属 M1B/M1C 既有模式， 本次不扩面。脱敏不破坏「项目正在被其他写操作占用：」前缀，project_gates.rs 与 provider_recovery.rs 两处按前缀分类的判据不受影响。 澄清轮次口径：clarificationRound 与 awaitingAnswerFor.round 都由 static_delegate_lineage_counters 派生，该函数排除目标自身，是 0-indexed 的 「已答轮数」；后端判上限用的是 current_round + 1。原样渲染成「轮次 X/3」 整体差一格——问最后一轮时显示「轮次 2/3」，字面暗示还剩一轮。只改前端 文案、不动 DTO 语义：等待回答时显示「第 N+1 轮 / 共 3 轮」（此时 latestDelegationId 就是当前 delivery，+1 恰好等于后端校验用的轮次）， 其余状态退回「已完成 N/3 轮澄清」，不猜当前轮。 顺带：planning_hydrate.rs 里 reconcile 的错误原本用同一 code 把 to_string() 当 detail 重包一层，而 PlanningStorageError 的 Display 已是「{code}: {detail}」， 渲染出 CODE: CODE: detail；code 与 detail 均无变化，改为直接 ? 传播，并把 「不重复拼 code」钉进回归。 测试陷阱：写「占住项目锁」的 fixture 必须给锁 JSON 填真实 createdAt。失效锁 回收的年龄判定读的是该 JSON 字段而不是文件 mtime，填 0 会让锁显得约 1.7e9 秒 老、越过 600 秒阈值被当场回收删除，hydrate 反而成功。第一版 fixture 正是这样 自证失败的，注释已写明。 验证：Rust planning_ 组 155 passed / 0 failed（原 154 + 本次 1 条）； appSurface.test.ts 383 passed / 0 failed（378 原有 + 5 条新增）；三条新回归均经 变异验证，逆转对应修复即变红。cargo fmt --check、agc:typecheck、ESLint --max-warnings 0、check:encoding、git diff --check 通过。 撤回一条此前的审查发现：曾判定 hydrate 读 manifest 缺符号链接判定。复核后不 成立——read_manifest 自身在 is_symlink 处即拒，防护在另一层；.agent 目录本身 为符号链接的残差也无窗口，紧随其后的 resolve_planning_path 同样逐段判定。 未据此改动代码。 新记一条既有问题（非 M1D 引入）：seedManifest.projectId 是常量 local-project-draft，App 的 5 个 init/import 调用点全传它，因此本机所有项目 projectId 相同。§18.3 第 1 步依赖的 projectId 校验因此分辨不出任意两个项目， 该门当前近乎恒真，须单独立项。 仍未修：hydrate 身份校验排在落盘投影修复之后（修它须注意 reconcile 自取项目 锁、.agent/project.lock 不可重入，不能把检查直接挪到 hydrate 取锁之后）； design 组展示名剩两处硬编码，且与 taskGroupLabels 命名体系不同，需先定口径。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:50:43 +00:00
lhk229	abcc393fde	修复M1D审查发现的审批决定失败路径 ... 决定失败也重灌权威状态，顺序钉死为先hydrate后写错误 responseId复用键纳入comment，改写修改意见时换新ID 恢复期门控扩到已打开的评论弹层，保留已输入内容 补appSurface harness的策划command分发与三条变异验证过的回归 审查基线为 14c00017c..bf2185fba（技术方案第 13、18 节）。其后分支已前进到 c6a08ef98，4624fd795 与 c6a08ef98 都不动 src/**，审查结论不受影响。 三条缺陷： 1. decidePlanGdd 只在成功分支 hydrate。后端 decide_plan_gdd_at 有多条真实 PLAN_STALE_APPROVAL 分支（GDD 不在当前 lineage、identity 不符、版本被取代、 pending 丢失），命中后卡片停在已失效的 pending 身份上、三个决定按钮仍可点， 且 recoveryPending 永不翻真导致「重试恢复」入口不渲染，卡内没有恢复路径。 现按第 18.3 节在失败分支同样 hydrate——该句不区分成功与失败。两句顺序不能反： hydratePlanGddState 入口会 setPlanGddError(null)，先写错误再 hydrate 会把错误 擦掉；回归钉死了这个顺序。 2. responseId 复用键为 approvalRequestId:action，不含 comment，违反第 13.2 节 「改变 action/comment 必须生成新 responseId」。在第 14 节承认的「receipt 已提交 但 response 丢失」构造下，改写修改意见后重提会带旧 ID，命中后端「同 responseId 的审批意图不一致」硬拒，改写后的原因永远落不了盘。现按 approvalRequestId 存 {action, comment, responseId} 全量意图。判据方向为宁可多换不可少换：多换的最坏 后果是 replayed 降级成 already-decided（都是 Ok，且 already-decided 正是第 18.2 节要求的刷新态），少换是硬错误。 3. 第 18.2 节「recoveryPending 时不允许提交决定」原来只作用于三个触发按钮，而弹层 是打开之后才可能被后台 hydrate 翻掉资格的，其提交按钮只看 busy 与非空。现在 submitComment 与该按钮都判 canDecide。刻意不自动关弹层，否则会丢掉用户已经写好 的修改意见。 测试：harness 新增 hydrate_game_creator_plan_gdd_state 与 decide_game_creator_plan_gdd 分发分支及 createPlanGddStateView fixture；未配置策划 状态时 hydrate 与接入前一样抛出，既有 378 条行为不变。新增 plan-gdd.suite.ts 三条 回归并逐条变异验证——逆转对应修复后三条各自以自己的断言变红；修复二的变异是部分 逆转（保留新 Map 结构、只删 comment 比对），因此钉住的是 comment 这一维本身。 验证：appSurface.test.ts 381 passed / 0 failed；agentTraceSummary 与 rememberCommand （另两个 import src/App 的用例文件）13 passed；agc:typecheck 通过；6 个改动文件 ESLint --max-warnings 0 通过；check:encoding 5409 文件通过；git diff --check 干净。 不改 Rust——三条全在前端，后端语义已经正确。 文档：更正第 23.8 节 M1D-1 行误引的合入提交（5b11a0530 是 ESLint 修正，落地是 0052a80da），并补 M1D 审查修复快照。同时更正既有记录里「Shell typecheck / appSurface 受仓库依赖缺失阻断」的说法——在原分支主工作树上两道门都干净，实际是 bf2185fba 改名 taskGroupLabels.design 后自己把 8 个用例文件断言改红，由 c6a08ef98 补修。 未并入的四条审查发现：hydrate 身份校验排在落盘投影修复之后（第 18.3 节固定顺序， session.previous.json 提升+删除不可逆）；锁竞争错误回传项目绝对路径（第 18.3 节）； design 组展示名剩两处字典未改（第 18.2 节）；阶段进度轮次差一格。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 11:11:18 +00:00
lhk229	4624fd7953	同步M1D合入状态记录 ... 更新M1D-1与M1D-2的合入提交和自审结论 保留M1E端到端与故障注入后续范围	2026-08-18 09:21:58 +00:00
lhk229	bf2185fba0	完成M1D-2入口分流与阶段进度 ... 游戏新项目默认进入立项策划并保留直接开建路径 项目总控页面挂载GDD审批卡与阶段进度 同步策划展示名称、定向测试与开发日志	2026-08-18 09:11:38 +00:00
lhk229	0052a80dad	完成M1D-1策划状态与审批卡 ... 新增严格输入的策划状态 hydrate command 与 plan-gdd-state-view.v1 read model 接入 GDD 审批卡、正文详情弹层、决定幂等与恢复重试 补充 M1D-1 开发日志和技术方案状态	2026-08-18 07:56:20 +00:00
lhk229	14c00017c6	同步M1C-2c合并状态 ... 更新项目决策日志中的合并提交信息 同步技术方案的M1C-2c完成状态	2026-08-18 06:20:49 +00:00
lhk229	c85452795d	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-18 06:16:47 +00:00
lhk229	0abdc41c3c	M1C-2c 收口：分隔符集合补全角冒号，并钉住 label 与回答的同尺比对 ... 分隔符集合原本只有 `·`/`:`/`-`。prompt 全中文、实测用的是 DeepSeek 系模型，在中文 语境下写 `A：方案名` 是高频输出；漏掉全角冒号的后果不是判错，而是合法信封被判形状 错误、回灌重试，白吃一个未推进回合预算——而第 23.9 节自己就记着无界重试把单次 prompt 撑到 15 万 token 的实测。 - PLAN_OPTION_LABEL_DELIMITERS 补 `：`；prompt 的 label 说明与技术方案 §5.1、§5.2、 §23.9 三处分隔符合同同步改口，避免两侧各写一份 - 回归 planning_clarification_accepts_fullwidth_colon_option_labels。变异验证： 去掉 `：` 后该用例立刻红 另外收回一条误报。此前判断「答案走 normalize_plan_text 被 trim、label 是信封原文没 trim，模型吐带尾随空白的 label 会让用户点选 A/B 掉进自由填写分支、台账记成 user_freeform」。写完测试做变异验证时把改动回退，用例照样绿；查下去发现 user_input.rs 的 normalize_single_line_user_input_text 在信封严格解析时就已经 trim 过 label（并拒掉含换行的 label）。两边本来就是同一把尺子，不对称不存在。 - 生产侧只把比较抽成具名函数并在原地写清它依赖的是解析侧那条 trim，不做多余的重复 规范化——那会把一个不存在的风险写进代码 - 保留 planning_clarification_option_pick_survives_untrimmed_label，它钉的是上游那条 不变量：解析侧哪天不 trim 了，这条会红 - 测试脚手架加 *_with_labels 变体，让用例能注入自定义 label；原有 helper 转为薄包装 planning_clarification_ 16/0、plan_ 160/0、recovery 107/0，fmt 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:15:25 +00:00
lhk229	6e4bd97039	收口M1C-2c决策卡A/B语义 ... 更新策划决策卡的A/B平行方案与原型验证合同 收紧Runtime选项校验和决定状态映射并保留用户原文 补充必要的自由填写与非法信封回归 同步更新提示词、技术方案与项目决策日志	2026-08-18 04:27:54 +00:00
lhk229	0199fb6e4c	决策卡 A/B 修订改回恒定三项，标注 M1C-2b 已合回、M1C-2c 可开工 ... - 技术方案 §5.2 指向注 / §23.8 M1C-2c 行 / §23.9：第 3 项「需要原型验证」每张卡固定给出， description 须给出可执行的验证方式；信封形状校验改为恰好三项 - §23.9 与 decision-log 条目：M1C-2b 已快进合回并把固定三选项的校验与映射冻结在 planning coordinator，映射翻转/形状校验/prompt 文案由 M1C-2c 承接，现在即可开工 - decision-log：补 M1C-2b 条目与本条之间缺失的空行 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-18 03:25:56 +00:00
lhk229	95facd9150	补充 M1C-2c 决策卡文档 ... 更新共享决策日志，记录 A/B 平行方案、改口转述规则与提问纪律。 更新 Fast GDD 技术方案的阶段状态、工作包矩阵和 M1C-2c 设计说明。	2026-08-18 02:58:52 +00:00
lhk229	152cc40c7b	完成 M1C-2b 策划澄清与预算接线 ... 接入三轮澄清中转、确定性 continuation/session 投影及恢复锁序 记录并幂等折叠 planning Provider 活跃时间与末次提交 usage 补齐审批后用户修订谱系校验和质量返工失败关闭 补充并发、恢复、重放、usage 回归并同步技术方案与决策日志	2026-08-17 15:01:33 +00:00
kdletters	7f60a00c84	修复预览镜像认证入口 ... 为分支预览启用首次密码登录自动注册 为预览短信入口配置隔离 mock 验证码 补充预览部署门禁和认证验收文档	2026-08-17 22:55:27 +08:00
kdletters	38ae9d7d07	完善预览发布记录管理 ... 发布记录改用 Jenkins 构建编号并展示 失败与停止记录增加自动清理期限 构建详情改为局域网 Jenkins 地址 同步测试、部署配置和运维文档	2026-08-17 12:42:29 +08:00
lhk229	a60f95b554	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-17 04:30:42 +00:00
kdletters	abb3912530	增加分支与提交搜索校验 ... 增加分支和 commit 的输入搜索下拉构建前复核固定仓库中的分支与 commit 归属补充预览控制面接口合同、配置和测试	2026-08-17 12:04:31 +08:00
kdletters	ced4b56dee	优化预览发布记录展示 ... 发布记录增加后端校验后的 Web 端口号 列表隐藏已成功卸载的容器记录 兼容恢复旧运行记录并回填 Web 端口 补充后端、前端测试和技术说明	2026-08-17 10:47:58 +08:00
lhk229	4498c15f90	完成 M1C-2a验收前置门 ... 固定 plan 根 Goal Contract 与唯一 Fast GDD 验收节点。 记录并校验 Supervisor 根 Run 的完整分页 file.read 证据。 接通认领后三态审批前置门、幂等 pending 恢复与完成门。 修复审批后 session 校验及 pending/receipt 优先级边界。 补齐恢复、finalization、身份冲突和工作包边界回归。 同步 Fast GDD 技术方案与项目决策日志。	2026-08-17 02:40:11 +00:00
lhk229	d96fa7b755	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-15 12:03:01 +00:00
lhk229	f45e90e36b	M1C-1：落地 Fast GDD 审批闭环与完成门 ... 新增 plan-gdd approval receipt、pending、审批命令及三动作幂等投影。 接入 receipt 恢复、generic submit 锚点精确消费与 terminal observation 完整性校验。 接入 exact plan-root completion blocker，并补充 pending、recovery、作用域和 identity 回归。 同步 Fast GDD 技术方案与项目决策记录。	2026-08-15 12:00:57 +00:00
kdletters	c75fcbf023	修复预览构建状态解析与工作进程恢复 ... 限制 Jenkins 状态接口只返回监控所需字段 避免完整构建 JSON 触发反序列化递归深度限制 让预览外部生成工作进程在身份初始化后自动重启 补充定向测试、防回归检查和技术说明	2026-08-15 18:52:10 +08:00
kdletters	cf5eac1c63	修复Jenkins成功收尾状态竞态 ... 为队列、构建状态和部署产物查询增加有限重试 避免 Jenkins 瞬态无效响应永久覆盖成功部署状态 增加构建收尾竞态回归测试和技术说明	2026-08-15 18:38:59 +08:00
kdletters	ea81d8ebb5	修复预览数据库容器内存不足 ... 将分支预览 SpacetimeDB 内存上限覆盖为 2 GiB 保留生产与压测 Compose 的原有资源基线 增加预览内存覆盖防回归检查和故障说明	2026-08-15 18:33:30 +08:00
kdletters	d0a8f254b3	修复预览环境非交互发布 ... 允许 SpacetimeDB 向受控容器网络地址非交互发布 固定预览结果使用内网主机地址 补充发布参数与内网地址防回归检查和文档	2026-08-15 18:30:08 +08:00
kdletters	7cd8b39593	Revert "修复预览部署可选提交参数" ... This reverts commit d2366bc40a.	2026-08-15 18:09:04 +08:00
kdletters	5e7ff450b6	Revert "修复预览部署脚本执行方式" ... This reverts commit 7fc739fad0.	2026-08-15 18:09:04 +08:00
kdletters	7fc739fad0	修复预览部署脚本执行方式 ... 通过 bash 显式调用 Jenkins 源码检出脚本 增加脚本执行方式防回归门禁 同步预览部署执行合同文档	2026-08-15 18:03:49 +08:00
kdletters	d2366bc40a	修复预览部署可选提交参数 ... 修复 Checkout 阶段在严格 shell 下展开未定义 COMMIT_HASH 的失败 增加预览流水线参数归一化防回归门禁 同步预览部署参数合同与项目决策文档	2026-08-15 18:00:05 +08:00
lhk229	23559b1b1c	修复 CI 五条失败：三处校验的位置错误放大了作用域 ... 撤回 M1B-2 对 tool-plan 交接判据的跨 loop 上提并补正向回归 恢复扫描的锚点探测器不再对不可读 state 强读，交还下游 fail-closed 兜底 planning 存储把链接路径统一分类为 PLAN_UNTRUSTED_PATH Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 09:45:44 +00:00
kdletters	41874ab391	新增内网容器预览部署控制面 ... 新增分支与指定提交的预览部署 SPA 和 Jenkins 代理服务 新增多实例 Docker 预览流水线、端口租约、实时健康状态和卸载能力 新增 /build 内网路由、systemd 部署资产和运维文档 修正容器 Nginx 健康检查探针	2026-08-15 17:18:10 +08:00
lhk229	ecfc6f1a2a	Merge remote-tracking branch 'web/master' into feat/five_min_design	2026-08-15 08:12:43 +00:00
lhk229	f93103760a	M1C-0b：合并原分支最新修复 ... 合入 Agent 主循环栈溢出修复 保留 M1C-0b 静态委派状态前向兼容实现	2026-08-15 08:08:01 +00:00
lhk229	53f2ba30c3	修复 Agent 主循环栈溢出：专用 worker 判据从枚举入口改为不变量 ... CI 上 background_agent_runtime_recovers_stale_running_before_pending_task 在 tokio-rt-worker 栈溢出。根因是 recovery_scan.rs 手写 tauri::async_runtime::spawn 直接 跑 drain_game_creator_agent_background_tasks——正是仓库规定必须上 16 MiB 专用 worker 的那个 future。pitfalls 2026-08-03 按入口枚举了三个（普通后台任务、静态委派子任务、 manifest ready-task 首次执行），恢复重启是第四个，从未被列进去；漏掉一个入口不会产生 任何信号，故判据改写为不变量：所有会进入 Agent 主循环的 future 必须在 agent-runtime-worker-* 专用线程上轮询。 改动： - 统一常量 AGENT_RUNTIME_BACKGROUND_WORKER_STACK_BYTES - spawn_next_*_with_lock 改用专用线程；签名保持 -> ()，8 个调用点不动。该入口是 best-effort 幂等语义（拿不到锁即返回、后续 wake 重试），建线程失败只需记录并随闭包 释放锁，无需交还锁、也就不需要握手 - recovery_scan.rs 两处手写 spawn 收敛为 helper 调用。恢复重启顺带补上首轮轮询握手： 原写法把执行锁 move 进一个无人保证会被轮询的 future，运行时关停时 run 会永远停在 running 且无主 回归钉不变量而非钉余量：drain 入口在 cfg(test) 下记录线程名，用例断言必须以 agent-runtime-worker- 开头。变异验证——改回手写 spawn 且 RUST_MIN_STACK=16MiB（因而不 溢出）时，用例仍以 ["tokio-rt-worker", "tokio-rt-worker"] 失败。 实测（同机、二分 RUST_MIN_STACK，默认栈 2048 KiB）： - started 变体：master 需 1536-1792 KiB，修复前 HEAD 需 2048-2176 KiB - 队列 drain：master 需 1280-1536 KiB，修复前 HEAD 需 1792-1856 KiB，余量已不足 256 KiB - 修复后两条用例在 1024 KiB（半个默认栈）下通过 同过滤器 A/B（runtime_actions + collaboration，同一 skip）： - 修复前 HEAD：19 failed，且在 planning_strategy 处栈溢出 abort - 修复后：289 passed / 0 failed 修复前分支实际有三处溢出点（recovery、response_stream::provider_handoff_*、 planning_strategy::tool_planning::*），CI 只报了最先撞上的那个；三处修复后均通过。 共享 tokio pool 不再被长时间占用，mock LLM 超时类失败同时大幅减少。 需回流 master：master 同样存在恢复重启走默认栈与 drain_next_* 余量偏低，只是尚未触发。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 08:04:06 +00:00
lhk229	89bbfd135a	M1C-0b：补齐静态委派状态前向兼容 ... - 未知 contractStatus 保留为 Unknown(raw) 并接入完成屏障、等待、返工与谱系门禁 - 补齐 planning Provider、自治 liveness 与终态扫描的 fail-closed 消费路径及回归 - 保持已知状态和损坏 sidecar 行为不变，更新技术方案与共享决策记录	2026-08-15 07:04:40 +00:00
kdletters	aa5221abcf	修复Jenkins Web依赖安装 ... Web构建同时安装根目录与AGC独立lockfile依赖 Full流水线同步RUN_NPM_CI参数说明 生产运维门禁锁定双依赖安装顺序 运维文档补充故障原因与依赖边界	2026-08-15 14:15:03 +08:00
lhk229	deae1e08ce	立项策划：裁决 M1C-1 三条开工前置，前向兼容粒度另拆 M1C-0b ... 对 2026-08-14「M1C-0 合入复核」留下的三条前置逐条读实代码后定稿： ① barrier：补，且必须是独立的第六个计数 user_revision_pending_count。 不能并进 repair_required_count——它带 repair_of_delegation_id.is_none() 只算原始委派，而用户第 2 次修订的父节点自身就是 repair 节点，并进去会让 第 2 次及以后的修订全部不阻塞。判据形状照 user_input_required_count。 另有四处逐字段读 barrier 的调用点不走 is_clear()，加字段不会自动传播。 ② 正向一致性：复用 EvidenceReady 的三条客观证据约束，并把该处 if/else-if 链改成穷尽 match；但不得更严——该函数在每次读取时都跑，过严会把写入方的 一个 bug 变成 delivery 永久读不出来。同时订正：这不是既有漏洞，唯一派生点 产不出该变体，约束的是 M1C-1 引入的第二个写入方。 ③ 前向兼容粒度：订正 08-14 自己写的「二选一」——「单条跳过并告警」不安全， barrier 是计数，跳过一条损坏的 Dispatched 记录会让 Supervisor 在仍有未完成 委派时收束，把可用性故障换成正确性故障。改走第三条路（损坏仍整体锁死， 前向不兼容解析进显式 Unknown 并最大化阻塞），并另开 M1C-0b 承接——该改动 触及 master 已发布机制的所有读路径，不得塞进 M1C-1 的 diff。 另记两条比 08-14 更糟的事实：锁死半径是整个项目目录而非单个 run； .json.previous 备份只在 primary NotFound 时回退，损坏但存在的 primary 不回退。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:57:12 +00:00
lhk229	f45db359bd	合并最新 master 到 feat/five_min_design，并修复 master 的 Windows 构建中断 ... master 侧 5 个提交（8e78be766..9f5c84ee7）。仅一处冲突： src/view/home/index.tsx 的 react import——我们这侧对该文件只有 prettier 格式化 改动，master 新增的 useRef 在合并后正文里用了 2 次，取 master 那行。 修复 master 带来的 Windows 构建中断（E0658）： project/manifest.rs 的 #[cfg(windows)] 分支用了 std 未稳定 API `MetadataExt::number_of_links`（rust-lang#63010），而 rust-toolchain.toml 锁在 stable 1.96.0。该文件与 origin/master 逐字节相同，即 master 自身在 Windows 上就 构建不过——Linux CI 上 #[cfg(windows)] 整块不参与编译，所以 CI 全绿。 改为本仓库既有写法：自声明 ByHandleFileInformation 调 GetFileInformationByHandle （另见 runner/endpoint.rs、tool_plan_handoff/storage_windows.rs 等六处）。保留原 错误文案与 fail-closed 语义（取不到句柄信息与确实是硬链接同等拒绝），并按 endpoint.rs 先例一并拒绝 directory / reparse point。 该修复目前只在本分支，须回流 master，否则下次合并会再撞一次。踩坑记录见 pitfalls.md 2026-08-15 条。 验证： - cargo check --offline --all-targets 通过（修复前 E0658，修复后 Finished） - cargo fmt --check 通过 - 定向 Rust 测试 project::manifest / godot / static_delegate / collaboration::static_deliveries 65 passed / 0 failed - agc:typecheck 通过；check:encoding 通过（5376 files）；git diff --check 干净 - 前端 vitest apps/ai-game-creator-shell/tests：738 passed / 1 failed，唯一失败是 已知的 Windows symlink EPERM（agentSwarmTestEntry），非本次回归 两条既有环境失败，已核实与本次合并无关： - command_exec::tests 两条报「找不到受信任的 rg 可执行文件」，该文件相对合并基线 逐字节相同 - npm run check:native-shells 在合并前的 master worktree 上失败得一模一样 （spawnSync npm.cmd EINVAL，脚本 spawn npm.cmd 未带 shell: true） Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:37:00 +00:00
lhk229	1d4d77ef3d	立项策划：落地 M1C-0 合入复核结论，三条 M1C-1 前置与一条哨兵订正 ... 生产代码零改动（delegation.rs 三个 hunk 全在 mod tests 内），本次只补回归与文档。 复核确认「今天行为零变化」成立且可证：contract_status 生产赋值点只有两处且都从 客观事实派生；StaticDelegateClaimRecord 全仓库唯一构造点是运行时构造，不是 agent 提交的 JSON；durable sidecar 在 .agent/runtime/** 下被 file_ops 与 filesystem 各 三处拒写；前端无 contractStatus 消费者。lineage 三个 fail-closed 出口全部返回 (u32::MAX, u32::MAX)，新分支的哨兵检查接得住。 三条 M1C-1 前置写进技术方案第 23.7、23.8 节与 decision-log： ① UserRevisionRequested 不进 repair_required_count / user_input_required_count 任一 barrier，写入方落地即意味着 Supervisor run 可在用户修订未派出时完成； ② validate_static_delegate_structured_result 对该变体只有否定约束，缺正向一致性 分支，UserRevisionRequested + failed + 缺产物 能通过校验落盘； ③ 前向兼容失败粒度是整个子系统——list_static_delegate_deliveries_at 逐条 ? 上抛， 一条解析失败即整个目录枚举失败。bump schema version 救不了（版本校验在 parse 之后）。 文档订正：STATIC_DELEGATE_LINEAGE_MAX_HOPS = 32 限的是链上节点数不是跳数 （判据排在入链之前），真实跳数上限 31，第 23.7 节原写 32 跳已订正。 测试： - static_delegate_user_revision_preserves_existing_clarification_round 名不副实， 它把 UserRevisionRequested 放在目标位置，而计数循环只遍历父节点集合，新分支 从未被执行。改名为 ..._parent_hop_preserves_depth_and_clarification_round，补 一跳真正以用户修订为父的续跑并加反证；原断言留作对照组并注明性质。 - 新增 concurrent_user_revision_dispatch_creates_exactly_one_delivery，父节点为 UserRevisionRequested 且 depth 已为 1，两侧同时钉住并发下恰好放行一条。 - user_revision_continuation_... 补兄弟检查断言（depth 门对用户修订失效后，它是 该路径上唯一剩下的扇出约束）。 变异测试：摘掉 counters 分支 4 条变红（含新增反证 left (2,0) / right (1,1)）； 摘掉 gate 分支 3 条变红（并发用例 left 0 / right 1）。两处守卫各自有回归覆盖。 验证：定向 41 passed / 0 failed；npm run check:encoding 通过（5374 files）； git diff --check 干净。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-15 05:17:39 +00:00
lhk229	8c4acaaad5	文档：记录 M1B-2 已合入原分支 ... 更新 Fast GDD 技术方案与 decision-log 的工作包状态和验收快照	2026-08-15 04:42:21 +00:00
kdletters	9f5c84ee71	重构AGC项目管理界面 ... 参考成熟桌面项目管理器重构紧凑项目表、搜索和行尾菜单 支持Windows路径及Godot根目录和一层子目录工程识别与导入 修复1280×720页面溢出、列表滚动和末行菜单裁切 补充项目页回归测试、PRD、技术方案和项目记忆	2026-08-15 11:43:58 +08:00
lhk229	27c3eb847a	立项策划：完成 M1B-2 GDD 提交与恢复 ... 接入 plan.submit_gdd 原生工具及 exact planning Provider 绑定与结构化注入 实现 create-only GDD 提交点、索引 Markdown session 恢复与策划子 run 收口 补齐定向门禁与阶段文档记录，审批 receipt UI 和构建准入留待后续	2026-08-14 14:23:58 +00:00
kdletters	578f8019fc	优化AGC项目入口并识别Godot工作区 ... 项目页只保留打开项目和新建项目并统一原生目录选择 按根目录及一层子目录识别project.godot并记录相对Godot根 保持.agent位于用户选择的工作区根并补齐Windows构建门禁 补充响应式布局、测试、技术方案和共享项目记忆	2026-08-14 21:53:43 +08:00
k88936	d901945c77	移除视频快速编辑支持 (#157) ... 当前实现: 视频快速编辑错误地复用了图片快速编辑的panel, 然后发起一个实际是生成视频的请求 策划建议删除. 因为后端没有实际意义上的视频快速编辑, 所以api 后端代码没有改动, 只在前端删除入口和处理 --------- Co-authored-by: kdletters <kdletters@qq.com> Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/157 Co-authored-by: 王德宇 <kvtodev@outlook.com> Co-committed-by: 王德宇 <kvtodev@outlook.com>	2026-08-14 18:52:56 +08:00
kdletters	d155e303bd	实现AGC回车自动创建工作区 ... 首页普通回车自动分配系统文档目录下的唯一工作区并启动项目总控 保留加号按钮手动选择目录和Shift回车换行语义 统一Windows Linux与macOS默认项目路径解析并移除产品态tmp默认值 补充自动工作区安全测试 首页交互回归与技术方案说明	2026-08-14 17:45:27 +08:00