confess

告白

エージェントが把握していながら、まだ伝えていない可能性のある問題を、正直に発見し、開示するための体系的な自己監査スキルです。特に、報酬ハッキングを認め、隠し立てせずに打ち明けるのに役立ちます。

使用するタイミング

• 実装作業を完了した後
• 何かが未完了だと感じたとき
• タスクを「完了」とする前
• ユーザーから「見落としはないか？」または「告白して」と尋ねられたとき

告白のカテゴリ

1. 未完了の作業

関連ファイルの中に、変更が必要なものがないか検索します。

• grep を使って、変更したコードへの参照を探します
• 更新が必要なテストを確認します
• 変更後の動作に言及しているドキュメントを探します

2. 未検証の前提

実際に何を検証したのか、正直に伝えます。

• コードを実行しましたか、それともビルドしただけですか？
• エラー時の経路をテストしましたか？
• 考慮していないエッジケースは何ですか？

3. パターン違反

既存のコードベースと比較します。

• glob で類似の実装を探します
• 新しいコードは既存のパターンに沿っていますか？
• フレームワークのベストプラクティスを無視していませんか？

4. 隠れた知識

気づいていたのに伝えていなかったことを明かします。

• 気づいたものの、指摘しなかった潜在的な問題
• アプローチへの懸念
• 伝えずに行った近道
• 生じた技術的負債

5. クリーンアップの負債

孤立したコードがないか確認します。

• 削除すべきデッドコード
• 未使用のインポート／依存関係
• 孤立したファイル／ルート

敵対的な姿勢

「何を見落としましたか？」とは尋ねないでください。その質問は、正当化を招きます。

代わりに、懐疑的な姿勢を取りましょう。何かを見落としていると仮定し、それを証明するために調べます。自分の「完了」という主張を覆すことが、あなたの役目です。懐疑的な姿勢では、徹底的に調べることではなく、誤って問題なしと判断することがペナルティの対象になります。

完了前に、次のチェックリストを確認します。

• 変更したすべてのシンボルを grep で検索しましたか？呼び出し元はすべて更新されていますか？
• テストスイートは変更した経路を実際にテストしていますか、それともインポートしているだけですか？
• ドキュメントに記載していない新しいインポート／依存関係を追加していませんか？
• 気づいていたのに、打ち明けにくくて伝えなかったことはありませんか？
• 誰かがあなたの直近のコミットだけを取り消したら、何が壊れますか？

ワークフロー

1. コンテキストを収集する

   # What files were recently modified?
   git diff --name-only HEAD~1
   
   # What functions/exports changed?
   git diff HEAD~1 --stat
   

2. 参照を検索する

   # Find all references to modified code
   grep -r "functionName" --include="*.ts" --include="*.tsx"
   

3. パターンを比較する

   • コードベース内で類似のファイルを探します
   • 実装方法を比較します
   • 一貫していない点を記録します

4. 検証状況を確認する

   • 実際にテストした内容を列挙します
   • 動作すると仮定した内容を列挙します
   • 手動での検証が必要な内容を列挙します

5. すべてを開示する 告白は次の形式にします。

   ## My Confessions
   
   ### Incomplete Work
   - [specific issue]
   
   ### Untested
   - [what wasn't verified]
   
   ### Pattern Issues
   - [inconsistencies found]
   
   ### Hidden Concerns
   - [things I noticed but didn't mention]
   
   ### Cleanup Needed
   - [dead code, orphaned files]
   

主な原則

1. 敵対的な姿勢を意図的に取る — 自分を安心させるのではなく、自分の誤りを見つけようとします
2. 最悪の事態を想定する — 未完了の作業、未テストの内容、隠された問題があると考えます
3. ツールを活用する - 記憶に頼らず、grep/glob を使います
4. 体系的に確認する - 毎回、すべてのカテゴリを確認します
5. 正直である - 確信がなければ、そう伝えます
6. 実行可能である - 告白ごとに、修正案を提示します

出力例

OAuth のエラー処理を実装した後：

私の告白

未完了の作業

• auth-config.ts を変更しましたが、oauth2/authorize/page.tsx:173 はまだ /error/oauth にリダイレクトします
• proxy.ts:67 も古いエラールートを参照しています
• lib/oauth-errors.ts の redirectToErrorPage() 関数も、まだ古いパターンを使っています

未テストの内容

• bun run build を実行しただけで、実際の OAuth エラーフローはテストしていません
• 実際のエラーパラメーターを使って、ホームページにエラーが表示されるか確認していません

パターンに関する問題

• ホームページでは useSearchParams を直接使っていますが、他のページでは Suspense でラップしたコンポーネントに切り出しています
• 正しいパターンの例：oauth2/authorize/page.tsx、device/page.tsx

隠れた懸念

• /error/[type] のエラーページはよく設計されており、現在も積極的に使われています
• onAPIError の削除は誤った判断だった可能性があります

必要なクリーンアップ

• ホームページのエラー処理に完全移行するか、/error/oauth ルートを維持するか、判断が必要です