2905 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
lhk229	c6a08ef98f	修复M1D前端文案回归断言 ... 同步立项入口与设计实现组展示文案的测试期望 恢复Frontend tests与Native shell tests中的前端测试覆盖	2026-08-18 09:35:28 +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	9bad7121b5	修复 Native shell tests 既存红：委派用例改调 _at_locked ... CI task 3784 的 Native shell tests 报 2121 passed / 3 failed，三条同因： agent.delegate -> failed, "无法取得一致项目快照" 项目正在被其他写操作占用：$PROJECT_ROOT/.agent/project.lock - autonomous_direct_child_collaboration_mutations_require_the_current_root - autonomous_delegate_descendant_inherits_and_enforces_the_current_root_guard - standard_delegate_collaboration_mutations_remain_compatible 根因是又一次「把动作挪到调用链更前面，改变的不是严格度而是作用范围」。 bc1fe7d8f 写这几个用例时，观察点是「测试先持项目写锁、再调 observe_agent_runtime_agent_delegate」，当时无害：老薄壳压根不碰项目锁，它调的 start_..._with_link_at 只对 planning 身份取锁，其余身份走 ..._with_project_lock_at(..., None)。 152cc40c7（完成 M1C-2b 策划澄清与预算接线）为了让 planning 子 session 的投影按 project -> session 取锁，把锁的所有权上提，拆出 observe_agent_runtime_agent_delegate_at_locked，并让同名薄壳在入口无条件取项目写锁。 而 .agent/project.lock 是 create_new(true) 的文件锁、不可重入：调用方已持锁再进薄壳 就死等满 2000x5ms 预算再失败。确定性红，不是抖动——本机复现逐字一致。 这不是生产漏洞。生产侧调 agent.delegate 的只有 action_execution.rs:436 和 pending_recovery.rs:162，两处都持锁后调 _at_locked；取锁的薄壳如今零生产调用方， 只剩测试在用（main_loop_tests、autonomous_completion_contract_tests 那些都不持锁， 所以一直是绿的）。所以改测试面，生产代码零行改动。 - delegation.rs 四处（2515/2584/2678/2740）改调 _at_locked 并传入已持有的 &project_lock。这不是迁就实现：_at_locked 才是生产唯一的调用形状，改完这三个用例 覆盖的是真实路径。首处留注释说明为何必须绕开同名薄壳——否则下次「顺手统一」回去 会复发，而症状是 10s 静默卡顿，很难往锁不可重入上想 - runtime_tools.rs 补一条 #[cfg(test)] pub(crate) 再导出。生产侧靠 pub(in crate::agent) 的 glob 即可见，测试模块在 crate::agent 之外需单独放行； 沿用旁边 #[cfg(test)] pub(crate) use delivery::{...} 的既有写法，不动生产可见面 验证：tests::collaboration::delegation 改前 22 passed / 3 failed（18.68s），改后 25 passed / 0 failed（5.54s）。少掉的 13 秒正是三条各自空等 10s 锁预算的量——那三次 等待没再发生，不是断言被放宽。cargo fmt --check 干净。 另记一条前提更正：AGC shell crate 是有 CI 的。project-ci.yml 的 native-shell-tests job 跑 npm run check:native-shells，本次覆盖 2124 条。此前「这个 crate 在 CI 里从不 编译也不测试」的判断是错的。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 08:35:27 +00:00
lhk229	5b11a05303	修复 M1D-1 带进的 eslint 红：import 排序与 hook 依赖判据 ... CI task 3777 的 Repository checks 停在 lint:eslint，前面的 encoding / git-hooks / rustfmt / spacetime schema / production-ops / preview-deployer / maintenance-page 全绿。三条问题全在 0052a80da 自己动的两个前端文件里。 - simple-import-sort：新加的 PlanGddDecisionAction / PlanGddStateViewV1 插在了 PendingCommand 前面（ASCII 序 Pending < PlanGdd），ProjectWorkspaceChatPane 里 GddApprovalCard 也落在同目录组末尾。autofix 修正 - react-hooks/exhaustive-deps 是 warning，但 lint 脚本带 --max-warnings 0，一样退 1。 这条不能靠补依赖解决：该 effect 的依赖只挖 phase/status/updatedAt 三个标量，正是 为了避开轮询每轮新建对象的身份变化；把 projectSupervisorRuntime 本体写进依赖会让 每个 tick 都触发一次 hydrate。改的是判据侧——存在性从整个对象换成必选字段 status（AgentRuntimeState.status: string 必选，为 undefined 当且仅当 runtime 为 null），语义等价且不再引用裸对象 本地 npm run lint:eslint（全仓，--max-warnings 0）、npm run typecheck、 npm run check:encoding 均通过。typecheck 是 CI 未走到的下一步。 另记一笔：.husky/pre-commit -> lint-staged -> scripts/lint-staged-eslint.mjs 会拦这 两类（自动修 import，且 errorCount 或 warningCount 非零即置退出码），本 worktree 的 core.hooksPath 也确实指向 .husky/_。这三条能进库说明 0052a80da 绕过了钩子。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 08:08:57 +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	6234b420fc	修复 HEAD 既存红：策划恢复门用例改建可达状态 ... planning_recovery_contains_session_identity_conflict_before_provider 自 M1C-2b （152cc40c7）写下起一天都没绿过：它伪造一个 source=agent-background-task、且没有 Run Profile 绑定的策划任务，而 agent_runtime_tool_policy_snapshot_for_run_at 早在 M1A-2（09c7d7af8，152cc40c7 的祖先，已核对该门在 152cc40c7 当时就一模一样）就按 agent 身份挡死了这种 run。被告造不出来，庭开不了。当时的定向门禁过滤器 planning_clarification_* 恰好匹配不到它的名字，加上本 crate 不在 CI 里编译，两层 网都没接住。 那道创建门不能放宽：放宽后伪造的策划 run 就能拿到默认宽工具面，正是 M1A-2 关掉的 洞。所以改测试而不是改生产代码。 也不删：该用例第四条断言「身份门必须早于任何 Provider lifecycle」是全 crate 唯一 一处该不变量的否定断言（AGENT_RUNTIME_PROVIDER_REQUEST_LIFECYCLE_RECORD_TYPE 共 22 处引用，否定断言仅此一处），且 plan_session_recovery_gate_tests 模块只有这一条 用例，删掉等于整个门失去覆盖。 先试了更贴现实的「事后删父绑定」，实测走不到本门：entrypoints 的 tool policy 收容 （currentAction=Run Profile 工具策略需要人工核对）先把 run 打成 failed， read_recoverable_... 随即不再认它，审计里只有 agent.runtime.turn。也就是说绑定层的 破坏到不了 session 门；能到这里的只有「绑定完好、task record 自身不满足 D11 契约」 这一类持久不一致——这正是本门存在的理由。 - 改成：supervisor plan 根与 planning child 绑定都合法（创建门放行），但裸 start 不带 task link，task record 上没有 parentAgentId/delegationId - 四条断言原样保留：resume 必须 Ok（收容不外溢）、该 run failed/needs-reconciliation 且 error 含 PLAN_SOURCE_PROFILE_MISMATCH、审计有 plan.session_recovery. needs_reconciliation、且没有任何 Provider lifecycle 记录 - 断言失败信息带上实际审计记录类型与 currentAction，下次判因不用再加探针 - 变异验证：把 exact_plan_child_identity_at 的策划识别翻成直接 Ok(None)，用例报出 "PLAN_NEEDS_RECONCILIATION: project-planning 恢复任务未命中 planning session 协调器" ——证明它确实在考这道门，而不是碰巧绿 - recovery 107/0、planning_ 151/0、session 88/0、plan_ 160/0、approval 11/0 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:02:33 +00:00
lhk229	73816bd512	修复 HEAD 既存红：planning session 恢复块给双锚缺失诊断让路 ... committed_plan_submit_without_either_anchor_is_publicly_recoverable_and_fails_closed 在 HEAD 上确定性失败（Windows 与 WSL 干净基线一致，与本轮审查修复无关）： phase 确实是 needs-reconciliation，但 error 不是「恢复锚点同时缺失」。 M1C-2b 把 planning session 恢复块插进了同一个循环，位置在 reconcile_missing_plan_submit_anchors_at 之前。该 fixture 用裸 start_game_creator_agent_runtime_task_at 建策划任务，task record 上没有 parentAgentId/delegationId，于是 exact_plan_child_identity_at 判定身份不符、 返回类型化 Err，session 块随即落 needs-reconciliation 并 continue，更具体的双锚 缺失诊断永远轮不到跑。两条都写 needs-reconciliation，谁先写谁赢，而先写的恰恰是 信息量更少的那条。 不是判错，是插在前面的门改变了哪条诊断胜出——与 M1C-1 那五条 CI 失败、与 P4 同一形状。 - session 恢复块加让路条件：该 run 是双锚缺失候选时跳过。本块只服务「将要继续」的 continuation，而双锚缺失的 run 根本不会继续，修投影没有意义 - 选让路而不是调换两块顺序：调换会让锚点探测对所有 Agent 提前，正是「前移改作用域」 那个坑本身。探测器只对 project-planning + agent-delegate + standard 返回 Some， 且对已按双锚缺失收敛过的状态返回 None，因此这道让路既窄又幂等 - recovery 族 105 passed/2 failed -> 106 passed/1 failed，planning_ 150/1、 session 87/1；剩下的唯一红是 planning_recovery_contains_session_identity_conflict _before_provider（另一条既存红，下一个提交处理） Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 06:02:05 +00:00
lhk229	c1a70cb37d	审查发现2：验收前置门先识别 Fast GDD 再走绑定父链 ... ensure_plan_gdd_approval_pending_after_acceptance_locked 先用会遍历并校验整条 祖先链的 read_..._run_profile_binding 读绑定，再检查 binding.source 是否为 project-supervisor-plan。顺序反了：任何祖先绑定的毛病都抢先变成 Err，连「这根本 不是策划根」都来不及说，于是别人的坏链变成了这道门的失败。 这正是 P4（cb5af31e7）在同文件 plan_root_completion_identity_at 修过的形状，当时 漏了这个姊妹函数。而它比完成门更容易被踩到：agent.run_status 每次 status observation 都会重跑本门（见 runtime_tools/run_status.rs 的 「Re-run the locked gate on every plan-root status observation」），那条路径上没有 任何上游守卫先把带父链的 run 挡掉，适用性完全交给门自己判。 - 识别改用 _once，只看 run 自己那条绑定记录；确认是策划根之后才走完整父链， 严格度一点没降，只是不再作用到别人身上 - 回归 broken_ancestor_binding_must_not_fail_the_acceptance_gate_for_a_non_plan_supervisor_run： 复用 P4 的构造（supervisor 的 isolated-join 子 run，删掉父绑定），断言门只能判 NotApplicable。变异验证：换回链走优先后该用例报出 Err("Agent Runtime Run Profile 父绑定缺失") Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 05:33:52 +00:00
lhk229	7e3fd411a1	审查发现1：澄清恢复的锁序重排改为让出本轮，不再掐掉整批 resume ... M1C-2b 为澄清 pending 新增的「drop 执行锁 -> 取项目锁 -> 重取执行锁」重排块， 两次取锁都用裸 `?`。执行锁的重取只等 25 x 10ms，而用户刚提交澄清回答时那把锁 会被 move 进后台续跑任务、持有整个 Provider 回合，稳超等待上限；错误经 recovery_scan 的裸 `?` 上抛，掐掉 for agent_id 循环里整批 Agent 的恢复，并把一次 纯瞬时的锁竞争直接返回给前端。 锁被占恰恰说明别处正在推进，是最不该判失败的时候。同一个 commit 里的姊妹代码 （planning session 恢复窗口）已经写对：项目锁按 transient 判据 continue，执行锁 用非阻塞 try_acquire 拿不到就 continue。 - AgentRuntimePendingActionResume 新增不带锁的 Deferred，表示两把锁都已释放、 本轮让出；批量扫描的三处 match 一律 continue - 项目锁改为 transient 判据让路，其余错误仍带上下文上抛 - 执行锁改用 try_..._with_wait：等待宽限不变，超时是「本轮没轮到」而非「恢复失败」 - Runner 定向续跑不是批量扫描，Deferred 仍如实报错，文案沿用执行锁自己的措辞 - 回归 planning_clarification_recovery_defers_when_execution_lane_is_still_held： 按住项目锁把恢复卡在重排窗口，抢走执行锁后放开项目锁，断言必须 Deferred。 变异验证：回退成阻塞版 `?` 后该用例报出 "Agent Runtime 正在执行该 Agent 的其他任务：project-supervisor" Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-18 05:33:36 +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
lhk229	9f12d84678	合并原分支最新修复 ... 合入 P4 的 Fast GDD 识别顺序修复。 合入 P5 的委派栅栏 detail 等价性锁定。	2026-08-17 07:31:55 +00:00
lhk229	a8215a5997	P5：把委派栅栏 detail 的「拼串→再解析」锁成等价关系 ... M1C-1 把 userRevisionPending 同时加进了 StaticDelegateCompletionBarrier::detail() 的输出和 project_gates 的解析门，两边靠一个字段名字符串隔空对齐，中间没有共享 schema。 当时生产侧只有 delegation.rs 一条 detail().contains("userRevisionPending=1")，解析侧 一条测试都没有，两者之间也没有任何东西相连：字段名一改，生产侧那条照过，而三个门静默 返回 false，父 run 就会越过用户修订边界收束。 已核实这条路径是「单一生产者 → 四个解析点」：static_delegate_completion_blocker_at 原样使用 detail: Some(barrier.detail())，main_loop 的四处解析都以 tool == "runtime.delegate_receipts" 为前提。 新增用例锁的是等价关系而不是拼写：对七个计数的全部 128 种 0/1 组合，断言三个门的判定 与 barrier 自己的语义谓词逐一相等；另加多位数计数与「键之间互不为前缀」两条护栏——后者 是 strip_prefix 读对值的隐含前提，等价关系测试抓不到这层前提何时被打破。 鉴别力已用变异验证：把解析器的 userRevisionPending 改名为 userRevisionRequested， 或往 has_waiting() 里加一个解析器不认的计数，两个漂移方向都会被抓住。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 07:24:55 +00:00
lhk229	cb5af31e79	P4：先识别 Fast GDD 再走绑定父链，别让祖先坏掉误伤非策划 run ... plan_root_completion_identity_at 读绑定用的是会遍历并校验整条祖先链的入口， 而识别 Fast GDD 只看 run 自己那条记录的 source/profile。链走排在识别前面，于是 任何祖先绑定的毛病都先变成 Err，再被完成门统一翻成 needs-reconciliation——扣在一个 下一行本来就会被判「不是策划根」的 run 头上，让它再也收束不了。 可达：task_start 里 requires_public_start_status 明确把 agent-delegate-receipt 与 agent-isolated-join 排除在「无父的公开启动」之外，带父链的 supervisor run 在生产中 确实存在。新增复现用例在修复前报 Some(NeedsReconciliation)。 改动安全的两条依据： - 两个入口对同一个 (agent, run) 返回的绑定值完全相同（链走版本最后返回的就是 run 自己那条记录），链走纯属校验副作用，识别判据一字未变。 - 策划根的严格度一点没降：validate_project_supervisor_plan_root_binding_at 内部读的 就是链走版本，且强制 parent 必须为空。被移除的只是即将判定「不是策划根」那条路径上 的链走，顺带消掉同一条绑定被连着走两遍父链。 另外把 PLAN_GDD_APPROVAL_SOURCE 与 AGENT_RUNTIME_SUPERVISOR_PLAN_SOURCE 必须同值钉成 编译期断言：识别用前者、复核用后者，两者分处不同模块各自定义，一旦分叉每个策划根都会 先通过识别再被复核拒掉，全部塌成 needs-reconciliation，而且没有测试会指向这个原因。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 07:08:47 +00:00
lhk229	23b6f3a7ca	合并原分支的 M1C-1 审查修复	2026-08-17 05:51:30 +00:00
lhk229	f8568f77db	P3：审批路径统一走 resolve_planning_path，并修正瞬时失败的处理 ... planning_storage 里 M1C-1 新增的六处审批路径绕过了 `resolve_planning_path`， 直接用通用解析器。通用解析器只认 `is_symlink()` 且把结果一律映射成 PLAN_INVALID_PATH；规划解析器认的是 FILE_ATTRIBUTE_REPARSE_POINT 全量重解析 标记，并如实报 PLAN_UNTRUSTED_PATH。审批回执是 GDD 完成门的判据，它的路径 分类必须和 GDD/session 一致。改完后 resolve_local_project_path 在本模块只剩 resolve_planning_path 内部一处调用，成为单一入口。 新增用例用 junction 而不是 symlink_dir 建链接：后者要开发者模式/管理员权限， 普通开发机上建不起来，用例会静默跳过成永远通过的空壳。 delivery.rs 里 user_revision_pending 那条分支是死代码——has_waiting() 已经 把它计入等待，上一道门必然先返回。删掉分支，把语义与跨文件依赖用 debug_assert 钉在使用现场，避免 has_waiting() 日后改动时静默跨过用户修订决策边界。 同时修正上一提交留下的问题：投影恢复失败必须分三路而不是两路。此前把「瞬时」 和「归属不到 run」并成同一个 false，导致瞬时锁争用走了全局上抛，让 resume 这 个可反复调用的恢复入口整轮失败——而锁被占恰恰说明别处正在推进。现在瞬时争用 只跳过本轮投影恢复，其余恢复照常，下一轮重试。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 05:40:00 +00:00
lhk229	34bcd61824	补齐 M1C-1 漏掉的 agent_db 守恒断言，并让审批投影恢复区分瞬时错误 ... M1C-1 给 agent_db 新增了 planning 决策预留车道并从普通追加额度里扣除，但 ordinary_append_soft_limit_preserves_action_receipt_record_slots 仍断言两车道的守恒 律，差额恰好是新车道的 2_097_280 字节；记录额度同样少算 128 条。master 没有这个常量， 所以 master CI 绿而本分支必红。断言补到三车道，记录额度改为 999_680。 审批投影恢复的收敛此前不分错误性质：`.agent/project.lock` 正被占用这类瞬时错误也会 把策划根 run 永久标成 needs-reconciliation——比收敛出现之前的强传播更糟。现在先过 static_delegate_parent_wake_error_is_transient（复用委派唤醒的既有判据，避免两处分类 漂移），瞬时错误照旧上抛，由调用方转成 recovery_pending 下一轮重试；只有持久不一致 才收敛到那个 run。新增回归覆盖这条分支。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:55:38 +00:00
kdletters	e455cd593c	兼容历史预览构建记录 ... 启动时回填旧记录的 Jenkins 构建编号 将旧 loopback 构建详情转换为局域网地址 补充历史记录迁移测试	2026-08-17 12:52:40 +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
lhk229	8d5338ce82	P2：reject 不是死路，锁住真正的约束 ... 原判定「reject 后同一 session 无法再次提交，因为 CAS 门只放行 collecting / revision_requested」不成立。提交门在 phase 判据之前先要求 session 的 activeRunId 等于 当前策划子 run，而 schema 不变量禁止 rejected / revision_requested / approved / awaiting_* / recovery_required 保留 activeRunId——两者互斥，终态 phase 根本到不了那条 phase 判据。把 rejected 加进允许集只会多一个不可达分支，续跑仍然起不来；连既有的 revision_requested 也已经是不可达的。 真正决定 reject 能否重做的是 M1C-2b 的 continuation 起点 writer：技术方案 §8.6 要求它 「以新 activeRunId 写 revision+1 successor」，而唯一能同时带 activeRunId 又过提交门的 phase 只有 collecting。本提交不改行为，只把这条因果写进门旁注释，并加一条回归锁住它： 终态 session 挂 activeRunId 在指纹阶段就被 PLAN_INVALID_SCHEMA 拒绝，而落回 collecting 的 continuation 能过提交门。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:28:49 +00:00
lhk229	1fa56a7aee	修复 M1C-1 打破的两条用户修订委派测试 ... M1C-1 让 UserRevisionRequested 与 EvidenceReady 共用同一套客观证据要求 （terminal completed、无缺失产物、验证已满足）。这两条测试仍沿用 M1C-0 时期的模拟 方式：拿一条 needs-repair 的 structuredResult 直接翻 contract_status，落盘时被判成 「evidence-ready/user-revision-requested 与客观证据冲突」——构造本身自相矛盾，不是 代码回归。改成先让 expected_artifacts 真实落盘、再按真实证据重建 structuredResult， 语义也更准：用户是在已交付的产物上要求修订。 已确认为既有破坏：两条在 A+B 之前的 c89a13e68 上以相同行号 panic。M1C-1 的验证范围 只写了 planning_submit/planning_storage 定向测试与 cargo check，delegation.rs 改了 +254 行却没跑，破坏就发生在那次改动里。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:16:09 +00:00
kdletters	abb3912530	增加分支与提交搜索校验 ... 增加分支和 commit 的输入搜索下拉构建前复核固定仓库中的分支与 commit 归属补充预览控制面接口合同、配置和测试	2026-08-17 12:04:31 +08:00
lhk229	a40080d525	P1：窄投影恢复失败不再掐掉整轮 resume，plan_gdd blocker 改类型化判别 ... A. reconcile_plan_gdd_approval_projections_at 挂在 resume 的第一行却用 `?` 强传播， 一次 Fast GDD 投影失败会掐掉全项目所有 Agent 的恢复；而它本身正是 receipt 投影失败 后的重试入口，掐掉它等于连兜底一起废掉。改成把 fail-closed 收敛到策划根 Supervisor 这个 run，其余 Agent 照常恢复；无法归属时才退回全局上抛。 B. main_loop 原来用 contains("approvalPending=awaiting_decision") 区分 plan_gdd blocker 的子状态，而三个 blocked 里只有一个含这个子串——尚未提交（下一步是 agent.delegate）和 receipt 锚点收尾都会掉进 else 被打成 needs-reconciliation，把最 正常的推进态当成故障停掉。改由构造方给出 PlanGddCompletionBlockerKind，消费方穷尽 match，判不出 kind 时保持 fail-closed。这两个推进态不再产生等待态，和 runtime.plan_update 一样让本轮循环继续。 映射抽成纯函数并建起 main_loop 至今没有的 mod tests：四个 kind × 两条映射全覆盖。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 04:02:54 +00:00
lhk229	c89a13e682	把 Fast GDD 审批等待的可恢复判据钉成不变量 ... 判据在 task record 的 status 而不是 phase：审批等待只改 phase、保留 status=running，恢复扫描仍会拉起；真正的澄清等待才会把 status 一并写成 waiting-for-user-input。一旦有人把审批等待也写成后者，审批命令的通用 wake 会静默变成 no-op，用户点完批准/修改/退回不会有任何东西继续跑，且无报错。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-17 03:28:24 +00:00
lhk229	360cedf4c0	合并隔离分支的M1C-1与M1C-2a改动	2026-08-17 03:10:18 +00: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	080c3ebc4f	修复预览部署结果字段冲突 ... 使用权威 branch 和 resolvedCommit 字段解析 Jenkins 产物 移除与附加 source 字段冲突的旧别名 保留状态解析错误上下文以便安全排障	2026-08-15 19:18:49 +08: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	a312ee20b5	修复预览流水线空提交参数 ... 允许 Jenkins 检出阶段安全读取未导出的可选参数 显式使用 bash 执行源码检出脚本 增加空提交参数与脚本执行方式防回归检查	2026-08-15 18:17:21 +08:00
kdletters	1a61c0bea7	修复Jenkins构建地址归一化 ... 将 Jenkins 返回的外部构建路径重绑定到受信本机 origin 增加外部 Jenkins URL 的状态与产物轮询回归测试	2026-08-15 18:12:39 +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	7400c706f8	修复预览流水线空参数校验 ... 在严格 shell 模式下归一化首次触发的空参数 避免 STATUS 与未指定 commit 的请求误报未定义变量	2026-08-15 17:39:07 +08:00