fix(merge-pipeline): transcript の読み取り順を timestamp ソートで決定論化する (nightly-todo 順位 239) - #391
Conversation
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthrough
ChangesTranscript の処理順序
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)該当なし (レビュー指摘 0 件) Applicable Findings (Medium 以下)該当なし (レビュー指摘 0 件) Filtered (not applicable)該当なし 次のアクション
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/cli-merge-pipeline/src/feedback/transcript.rs`:
- Around line 67-71: Update the jsonl_paths sorting in the transcript filtering
flow to use a deterministic secondary key, such as PathBuf, after the
modified-time key so equal mtimes and metadata failures are consistently
ordered. Extend filter_transcripts_orders_by_mtime_not_filename with two files
sharing the same mtime and assert their stable secondary-key order while
preserving mtime as the primary ordering.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 5f27b4bd-b8d4-4e81-9583-86349c6f52b9
📒 Files selected for processing (1)
src/cli-merge-pipeline/src/feedback/transcript.rs
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)
Applicable Findings (Medium 以下)該当なし Filtered (not applicable)該当なし 次のアクション
|
…る (CodeRabbit PR #391)
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)該当なし (唯一の Major 指摘は commit Applicable Findings (Medium 以下)該当なし Filtered (not applicable)該当なし 次のアクション
|
夜間 todo ループの PR 2 本について、マージ後の台帳後始末が滞留していた。実体を検証 したところ完了状況が分かれた。 ## 順位 239 (#391) — 完了を確認して削除 transcript.rs に sort_by_key が存在することを確認し、台帳・todo-summary2.md・ todo13.md の 3 箇所を削除して根拠を § 棚卸し履歴 に記帳。 ## 順位 216 (#394) — 未完了だったので完成させてから削除 #394 は fixture 2 ファイルだけを追加して CI green でマージされており、rule 定義・ rule test・E2E case・dogfood がいずれも入っていなかった。 原因は既存 3 検査 (rule_test_coverage_check / incident_fixture_coverage_check / cases_cover_every_incident_rule) がすべて rule を起点に回る一方向の設計で、rule を 伴わない孤児 fixture を素通りしていたこと。逆向きの orphan_fixture_check を追加し 「fixture があるなら必ず rule がある」を fail-closed で強制する (追加時点で孤児 2 件を 実際に検出することを確認済み。この検査があれば #394 は CI で止まっていた)。 そのうえで残り作業を実装した: - rule 定義 (pattern \bPR-[0-9]+\b、toml/yaml/yml/jsonc/json、warning) - rule test 5 件 (主要拡張子ごとの positive + PR #NNN 形式の negative) - incident_eval.rs の E2E case - dogfood: .claude/hooks-config.toml の workstream 連番 2 箇所を除去 rule 自身の説明文が自分の pattern に反応したため、rule⑥ が docs/todoN.md と書くのと 同じ placeholder 方式 (PR-N) で回避している。 完了基準を満たしたので台帳・todo-summary.md・todo18.md から削除し、 § 未完了のままマージされた順位 には事例と対処を残した (「マージ ≠ 完了」の失敗モードは 他タスククラスに残るため)。
* fix(post-tool-linter): 孤児 fixture を CI で検出し、順位 216/239 の後始末を完了する 夜間 todo ループの PR 2 本について、マージ後の台帳後始末が滞留していた。実体を検証 したところ完了状況が分かれた。 ## 順位 239 (#391) — 完了を確認して削除 transcript.rs に sort_by_key が存在することを確認し、台帳・todo-summary2.md・ todo13.md の 3 箇所を削除して根拠を § 棚卸し履歴 に記帳。 ## 順位 216 (#394) — 未完了だったので完成させてから削除 #394 は fixture 2 ファイルだけを追加して CI green でマージされており、rule 定義・ rule test・E2E case・dogfood がいずれも入っていなかった。 原因は既存 3 検査 (rule_test_coverage_check / incident_fixture_coverage_check / cases_cover_every_incident_rule) がすべて rule を起点に回る一方向の設計で、rule を 伴わない孤児 fixture を素通りしていたこと。逆向きの orphan_fixture_check を追加し 「fixture があるなら必ず rule がある」を fail-closed で強制する (追加時点で孤児 2 件を 実際に検出することを確認済み。この検査があれば #394 は CI で止まっていた)。 そのうえで残り作業を実装した: - rule 定義 (pattern \bPR-[0-9]+\b、toml/yaml/yml/jsonc/json、warning) - rule test 5 件 (主要拡張子ごとの positive + PR #NNN 形式の negative) - incident_eval.rs の E2E case - dogfood: .claude/hooks-config.toml の workstream 連番 2 箇所を除去 rule 自身の説明文が自分の pattern に反応したため、rule⑥ が docs/todoN.md と書くのと 同じ placeholder 方式 (PR-N) で回避している。 完了基準を満たしたので台帳・todo-summary.md・todo18.md から削除し、 § 未完了のままマージされた順位 には事例と対処を残した (「マージ ≠ 完了」の失敗モードは 他タスククラスに残るため)。 * fix(review): apply CodeRabbit fixes for #402 - orphan_fixture_check の宣言集合を bad/good で分離 (跨ぎ名で孤児を見逃す欠陥) + 回帰テスト - fixture 列挙の entry エラー / 非 UTF-8 名を panic に (false-green 防止、ADR-043) - rule の extensions から json を除去 (JSON は comment 構文を持たず、順位 216 の設計決定でも除外されていた)
台帳 (docs/claude-code-web-tasks.md) の無人可タスク 順位 239 を
夜間ループ (nightly-todo workflow) が無人で実装した PR です。
'filter_transcripts' の 'read_dir' 非決定順を timestamp ソートで決定論化 + 回帰テストcargo test --workspace+cargo clippy --workspace --all-targets -- -D warningsを回して green を確認済み(agent の自己申告ではなく workflow が回し直した結果)。これはコストフィルタで
品質の保証ではありません — 単一 OS で
--ignoredも hooks smoke も含みませんcli-autonomy-gate --operation autonomous-pr(kill-switch + 背圧) を通過マージ判断は人間が行います (ADR-052 の commitment 点)。CI が緑で内容が台帳の
意図に沿っていればマージしてください。ずれている場合はクローズを —
採用率は WP-18 の受け入れ基準の測定対象です。
run: https://github.com/aloekun/claude-code-hook-test/actions/runs/31522018858
Summary by CodeRabbit
バグ修正
テスト