decomplex

Decomplex

厳守事項

• モードは必ず1つだけにします：
  • 予防 — 未実装の計画／設計／依存関係／保護策
  • 監査 — 既存のソース／テスト／設定／依存関係／アーキテクチャ
  • 指摘事項のトリアージ — 複雑さを増す可能性がある、提示済みの推奨事項
• レビューの前に、以下を確定します：
  • 対象
  • 権限
  • 必須の振る舞い
  • スコープ
• 曖昧さによってこれらが変わる場合に限り、質問します。
• 対象は変更しません。
• 契約を確定する前に、パスと決定権限について ADR conventions を読みます。
• 明示的に別の出力パスが指定されていない限り、書き込むのは adrs/work/<change>-decomplex.md 1つだけです。
• レビュー対象の成果物は、修正を依頼された場合でも編集しません。
• 書き込みなし／チャットのみの明示的な依頼には、チャットで指摘事項を提示して対応します。依頼されたファイルに書き込めない場合は、その制限を明示します。保存したと主張してはいけません。
• 複雑さのトレードオフのみを扱います。
• 欠陥／セキュリティ／パフォーマンス／計画への準拠に関する問題は、担当ワークフロー（例：code-review）に回します。
• 単純さは、行数／ヘルパー／依存関係の少なさと同義ではありません。
• 根拠のある以下の要素を維持します：
  • 信頼境界
  • 不変条件
  • 互換性
  • ライフサイクルのクリーンアップ
  • 運用上のニーズ
• 指摘事項は助言です。
• 対応方針の決定／実装／エスカレーションは利用者が行います。
• 「潜在的な複雑さに関する指摘事項はありません」も有効な結論です。
• 利用者は以下を必ず守る必要があります：
  • すべての項目について対応方針を決定する
  • 自動的に実装しない
  • 判断に迷う場合は、ユーザーに確認する

受付ゲート（すべて必須）

1. 具体的な概念上／保守上／運用上の負担がある
2. 現在のニーズに対する妥当な根拠がない、または不十分である
3. 実際に発生しうる、到達可能な実用上のコストがある
4. 具体的かつ最小限の、より単純な代替案がある
5. 必須の振る舞いが維持される
6. 単純化による価値と回帰コストが釣り合っている
7. 明示的な例外／境界の確認が行われている

根拠：

• Confirmed または Supported のみ

ゲートを通過しない場合：

• 範囲を限定して検証する
• ユーザーに質問する
• または省略する

以下を理由に指摘してはいけません：

• ヘルパーの数
• 重複があることだけ
• 新規性
• 仮定上の規模
• スタイルだけ

優先順位：

1. 削除
2. 直接利用
3. ローカルなロジック／ヘルパー
4. 既存の共有抽象化
5. 新しい抽象化

手順

1. 契約
   • ADR の規約と、関連する承認済み決定を読む
   • モード
   • 対象
   • 権限
   • スコープ
   • 振る舞い
   • レポートのパス
   • 制約
   • ゲートの確認に必要な場合に限り、呼び出し元／テスト／設定／履歴を調査する
2. 候補の検討前
   • references/complexity-gates.md を最後まで読む
   • 文脈上のシグナルとして扱い、ノルマを満たすためのチェックリストにはしない
3. 評価
   • 各候補についてゲート全体を適用する
   • 期待される単純化の価値が高いものから並べる
4. 推奨
   • Act | Validate | Ask user のみを使用する
   • アクションを実行しない
   • トリアージモードでは、提示されたすべての ID を維持する
   • トリアージの対応方針：Act | Validate | Ask user | No action
5. 書き込み前
   • assets/decomplex-review-template.md を最後まで読む
   • レポートを1つだけ書くか、書き込みなしの制約がある場合はチャットで返す
   • テンプレートのガイダンス／空のセクションを取り除く
   • 調査済み／未調査の範囲と制限事項を記載する
6. 検証
   • 依頼されたレポートが存在すること、またはチャットのみでの提供／制限が明示されていることを確認する
   • 採用した項目がゲートを通過していることを確認する
   • トリアージのすべての ID が考慮されていることを確認する
   • 対象ファイルが変更されていないことを確認する