From 44d64086cd2b3226d33898ac69016b4732306182 Mon Sep 17 00:00:00 2001 From: aloekun Date: Wed, 19 Aug 2026 20:31:29 +0900 Subject: [PATCH] =?UTF-8?q?docs(todo):=20#417-#424=20=E3=81=AE=20feedback?= =?UTF-8?q?=20=E6=8E=A1=E7=94=A8=E5=88=86=E3=82=92=205=20=E3=82=BF?= =?UTF-8?q?=E3=82=B9=E3=82=AF=E3=81=A8=E3=81=97=E3=81=A6=E8=B5=B7=E7=A5=A8?= =?UTF-8?q?=E3=81=99=E3=82=8B?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 不具合修正バックログ消化計画の PR A〜D (7 PR) の post-merge feedback を まとめて採否判定した。全 48 提案の内訳は採用候補 16 / 様子見 18 / 却下推奨 14。 採用候補を 7 系統に分類し、そのまま 1 PR になる粒度で 5 タスクへ統合して todo24.md へ起票した (順位 470-474)。様子見・却下推奨は個別登録しない。 - 470: 誤帰属と副作用フラグ欠如を決定論ルールで弾く (custom lint 2 件) - 471: cross-crate 定数 pin と reaper 回帰テストの残片 - 472: 語彙・テスト作法・判断規律の convention 明文化 (8 項目) - 473: テスト用 staging ロックの 2 crate 重複の再評価 - 474: 夜間 auto lane とユーザー割当 PR の同一ファイル競合検知 起票前の実コード確認で 1 件が脱落した — #417 の pin テスト提案は既に両 crate に 実装済みだった。同 PR の他 2 提案も大部分が実装済みで、残片だけを 471 に載せている。 あわせて計画書の保留事項を消化済みにした。cwd_to_project_id の case 不一致は 調査の結果 PR #421 で既に解消済みと判明し (実 Linux でテスト pass を確認)、 ユーザー判断で閉じた。これで保留事項は空になり退役条件 4 を充足する。 --- docs/bugfix-batch-plan.md | 32 ++++--- docs/todo-summary2.md | 6 ++ docs/todo24.md | 196 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 221 insertions(+), 13 deletions(-) diff --git a/docs/bugfix-batch-plan.md b/docs/bugfix-batch-plan.md index e03cf456..a3c230eb 100644 --- a/docs/bugfix-batch-plan.md +++ b/docs/bugfix-batch-plan.md @@ -355,25 +355,31 @@ --- -## 保留事項 (PR D 完了時に扱う) +## 保留事項 (PR D 完了時に扱う) — すべて消化済み -ユーザー判断で PR D まで先送りしたもの。**本計画の外に記録が無いため、ここが唯一の記録である。** +ユーザー判断で PR D まで先送りしたもの。**先送りした時点では本計画の外に記録が無く、ここが唯一の記録だった。** 各項の消化にあたって記録先を本計画書の外へ移したため (下記)、現時点で本節の削除により失われる記録は無い — これが退役条件 4 の求める状態である。 -### フィードバック採否 (5 PR 分が滞留) - -[PR #417](https://github.com/aloekun/claude-code-hook-test/pull/417) / [#418](https://github.com/aloekun/claude-code-hook-test/pull/418) / [#419](https://github.com/aloekun/claude-code-hook-test/pull/419) / [#420](https://github.com/aloekun/claude-code-hook-test/pull/420) / [#421](https://github.com/aloekun/claude-code-hook-test/pull/421) の post-merge-feedback で挙がった採用候補を**未処理で溜めている** (2026-08-18 ユーザー判断: 「PR D まで完了したタイミングで実施」)。レポートは `.claude/feedback-reports/.md` にある (gitignore 対象なのでローカルのみ)。 +> **`cwd_to_project_id` の Linux case 不一致は調査のうえ閉じた (2026-08-19、ユーザー判断)。** +> +> **課題としては残さない** — 記述されていた欠陥は [PR #421](https://github.com/aloekun/claude-code-hook-test/pull/421) で既に解消済みだった。`resolve_project_dir` が `read_dir` + 両側 lowercase 比較で解決し、`resolve_project_dir_matches_case_insensitively` ほか 2 本のテストで seal されている。**実 Linux (WSL Ubuntu-24.04 / ext4、case-sensitive であることを probe で確認) で 2 本とも pass** し、`cwd_to_project_id` の呼び出し元も `resolve_project_dir` のみと確認した。実障害の観測は無し。 +> +> **解決の記録は本計画書の外にある** (だから本節の削除で記録は失われない) — 機構と理由は `resolve_project_dir` の doc コメントにあり、Linux で成立し続けることは [ADR-065](adr/adr-065-ci-matrix-cross-os-regression.md) の ubuntu leg が毎 PR 実行して担保する。**一度きりの観測ではなく機械化された保証**である点が、退役条件 4 が守ろうとしている「本ファイルが唯一の記録である項目」との違い。 +> +> **残る既知の穴 (実測済み・対応保留)**: case-sensitive filesystem では `Foo` と `foo` を同じ `projects_root` に置ける。両方が lowercase 比較に一致すると `resolve_project_dir` の `.find(...)` は **1 件だけ返し、もう一方を無言で除外する**。WSL Ubuntu-24.04 / ext4 で 5 回試行し、毎回 1 件のみ返ることを確認した (どちらが返るかは `read_dir` の順序依存で、契約上は未規定)。**対応を保留する根拠**は「今のところ発現経路を確認できていない」ことのみ — case-sensitive FS では同一ディレクトリの綴りが一意なので、同じ workspace root から 2 通りの綴りは通常生まれない。**ただしこれは実測ではなく推論であり、`~/.claude/projects` を OS 間で持ち込む等の経路は排除できていない。** 発現したら「複数一致は黙って選ばず loud にする」で塞ぐ ([ADR-043](adr/adr-043-security-gates-fail-closed.md))。**この穴自体の記録は本計画書の外に無かったため、[todo24.md](todo24.md) 順位 475 として起票し、本節の削除後も記録が残るようにした。** -PR D 完了時に 5 件分をまとめて採否判定する。件数が多いので、系統ごとに統合してから台帳へ登録する運用が要る (先例: `docs/todo24.md` の「#409-#414 の 5 PR 分」を 3 タスクへ統合した節)。 +### フィードバック採否 — 消化済み (2026-08-19) -### `cwd_to_project_id` の Linux での case 不一致 +7 PR 分 ([#417](https://github.com/aloekun/claude-code-hook-test/pull/417) / [#418](https://github.com/aloekun/claude-code-hook-test/pull/418) / [#419](https://github.com/aloekun/claude-code-hook-test/pull/419) / [#420](https://github.com/aloekun/claude-code-hook-test/pull/420) / [#421](https://github.com/aloekun/claude-code-hook-test/pull/421) / [#423](https://github.com/aloekun/claude-code-hook-test/pull/423) / [#424](https://github.com/aloekun/claude-code-hook-test/pull/424)) の +post-merge feedback **全 48 提案**を採否判定した。内訳は **採用候補 16 / 様子見 18 / 却下推奨 14**。 -**順位 469 のエントリを削除した際にこの記録も消えたため、ここに移設する** (2026-08-18 ユーザー判断: 「case 問題は D の作業完了後に対応を検討」)。 +採用分を 7 系統に分類し、**[todo24.md](todo24.md) へ 5 タスク (順位 470-474) として起票した** (ユーザー判断: 全 7 系統を採用)。 +統合の単位は「そのまま 1 PR になる粒度」。様子見・却下推奨は個別登録しない。 -`src/cli-merge-pipeline/src/feedback/transcript.rs` の `cwd_to_project_id` は path を `to_lowercase()` するが、`~/.claude/projects/` の実フォルダ名は**大文字小文字が保存されている** (`c--Users-owner-...` と `C--Users-owner-...-improve` が併存)。Windows は case-insensitive なので現状は偶然動いているだけで、**case-sensitive filesystem では一致しない**。 +**起票前の実コード確認で 1 件が脱落した** — #417 の「`REPORT_FILE_NAME` / `RUN_REPORT_FILE_NAME` の pin テスト」は +既に両 crate に実装済みだった。同 PR の他 2 提案も大部分が実装済みで、残片だけを順位 471 に載せている。 +**feedback レポートも台帳と同じく実装が動くほどずれる** — 本計画の「着手前に必ずやること」がそのまま当てはまる。 -- **未検証**: Linux の典型的なパスは全小文字なので `to_lowercase()` が実質 no-op になり、発現しない可能性が高い。WSL Ubuntu で確認できる (→ memory `wsl-linux-verification-setup`) -- **影響範囲**: [ADR-063](adr/adr-063-linux-portability-release-binaries.md) のクラウドセッションと [ADR-065](adr/adr-065-ci-matrix-cross-os-regression.md) の Linux CI matrix -- **B-3 の範囲外とした理由**: 発現条件が限定的で、workspace 横断の本体とは独立に直せるため +**これで § 保留事項は空になった** (退役条件 4 を充足)。 ## 残観測トラッキング @@ -391,7 +397,7 @@ PR D 完了時に 5 件分をまとめて採否判定する。件数が多いの 1. 進行表の 12 PR がすべてマージ済みであること 2. [§ 残観測トラッキング](#残観測トラッキング) の 4 項目がすべて消化され、対応するエントリ後始末が完了していること 3. 順位 288 のエントリ (todo15.md) が PR I 完了時に削除されていること -4. **[§ 保留事項](#保留事項-pr-d-完了時に扱う) が空であること** — 未処理のまま残っていれば、行き先を作ってから削除する (フィードバック採否は消化、`cwd_to_project_id` の case 問題は台帳エントリへ起票)。**本ファイルが唯一の記録である項目を、本ファイルの削除と一緒に消してはならない。** 順位 469 のエントリ削除で実際にこれをやり、記録を一度失った +4. **[§ 保留事項](#保留事項-pr-d-完了時に扱う--すべて消化済み) が空であること** (2026-08-19 に充足) — 未処理のまま残っていれば、行き先を作ってから削除する (フィードバック採否は消化、`cwd_to_project_id` の case 問題は台帳エントリへ起票)。**本ファイルが唯一の記録である項目を、本ファイルの削除と一緒に消してはならない。** 順位 469 のエントリ削除で実際にこれをやり、記録を一度失った 5. **[§ 着手前に必ずやること](#着手前に必ずやること) の各項が、本ファイル外へ移送済みであること** — 台帳前提の実測・シグネチャ変更時の下流追跡・照合キーの一意性確認・doc 記述の実在確認はいずれも本計画に固有でない再発防止知見なので、[dev-conventions.md](dev-conventions.md) へ移す 6. `grep -rn "bugfix-batch-plan" .` で本ファイルへの参照が残っていないことを確認する (検索対象パス `.` を省くと標準入力待ちになるため必ず付ける) 7. 本ファイルを物理削除する (削除自体は残観測の最後のエントリ後始末と同じ docs バッチ PR に同乗してよい) diff --git a/docs/todo-summary2.md b/docs/todo-summary2.md index cd47e27e..f1b874e3 100644 --- a/docs/todo-summary2.md +++ b/docs/todo-summary2.md @@ -193,6 +193,12 @@ | 466 | 💎 Tier 3 | **出力先と検証設計の convention を明文化する (#409-#414 feedback 系統 C+E を統合)** | todo24.md | S | なし (2026-08-17 採用。docs のみ。出力の visible paths / fixture と実データの対 / step outcome の組み合わせ の 3 点) | | 467 | 🔧 Tier 2 | **夜間ループとレポート出力の小さな穴を塞ぐ (#409-#414 feedback 系統 D + dispatch 実走 F-2)** | todo24.md | S | なし (2026-08-17 採用。ブランチ削除の事前存在確認 / parse エラー診断強化 / GIT_DIR 警告抑止。D-1 の効果確認は実走が要る) | | 468 | 🔧 Tier 2 | **post-merge-feedback の takt run が起動直後に死ぬ経路 — 終了理由が記録されない** | todo24.md | S | なし (2026-08-18 起票。PR #417 の調査で判明。142 run 中 2 件が analyze 起動 34 秒以内に成果物ゼロで死亡。順位 444 は回復層の修正で死因には触れていない。まず終了コード / シグナルの観測を足す) | +| 470 | 🚀 Tier 1 | **誤帰属と副作用フラグ欠如を決定論ルールで弾く (`..` 混入検出 / `jj workspace list` の `--ignore-working-copy` 欠如検出、#417+#421 feedback 採用、系統 A)** | todo24.md | S | なし (両者とも実 incident 実績あり。`.claude/custom-lint-rules.toml` の正規表現層で完結) | +| 471 | 🔧 Tier 2 | **cross-crate 定数 pin と reaper 回帰テストの残片を埋める (#417+#420 feedback 採用、系統 B 実装 + C)** | todo24.md | XS-S | なし (元 3 提案のうち 1 件は起票時点で実装済みと判明。着手時に再確認する) | +| 472 | 🔧 Tier 2 | **語彙・テスト作法・判断規律の convention を dev-conventions.md に明文化 (8 項目、#418 / #419 / #420 / #421 / #423 feedback 採用、系統 B 規約 + D + E + F 規約)** | todo24.md | S-M | なし (docs のみ。分量次第で 3 セクションに PR 分割可) | +| 473 | 💎 Tier 3 | **テスト用 staging ロックの 2 crate 重複を共有化するか再評価する (#423 feedback 採用、系統 F 実装)** | todo24.md | S | なし (ADR-044 層 1 の再評価。#423 の「3 つ目が出たら」判断の見直し) | +| 474 | 🔧 Tier 2 | **夜間 auto lane とユーザー割当 PR の同一ファイル競合を自動検知する (#424 feedback 採用、系統 G)** | todo24.md | S | なし (ADR-074 は lane 割当基準のみで並行競合検知は範囲外) | +| 475 | 💎 Tier 3 | **`resolve_project_dir` の case-sensitive FS 複数一致が無言で 1 件に縮退する (bugfix-batch-plan.md 退役準備中に発見、2026-08-19)** | todo24.md | S | なし (WSL Ubuntu-24.04 / ext4 で 5 回試行し毎回 1 件のみ返ることを確認。発現経路は未確認だが bugfix-batch-plan.md 削除後も記録を残すため起票) | **戦略**: Tier 1 を 2〜3 セッションで片付け → Tier 2 で計測基盤 (gate telemetry / weekly-review 保存) + rate-limit + convergence cost 削減を進める → Tier 3 でドキュメント整備。Tier 4-5 は cleanup / 外部展開で daily efficiency への直接効果は小さい。(2026-08-12 更新: 旧記述の ADR-032 は ADR-057 置換で欠番) diff --git a/docs/todo24.md b/docs/todo24.md index c18f91bd..9a9c88be 100644 --- a/docs/todo24.md +++ b/docs/todo24.md @@ -224,3 +224,199 @@ lane モデルへの移行 ([ADR-072](adr/adr-072-nightly-todo-loop.md) 決定 1 - 分類の結果として対処が不要と判断した場合は、その根拠を negative result として永続化して閉じること ([dev-conventions.md](dev-conventions.md) § spike / 実験タスクの見送り (negative result) 永続化 convention)。 --- + +## post-merge feedback 採用分 (#417 / #418 / #419 / #420 / #421 / #423 / #424 の 7 PR 分、2026-08-19 採否確定) + +> **由来**: 不具合修正バックログ消化計画 (PR A〜D) の 7 PR の post-merge feedback。全 48 提案のうち +> **採用候補 16 / 様子見 18 / 却下推奨 14**。採用候補を 7 系統に分類し、**5 タスクへ統合**した +> (様子見・却下推奨はそのまま、個別登録しない)。統合の単位は「そのまま 1 PR になる粒度」。 +> +> **起票前の実コード確認で 1 件が脱落した** — #417 の「`REPORT_FILE_NAME` / `RUN_REPORT_FILE_NAME` の +> pin テストを両 crate に追加」は既に両側に実装済みだった (`run_registry.rs` / `reaper/mod.rs` の +> tests、PR #418 で追加)。同 PR の他 2 提案も大部分が実装済みで、残片のみを順位 471 に載せている。 +> **feedback レポートも台帳と同じく実装が動くほどずれる。** + +### 誤帰属と副作用フラグ欠如を決定論ルールで弾く (系統 A) + +> **動機**: 2 件とも**過去に実 incident を生んだパターン**の機械検出で、実装先も手法も同じ。 +> +> - **設定文字列のパス相当フィールドへの `..` 混入**: `reportDirectory` の `..` で別 run の成果物を +> 成功証拠に誤用した (PR [#417](https://github.com/aloekun/claude-code-hook-test/pull/417) で修正)。 +> 同型の誤帰属は 2026-08-09 #374 / 2026-07-16 #281 でも観測されている +> - **`jj workspace list` の `--ignore-working-copy` 欠如**: `list_workspace_roots` が `discover.rs` と +> 違ってフラグを欠いていた (PR [#421](https://github.com/aloekun/claude-code-hook-test/pull/421) で修正)。 +> 並行 jj セッションの op-log divergence による commit 済み作業の silent revert に直結しうる +> +> **なぜ 1 タスクか**: 実装先が同じ `.claude/custom-lint-rules.toml` の正規表現層 ([ADR-007](adr/adr-007-custom-linter-layer-boundary.md)) +> で、既存 13 ルールと同水準の単純パターン。fixture も同じ `tests/fixtures/incidents/{bad,good}/` ([ADR-049](adr/adr-049-incident-eval-regression-suite.md))。 +> +> **将来の false positive に注意**: `--ignore-working-copy` は `update-stale` 等の意図的例外が増えると +> 誤検出しうる (現時点の例外呼び出しは 0 件)。逃がし方を決めてから有効化する。 +> +> **参照**: `.claude/feedback-reports/417.md` Tier1 #2、`421.md` Tier1 #1、[ADR-054](adr/adr-054-prompt-injection-trust-boundary-defense.md) (同型の trust boundary 検出ルール) +> +> **実行優先度**: 🚀 **Tier 1** — Severity High (両者とも実 incident 実績) / Frequency Medium / Effort S / Adoption Risk None。 + +#### 作業計画 + +- [ ] `..` 混入検出ルールを正規表現層に追加 + bad/good fixture +- [ ] `jj workspace list` の `--ignore-working-copy` 欠如検出ルールを追加 + bad/good fixture +- [ ] **修正前に bad fixture が実際に落ちることを確認する** ([ADR-049](adr/adr-049-incident-eval-regression-suite.md)) +- [ ] 既存コードで違反 0 を確認してから有効化する +- [ ] 意図的例外が出た場合の逃がし方を決めて doc に書く + +#### 完了基準 + +- 両ルールが bad fixture で発火し、good fixture では発火しないこと +- 既存コードに違反が無いこと (有効化時点で赤にならない) + +### cross-crate 定数 pin と reaper 回帰テストの残片を埋める (系統 B 実装 + C) + +> **動機**: 起票前の実コード確認で**大部分が実装済み**と判明したため、**残っているのは次の 3 つだけ**。 +> +> - `TASK_BOOKMARK_SEPARATOR` の直接 assert が `cli-merge-pipeline` 側に無い。定数は `context.rs` に +> あるが assert が無く、`cli-push-runner` 側だけが pin している。**doc コメントの「両 crate の +> unit test が pin する」という主張と実装が食い違っている** (doc の嘘) +> - reaper の「**同一 run の `reportDirectory` は受理される**」の明示 assert (拒否側は実装済み) +> - `settle_meta_status` の **I/O 失敗**ケース (JSON malformed と「失敗を成功と報告しない」は実装済み) +> +> **なぜ 1 タスクか**: いずれも既存テストファイルへの小片追加で、production コードの変更を伴わない。 +> +> **参照**: `.claude/feedback-reports/417.md` Tier2 #2/#3、`420.md` Tier2 #1 +> +> **実行優先度**: 🔧 **Tier 2** — Severity Medium / Frequency Low / Effort XS-S / Adoption Risk None。 + +#### 作業計画 + +- [ ] **着手時に再度実コードを確認する** — 本エントリの元になった 3 提案のうち 1 件は起票時点で既に実装済みだった +- [ ] `context.rs` の tests に `TASK_BOOKMARK_SEPARATOR` の literal pin assert を追加し、doc コメントの主張と一致させる +- [ ] `reaper/tests.rs` に「同一 run の `reportDirectory` は受理される」assert を追加 +- [ ] `settle_meta_status` の I/O 失敗 (読み取り不能 / 書き込み不能) ケースを追加 + +#### 完了基準 + +- 共有定数が片側だけ変わったとき、両 crate のテストが落ちること +- reaper の受理/拒否が両方向 assert されていること +- `settle_meta_status` の I/O 失敗 (読み取り不能 / 書き込み不能) が `Err` として扱われ、**成功と報告されない**ことがテストで固定されていること + +### 語彙・テスト作法・判断規律の convention を明文化する (系統 B 規約 + D + E + F 規約) + +> **動機**: 8 項目、すべて行き先が [dev-conventions.md](dev-conventions.md) で実装を伴わない。 +> +> **語義の分離** (同じに見える別物を区別する): +> +> - 「コメント投稿の有無 (presence)」と「actionable findings の有無」を混同しない (#418 の根本原因) +> - ソートキーが「決定論的」なのか「時系列」なのかを doc comment で明示する (#419 の真因。 +> 決定論的ではあるが時系列でない順序が `session_data_unavailable` の誤報を生んだ) +> +> **テスト作法**: +> +> - cross-crate で共有する canonical constant は producer/consumer 双方で literal pin test を書く (#418) +> - filesystem の mtime 分解能に依存しないテスト (`filetime::set_file_mtime`) を既定パターンにする (#419) +> +> **判断の規律**: +> +> - 再利用されるキーを一意識別子として使わない / evidence の scope を実際より狭く見積もらない (#420) +> - 「将来リスク」分類は着手前の実測で裏付けてから PR 分割・優先順位を決める (#421) +> - fail-open でも黙って飛ばさない + todo 削除前に完了基準の全項目が実コードに現れているか確認する (#421) +> - 効きが確認できない修正を入れない / 計画案を実測で棄却し観測ベースで解を選ぶ (#423) +> +> **なぜ 1 タスクか**: 行き先が 1 ファイルに閉じ、実装を伴わない。docs 変更はマイルストーンでまとめる運用。 +> 分量が大きくなるなら語義 / テスト作法 / 判断規律の 3 セクションで PR を分けてよい。 +> +> **様子見だった #424 の「意味的に異なる状態が同じ見え方になるバグクラス」も語義セクションに畳める。** +> 着手時に採否を判断する。 +> +> **参照**: `.claude/feedback-reports/418.md` Tier3 #1/#2、`419.md` Tier2 #3・Tier3 #1、`420.md` Tier3 #2、`421.md` Tier3 #1/#2、`423.md` Tier3 #1 +> +> **実行優先度**: 🔧 **Tier 2** — Severity Medium / Frequency Medium / Effort S-M / Adoption Risk None。 + +#### 作業計画 + +- [ ] 語義セクション (2 項目) を追記 +- [ ] テスト作法セクション (2 項目) を追記 +- [ ] 判断規律セクション (4 項目) を追記 +- [ ] **各項に実例 (PR 番号と何が起きたか) を必ず添える** — 一般論だけの規約は守られない +- [ ] #424 の様子見項目を畳むか判断する + +#### 完了基準 + +- 8 項目が [dev-conventions.md](dev-conventions.md) に順位付きセクションとして載っていること +- 各項が「なぜ」と実例を持つこと +- #424 の様子見項目 (「意味的に異なる状態が同じ見え方になるバグクラス」) を**採用 / 保留 / 却下のいずれかに決定し、理由を記録**していること + +### テスト用 staging ロックの 2 crate 重複を共有化するか再評価する (系統 F 実装) + +> **動機**: PR [#423](https://github.com/aloekun/claude-code-hook-test/pull/423) で `EXEC_STAGING_LOCK` / +> `exec_staging_guard()` を `smoke.rs` と `t7_cwd_independence.rs` に**意図的に複製した** +> ([ADR-044](adr/adr-044-subprocess-utility-extraction-boundary.md) 層 1「2 crate 重複は extract 必須ではなく要 dogfood」)。 +> pre-push レビューと post-merge feedback の双方が DRY 違反として指摘しており、**判断の是非を一度見直す**。 +> +> **判断が要る点**: 共有化すると **test 専用の同期プリミティブを `lib-subprocess` の production surface に載せる** +> ことになる。ロックはプロセス内でしか意味を持たず、テストバイナリは別プロセスなので共有しても保証は増えない。 +> #423 時点の決定は「3 つ目の copy→spawn テストが現れた時点で extract を再評価する」。 +> +> **なぜ独立タスクか**: 前回判断の巻き戻しを含むため、切り戻し単位を分ける。 +> +> **参照**: `.claude/feedback-reports/423.md` Tier2 #1、`t7_cwd_independence.rs` の `EXEC_STAGING_LOCK` doc +> +> **実行優先度**: 💎 **Tier 3** — Severity Low / Frequency Low / Effort S / Adoption Risk Low。 + +#### 作業計画 + +- [ ] 3 つ目の copy→spawn テストが出現したかを確認する (#423 の再評価トリガ) +- [ ] 出ていなければ現状維持と結論し、本エントリを閉じる (negative result の残し方を判断する) +- [ ] 共有するなら置き場 (`lib-subprocess` の test-support か、新規 dev-dependency crate か) を決める + +#### 完了基準 + +- 複製を残すか共有するかが根拠付きで決まり、コード doc に反映されていること + +### 夜間 auto lane とユーザー割当 PR の同一ファイル競合を自動検知する (系統 G) + +> **動機**: PR D の着手前に、台帳・作業計画書・実装の 3 箇所を人手で横断確認する必要が生じた +> (2026-08-19)。台帳の順位 176 (auto lane) が PR D と同じ `src/check-ci-coderabbit/src/rate_limit.rs` を +> 触る想定だったため。結果的に PR D はそのファイルを触らず競合しなかったが、**それを判定するのに +> 手作業の横断確認が要った**。 +> +> [ADR-074](adr/adr-074-auto-lane-screening-criteria.md) は lane 割当の判断基準を定めるが、 +> **同一ファイルの並行競合検知は範囲外**で重複しない。 +> +> **参照**: `.claude/feedback-reports/424.md` Tier2 #1、`lib_ledger::select` (文書順で 1 件選択) +> +> **実行優先度**: 🔧 **Tier 2** — Severity Medium (手戻りリスク) / Frequency Low / Effort S / Adoption Risk None。 + +#### 作業計画 + +- [ ] 検知の入力を決める (台帳の対象ファイル欄 × open PR の changed files) +- [ ] 実装先を決める (`nightly-todo.yml` の step か `cli-nightly-task-select` の拡張か) +- [ ] 競合時の挙動を決める (選定から除外するか、warning に留めるか) + +#### 完了基準 + +- auto lane の選定が、ユーザー割当 PR と同一ファイルを触る順位を**機械的に検知し、選定から除外するか警告として報告する**こと (どちらを採るかは作業計画で決める。warning に留める場合も、検知結果が run log から読めること) + +--- + +## pre-push review 由来 (2026-08-19、bugfix-batch-plan.md 退役準備中に発見) + +### `resolve_project_dir` の case-sensitive FS 複数一致が無言で 1 件に縮退する + +> **動機**: [bugfix-batch-plan.md](bugfix-batch-plan.md) の `cwd_to_project_id` Linux case 不一致調査 (順位 469 の完了確認) で、**別の未対応の穴**が実測で見つかった。case-sensitive filesystem (WSL Ubuntu-24.04 / ext4 で確認) では `Foo` と `foo` を同じ `projects_root` に置ける。両方が `cwd_to_project_id` の lowercase 比較に一致すると、`resolve_project_dir` (`src/cli-merge-pipeline/src/feedback/transcript.rs:37`) の `.find(...)` は **1 件だけ返し、もう一方を無言で除外する** (どちらが返るかは `read_dir` の順序依存で契約上未規定)。5 回試行して毎回 1 件のみ返ることを確認済み。 +> +> **発見時点で発現経路は未確認** — case-sensitive FS では同一ディレクトリの綴りが通常一意なため、同じ workspace root から 2 通りの綴りは生まれにくい。ただしこれは推論であり、`~/.claude/projects` を OS 間で持ち込む等の経路は排除できていない。**bugfix-batch-plan.md は退役予定で削除されるため、この観測の記録先を本エントリに移した。** +> +> **参照**: [bugfix-batch-plan.md](bugfix-batch-plan.md) § 保留事項、`resolve_project_dir` の doc コメント (`transcript.rs:28-36`)、[ADR-043](adr/adr-043-security-gates-fail-closed.md) (fail-closed 原則) +> +> **実行優先度**: 💎 **Tier 3** — Severity Low (発現経路未確認) / Frequency Low / Effort S / Adoption Risk None。 + +#### 作業計画 + +- [ ] `resolve_project_dir` の doc コメントに、複数一致時は 1 件のみ返し他方を無言で除外すること (順序は `read_dir` 依存で未規定) を明記する +- [ ] `~/.claude/projects` を OS 間で持ち込む等、発現経路が実在するかを再評価する +- [ ] 発現しうると判断したら、ADR-043 に従い複数一致を loud に検出する実装を追加する。発現しないと判断したら、その根拠を negative result として本エントリに記録して閉じる ([dev-conventions.md](dev-conventions.md) § spike / 実験タスクの見送り (negative result) 永続化 convention) + +#### 完了基準 + +- `resolve_project_dir` の doc コメントが複数一致時の挙動を明記していること +- 発現経路の評価結果 (対応要否とその根拠) が記録されていること