autoresearch

Autoresearch — 自律的な目標指向型反復

安全性の不変条件（すべてのサブコマンド）

• 明示的なユーザー承認なしに、プッシュ、公開、デプロイを行いません。
• デフォルトでは上限が設定されています。Iterations: unlimited で上書きできます。
• すべての結果は autoresearch/{subcommand}-{YYMMDD}-{HHMM}/ ディレクトリに記録されます。
• チェーンの引き継ぎには handoff.json を使用します。Evals は *-results.tsv を読み込みます。

ディスパッチ（単独の $autoresearch）

呼び出しを次の順序で解析します。

条件	モード
Metric: または Verify: がある	Classic — 既存のメトリクスループを変更せずに実行
自由形式の自然言語による目標があり、メトリクス／検証がない	Orchestrator — Orchestrator セクションを参照
何もない	Setup wizard — 対話形式の設定ビルダー
--classic フラグ	目標のテキストにかかわらず Classic を強制
--auto フラグ	目標のテキストにかかわらず Orchestrator を強制

呼び出しのたびに、バナー [autoresearch] mode: classic | orchestrator | wizard を表示します。

サブコマンド

コマンド	内容	デフォルトの反復回数
$autoresearch	メトリクスに対して反復：変更 → 検証 → 採用／破棄	25
$autoresearch plan	目標を、検証済みの Scope、Metric、Verify 設定に変換	N/A
$autoresearch debug	バグを特定：仮説を立てる → テストする → 反証する → 繰り返す	15
$autoresearch fix	エラーがゼロになるまで、1つずつ解消	20
$autoresearch security	レッドチームのペルソナを用いて STRIDE + OWASP 監査を実施	15
$autoresearch ship	8つのフェーズでリリース：チェックリスト → ドライラン → デプロイ → 検証	N/A
$autoresearch scenario	12の観点でエッジケースを生成	20
$autoresearch predict	実装前に5人の専門家ペルソナが議論	N/A
$autoresearch learn	コードベースを調査 → ドキュメントまたは Wiki を生成 → 検証 → 修正を繰り返す	10
$autoresearch reason	盲検の判定者を交えた敵対的な議論を、収束するまで実施	8
$autoresearch probe	8つのペルソナが要件を飽和するまで問いただす	15
$autoresearch improve	ICP の課題を調査し、改善点を発見して PRD を生成	15
$autoresearch evals	反復結果を分析：傾向、停滞、リグレッション	N/A
$autoresearch regression	リグレッション安定性ゲート：ベースラインと候補を比較し、STABLE／UNSTABLE を判定	N/A

共通フラグ

フラグ	適用対象	目的
Iterations: N	すべてのループ	反復回数を設定
Iterations: unlimited	すべてのループ	上限なしを明示的に有効化
--evals	すべてのループ	ループ途中のチェックポイントと最終サマリー
--evals-interval N	すべてのループ	チェックポイントの頻度を上書き
--chain <targets>	すべて	完了後に順次引き継ぎ
--<subcommand>	すべて	--chain <subcommand> の短縮形
--dry-run	Orchestrator	導出した設定と予定されたパイプラインを表示。実行はしません
--max-cycles N	Orchestrator	オーケストレーションサイクルの上限（デフォルトは50）
--classic	単独の $autoresearch	Classic のメトリクスループモードを強制
--auto	単独の $autoresearch	Orchestrator モードを強制

Orchestrator

Metric:／Verify: を指定せずに平易な言葉で目標を与えると有効になります。目標を Goal archetype に分類します。アーキタイプの表とルーターの判定表については、references/orchestrator-routing.md を参照してください。

以下の scripts/... パスはすべて、呼び出し元の作業ディレクトリではなく、このインストール済みスキルディレクトリを基準に解決してください。

アーキタイプに応じた2つのモード：

• Orchestration loop — 述語を持つアーキタイプ（ship-ready、optimize-metric、fix-broken、harden、build-feature、explore）。目標には機械的に判定可能な成功述語があります。ループはその述語を満たすまで実行されます。
• Single-pass dispatch — 主観的／終端的なアーキタイプ（document、what-to-build、decide-design）。適切なサブコマンド（learn／improve／reason）に一度だけルーティングし、サブコマンドが自ら終了した後に結果を報告します。ループ、Plateau、リリースゲートはありません。

オーケストレーションループのステップ

scripts/orchestrate.sh によって実行されます（決定論的な境界であり、すべてのルーティングロジックはここにあります）。公開されているサブコマンド：classify、next-hop、units、plateau、screen-cmd、verdict、validate-state、screen-state-predicate。

