修复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>

docs/project-memory/shared-memory/decision-log.md

@@ -1,5 +1,16 @@
 # 决策记录
 
+## 2026-08-18 M1D 审查修复补充：锁错误脱敏与澄清轮次口径
+
+- **锁错误回传绝对路径**：`acquire_project_write_lock` 的 Err 内嵌 `.agent/project.lock` 真实绝对路径，违反第 18.3 节「返回值不包含绝对路径……或内部诊断」。补 `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（`project_write_lock_age_seconds`），填 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 缺符号链接判定（因其走裸 `root.join` 而非 `resolve_local_project_path`）。复核后**不成立**：`read_manifest` 自身在 `metadata.file_type().is_symlink()` 处即拒（`manifest.rs`），防护在另一层；`.agent` 目录本身为符号链接的残差也无窗口，紧随其后的 `resolve_planning_path` 同样逐段判定。未据此改动代码。
+- **仍未修**：① hydrate 在校验 GDD/session 的 projectId 与 manifest 一致之前已执行落盘投影修复，违反第 18.3 节固定顺序（修它须注意 `reconcile` 自取项目锁、`.agent/project.lock` 不可重入，不能把检查直接挪到 hydrate 取锁之后）；② design 组展示名仍有 `agentPresentation.ts` 的 `groupConfigs` 与 `view/project-development/index.tsx` 的 `summarizeAgent` 两处硬编码「策划 Agent」，注意该两处与 `taskGroupLabels` **命名体系不同**（「X Agent」对「X组」），直接替换会连带改掉另外五个分组名，需先定命名口径。
+- **新记一条既有问题（非 M1D 引入）**：`seedManifest.projectId` 是常量 `local-project-draft`，App 的 5 个 init/import 调用点全传它，因此**本机所有项目 projectId 相同**。第 18.3 节第 1 步依赖的「manifest 与 projectId 校验」因此分辨不出任意两个项目——把 A 项目的 `.agent/planning/**` 整体拷入 B 项目仍会通过。该门当前近乎恒真，须单独立项处置。
+
 ## 2026-08-18 M1D 审查修复：GDD 审批决定失败路径与恢复期弹层门控
 
 - **审查范围与基线**：对 `14c00017c..bf2185fba` 的 M1D-1/M1D-2 全量改动做规格对照审查（技术方案第 13、18 节）。审查完成后分支又前进了 `4624fd795`（文档同步）与 `c6a08ef98`（前端文案回归断言修复）两条，二者都不改 `src/**` 生产代码，审查结论不受影响。

docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md

@@ -2027,7 +2027,7 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 | `M1D-2` | 入口分流与阶段进度 | `M1D-1` | **已完成并以 `bf2185fba` 合入 `feat/five_min_design`**：游戏新项目默认 `standard + project-supervisor-plan`，显式“直接开建”保持 `autonomous-game-build`；阶段进度显示轮次 x/3、当前版本和状态徽章；实际项目总控页面挂载 hydrate/审批卡，并将 `project-planning` / 设计组展示名收口。未接 M2 approved-GDD 构建绑定或完整构建按钮。 |
 | `M1E` | 端到端与故障注入收口 | `M1D-2` | 第 21 节测试矩阵中跨层场景 |
 
-**2026-08-18 M1D 审查修复快照**：对 `14c00017c..bf2185fba` 做规格对照审查后，修复三条决定链路缺陷并补齐回归。① `decidePlanGdd` 的失败分支原来不 hydrate，命中后端任一 `PLAN_STALE_APPROVAL` 分支后卡片会停在已失效的 pending 身份上、`recoveryPending` 永不翻真导致「重试恢复」入口不渲染，现已按第 18.3 节在失败分支同样重灌（顺序钉死：`hydratePlanGddState` 入口会清空错误，必须先 hydrate 再写决定错误）。② responseId 复用键原为 `approvalRequestId:action`，不含 comment，违反第 13.2 节「改变 action/comment 必须换新 responseId」，现改为比对 `{action, comment}` 完整意图，判据方向为宁可多换不可少换。③ 第 18.2 节「`recoveryPending` 时不允许提交决定」原来只作用于三个触发按钮，已打开的评论弹层仍可提交，现已同门控并保留用户已输入内容。回归位于 `tests/appSurface/plan-gdd.suite.ts`，三条均经变异验证（逆转对应修复即变红）；`appSurface.test.ts` 381 passed，`agc:typecheck`、ESLint、编码检查通过。**本次不含 Rust 改动**；hydrate 身份校验与落盘投影修复的顺序、锁错误回传绝对路径、design 组展示名剩余两处字典、以及阶段进度轮次差一格四条审查发现单列后续，未并入。
+**2026-08-18 M1D 审查修复快照**：对 `14c00017c..bf2185fba` 做规格对照审查后，修复三条决定链路缺陷并补齐回归。① `decidePlanGdd` 的失败分支原来不 hydrate，命中后端任一 `PLAN_STALE_APPROVAL` 分支后卡片会停在已失效的 pending 身份上、`recoveryPending` 永不翻真导致「重试恢复」入口不渲染，现已按第 18.3 节在失败分支同样重灌（顺序钉死：`hydratePlanGddState` 入口会清空错误，必须先 hydrate 再写决定错误）。② responseId 复用键原为 `approvalRequestId:action`，不含 comment，违反第 13.2 节「改变 action/comment 必须换新 responseId」，现改为比对 `{action, comment}` 完整意图，判据方向为宁可多换不可少换。③ 第 18.2 节「`recoveryPending` 时不允许提交决定」原来只作用于三个触发按钮，已打开的评论弹层仍可提交，现已同门控并保留用户已输入内容。回归位于 `tests/appSurface/plan-gdd.suite.ts`，三条均经变异验证（逆转对应修复即变红）；`appSurface.test.ts` 381 passed，`agc:typecheck`、ESLint、编码检查通过。其中锁错误回传绝对路径与阶段进度轮次差一格两条已于同日补修（见 decision-log 同日「M1D 审查修复补充」条）；hydrate 身份校验与落盘投影修复的顺序、design 组展示名剩余两处字典两条单列后续，未并入。
 
 **2026-08-14 `M1B-1` 合入验收快照**：已合入实现集中在 `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_storage.rs`，并由 `runtime_protocol.rs` 注册。已具备 `plan-gdd.v1`、`plan-gdd-index.v1`、`plan-session.v1` 及 `plan.submit_gdd` input 的 strict serde 形状校验、文本/ID/时间/枚举边界、typed serde fingerprint、canonical JSON（重复键、BOM、尾空白、字段顺序）解析、GDD 连续版本链、session `revision + 1` / `previousFingerprint` 链、create-only durable writer、session 原子替换与受限 recovery，以及 `project-planning / agent-delegate / standard / project-supervisor` writer identity。通用 `file.write`、`file.patch`、`file.delete`、`project.patchset` 与 checkpoint restore 对 `.agent/planning/**` 和 `game/fast_gdd.md` 只挡写，planning 的 `file.read` / `file.list` 仍可读；M1B-1 合入时没有注册或执行 `plan.submit_gdd`，也没有实现 approval pending、receipt、UI 或构建准入。