feat(weekly-review): 分析フェーズを cloud routine へ移行し reminder を監査用途へ転換 (WP-17 PR 4) - #354
Conversation
…P-17 PR 4)
分析の主経路が cloud routine (週 1 schedule) へ移った (ADR-070) ことに伴い、SessionStart
reminder の意味を「レビューを実行せよ」から「**routine の稼働と結果の取り込みを確認せよ**」
へ変える。
## なぜ「格下げ」ではなく「意味の転換」なのか
計画書は当初「バックストップへ格下げ (文言・閾値を調整)」としていたが、実装時に構造的な
制約が判明した。`.claude/weekly-review-last-run.json` は skill Phase 4 が**ローカル実行時に
のみ**書き込む。**cloud routine は使い捨てクローンで動くため書き込んでも破棄され、この値は
routine 実行では更新されない**。
つまり旧実装のままだと、routine が正常に週次で回っていても last_run_at は永久に古いままで、
staleness reminder が threshold 超過後は毎セッション発火し続ける。2026-08-04 の one-off 実行で
実観測した (ユーザー報告: 「SessionStart reminder は次回も発火し続けます」)。
reminder は routine を観測できない以上、「前回実行から N 日 → 実行せよ」という指示自体が
成立しない。閾値だけ延ばしても嘘の指示が遅れて出るだけなので、意味を変える。
## 変更内容
- **文言**: staleness を「前回**ローカル**実行から」に限定し、「**本 reminder は cloud routine の
実行を観測できません**」「発火は routine が止まっている証拠ではない」を明記。推奨アクションを
(1) claude.ai/code/routines で稼働確認 → (2) 直近 run の transcript から findings を取り込み →
(3) 必要ならローカルで `/weekly-review`、の順に並べ替えた。
- **閾値**: 既定 7 日 → **30 日**。週次サイクルではなく監査サイクルに合わせる。7 日のままだと
routine 正常時も毎週発火して必ずノイズになる。
- **systemMessage**: 「週次レビュー監査: ... routine の稼働と結果の取り込みを確認してください」
へ変更し、ユーザー可視の 1 行でも誤誘導しないようにした。
- `.failed` marker 経路は**ローカル実行の失敗**を見るものなので従来の意味を維持。
## テスト
- 既存 2 件を新文言へ更新 (「実行記録なし」→「ローカル実行の記録なし」)。
- 回帰テスト 2 件を追加:
- `default_threshold_is_audit_cycle_not_weekly`: 既定 30 日を固定し、10 日では発火せず
31 日で発火することを machine-enforce (7 日へ戻す変更を検知する)
- `additional_context_states_routine_is_unobservable_and_primary`: 「観測できません」の明示と
claude.ai/code/routines への導線が additionalContext にあることを固定 (旧文言への
リグレッションを検知する)
検証: cargo test -p hooks-session-start 112 件 pass、workspace 1908 件 pass、
clippy --workspace -D warnings 緑。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
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:
📝 WalkthroughWalkthroughweekly-review の Phase 1–2 を cloud routine の schedule 実行へ移行する設計を追加しました。SessionStart reminder は、ローカル実行の促進から routine の稼働と結果取り込みを確認する監査通知へ変更しました。 Changesweekly-review cloud routine 移行
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant CloudRoutine
participant WeeklyReview
participant SessionStartHook
CloudRoutine->>WeeklyReview: Phase 1-2 の分析を実行
WeeklyReview-->>CloudRoutine: findings と transcript を生成
SessionStartHook->>SessionStartHook: ローカル実行記録を確認
SessionStartHook-->>CloudRoutine: 稼働と結果取り込みの確認を促す
Possibly related PRs
🚥 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 以下)(該当なし) Filtered (not applicable)(該当なし) 差分概要mergeStateStatus は
Rust ソースロジック変更( 次のアクション
|
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (1)
src/hooks-session-start/src/weekly_review.rs (1)
714-721: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win30 日ちょうどの境界を回帰テストで固定してください。
weekly_review_staleness_hitsは Line 154 で>=を使います。したがって 30 日ちょうどで発火します。しかし現在のテストは 10 日と 31 日だけを検証します。文言の「超えました」は>とも解釈できるため、仕様を決めて実装、メッセージ、テストを一致させてください。30 日で発火する仕様なら、
ElapsedDays(30)がtrueになることを追加で検証し、文言を「30 日以上」などに変更してください。🤖 Prompt for 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. In `@src/hooks-session-start/src/weekly_review.rs` around lines 714 - 721, Align the weekly review threshold contract across weekly_review_staleness_hits, its user-facing message, and the regression tests. Preserve the existing >= behavior by adding an assertion that ElapsedDays(30) returns true, and update wording that currently implies the threshold must be exceeded to state that 30 days or more triggers the review.
🤖 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 `@docs/adr/adr-031-weekly-review-pipeline.md`:
- Line 7: Update the wording in the ADR-031 update so the phrase after
“ローカルの人間作業” uses “であり、” instead of “で、”, preserving the surrounding meaning and
formatting.
- Around line 7-8: Update the existing L1/L2, overall flow, and trigger sections
in ADR-031 to align with ADR-070: assign Phase 1–2 to the weekly cloud routine,
retain Phase 3–4 as local human work, and describe SessionStart as a 30-day
audit reminder verifying routine execution and result intake. Remove or revise
stale 7-day detection, manual /weekly-review execution, and skill-based Phase
1–4 claims, while preserving the contract that the routine does not update
last_run_at.
In `@docs/adr/adr-070-weekly-review-cloud-routine.md`:
- Line 160: Update the ADR-031 reference in the related-ADR section to state
that this ADR changes not only the startup trigger but also the SessionStart
reminder semantics and threshold. Ensure the scope reflects the corresponding
weekly review hook and hook configuration contract.
- Around line 38-40: ADR-070の「永久に更新されず」という記述を、cloud
routine実行では更新されない一方、ユーザーがローカルで/weekly-reviewのPhase
4を完了した場合はlast_run_atが更新される内容に修正してください。対象は「転換が必要な構造的理由」の説明に限定し、ローカルPhase
4を実行しない場合のみ更新されないことを明記してください。
In `@src/hooks-session-start/src/weekly_review.rs`:
- Around line 1-18: Update the Missing branch in weekly_review_staleness_hits
and the surrounding compute_weekly_review_reminder_nudge flow so absent local
last-run data is throttled by a persisted local audit-notification timestamp,
applying reminder_threshold_days rather than returning true every session.
Persist and reuse that state across calls while preserving stale/failed-marker
behavior, and add a regression test proving consecutive
compute_weekly_review_reminder_nudge calls do not both fire for Missing.
- Line 245: WeeklyReviewNudge::system_message のユーザー向け文言に、ローカル状態だけでは cloud
routine の停止を判断できない旨を追加してください。関連する system_message
のテストにも、その注意文が含まれることを検証するケースを追加してください。
---
Nitpick comments:
In `@src/hooks-session-start/src/weekly_review.rs`:
- Around line 714-721: Align the weekly review threshold contract across
weekly_review_staleness_hits, its user-facing message, and the regression tests.
Preserve the existing >= behavior by adding an assertion that ElapsedDays(30)
returns true, and update wording that currently implies the threshold must be
exceeded to state that 30 days or more triggers the review.
🪄 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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: f6b8d757-7c62-47b7-91db-d2ab10ed18ca
📒 Files selected for processing (6)
.claude/hooks-config.tomlCLAUDE.mddocs/adr/adr-031-weekly-review-pipeline.mddocs/adr/adr-070-weekly-review-cloud-routine.mddocs/harness-improvement-plan.mdsrc/hooks-session-start/src/weekly_review.rs
|
|
||
| 承認済み (2026-06-01、試験運用 2026-04-27 → 本採用に昇格) | ||
|
|
||
| > **2026-08-04 更新 (WP-17 PR 4)**: 起動トリガーを [ADR-070](adr-070-weekly-review-cloud-routine.md) が変更した。分析フェーズ (Phase 1-2 = takt workflow 実行) は cloud routine (週 1 schedule) が担い、SessionStart reminder は「レビューを実行せよ」から「**routine の稼働と結果の取り込みを確認せよ**」の監査リマインダー (既定 30 日) へ転換。**Phase 3 (採否判断) / Phase 4 (task list 反映 + last-run 更新) は従来どおりローカルの人間作業**で、routine は置き換えではない。本 ADR のパイプライン設計そのものは変更なし。 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
接続表現を であり に修正してください。
ローカルの人間作業**で、routine は置き換えではない。 は接続が不自然です。ローカルの人間作業であり、routine は置き換えではない。 のように修正してください。
🧰 Tools
🪛 LanguageTool
[uncategorized] ~7-~7: 文法ミスがあります。"のでは"の間違いです。
Context: ...k list 反映 + last-run 更新) は従来どおりローカルの人間作業**で、routine は置き換えではない。本 ADR のパイプライン設計そのものは変更なし...
(DOUSI_DEHA)
🤖 Prompt for 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.
In `@docs/adr/adr-031-weekly-review-pipeline.md` at line 7, Update the wording in
the ADR-031 update so the phrase after “ローカルの人間作業” uses “であり、” instead of “で、”,
preserving the surrounding meaning and formatting.
Source: Linters/SAST tools
| > **2026-08-04 更新 (WP-17 PR 4)**: 起動トリガーを [ADR-070](adr-070-weekly-review-cloud-routine.md) が変更した。分析フェーズ (Phase 1-2 = takt workflow 実行) は cloud routine (週 1 schedule) が担い、SessionStart reminder は「レビューを実行せよ」から「**routine の稼働と結果の取り込みを確認せよ**」の監査リマインダー (既定 30 日) へ転換。**Phase 3 (採否判断) / Phase 4 (task list 反映 + last-run 更新) は従来どおりローカルの人間作業**で、routine は置き換えではない。本 ADR のパイプライン設計そのものは変更なし。 | ||
| > |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
ADR-070 の境界を既存セクションにも反映してください。
Line 7–8 は、Phase 1–2 を週次 cloud routine、SessionStart を 30 日の監査通知へ変更します。しかし同じ docs/adr/adr-031-weekly-review-pipeline.md の Line 130–163 と Line 264–270 には、7 日 stale 判定、/weekly-review の手動実行、skill が Phase 1–4 を実行する旧仕様が残っています。
.claude/hooks-config.toml は既に reminder_threshold_days = 30 と、cloud routine が last_run_at を更新しない契約を定義しています。このままでは ADR-031 内の運用手順が矛盾します。L1/L2、全体フロー、トリガー節を ADR-070 の Phase 1–2 / Phase 3–4 境界と監査 reminder の責務に合わせて同期してください。
Based on learnings: 適用対象の ADR の決定を現行文書へ反映し、superseded ADR を現行要件として扱わない方針に従ってください。
🧰 Tools
🪛 LanguageTool
[uncategorized] ~7-~7: 文法ミスがあります。"のでは"の間違いです。
Context: ...k list 反映 + last-run 更新) は従来どおりローカルの人間作業**で、routine は置き換えではない。本 ADR のパイプライン設計そのものは変更なし...
(DOUSI_DEHA)
🤖 Prompt for 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.
In `@docs/adr/adr-031-weekly-review-pipeline.md` around lines 7 - 8, Update the
existing L1/L2, overall flow, and trigger sections in ADR-031 to align with
ADR-070: assign Phase 1–2 to the weekly cloud routine, retain Phase 3–4 as local
human work, and describe SessionStart as a 30-day audit reminder verifying
routine execution and result intake. Remove or revise stale 7-day detection,
manual /weekly-review execution, and skill-based Phase 1–4 claims, while
preserving the contract that the routine does not update last_run_at.
Source: Learnings
| ### 2. SessionStart reminder を「staleness 検知」から「監査リマインダー」へ転換する | ||
|
|
||
| **転換が必要な構造的理由**: `.claude/weekly-review-last-run.json` は skill Phase 4 がローカルで書き込むファイルだが、**cloud routine は使い捨てクローンで動くため書き込んでも破棄される**。routine 移行後もこのファイルは永久に更新されず、旧実装のままでは staleness reminder が毎セッション発火し続ける (2026-08-04 の手動実行で実観測。§ 検証記録)。 |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
weekly-review-last-run.json の更新条件を限定してください。
ユーザーが /weekly-review をローカルで実行して Phase 4 を完了した場合、last_run_at は更新されます。したがって「永久に更新されず」は正しくありません。cloud routine の実行では更新されず、ローカル Phase 4 を実行しない場合に限って更新されない、と記述してください。
修正例
- routine 移行後もこのファイルは永久に更新されず、旧実装のままでは staleness reminder が毎セッション発火し続ける
+ cloud routine の実行ではこのファイルは更新されない。ローカル Phase 4 を実行しない場合、旧実装の staleness reminder は毎セッション発火し続ける根拠: 本 ADR の Phase 4 定義と、ローカル実行記録だけを保持する説明です。
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### 2. SessionStart reminder を「staleness 検知」から「監査リマインダー」へ転換する | |
| **転換が必要な構造的理由**: `.claude/weekly-review-last-run.json` は skill Phase 4 がローカルで書き込むファイルだが、**cloud routine は使い捨てクローンで動くため書き込んでも破棄される**。routine 移行後もこのファイルは永久に更新されず、旧実装のままでは staleness reminder が毎セッション発火し続ける (2026-08-04 の手動実行で実観測。§ 検証記録)。 | |
| ### 2. SessionStart reminder を「staleness 検知」から「監査リマインダー」へ転換する | |
| **転換が必要な構造的理由**: `.claude/weekly-review-last-run.json` は skill Phase 4 がローカルで書き込むファイルだが、**cloud routine は使い捨てクローンで動くため書き込んでも破棄される**。cloud routine の実行ではこのファイルは更新されない。ローカル Phase 4 を実行しない場合、旧実装の staleness reminder は毎セッション発火し続ける (2026-08-04 の手動実行で実観測。§ 検証記録)。 |
🤖 Prompt for 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.
In `@docs/adr/adr-070-weekly-review-cloud-routine.md` around lines 38 - 40,
ADR-070の「永久に更新されず」という記述を、cloud
routine実行では更新されない一方、ユーザーがローカルで/weekly-reviewのPhase
4を完了した場合はlast_run_atが更新される内容に修正してください。対象は「転換が必要な構造的理由」の説明に限定し、ローカルPhase
4を実行しない場合のみ更新されないことを明記してください。
|
|
||
| ## 関連 | ||
|
|
||
| - [ADR-031](adr-031-weekly-review-pipeline.md) — weekly-review パイプライン本体。本 ADR は起動トリガーのみを変更する |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
関連 ADR の変更範囲を更新してください。
この行は「起動トリガーのみを変更する」と記述しています。しかし本 ADR は、SessionStart reminder の意味と threshold も変更します。現在の記述では、後続の実装者が監査リマインダーの契約を見落とします。
修正例
- 本 ADR は起動トリガーのみを変更する
+ 本 ADR は起動トリガーと SessionStart 監査リマインダーの意味を変更する根拠: src/hooks-session-start/src/weekly_review.rs と .claude/hooks-config.toml も同じ契約を変更しています。
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [ADR-031](adr-031-weekly-review-pipeline.md) — weekly-review パイプライン本体。本 ADR は起動トリガーのみを変更する | |
| - [ADR-031](adr-031-weekly-review-pipeline.md) — weekly-review パイプライン本体。本 ADR は起動トリガーと SessionStart 監査リマインダーの意味を変更する |
🤖 Prompt for 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.
In `@docs/adr/adr-070-weekly-review-cloud-routine.md` at line 160, Update the
ADR-031 reference in the related-ADR section to state that this ADR changes not
only the startup trigger but also the SessionStart reminder semantics and
threshold. Ensure the scope reflects the corresponding weekly review hook and
hook configuration contract.
| //! ADR-031 Phase C / ADR-070: weekly-review の**監査リマインダー** (バックストップ)。 | ||
| //! | ||
| //! ADR-070 で分析の主経路が cloud routine (週 1 schedule) へ移ったため、本 module の役割は | ||
| //! 「レビューを実行せよ」から「**routine の稼働と結果の取り込みを確認せよ**」へ転換した。 | ||
| //! | ||
| //! **重要な非対称**: `.claude/weekly-review-last-run.json` は skill Phase 4 が**ローカル実行時**に | ||
| //! のみ書き込む。cloud routine は使い捨てクローンで動くため書き込んでも破棄され、この値は | ||
| //! routine 実行では更新されない。したがって本 reminder は **cloud routine の実行を観測できない** — | ||
| //! 発火は「routine が止まっている」の証拠ではなく、定期的な監査を促す助言に過ぎない。 | ||
| //! threshold も週次サイクル (7 日) ではなく監査サイクル (既定 30 日) に合わせてある。 | ||
| //! | ||
| //! 2 種類の reminder を発火: | ||
| //! - last-run staleness: `.claude/weekly-review-last-run.json` の `last_run_at` が | ||
| //! `reminder_threshold_days` を超えていれば「`/weekly-review` の実行を検討」を nudge。 | ||
| //! `last_run_at` が欠落/不正な旧・破損データは stale 扱い (= 発火) にする。 | ||
| //! - last-run staleness: 上記 `last_run_at` が `reminder_threshold_days` を超えていれば | ||
| //! 「routine の稼働確認と結果取り込み」を nudge。`last_run_at` が欠落/不正な旧・破損データは | ||
| //! stale 扱い (= 発火) にする。 | ||
| //! - failed marker: `.claude/weekly-reviews/*.md.failed` が 1 件以上存在すれば | ||
| //! 「前回 weekly-review が失敗、`/weekly-review` で resume」を nudge | ||
| //! 「前回**ローカル**実行が失敗、`/weekly-review` で resume」を nudge (これは routine ではなく | ||
| //! ローカル実行の失敗を見るため、従来どおりの意味を保つ) |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Missing 状態にも 30 日監査の周期を適用してください。
WeeklyLastRunState::Missing は Line 152 で threshold_days に関係なく true になります。cloud routine は .claude/weekly-review-last-run.json を更新しないため、ローカル Phase 4 を一度も実行していない環境では、30 日設定でも SessionStart nudge が毎回発火します。これは ADR-070 が解消対象とする毎セッション発火を残します。
Missing を単に false にするのではなく、監査通知の最終発火時刻など別のローカル状態を持ち、その状態に対して 30 日周期を適用してください。連続した compute_weekly_review_reminder_nudge 呼び出しで毎回発火しない回帰テストも追加してください。
根拠: weekly_review_staleness_hits の Missing 分岐と、cloud routine が local last-run state を更新しない ADR-070 の契約です。
Also applies to: 42-48, 173-178, 705-713
🤖 Prompt for 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.
In `@src/hooks-session-start/src/weekly_review.rs` around lines 1 - 18, Update the
Missing branch in weekly_review_staleness_hits and the surrounding
compute_weekly_review_reminder_nudge flow so absent local last-run data is
throttled by a persisted local audit-notification timestamp, applying
reminder_threshold_days rather than returning true every session. Persist and
reuse that state across calls while preserving stale/failed-marker behavior, and
add a regression test proving consecutive compute_weekly_review_reminder_nudge
calls do not both fire for Missing.
| } | ||
| Some(SingleLineMessage::new(format!( | ||
| "週次レビュー: {}。`/weekly-review` の実行を検討してください", | ||
| "週次レビュー監査: {}。routine の稼働と結果の取り込みを確認してください (claude.ai/code/routines)", |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
ユーザー可視の systemMessage に観測不能の注意を追加してください。
systemMessage はユーザー可視です。現在の文言はローカル記録と routine の確認先を示しますが、ローカル状態だけでは cloud routine の停止を判断できないことを明記していません。この注意は additional_context にしかありません。.claude/hooks-config.toml では system_message_enabled = true のため、この差はユーザーに届きます。
修正例
- "週次レビュー監査: {}。routine の稼働と結果の取り込みを確認してください (claude.ai/code/routines)",
+ "週次レビュー監査: {}。ローカル記録だけでは routine の停止を判断できません。routine の稼働と結果の取り込みを確認してください (claude.ai/code/routines)",テストにも 停止を判断できません の検証を追加してください。
根拠: WeeklyReviewNudge::system_message のユーザー可視契約と、.claude/hooks-config.toml の有効化設定です。
Also applies to: 624-635
🤖 Prompt for 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.
In `@src/hooks-session-start/src/weekly_review.rs` at line 245,
WeeklyReviewNudge::system_message のユーザー向け文言に、ローカル状態だけでは cloud routine
の停止を判断できない旨を追加してください。関連する system_message のテストにも、その注意文が含まれることを検証するケースを追加してください。
🤖 PR Monitor 分析 (GitHub Actions バックストップ)
Applicable Findings (Critical / High / Major)
Applicable Findings (Medium 以下)
Filtered (not applicable)
次のアクション
|
… (WP-17 PR 4) WP-17 PR 4 の決定を永続記録へ移す。 ## ADR-070 起票 - **決定 1**: 分析フェーズ (Phase 1-2) を cloud routine の schedule トリガーで実行する。 routine は commit / push / PR 作成を行わず、findings の報告までを責務とする (ADR-031 の「採否は人間が判断する」設計を維持し、Phase B (ADR-067) 以外の自律 push 経路を増やさない)。 - **決定 2**: SessionStart reminder を staleness 検知から監査リマインダーへ転換する (構造的理由は同 PR のコード側コミット参照)。 - **決定 3**: routine run の緑ステータスはタスク成功を意味しないため、成功判定は transcript を 読むことでのみ行う。プロンプトに exit code 報告と「成功を装わない」を明示的に含める。 ## 検証記録 (2026-08-04 の one-off 実行) - `pnpm install` / `cloud-setup.sh` / `takt -w weekly-review` の 3 ステップすべて exit 0 - 6 facet を parallel 実行 → aggregate-weekly まで完走 (2 iterations / 7m18s / completed) - reports 8 ファイル生成、findings 1 件 (medium、todo-preamble-drift) - Ollama 未導入の警告は fail-open で degrade する設計どおり (本 workflow は未使用) - 制約遵守: commit / push / PR 作成なし (`jj status` clean) → 決定 1 がクラウド Linux 環境で成立することを実測。ADR-060 / ADR-063 の dogfood を兼ねる。 ## 「2. 検証済みの前提事実」の永続化 計画書 § 2 が ADR 起票時の必須要件としていた routines 事実を ADR-070 へ移管した。 **観測していない値は「未再確認」と明示**する方針を貫いた: - daily run cap / webhook 上限の具体値 → 今回は one-off + schedule のみで到達せず未再確認 - **Claude GitHub App は本リポジトリにインストール済み** (2026-08-04 ユーザー確認)。したがって 「schedule トリガーのみなら App 不要か」は**検証していない** — インストール済みの状態でしか 観測しておらず、不要であることを主張できない - routine の push 認証も未観測 (今回は制約で push を禁じたため)。clone が通ったことは push 可否の 証拠にならない (public repo の clone は無認証で成立する) ## 中核の残課題 — 実行主体を含む 3 択として整理 routine の分析結果は使い捨てクローン内と transcript にしか存在せず、ユーザーが読まなければ 7 分の分析がそのまま消える。この問題を「配送方法の選択」ではなく**実行主体を含む 3 択** として残課題に記録した: 1. **cloud routine** — research preview 依存。push 認証が未検証 2. **GitHub Actions schedule workflow** — WP-17 バックボーンの再利用。claude-code-action + OAuth token は pr-monitor で稼働実績、Linux 実行は本 ADR の検証記録で実証済み、 `claude/` push は `GITHUB_TOKEN` で可能 (ruleset 5 層目と整合、push 可否に不確実性なし)。 research preview 非依存、観測性が高い 3. **ローカル維持 (= routine 断念)** — 配送問題自体が存在しない。**正規の出口**として明記 価値評価も正直に記録した: weekly-review のボトルネックは人間の採否時間 (Phase 3/4、どの実行 主体でも不変) で、クラウド実行が buy するのは数分の待ち時間短縮に留まる。PR 監視 (イベント 駆動・人間の関与なしに完成品が届く) とは価値方程式が根本的に違う。採用バーは「配送ループが 追加運用負担ほぼゼロで閉じること」。 配送チャネルの選択が検出問題を規定する点も明記: ブランチ push (通知なし) は SessionStart hook の検出が必要になるが、hook は fetch 済み ref しか見えない (fetch は push/merge フロー内 でのみ発生) という制約に当たる。**通知を持つチャネル (Issue 等) なら GitHub 自身の通知が 届くため検出機構そのものが不要**。 ## 整合 - ADR-031: ステータス冒頭に「起動トリガーは ADR-070 が変更、パイプライン設計は不変」を追記 - CLAUDE.md: ADR-070 を登録 - 計画書: PR 4 を実施中に更新、着手前決定 3 (App 未インストール前提) に 2026-08-04 の インストール済み確認を追記、WP-17 の全体状態を「着手中」→「観測中」へ 検証: pnpm lint:docs / lint:md 0 error。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
6a1ff2a to
b3b0523
Compare
… PR 4) PR 作成後に実施した push 認証テスト (one-off routine) の結果を残課題へ反映する。 ## 実測結果 — 認証層に到達せず hook で停止 `jj git push` は `jj-push-guard` プリセット (ADR-015) が無条件でブロックし `pnpm push` へ 誘導した。routine は誘導先が自律レビュー / fix パイプライン全体を起動する (外部可視の 副作用を伴う) と判断して実行を見送った。**push 可否そのものは未検証のまま**。 副次観測: - サンドボックスの remote は `http://local_proxy@127.0.0.1:<port>/git/...` のローカル proxy 経由。セッション内トークンが直接使われる構成ではない - `jj git fetch` は成功 = **read は通る**。jj コマンド自体は hook 対象外で、ブロックは push 系のみ ## 判定への含意 — 実行主体 1 が劣後した 実行主体 1 (routine) + ブランチ配送を成立させるには、`jj git push -b claude/weekly-review-*` を docs-only 条件付きで許可する例外をローカル hook に新設する必要がある。これは ADR-067 (Phase B) と同クラスの「自律 push 経路の新設」であり、本 ADR が定めた採用バー (配送ループが **追加運用負担ほぼゼロ**で閉じること) を明らかに超える。 対して: - **実行主体 2 (Actions schedule) はこの問題が構造的に発生しない** — workflow の push は ローカル hook 層を通らず、ゲートは Phase B と同じく workflow 自身のロジックが持つ - **配送先を Issue にする案も push 自体が不要**になるため同様に回避できる 判定手順を更新し、bounded lifetime (b) が不成立と判定された場合の実質的な選択は **Actions schedule / Issue 配送 / 断念 (ローカル維持)** の 3 つになることを明記した。 ## テスト実行時の判断について routine が `pnpm push` の実行を見送った判断は正しい。無人実行で自律パイプラインを起動すると PR コメント投稿・Max 枠消費・場合により auto-push という外部可視の副作用が発生する。得られる 情報 (proxy が push を通すか) は上記の含意により実行主体の判定にもはや影響しないため、 追試も行わない。この判断根拠も ADR に残した。 検証: pnpm lint:docs / lint:md 0 error。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
概要
WP-17 PR 4(最終)です。weekly-review の分析フェーズを cloud routine(週 1 schedule)へ
移し、SessionStart reminder を監査リマインダーへ転換します。これで WP-17(イベント駆動
バックボーン完成)の全 PR が揃います。
2 コミット / 6 ファイル / +300 行規模。
実測で確認済み: routine はクラウドで完走する
ユーザーが routine を作成し one-off 実行した結果(ADR-070 § 検証記録):
pnpm installbash scripts/cloud-setup.shpnpm exec takt -w weekly-review -t weekly-review --pipeline --skip-git6 facet を parallel 実行 → aggregate-weekly まで完走(2 iterations / 7m18s / completed)。
reports 8 ファイル生成、findings 1 件(medium)。commit / push / PR 作成はいずれも発生せず。
ADR-060 / ADR-063 のクラウド可搬性レイヤが weekly-review 経路でも機能することの実測を
兼ねます。
実装中に判明した構造的制約(計画からの逸脱)
計画書は「reminder をバックストップへ格下げ」としていましたが、格下げでは済みません
でした。
.claude/weekly-review-last-run.jsonは skill Phase 4 がローカル実行時にのみ書き込みます。cloud routine は使い捨てクローンで動くため、この値は routine 実行では
更新されません。旧実装のままだと routine が正常でも reminder が毎セッション発火し続けます
(one-off 実行後に実観測)。
そこで reminder の意味そのものを転換しました:
回帰テスト 2 件で固定(既定 30 日 / 「観測できません」の明示。旧仕様への逆行を検知)。
.failedmarker 経路はローカル実行の失敗を見るものなので従来の意味を維持。routine は skill の置き換えではない
routine には commit / push / PR 作成を一切させません(ADR-031 の設計を維持)。
中核の残課題: 成果物デリバリと実行主体(ADR-070 § 残課題)
routine の分析結果は transcript にしか残らず、ユーザーが読まなければ 7 分の分析が消えます。
この問題を「配送方法の選択」ではなく実行主体を含む 3 択として ADR に記録しました:
claude/push はGITHUB_TOKENで可(App 不要・ruleset 整合)。統合性で routine 案をほぼ支配配送チャネルも設計を左右します: ブランチ push(通知なし)はローカル検出機構が必要になり、
SessionStart hook は fetch 済み ref しか見えない制約に当たります。通知を持つチャネル
(Issue 等)なら GitHub 自身の通知が届くため検出機構そのものが不要です。
価値評価も正直に記録しました: weekly-review のボトルネックは人間の採否時間(どの実行主体でも
不変)で、クラウド実行が buy するのは数分の待ち時間短縮。採用バーは「配送ループが追加運用負担
ほぼゼロで閉じること」で、閉じないならローカル維持が正解です。判定は ADR-070 の
bounded lifetime(schedule 実行 3〜5 回、期限 2026-11-04)の観測後に行います。
検証
cargo test --workspace1908 件 pass(新規 2 件、既存 2 件を新文言へ更新)cargo clippy --workspace --all-targets -- -D warnings緑、pnpm lint:docs/lint:md0 errorWP-17 の完了状況
スモークは段 0 / 0.5 / 1 完了済み。段 2(
claude/テストブランチでの allow 経路観測)が残。🤖 Generated with Claude Code
Summary by CodeRabbit