1. 分類 — scripts/orchestrate.sh classify "<goal>" → アーキタイプのラベルとモード。
2. 述語の導出 — plan のロジックを再利用して、具体的な成功述語を作成します：正確なシェルコマンドと期待される出力。optimize-metric の場合は、完全な plan／ウィザードによる導出を内部で実行します。
3. 確認 — 次の内容を表示する request_user_input を1回だけ実行します：アーキタイプ、モード、具体的な述語（コマンドと期待される出力）、終了時の選択肢（検証時点で停止するか、出荷まで続行するか）。分類の誤りは実行中ではなく、ここで検出されます。
4. ラウンド0のドライラン — 述語のコマンドが実行され、値を返すことを確認します。導出されたすべてのコマンドを screen-cmd で安全性チェックし、予測されるサイクル数を表示します。--dry-run の場合はここで停止します。
5. 述語が満たされるまでループします： a. 安価なシグナル（直近の handoff.json、リグレッション判定、エラー数）と、影響を受けるテストの検証によって状態を評価します。 b. scripts/orchestrate.sh next-hop orchestrator-state.json → 次のサブコマンド。 c. サブコマンドを実行します（独自の制限付き内部ループを使用）。 d. 各ホップの結果を ∈ {進行、変化なし、失敗、ブロック} として記録します。 e. ホップの handoff.json を orchestrator-state.json に取り込みます。 f. scripts/orchestrate.sh units → 残りユニット数を再計算します。
6. 停止条件（各ホップの後に確認）：
   • 述語を満たした場合 → シップゲート（パイプラインに ship が含まれる場合のみ）、それ以外は CONVERGED。
   • scripts/orchestrate.sh plateau orchestrator-state.json → true → 停止し、PLATEAU を報告します。
   • サイクル数が上限を超えた場合（既定値は50、--max-cycles N で変更可能）→ 停止し、CEILING を報告します。
   • 代替ルートがない状態で、ホップの結果が blocked／failed の場合 → チェックポイントを作成し、停止して BLOCKED を報告します。

オーケストレーターの状態

orchestrator-state.json — オーケストレーターが所有する追加型の状態です。次の情報を追跡します：目標、アーキタイプ、述語、終了時の選択肢、units_remaining の履歴、サイクル数、結果を含むホップごとのパイプラインログ、現在の最良候補。各ホップの handoff.json は変更されず（単一ホップのブリッジ）、オーケストレーターが読み取って取り込みます。所有者が明確に分かれた2つの状態オブジェクトであり、重複はありません。

オーケストレーターの安全性不変条件

• ship／deploy／push を自動承認しません。 オーケストレーターが ship に --auto を渡すことはありません。deploy には常に明示的なユーザー承認が必要です。
• データ移行は固定されたDB URL許可リストで制限されます。 regression の許可リストを再利用します。ホストは localhost／127.0.0.1／コンテナのホスト名であるか、データベース名が _test／_ci のサフィックスを含む必要があります。部分文字列の単純な一致は対象になりません。それ以外はすべて拒否されます。
• 導出されたすべてのコマンドに screen-cmd を適用します — ループ開始前と、再開時に永続化された状態ファイルから読み取るすべてのコマンドに対して実行します。永続化されたコマンドは決して信頼せず、再開時には screen-state-predicate で固定された述語を再スクリーニングし、refuse の場合は拒否します。
• ループ中に未スクリーニングのコマンドを実行しません。 自律ループが screen-cmd を回避する新しいシェルコマンドを導入することはできません。
• 述語は固定され、再導出されません。 ラウンド0では、導出された成功述語をそのまま orchestrator-state.json に書き込みます。すべてのサイクルと再開時に同じ文字列を再利用するため、実行ごとに「完了」を再現できます。
• ルーティング前に台帳を検証します。 validate-state が orchestrator-state.json を検証します（必須フィールドと大まかな型）。形式が不正な台帳をルーティングの根拠として信頼することはありません。
• 収束前に独立した検証を行います。 影響の大きい変更が作業中のシグナルに基づいて受け入れられると、pending_verify が設定されます。next-hop は DONE または ship の前に verify ホップ（ホールドアウト／敵対的チェック）へルーティングします。verify ホップが ship を自動承認することはありません。
• ユニット数が不明なサイクルはプラトーカウンターから除外します。 units が unknown を返すサイクル（例：ランナーのクラッシュ）は、進捗ゼロとしてカウントしません。unknown が繰り返された場合は BLOCKED にルーティングします。