takt/builtins/ja/pieces/structural-reform.yaml

438 lines
13 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

name: structural-reform
description: プロジェクト全体レビューと構造改革 - 段階的なファイル分割による反復的コードベース再構築
piece_config:
provider_options:
codex:
network_access: true
opencode:
network_access: true
max_movements: 50
initial_movement: review
loop_monitors:
- cycle:
- implement
- fix
threshold: 3
judge:
persona: supervisor
instruction_template: |
implement → reviewers → fix のループが現在の改革ターゲットに対して {cycle_count} 回繰り返されました。
各サイクルのレポートを確認し、このループが進捗しているか、
同じ問題を繰り返しているかを判断してください。
**参照するレポート:**
- アーキテクチャレビュー: {report:04-architect-review.md}
- QAレビュー: {report:05-qa-review.md}
**判断基準:**
- 各修正サイクルでレビュー指摘が解消されているか
- 同じ問題が解決されずに繰り返されていないか
- 実装が承認に向かって収束しているか
rules:
- condition: 健全(承認に向けて進捗あり)
next: implement
- condition: 非生産的(同じ問題が繰り返され、収束なし)
next: next_target
movements:
- name: review
edit: false
persona: architecture-reviewer
policy: review
knowledge:
- architecture
- backend
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
instruction_template: |
## ピースステータス
- イテレーション: {iteration}/{max_movements}(ピース全体)
- ムーブメントイテレーション: {movement_iteration}(このムーブメントの実行回数)
- ムーブメント: reviewプロジェクト全体レビュー
## ユーザーリクエスト
{task}
## 指示
プロジェクトのコードベース全体に対して、包括的な構造レビューを実施してください。
**重点領域:**
1. **God Class/Function**: 300行を超えるファイル、複数の責務を持つクラス
2. **結合度**: 循環依存、モジュール間の密結合
3. **凝集度**: 無関係な関心事が混在した低凝集モジュール
4. **テスタビリティ**: 密結合や副作用によるテスト困難なコード
5. **レイヤー違反**: 依存方向の誤り、アダプター層にドメインロジック
6. **DRY違反**: 3箇所以上の重複ロジック
**発見した問題ごとに報告:**
- ファイルパスと行数
- 問題カテゴリGod Class、低凝集など
- 深刻度Critical / High / Medium
- 分離すべき具体的な責務
- 分割により影響を受ける依存先
**出力フォーマット:**
```markdown
# プロジェクト全体構造レビュー
## サマリー
- レビュー対象ファイル数: N
- 検出された問題: NCritical: N, High: N, Medium: N
## Critical Issues
### 1. {ファイルパス}{行数}行)
- **問題**: {カテゴリ}
- **深刻度**: Critical
- **検出された責務**:
1. {責務1}
2. {責務2}
- **分割提案**:
- `{新ファイル1}.ts`: {責務}
- `{新ファイル2}.ts`: {責務}
- **影響を受ける依存先**: {このモジュールをインポートしているファイル}
## High Priority Issues
...
## Medium Priority Issues
...
## 依存グラフの懸念事項
- {循環依存、レイヤー違反}
## 推奨改革順序
1. {ファイル} - {優先理由}
2. {ファイル} - {優先理由}
```
rules:
- condition: 全体レビューが完了し、問題が検出された
next: plan_reform
- condition: 構造的な問題は見つからなかった
next: COMPLETE
output_contracts:
report:
- name: 00-full-review.md
- name: plan_reform
edit: false
persona: planner
knowledge: architecture
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
## ピースステータス
- イテレーション: {iteration}/{max_movements}(ピース全体)
- ムーブメントイテレーション: {movement_iteration}(このムーブメントの実行回数)
- ムーブメント: plan_reform改革計画策定
## ユーザーリクエスト
{task}
## 全体レビュー結果
{previous_response}
## ユーザー追加入力
{user_inputs}
## 指示
全体レビュー結果を基に、具体的な改革実行計画を策定してください。
**計画の原則:**
- 1イテレーションにつき1ファイルの分割変更を管理可能に保つ
- 依存順に実行:まずリーフノードを分割し、内側に向かって進む
- 各分割後にテストとビルドが通ること
- 後方互換は不要(ユーザー指示通り)
**各改革ターゲットについて指定:**
1. 対象ファイルと現在の行数
2. 提案する新ファイルと責務
3. 依存先ファイルのインポート変更予定
4. テスト戦略(新規テスト、既存テストの更新)
5. リスク評価(何が壊れる可能性があるか)
**出力フォーマット:**
```markdown
# 構造改革計画
## 改革ターゲット(実行優先順)
### ターゲット1: {ファイルパス}
- **現状**: {行数}行、{N}個の責務
- **分割提案**:
| 新ファイル | 責務 | 推定行数 |
|----------|------|---------|
| `{パス}` | {責務} | ~{N} |
- **依存先ファイル**: {このモジュールをインポートしているファイル一覧}
- **テスト計画**: {追加・更新すべきテスト}
- **リスク**: {Low/Medium/High} - {説明}
### ターゲット2: {ファイルパス}
...
## 実行順序の根拠
{この順序がリスクと依存関係の競合を最小化する理由}
## 成功基準
- 各分割後に全テストが通る
- 各分割後にビルドが成功する
- 300行を超えるファイルがない
- 各ファイルが単一責務を持つ
```
rules:
- condition: 改革計画が完成し、実行可能な状態
next: implement
- condition: 実行可能な改革が特定されなかった
next: COMPLETE
- condition: 要件が不明確、ユーザー入力が必要
next: ABORT
appendix: |
確認事項:
- {質問1}
- {質問2}
output_contracts:
report:
- name: 01-reform-plan.md
format: plan
- name: implement
edit: true
persona: coder
policy:
- coding
- testing
session: refresh
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
required_permission_mode: edit
instruction: implement
rules:
- condition: 実装完了
next: reviewers
- condition: 判断できない、情報不足
next: reviewers
- condition: ユーザー入力が必要
next: implement
requires_user_input: true
interactive_only: true
output_contracts:
report:
- Scope: 02-coder-scope.md
- Decisions: 03-coder-decisions.md
- name: reviewers
parallel:
- name: arch-review
edit: false
persona: architecture-reviewer
policy: review
knowledge:
- architecture
- backend
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction: review-arch
output_contracts:
report:
- name: 04-architect-review.md
format: architecture-review
- name: qa-review
edit: false
persona: qa-reviewer
policy:
- review
- qa
allowed_tools:
- Read
- Glob
- Grep
- WebSearch
- WebFetch
rules:
- condition: approved
- condition: needs_fix
instruction: review-qa
output_contracts:
report:
- name: 05-qa-review.md
format: qa-review
rules:
- condition: all("approved")
next: verify
- condition: any("needs_fix")
next: fix
- name: fix
edit: true
persona: coder
policy:
- coding
- testing
knowledge:
- backend
- architecture
allowed_tools:
- Read
- Glob
- Grep
- Edit
- Write
- Bash
- WebSearch
- WebFetch
required_permission_mode: edit
rules:
- condition: 修正完了
next: reviewers
- condition: 判断できない、情報不足
next: plan_reform
instruction: fix
- name: verify
edit: false
persona: supervisor
policy: review
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
## ピースステータス
- イテレーション: {iteration}/{max_movements}(ピース全体)
- ムーブメントイテレーション: {movement_iteration}(このムーブメントの実行回数)
- ムーブメント: verifyビルド・テスト検証
## 指示
現在の改革ステップが正常に完了したことを検証してください。
**検証チェックリスト:**
1. **ビルド**: ビルドコマンドを実行し、成功することを確認
2. **テスト**: テストスイートを実行し、全テストが通ることを確認
3. **ファイルサイズ**: 新しいファイルが300行を超えていないことを確認
4. **単一責務**: 各新ファイルが明確な単一の目的を持つことを確認
5. **インポート整合性**: すべてのインポートが正しく更新されていることを確認
**レポートフォーマット:**
```markdown
# 検証結果
## 結果: PASS / FAIL
| チェック項目 | 状態 | 詳細 |
|------------|------|------|
| ビルド | PASS/FAIL | {出力サマリー} |
| テスト | PASS/FAIL | {N passed, N failed} |
| ファイルサイズ | PASS/FAIL | {300行超のファイルの有無} |
| 単一責務 | PASS/FAIL | {評価} |
| インポート整合性 | PASS/FAIL | {壊れたインポートの有無} |
## 問題点FAILの場合
1. {問題の説明}
```
rules:
- condition: すべての検証に合格
next: next_target
- condition: 検証に失敗
next: fix
output_contracts:
report:
- name: 06-verification.md
format: validation
- name: next_target
edit: false
persona: planner
knowledge: architecture
allowed_tools:
- Read
- Glob
- Grep
- Bash
- WebSearch
- WebFetch
instruction_template: |
## ピースステータス
- イテレーション: {iteration}/{max_movements}(ピース全体)
- ムーブメントイテレーション: {movement_iteration}(このムーブメントの実行回数)
- ムーブメント: next_target進捗確認と次ターゲット選択
## 改革計画
{report:01-reform-plan.md}
## 最新の検証結果
{previous_response}
## 指示
構造改革の進捗を評価し、次のアクションを決定してください。
**手順:**
1. 改革計画を確認し、完了したターゲットを特定
2. 現在のコードベースの状態を計画と照合
3. 残りの改革ターゲットがあるか判断
**出力フォーマット:**
```markdown
# 改革進捗
## 完了ターゲット
| # | ターゲット | 状態 |
|---|----------|------|
| 1 | {ファイル} | 完了 |
| 2 | {ファイル} | 完了 |
## 残りターゲット
| # | ターゲット | 優先度 |
|---|----------|-------|
| 3 | {ファイル} | 次 |
| 4 | {ファイル} | 保留 |
## 次のアクション
- **ターゲット**: {次に改革するファイル}
- **計画**: {分割の概要}
## 全体進捗
{N}/{合計}ターゲット完了。残りの推定イテレーション数: {N}
```
rules:
- condition: まだ改革ターゲットが残っている
next: implement
- condition: すべての改革ターゲットが完了
next: COMPLETE
output_contracts:
report:
- name: 07-progress.md