feat(hooks-stop-feedback-dispatch): Stop 時 skill 自動起動 (task 1-C)#71
Merged
feat(hooks-stop-feedback-dispatch): Stop 時 skill 自動起動 (task 1-C)#71
Conversation
… 起動指示 (task 1-C) ADR-029 で規定した新規 Stop hook を追加。cli-merge-pipeline (task 1-B) が書く `.claude/post-merge-feedback-pending.json` を検出し、status=pending なら additionalContext で /post-merge-feedback skill の起動を Claude に指示、 status を dispatched に atomic 更新する。 責務分離 (ADR-022): hooks-stop-quality と並列の Stop hook として登録し、 実行順序 1 (品質ゲート) → 2 (dispatch) を settings template の array order で保証。 主な実装: - src/hooks-stop-feedback-dispatch/ 新規 crate (workspace member に登録) - pending_file.rs は cli-merge-pipeline 側から duplicate (3 callers 目での lib 切出しは 別 PR、本 PR スコープは新規 exe + 配布統合) - ExistingPending を Pending / Dispatched variant で分離 (cli 側の Active(String) とは差分) - stale 判定 (24h TTL) は ISO 8601 UTC 'Z' の lex 比較性を活用 - fail-open: stdin/parse/write エラーは silent exit or stderr WARN 配布統合: - Cargo.toml workspace members に alphabetical 順で追加 - package.json の build:hooks-stop-feedback-dispatch + build:all チェーン - scripts/deploy-hooks.ts の EXE_FILES - .claude/settings.local.json.template の Stop hook 2 つ目のエントリ (timeout 10s) テスト: unit 23 件 + E2E smoke 7 経路 (absent/stop_hook_active/pending/dispatched/ consumed/corrupt/stale) 全て ADR-029 仕様通り。 付随変更 (task 1-C 完了に伴うクリーンアップ): - docs/todo.md: 完了済み 1-B セクションを削除 + 依存関係を更新 - src/cli-merge-pipeline/src/pending_file.rs: 1 箇所の doc コメント整合性修正 Note: todo.md に 'templates/settings.json にも反映' とあるが、実際の配布テンプレートは .claude/settings.local.json.template (deploy-hooks.ts が参照) のみで、templates/ 配下に settings ファイルは存在しない。正しいテンプレートに反映済。
📝 WalkthroughWalkthroughStop フェーズでペンディングファイルを読み取り・ロック・更新してフィードバック送信用 JSON を stdout に出力する新しい dispatcher 実装と共有ライブラリを追加し、ワークスペース設定・ビルド・デプロイ・既存モジュールの再エクスポートを更新しました。 Changes
Sequence Diagram(s)sequenceDiagram
participant StopPhase as Stop Phase
participant Dispatcher as hooks-stop-feedback-dispatch
participant FS as Filesystem
participant Lock as PendingLock
participant Stdout as Stdout
StopPhase->>Dispatcher: 起動 (stdin JSON)
Dispatcher->>Dispatcher: parse -> check stop_hook_active
alt stop_hook_active == true
Dispatcher-->>StopPhase: サイレント終了
else
Dispatcher->>FS: locate & read pending file
FS-->>Dispatcher: ExistingPending
alt Pending
Dispatcher->>Dispatcher: 24h staleness 判定
alt not stale
Dispatcher->>Lock: try_acquire (.lock create)
Lock-->>Dispatcher: acquired?
Dispatcher->>FS: re-read pending
Dispatcher->>Stdout: emit JSON {hookEventName:"Stop", additionalContext:"/post-merge-feedback <pr>"}
Dispatcher->>FS: write_overwrite(status="dispatched", dispatched_at=UTC)
Lock-->>Dispatcher: drop (remove .lock)
else stale
Dispatcher->>FS: delete stale pending (+.lock cleanup)
Dispatcher->>Dispatcher: stderr 警告 / 終了
end
else Dispatched/Consumed
Dispatcher-->>Dispatcher: サイレント終了
else Corrupt
Dispatcher->>FS: delete corrupt file
Dispatcher-->>Dispatcher: サイレント終了
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~65 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/hooks-stop-feedback-dispatch/src/pending_file.rs`:
- Around line 85-112: write_overwrite is not providing process-level atomicity
for the pending→dispatched transition, allowing multiple Stop hooks to dispatch
concurrently; fix by implementing a lock-file based claim similar to
lib-pending-file::write_new_exclusive: attempt to create a lock file named
"{file_name}.lock" with OpenOptions::create_new(true), on success re-read the
pending via read_existing, verify pending.status == "pending", then perform the
stdout dispatch and finally write the new status (use write_overwrite or its
logic) to mark "dispatched"; if the status is no longer pending or any step
fails, release/remove the lock and do nothing (no dispatch), and always ensure
the lock file is removed on exit/failure to avoid deadlock.
🪄 Autofix (Beta)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f4c82a41-502f-4939-9398-43a50cb4fb09
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (24)
.claude/settings.local.json.templateCargo.tomldocs/todo.mdpackage.jsonscripts/deploy-hooks.tssrc/check-ci-coderabbit/src/main.rssrc/cli-merge-pipeline/Cargo.tomlsrc/cli-merge-pipeline/src/pending_file.rssrc/cli-pr-monitor/Cargo.tomlsrc/cli-pr-monitor/src/config.rssrc/cli-pr-monitor/src/util.rssrc/cli-push-pipeline/src/main.rssrc/cli-push-runner/src/config.rssrc/cli-push-runner/src/stages/push_jj_bookmark.rssrc/hooks-pre-tool-validate/src/main.rssrc/hooks-session-start/src/main.rssrc/hooks-stop-feedback-dispatch/Cargo.tomlsrc/hooks-stop-feedback-dispatch/src/main.rssrc/hooks-stop-feedback-dispatch/src/pending_file.rssrc/hooks-stop-quality/src/main.rssrc/lib-jj-helpers/src/lib.rssrc/lib-pending-file/Cargo.tomlsrc/lib-pending-file/src/lib.rssrc/lib-report-formatter/src/lib.rs
… 排他化 (CodeRabbit PR #71) CodeRabbit Major 指摘 (src/hooks-stop-feedback-dispatch/src/pending_file.rs:112): pending→dispatched 遷移が atomic でなく複数の Stop hook が同時 dispatch 可能。 修正: `PendingLock` (RAII struct) を追加し、handle_pending で lock 取得 → 再読込 → status=pending 再検証 → emit → write dispatched の順で process-level 排他を担保。lib-pending-file::write_new_exclusive と 同じ `OpenOptions::create_new(true)` パターン。 - Lock path: `{pending}.lock` (path.with_extension("lock")) - Stale recovery: lock mtime > 60秒 なら crash 残骸扱いで gc + 1 回再取得 (kill -9 による permanent stuck の defense-in-depth) - Drop guard で panic / 早期 return でも RAII 解放 - stale (24h) 判定は lock 前に実行 (GC は lock 不要) ADR-029「ロックファイル不要」は pending file 自体の **新規作成 atomicity** (create_new) の記述であり、pending を **read して dispatched へ write** する 遷移の同期とは別軸の問題、という区別を doc コメントに明記。 テスト (5 件追加、合計 30 件 pass): - pending_lock_atomic_under_concurrent_acquirers: 8 スレッド → exactly 1 wins - pending_lock_recovers_from_stale_lock: File::set_modified で 120秒前 mtime 設定 → 回復確認 - pending_lock_acquires_and_releases_on_drop / _returns_none_when_already_held - pending_lock_is_stale_with_threshold_rejects_fresh_lock / _on_missing_file_returns_false E2E smoke: 正常 dispatch + lock cleanup、lock 競合時の silent skip + pending status 維持 を確認。
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/hooks-stop-feedback-dispatch/src/pending_file.rs`:
- Around line 502-551: The test pending_lock_atomic_under_concurrent_acquirers
is flaky because the winner only holds the lock for 50ms and thread start delays
can let a second thread win; fix it by introducing an Arc<std::sync::Barrier>
(e.g. barrier) shared with each spawned thread and have each thread wait on
barrier.wait() immediately before calling PendingLock::try_acquire(&p) so all
threads attempt acquisition simultaneously; keep the existing
success_count/none_count logic and the short sleep inside the winner branch to
ensure observation, then join threads and assert counts as before.
🪄 Autofix (Beta)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d190fe9f-f990-4f0c-8a4e-e19ac96d3390
📒 Files selected for processing (2)
src/hooks-stop-feedback-dispatch/src/main.rssrc/hooks-stop-feedback-dispatch/src/pending_file.rs
aloekun
added a commit
that referenced
this pull request
Apr 23, 2026
…abbit PR #71) CodeRabbit Minor 指摘: pending_lock_atomic_under_concurrent_acquirers が負荷の高い CI で flaky になりうる。winner が 50ms しか lock を保持しないため、スレッド起動遅延が 50ms を超える環境 (slow CI / Windows Defender 常駐スキャン下等) では winner drop 後に後発スレッドが再取得して success_count=2 になる可能性があった。 修正: std::sync::Barrier で THREAD_COUNT=8 の同期を追加。全スレッドが try_acquire 直前まで barrier.wait() で揃ってから一斉発火するため、起動遅延に依らず race が決定論化される。 - 50ms 保持は維持 (scheduling が極端に歪んでも後発が lock 存在を観測できる余裕) - 成功条件を THREAD_COUNT - 1 に一般化 (スレッド数を変えても追従) - ローカルで 30 回連続 run → 全 pass 確認
Owner
Author
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/hooks-stop-feedback-dispatch/src/pending_file.rs`:
- Around line 161-168: The stale-lock recovery currently unconditionally removes
and re-creates the lock (using Self::is_stale and Self::try_create), which can
race and delete another process's newly-created lock and cause duplicate
ownership and double dispatch; change the strategy to (1) serialize GC with a
separate GC-guard create_new (e.g., "{lock}.gc") so only one process performs
cleanup, (2) make lock creation write a unique owner token (UUID/PID+nonce) into
the lock file in try_create/create_new and return that token as part of the
guard, and (3) modify Drop to only remove the lock file if the on-disk token
matches the guard's token (so a process never removes a lock it doesn't own).
Update the codepaths that call Self::is_stale/Self::try_create (and the similar
block at the other spot) to use the GC-guard flow and token-aware create/remove
logic to eliminate the race.
🪄 Autofix (Beta)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f67f5c66-6d25-4a95-bf5d-2ca4ff488d1b
📒 Files selected for processing (2)
src/hooks-stop-feedback-dispatch/src/main.rssrc/hooks-stop-feedback-dispatch/src/pending_file.rs
✅ Files skipped from review due to trivial changes (1)
- src/hooks-stop-feedback-dispatch/src/main.rs
…abbit PR #71) CodeRabbit Minor 指摘: pending_lock_atomic_under_concurrent_acquirers が負荷の高い CI で flaky になりうる。winner が 50ms しか lock を保持しないため、スレッド起動遅延が 50ms を超える環境 (slow CI / Windows Defender 常駐スキャン下等) では winner drop 後に後発スレッドが再取得して success_count=2 になる可能性があった。 修正: std::sync::Barrier で THREAD_COUNT=8 の同期を追加。全スレッドが try_acquire 直前まで barrier.wait() で揃ってから一斉発火するため、起動遅延に依らず race が決定論化される。 - 50ms 保持は維持 (scheduling が極端に歪んでも後発が lock 存在を観測できる余裕) - 成功条件を THREAD_COUNT - 1 に一般化 (スレッド数を変えても追従) - ローカルで 30 回連続 run → 全 pass 確認
…L backstop (CodeRabbit PR #71 2 回目)
aloekun
force-pushed
the
feat-hooks-stop-feedback-dispatch-task-1c
branch
from
3e857a3 to
bfb7b57
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/hooks-stop-feedback-dispatch/src/main.rs`:
- Around line 127-135: The current stale-GC branch calls
is_stale(&pending.created_at, utc_now_epoch_secs()) before any lock check and
unconditionally removes path.with_extension("lock"), which can delete an active
lock held by another process; instead, acquire or inspect the lock atomically
before deleting: either perform the stale check while holding the pending-file
lock (use the same lock acquisition routine your codebase uses), or
read/validate the lock owner token/GC guard in the lock file and only remove the
.lock if the owner token indicates it is safe for this GC to reclaim it (i.e.,
we own it or it's explicitly expired); update the branch around is_stale /
std::fs::remove_file(path.with_extension("lock")) to enforce this
ownership/lock-held check before deleting the lock.
🪄 Autofix (Beta)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7bd5da7c-aaef-4bce-9696-a92ceb3bd7ee
📒 Files selected for processing (2)
src/hooks-stop-feedback-dispatch/src/main.rssrc/hooks-stop-feedback-dispatch/src/pending_file.rs
Comment on lines
+127
to
+135
| if is_stale(&pending.created_at, utc_now_epoch_secs()) { | ||
| eprintln!( | ||
| "[stop-feedback-dispatch] Warning: stale pending file removed (created_at={})", | ||
| pending.created_at | ||
| ); | ||
| let _ = std::fs::remove_file(path); | ||
| // leak した可能性がある lock file も backstop で削除 | ||
| let _ = std::fs::remove_file(path.with_extension("lock")); | ||
| return; |
There was a problem hiding this comment.
stale GC が稼働中の lock を削除し得ます。
Line 127 の stale 判定が lock 取得前に走り、Line 134 で {pending}.lock を無条件削除しています。24h 境界付近で別プロセスが既に lock を取得して dispatch 中だと、この branch がその active lock を消せるため、第三プロセスが再取得して二重 dispatch できます。
stale pending の削除も lock 保有下で行うか、leaked lock 回収が必要なら owner token / GC guard などで「自分が消してよい lock」だけを削除する形にしてください。Based on learnings, Auto-trigger Post-Merge Feedback using pending file and current session startup (ADR-029).
修正方向の例
fn handle_pending(path: &Path, pending: PendingFile) {
if is_stale(&pending.created_at, utc_now_epoch_secs()) {
- eprintln!(
- "[stop-feedback-dispatch] Warning: stale pending file removed (created_at={})",
- pending.created_at
- );
- let _ = std::fs::remove_file(path);
- // leak した可能性がある lock file も backstop で削除
- let _ = std::fs::remove_file(path.with_extension("lock"));
+ // Active lock を消さないため、stale cleanup も lock 取得後に行う。
+ // try_acquire が None の場合は別プロセスが処理中、または leaked lock の可能性があるため
+ // token-aware GC なしでは lock file を削除しない。
+ let _lock = match PendingLock::try_acquire(path) {
+ Ok(Some(lock)) => lock,
+ Ok(None) => return,
+ Err(e) => {
+ eprintln!(
+ "[stop-feedback-dispatch] Warning: lock acquisition failed during stale cleanup ({}); skip cleanup",
+ e
+ );
+ return;
+ }
+ };
+ if matches!(read_existing(path), ExistingPending::Pending(ref p) if is_stale(&p.created_at, utc_now_epoch_secs())) {
+ eprintln!(
+ "[stop-feedback-dispatch] Warning: stale pending file removed (created_at={})",
+ pending.created_at
+ );
+ let _ = std::fs::remove_file(path);
+ }
return;
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/hooks-stop-feedback-dispatch/src/main.rs` around lines 127 - 135, The
current stale-GC branch calls is_stale(&pending.created_at,
utc_now_epoch_secs()) before any lock check and unconditionally removes
path.with_extension("lock"), which can delete an active lock held by another
process; instead, acquire or inspect the lock atomically before deleting: either
perform the stale check while holding the pending-file lock (use the same lock
acquisition routine your codebase uses), or read/validate the lock owner
token/GC guard in the lock file and only remove the .lock if the owner token
indicates it is safe for this GC to reclaim it (i.e., we own it or it's
explicitly expired); update the branch around is_stale /
std::fs::remove_file(path.with_extension("lock")) to enforce this
ownership/lock-held check before deleting the lock.
Owner
Author
There was a problem hiding this comment.
resolved: 理論的には正しい指摘ですが、現時点では 既知の受容可能なトレードオフ として対応を見送ります。
race が成立する条件:
- pending の created_at が 24h 境界を越えた瞬間
- 別プロセスが同時に active に dispatch 中 (dispatch 処理は 10-100ms オーダー)
- 別の第三プロセスも同時に handle_pending の stale branch に到達
dispatch の処理時間と 24h 境界の重なりから、race window は実効的に 1 秒 / 86400 秒 ≈ 0.001% 未満です。さらに複数の Stop hook が同時発火する前提も加わります。
提案 fix のトレードオフ: 提案通り lock 明示削除を撤去すると、try_acquire が None を返した leaked lock (kill -9 等で Drop が走らなかった場合) を回収する手段がなくなり、permanent stuck 状態になります。これは前回の CodeRabbit Major 指摘 (stale-recovery の TOCTOU race) を簡潔版で解決した際にユーザーと合意した方向性 (撤去 + pending 24h TTL backstop) と衝突します。
本 PR のスタンス: シンプルな実装で運用を開始し、実運用で race が顕在化したら owner token + GC guard の堅牢版へ段階的に発展させる方針。現時点では実務的リスクが極めて低いため、複雑化を避けます。
もし将来この finding を再度提案する場合は、次の条件のいずれかが満たされた時点でお願いします:
- 実運用で double dispatch が観測された
- より短い stale TTL (例: 1h) を採用する必要が生じた
- 敵対的 process が前提の環境に移植する場合
それまでは本トレードオフで運用します。
There was a problem hiding this comment.
@aloekun、詳細なトレードオフ分析をありがとうございます。論点を整理します。
- race window の評価: 24h TTL × 10–100ms dispatch window ≈ 0.001% という算定は妥当です。さらに同一 session で複数の Stop hook が並行発火する前提が必要なため、実効確率はさらに低くなります。
- 提案 fix の副作用:
lockを stale cleanup から除外するとkill -9後の leaked lock を回収する手段が失われ、permanent stuck というより深刻な問題を生じさせます。これは前回の合意（撤去 + 24h TTL backstop）と整合しており、今回の設計判断は一貫しています。 - 再提案の条件: 指定いただいた 3 条件（実観測 / TTL 短縮 / 敵対的環境移植）を記憶します。
設計判断を承りました。今後のレビューでは上記条件に達するまでこの finding を再提起しません。
✏️ Learnings added
Learnt from: aloekun
Repo: aloekun/claude-code-hook-test PR: 71
File: src/hooks-stop-feedback-dispatch/src/main.rs:127-135
Timestamp: 2026-04-23T17:49:41.315Z
Learning: In `aloekun/claude-code-hook-test`, `src/hooks-stop-feedback-dispatch/src/main.rs`, the stale-GC branch in `handle_pending()` unconditionally deletes `{pending}.lock` before acquiring the lock. This is an accepted tradeoff: the race window is ~0.001% (24h TTL vs 10–100ms dispatch), and acquiring the lock before stale cleanup was rejected because it would eliminate the only recovery path for leaked locks (from kill -9 etc.), causing permanent stuck state. The design relies on the 24h TTL as a backstop for leaked locks. Re-raise this finding only if: (1) double dispatch is observed in production, (2) a shorter stale TTL (e.g., 1h) is needed, or (3) the code is ported to a hostile multi-process environment.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: CR
Repo: aloekun/claude-code-hook-test PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-23T03:47:18.222Z
Learning: Implement Stop hook quality gates (ADR-004)
Learnt from: CR
Repo: aloekun/claude-code-hook-test PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-23T03:47:18.222Z
Learning: Implement hooks in Rust (ADR-001)
Learnt from: aloekun
Repo: aloekun/claude-code-hook-test PR: 38
File: src/cli-pr-monitor/src/runner.rs:109-115
Timestamp: 2026-04-15T05:44:11.960Z
Learning: The `cli-pr-monitor` tool in `aloekun/claude-code-hook-test` is Windows-only. Hardcoded `.exe` suffixes (e.g., in `checker_exe_path()` in `src/cli-pr-monitor/src/runner.rs` and error messages in `src/cli-pr-monitor/src/stages/daemon.rs`) are intentional. Cross-platform support is not required.
4 tasks
aloekun
added a commit
that referenced
this pull request
Apr 24, 2026
…72) - .claude/hooks-config.toml: プレースホルダの post_merge_learnings スタブを外し、type="ai" / prompt="post-merge-feedback" の post_steps を有効化。本プロジェクトで dogfood 開始。 - templates/hooks-config-{typescript,python}.toml: 派生プロジェクト 向けに同ブロックをコメントアウト状態で追記。post-merge-feedback skill が deploy されるまで opt-in。 - docs/todo.md: 1-D 削除 + section ヘッダー / 前文を除去。 1-E (skill 側 Phase 0) と 1-F (ADR-014 本採用化) は ADR-029 参照付きの独立 section に昇格。 ADR-029 試験運用の有効化。config のみの変更で exe 再ビルド不要 (cli-merge-pipeline.exe / hooks-stop-feedback-dispatch.exe は PR #70 / #71 で deploy 済み)。実地検証は次の pnpm merge-pr で発火。 Refs: ADR-029
This was referenced Apr 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
hooks-stop-feedback-dispatchを追加 (ADR-029)。.claude/post-merge-feedback-pending.jsonを検出して status=pending なら Claude に/post-merge-feedbackskill 起動を指示、status=dispatched に atomic 更新lib-pending-filecrate を新設し、cli-merge-pipeline / hooks-stop-feedback-dispatch のPendingFilestruct +epoch_secs_to_iso8601+ カレンダー定数 10 個 +is_valid_owner_repoを共通化 (3 callers 目の DRY 解消).claude/settings.local.json.templateの Stop hook に 2 つ目エントリを追加 (実行順序: hooks-stop-quality → hooks-stop-feedback-dispatch)package.jsonbuild scripts +scripts/deploy-hooks.tsの EXE_FILES に新規 exe を統合docs/todo.mdから削除 + cli-merge-pipeline の doc コメント微修正Context
Why: ADR-029 で規定した 3 コンポーネント連携の Stop hook 側を実装する。
pnpm merge-pr後に skill 呼び忘れでフィードバックループが失われていた課題を、pending file + 現セッション起動で解決する (新規 session spawn を避けセッション知見を維持)。Trigger: docs/todo.md「マージ後フィードバックの定常化」task 1-C。PR #69 (ADR 策定) + PR #70 (CLI 側 task 1-B) の後続。
Scope decision:
lib-pending-file抽出は当初スコープ外の想定だったが、takt pre-push-review (simplicity) が DRY-001 として blocking 指摘 → 本 PR に含めた (3 callers 超で shared lib の閾値を明確に越えた)。skill 側 Phase 0 対応は task 1-E (別リポジトリ)、post_steps 有効化は task 1-D (別 PR) に分離。Validation
cargo test(workspace): 全クレート pass (hooks-stop-feedback-dispatch 23件、他クレート回帰なし)pnpm build:hooks-stop-feedback-dispatch: 成功 (exe が .claude/ に配置)pnpm pushpre-push review: verdict=APPROVE (3 iterations / 17m46s)References
lib-pending-file追加)stop_hook_active無限ループ防止パターン)project_takt_pre_push_iterations.md: takt の REJECT → fix 収束パターン (本 PR でも DRY-001 が iteration 1-3 で fix 反映 → iter 3 で APPROVE)Summary by CodeRabbit
新機能
リファクタリング
ドキュメント
その他の改善