Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,8 @@
- [ADR-031: 週次プロジェクト全体レビューパイプライン — whole-tree review の自己改善ループ](docs/adr/adr-031-weekly-review-pipeline.md) *(試験運用)*
- [ADR-033: todo.md 採番管理の簡素化 — 絶対番号は table のみに保持](docs/adr/adr-033-todo-numbering-simplification.md) *(試験運用)*
- [ADR-034: CodeRabbit 監視・対話の自動化戦略 — Bundle a 設計根拠](docs/adr/adr-034-coderabbit-auto-monitoring.md) *(試験運用)*
- [ADR-036: Bundle Z — 決定論層 + 制約付き修正 + 異常検知レビュアーの 3 層アーキテクチャ](docs/adr/adr-036-bundle-z-three-layer-review.md) *(試験運用)*
- [ADR-037: takt fix-trust shortcut — convergence_verdict による Iter 3 短絡](docs/adr/adr-037-takt-fix-trust-shortcut.md) *(試験運用)*

## Build

Expand Down
18 changes: 4 additions & 14 deletions docs/adr/adr-034-coderabbit-auto-monitoring.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ PR #99 セッションで以下の運用痛が観測された:

## 検討した選択肢

`docs/pipeline-token-efficiency.md` #D セクションで 4 案を検討:
(削除済) `docs/pipeline-token-efficiency.md` #D セクションで 4 案を検討:

- **#D-1**: gh CLI 使用ルール (rule 追記)
- **#D-2**: `pnpm cr:findings <PR>` wrapper script
Expand All @@ -39,7 +39,7 @@ PR #99 セッションで以下の運用痛が観測された:
### 取り下げた案

- **#D-2 (pnpm cr:findings wrapper)**: ❌ 取り下げ。#D-3 が機能を内包 (Rust 構造化 findings JSON は wrapper script より widely usable、ADR-022 責務分離原則にも整合)
- **#D-4 (応答スタイル簡素化)**: ⏸️ 保留。**思考連続性低下リスク** (中間出力削減で後段の context 再構築コストが増え、token カテゴリが入れ替わるだけで正味削減が縮む可能性) を考慮、Bundle Z Phase 2/3 完了後の副作用観測手段確立を待つ。再評価条件は「将来の検討事項」参照
- **#D-4 (応答スタイル簡素化)**: ❌ **不採用** (2026-05-04 ユーザー判断、Bundle Z Phase 2/3 完了後の再評価で確定)。**思考連続性低下リスク** (中間出力削減で後段の context 再構築コストが増え、token カテゴリが入れ替わるだけで正味削減が縮む可能性) と **副作用観測手段の継続的不在** を考慮した最終判断。潜在 2.5-4M tokens 削減は採用見送り

## 実装方針 (2 Sub-PR 分割)

Expand Down Expand Up @@ -120,7 +120,7 @@ PR #99 セッションで以下の運用痛が観測された:
### Trade-off

- 開発体験の質的変化 (rate-limit 手動介入消滅) を **token 削減効果より優先**
- #D-4 (応答スタイル) の保留により、潜在 2.5-4M tokens 削減を見送り
- #D-4 (応答スタイル) の **不採用** (2026-05-04 確定) により、潜在 2.5-4M tokens 削減は永続的に見送り

## 別セッションでの実装に必要な情報

Expand Down Expand Up @@ -174,16 +174,6 @@ PR #99 セッションで以下の運用痛が観測された:

## 将来の検討事項

### #D-4 (Claude 応答スタイル簡素化) の再評価条件

Bundle Z Phase 2/3 (#B-β / #B-γ) 完了後、以下が確立した時点で慎重 pilot を実施:

- **副作用観測手段**: session 比較メトリクス (思考品質 proxy 指標 = 再 grep / 再 read 頻度の変化、修正回数の変化等)
- **段階的展開**: rule を一気に書かず、1 種類ずつ (Insight ブロック → 完了報告 → 分析テーブル) 試す
- **dogfood 比較**: 同種 PR を rule あり / なしで比較し、token 削減量と思考品質の trade-off を定量化

これらが揃わない限り、#D-4 は保留継続。

### Bundle a 着手時の前提条件 reality check

- CR の rate-limit 仕様が変わっていないか (memory `project_coderabbit_rate_limit_overlay.md` の挙動が再現するか) を着手前に dogfood で確認
Expand All @@ -196,6 +186,6 @@ Bundle Z Phase 2/3 (#B-β / #B-γ) 完了後、以下が確立した時点で慎
- ADR-022: 自動化コンポーネントの責務分離原則
- ADR-026: Cargo workspace
- ADR-030: Deterministic post-merge-feedback
- `docs/pipeline-token-efficiency.md` #D セクション (採用判定改訂 2026-05-02)
- (削除済) `docs/pipeline-token-efficiency.md` #D セクション (採用判定改訂 2026-05-02、本 ADR で経緯保存)
- memory `project_coderabbit_rate_limit_overlay.md`
- PR #99 (本 ADR の起源、cli-pr-monitor の rate-limit detection gap が顕在化したセッション)
104 changes: 104 additions & 0 deletions docs/adr/adr-036-bundle-z-three-layer-review.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
# ADR-036: Bundle Z — 決定論層 + 制約付き修正 + 異常検知レビュアーの 3 層アーキテクチャ

## ステータス

試験運用 (2026-05-04)

## コンテキスト

PR #97 セッション (2026-04-30 〜 2026-05-01) で `pre-push-review` パイプラインに **6 iter / 17-18 分の outlier** が 2 回観測された。総時間 36 分 (47.9 分中 75% を消費)。両 run の root cause 分析より、3 つの構造的根因が判明:

| 根因 | 例 |
|---|---|
| 1. **simplicity-review iter 1 の検出漏れ** | LLM の attention drift で What コメント S04 を見落とし |
| 2. **fix step が新 violation を introduce** | F-001 修正で `match Ok / Err` 採用 → nesting depth 7 を導入 |
| 3. **AI が What/How コメントをそもそも書く** | explanatory output style の指示があっても Claude の習性として残る |

これらは LLM 主導 review の **本質的限界** に由来し、prompt の改良 (より詳細な checklist 等) では解消できない。LLM の attention drift と self-evaluation 不安定性は、より厳しい指示を与えるほど attention 分散して悪化する性質を持つ。

## 検討した選択肢

(削除済) `docs/pipeline-token-efficiency.md` の #B セクションで 3 案を検討 (本 ADR が代替):

- **#B-α**: 決定論レイヤー (Rust comment lint hook、PostToolUse で AI が書く瞬間を block)
- **#B-β**: 制約付き修正 (fix step に metric diff の機械チェックを義務付け)
- **#B-γ**: 異常検知レビュアー (reviewer の責務を「lint で防げない高次違反のみ flag」に再定義)

**個別採用ではなく 3 層スタックとして統合**することを決定。各層が前提とする状態を後段の層が信頼することで責務を狭める設計。

## 決定

**Bundle Z = 3 層スタック** で pre-push-review の review 品質と速度を両立する:

```text
[書く瞬間] [修正の瞬間] [レビューの瞬間]
#B-α 決定論層 → #B-β 制約付き修正 → #B-γ 異常検知
PostToolUse hook fix-metrics check review facets
ファイルが書かれた時点で fix iteration ごとに 決定論層が intercept する
violation を block metric 増加を block metric は skip、 高次違反のみ flag
```

### 各層の責務分担

| 層 | 配置 | 検出対象 | 完了 PR |
|---|---|---|---|
| **#B-α 決定論層** | `src/hooks-post-tool-comment-lint-rust/` (PostToolUse hook) | 非 doc コメント (例外マーカー除外) / 関数長 50 行超 (touch-trigger ratchet) | PR #99 (Phase 1) + PR #105 (関数長 lint 追加 = 順位 48) |
| **#B-β 制約付き修正** | `.takt/facets/instructions/fix.md` + `scripts/fix-metrics-check.ps1` | fix iteration での per-function metric 増加 (comment count / function length / nesting depth) | PR #103 (Phase 2) |
| **#B-γ 異常検知** | `.takt/facets/instructions/review-{simplicity,security}.md` | 決定論層が intercept できない高次違反 (Unexplained complexity / Inconsistent style / Hidden coupling 等) | PR #106 (Phase 3) |

### 設計原則: 上層は下層が intercept する metric を skip する

`review-simplicity.md` の "Determinism layer guarantees (do NOT duplicate)" セクションで明文化:

- Comment policy → #B-α が PostToolUse で block 済 → reviewer は skip
- Function length → 順位 48 (`hooks-post-tool-comment-lint-rust`) が touch-trigger ratchet で block 済 → reviewer は skip
- Function metrics during fix → #B-β `fix-metrics-check.ps1` が pre/post diff で block 済 → reviewer は skip

**reviewer の責務 = 「決定論層 + 制約付き修正でも防げない高次違反」のみ**。enumerate 義務を削除し、attention drift 問題を構造的に解消。

### 二重 miss リスクへの対策

`review-simplicity.md` に "Calibration: avoid over-narrowing" セクションを残置:

- 異常検知への shift は重複作業の削減が目的、review skip ではない
- 「articulable concern」は raise する (criterion に当てはまらなくても)
- 機械的 checklist 適用なら下層がカバーしている

## 影響

### Positive

- ✅ pre-push-review iter 分布: PR #97 baseline `{1×3, 3×2, 6×1}` (avg 2.5、6-iter outlier 1 件) → 1-iter ALL APPROVE 構造化を目指す (Phase 3 実装直後の dogfood で初観測)
- ✅ attention drift 問題が構造的に消滅 (検出対象が absolute に narrow に)
- ✅ review 所要時間も短縮 (現 baseline 1m 30s〜3m → 30s〜1m 期待)
- ✅ 各層の責務が明確に分離、後続改修時の責務帰属が判断しやすい

### Negative

- ⚠️ 二重 miss の可能性 (決定論層の coverage gap で漏れた違反が reviewer もスルー) → "Calibration" セクションで対策
- ⚠️ 「異常」の定義が LLM 主観で false positive が出る場合、決定論層 update (lint rule 追加) で対応する継続的メンテが必要
- ⚠️ Rust 限定 (PoC は `tree-sitter-rust` 依存)。将来言語拡張時に決定論層の再実装が必要

### Trade-off

- 設計複雑度の増加 vs 検出精度の向上 → review 効率の改善が複雑度コストを上回ると判断
- 言語固有実装 (Rust 専用) vs 言語非依存抽象化 → PoC として Rust に絞り、言語拡張は需要発生時に判断 (YAGNI)

## 派生プロジェクトへの展開

`hooks-post-tool-comment-lint-rust` は派生プロジェクト (`techbook-ledger`、`auto-review-fix-vc`) でも展開済 (PR #99 / PR #105 deploy)。

facet instructions (`.takt/facets/instructions/*.md`) は本リポジトリと派生プロジェクトで個別更新する運用。

## 関連 ADR

- **ADR-001**: Rust 採用根拠 (#B-α / #B-β の実装言語選定根拠)
- **ADR-007**: AST 層 / 正規表現層の線引き (#B-α が AST 層で動作する根拠)
- **ADR-027**: Push-time review を simplicity に限定し architectural review は post-PR に委ねる (#B-γ の scope 設計と整合)
- **ADR-019**: CodeRabbit レビュー運用のハイブリッド構成 (post-PR 側の reviewer = CodeRabbit、pre-push 側の reviewer = takt との役割分担)

## References

- 元セッション: PR #97 (`6cbc5021-...jsonl`、6.18MB / 1180 turns) — 6-iter outlier の root cause 分析
- 完了 PR: #99 (Phase 1 #B-α) / #103 (Phase 2 #B-β) / #105 (順位 48 関数長 lint) / #106 (Phase 3 #B-γ)
- (削除済) `docs/pipeline-token-efficiency.md` #B セクション — 本 ADR が代替
117 changes: 117 additions & 0 deletions docs/adr/adr-037-takt-fix-trust-shortcut.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,117 @@
# ADR-037: takt fix-trust shortcut — convergence_verdict による Iter 3 短絡

## ステータス

試験運用 (2026-05-04)

## コンテキスト

`post-pr-review` パイプラインで 3-iter outlier が発生する根因分析より、Iter 3 の analyze step が **本質的に冗長** であることが判明した:

> Iter 3 output 例 (PR #96 の auto-fix run、10m 19s):
> 「`.takt/review-comments.json` is a snapshot captured before fix iteration 1 ran; CodeRabbit has not re-reviewed yet, so the same 2 findings appear. The previous fix step report indicates both were addressed. **I verified each by reading the current source**...」

つまり Iter 3 の analyze は「前 iter の fix step が言う通りに本当に修正されているか」をソースを読んで再確認している作業に過ぎない。fix step を信頼すれば不要。

同様の構造は `pre-push-review` パイプラインの 6-iter outlier でも観測されており、reviewers→fix→reviewers の 2 cycle 後に supervise → fix_supervisor のエスカレーションが発生する。これも fix step の自己評価を信頼できれば短絡可能。

LLM の self-evaluation 信頼性は本質的に揺らぐが、**機械的に検証可能な指標** (Convergence gate metrics) を fix step に emit させ、その出力を後段の routing に直接使うことで信頼性を確保できる。

## 決定

`fix.md` instruction に **convergence_verdict** マーカー emit を必須化し、workflow yaml の routing rule に「fully_resolved → COMPLETE 直行」condition を追加する。

### convergence_verdict 仕様

`fix.md` の Convergence gate (既存) は以下 4 metrics を fix step に emit させる:

| Metric | Count |
|--------|-------|
| new (fixed in this iteration) | {N} |
| reopened (recurrence fixed) | {N} |
| persists (carried over, not addressed this iteration) | {N} |
| misdirected (suggestion pointed at a read-only zone, skipped) | {N} |

これに加えて、fix step は report 末尾に以下のいずれかを single bare line で emit する (REQUIRED):

- `convergence_verdict: fully_resolved` — `persists == 0` AND `misdirected == 0`、すべての findings が解決済み
- `convergence_verdict: partial` — `persists > 0` OR `misdirected > 0`、再 analyze が必要

### workflow yaml routing

`post-pr-review.yaml` + `pre-push-review.yaml` の fix step rules に以下の condition を追加:

```yaml
rules:
- condition: |
Report ends with `convergence_verdict: fully_resolved` (Convergence
gate shows persists: 0 AND misdirected: 0). All findings of this
iteration are fully resolved with no remaining work.
next: COMPLETE
- condition: |
Fixes applied but `convergence_verdict: partial` (some findings
persist or were misdirected, re-analysis needed).
next: analyze # post-pr-review の場合 / reviewers (pre-push-review の場合)
- condition: Unable to proceed with fixes
next: supervise
```

### Honesty constraint

`fix.md` の convergence_verdict セクションに以下を明記:

> **Honesty constraint**: This verdict gates whether the analyze step runs again. Reporting `fully_resolved` while leaving findings unaddressed bypasses the safety re-check. If you are uncertain whether a finding was truly resolved (e.g., you applied a fix but did not verify the build passes), emit `partial` so the analyze step can re-evaluate.

虚偽申告 (= 未修正で fully_resolved を emit) は安全網 bypass に直結するため、不確実な場合は `partial` を選ぶよう明示。

## 設計哲学

本決定は **「LLM が出した結果を後段で再検証しない」** 原則の応用:

- 従来: fix step → analyze step (= ソースを読んで再確認) → fix step → ...
- 改訂後: fix step → (verdict ベース routing) → COMPLETE / analyze step

LLM 同士で互いを再評価する loop は token と時間を消費するが、信頼境界 (= verdict) を明確にすれば中間ステップを構造的に削減できる。

ADR-036 の Bundle Z 3 層アーキテクチャと同じ思想:

- Bundle Z #B-γ (異常検知 reviewer): **下層が intercept した metric を上層は skip** (上層は下層を信頼)
- 本 ADR (fix-trust): **fix step が emit した verdict を analyze step は再確認しない** (analyze は fix を信頼)

## 影響

### Positive

- ✅ post-pr-review の 3-iter outlier 圧縮: 3-iter run → 2-iter (~3 分削減/run)
- ✅ pre-push-review の reviewers→fix loop 短縮: 全 finding が一発で fix された場合の 2 cycle 目を skip
- ✅ 設計原則の明文化: 「LLM 結果の信頼境界」を verdict で portable に表現

### Negative

- ⚠️ fix step の自己評価信頼性に依存 (虚偽 fully_resolved → 未修正 finding land リスク)
- ⚠️ 後続 supervise step でカバーされない場合は安全網が薄くなる

### Mitigations

- **Honesty constraint** で安全網 bypass リスクを fix step に明示
- 不確実な場合は `partial` を選ぶデフォルトを推奨
- dogfood で虚偽 fully_resolved が観測されたら順位 53 系列の post-merge-feedback follow-up (T1-1: convergence_verdict gate validator) を採用検討

## 完了状態

- 完了 PR: #106 (Bundle Z Phase 3 と同梱)
- 影響範囲: `post-pr-review.yaml` / `pre-push-review.yaml` (fix step rules) + `fix.md` (Convergence verdict セクション追加)
- 派生プロジェクトへの展開: facet instructions は本リポジトリと派生プロジェクトで個別更新する運用 (ADR-036 と同じ)

## 関連 ADR

- **ADR-036**: Bundle Z 3 層アーキテクチャ (本 ADR と同じ「LLM 結果の信頼境界」原則を pre-push-review に適用)
- **ADR-008**: Push Pipeline ハーネスの実装 (workflow yaml 設計の前提)
- **ADR-015**: Push Pipeline を takt ベースの push-runner に移行 (workflow + facet 機構)
- **ADR-018**: cli-pr-monitor takt 化 (post-pr-review.yaml の起源)

## References

- 元セッション: PR #97 セッション (post-pr-review 3-iter outlier の root cause 分析)
- 完了 PR: #106 (Bundle Z Phase 3 + #C-2 同梱)
- (削除済) `docs/pipeline-token-efficiency.md` #C-2 セクション — 本 ADR が代替
Loading