Institution Mode: オペレーターリファレンス

minara_institution_analyze は、Minara の標準委員会フロー、または Web UI でセッションに保存した Roundtable を実行します。本ページは 標準アナリスト経路が使う低レベルのリカバリと資産解決を扱います。 フェーズ構成、Agent 設定、テンプレート、変更不能な実行スナップ ショットは Institution Mode を参照してください。

標準フローには並列分析、強気と弱気の討論、調査統合、取引計画、 リスク討論、最終ポートフォリオ判断があります。カスタム Roundtable はこの構成を置き換えても、同じ読み取り専用の安全境界を保ちます。

パイプラインのタイムアウトとベンチマーク設定は 環境変数: Institution Mode を参照してください。

Roundtable の状態とスナップショット

Builder は Institution セッションごとに有効なパイプラインを保存します。 保存時に期待リビジョンを確認するため、別のブラウザウィンドウが新しい 変更を黙って上書きすることはなく、競合が返されます。保存済みパイプライン がない場合、ゲートウェイは最新実行スナップショット、次に組み込み標準を 使います。

Agent、フェーズ、Roundtable テンプレートは別々に保存され、組み込み テンプレートは変更できません。実行開始時には、フェーズ結果、Agent 使用量、 最終状態、レポートファイルを含む完全なパイプラインが変更不能なスナップ ショットへコピーされます。関連 API は次のとおりです。

• セッションパイプラインを取得
• セッションパイプラインを保存
• セッション実行を一覧表示
• 実行スナップショットを取得
• Agent テンプレートを一覧表示
• Roundtable テンプレートを一覧表示
• 利用可能な Institution スキルを一覧表示

アナリストリカバリ : synthesis-and-parse

各 Phase-1 アナリスト slot はまず自由な tool 呼び出しループで モデルを動かします（submit_analyst_report は常にロールの データツールと並べて公開されます）。メインループが本物の non-stub レポートを提出した場合、slot は捕捉した tool_outputs[] を添付してそのまま返します。

メインループが提出しなかった（ターン上限到達、モデルが散文を 書いて提出を忘れた）、または空・プレースホルダー引数を提出 した場合、オーケストレーターは synthesis ターンを 1 回 だけ 実行します。

• ツールも tool_choice も付けない。thinking は有効 : これは 以前 tool_choice: { type: "tool" } 下で失敗していた呼び出し です。Anthropic がその組み合わせを拒否するため、モデルが 引数を埋める推論余地がゼロになるからです。

• ユーザーメッセージは厳密な 3 セクション散文フォーマットを 要求します:

  HEADLINE: <1 文の結論>
  
  KEY FINDINGS:
  - <finding 1, ツール名 + 具体的な数値を引用>
  - <finding 2, ...>
  
  CONFIDENCE: <0.0 から 1.0 の数値>

オーケストレーターは parseSynthesisProseToReport でサーバー サイドで散文を直接 AnalystReport にパースします。パーサーは bullet スタイルの混在、セクションマーカー周りの markdown 強調、レンジ外の confidence（[0, 1] にクランプ）に寛容です。

synthesis ターンの散文が空、フォーマット崩壊、または全 bullet がプレースホルダー形状（"tried X: ok"）の場合、 オーケストレーターは buildSubagentSummaryReport : 普遍的な 「常に使えるものを出す」ビルダー : にフォールバックします。 2 分岐：

一部 tool が成功した場合、レポートは捕捉したツールデータを 引用（1 ツールあたり 1 bullet、preview から派生）するので 下流フェーズは何が返ってきたか見えます。全て失敗した場合は 試行した tool を列挙し、最後にロールのドメインデフォルト推論を 1 文で締めます（ロールごとに 1 文、roles.ts のロール定義 近くに定義）。

どちらの分岐でも slot の ok は true です : 旧 "data-gap" コンセプトは退役しました。各 Phase 1 slot は常にメイン エージェントに使えるサマリーを出すので、Phase 2-6 は常に 実行されます。

Tool outputs : 捕捉した戻り値の出口

各 AnalystReport はオプションの tool_outputs[] を保持し、 slot の会話からオーケストレーターが埋めます。tool 呼び出し ごとに 1 エントリ:

{
  tool: string;           // ツール名
  ok: boolean;            // 成功した呼び出しなら true
  preview: string;        // 成功: 切り詰められた JSON / テキスト（~1500 文字）
                          // 失敗: エラーメッセージ文字列
  args_summary?: string;  // 呼び出し入力の 1 行要約
  error_code?: string;    // 構造化された失敗カテゴリ（あれば）
}

成功した呼び出しは pretty-print された JSON プレビューを 携えます。失敗した呼び出しは失敗理由をそのまま preview に 入れるので、オペレーターはなぜ呼び出しがデータを返さなかった かを直接見られます（返さなかったという事実だけではなく）。 web-ui の PersonaOutputRenderer がこれを構造化アウトプット ポップアップ内の "Tool outputs" セクションとしてレンダリングし、 各行はクリックで展開できます。

正規化アセット preflight

Phase 1 ディスパッチ前、classifyAsset(ticker) === "unknown" （または INSTITUTION_FORCE_RESOLVER_PREFLIGHT=true）の場合、 オーケストレーターはサーバーサイド preflight を実行します:

1. SQLite キャッシュ（canonical_asset_cache テーブル）を確認。
2. キャッシュミスまたは期限切れの場合: 並列で CoinGecko / CMC / DexScreener を引き、chain+contract アイデンティティ (CAIP-19 風の evm / native / solana / cosmos / polkadot / equity の discriminated union) に正規化。 outcome 別 TTL で永続化。
3. outcome ルーティング:
   • resolved (一意な chain+contract): meta.resolved_ticker を強化、アナリストは preamble で正規アイデンティティを 確認できる。
   • multi (マルチチェーン展開): 同上、ただし候補配列が 曖昧性解消コンテキストに渡る。
   • ambiguous (provider 間で食い違い): 中央集権的な曖昧性 解消イベントを発火（並列 4 つの "どのトークン?" プロンプト ではなく）。
   • none: Phase 1 前に中止、LLM 呼び出しゼロ。これが オーケストレーターが現在唯一発する abort kind です。

正規アイデンティティは chain+contract であり CoinGecko id ではありません。CoinGecko の内部 id は彼らのキュレーションに 依存する中央集権インデックスなので、それを bootstrap 出力に 使うとエージェントを単一 provider の世界観に縛り付けてしまい ます。on-chain クエリを受け取る下流ツールは CAIP-19 を直接 受け付けます。provider 固有ツール（CoinGecko の価格チャート など）は正規アイデンティティが確定した 後 に sources から 自分の id を読みます。

outcome 別 TTL

キャッシュは outcome ごとに異なる TTL を使います。outcome の 鮮度の劣化速度が違うためです:

クラスごとの TTL は CANONICAL_ASSET_CACHE_TTL_*_DAYS 環境 変数で調整（env-vars リファレンス参照）。

ライブアグリゲーターが失敗した場合（provider ダウン、レート リミット）、CANONICAL_ASSET_CACHE_FALLBACK_TO_EXPIRED=true （デフォルト）は from_expired_fallback: true でタグ付け された期限切れキャッシュを返します。デプロイがいかなる ドリフトも許容できないなら false に設定。

未登録 ticker の追加

エージェントは新しい ticker に初めて遭遇したとき、 ticker → 正規アイデンティティのマッピングを学習します。新トー クンのためのコードデプロイは不要。2 つの経路:

1. ライブ解決: 次の /institution <ticker> 呼び出しで preflight が走り、結果がキャッシュされ、以降すべてのロール が正規アイデンティティを見られます。
2. オペレーター上書き: CoinGecko / CMC / DexScreener に トークンがない場合（例: 新規リリース）、オペレーターは 正規アイデンティティを直接 pin できます。UI: 中止バナーに コントラクトアドレスフォーム。CLI: minara assets pin <ticker> --chain <chain> --contract <0x...> (デプロイで assets CLI が有効な場合)。

methodology-store の TICKER_TO_CLASS テーブルは存続して いますが用途が変わりました（リスク/ポートフォリオコード 向けの asset-class ルックアップ）。正規リゾルバーは asset_class フィールドが新情報を提供するときに書き戻し ますが、TICKER_TO_CLASS は正規アイデンティティの真理源では なくなりました。

実運用でのリカバリ検査

institution_role_outputs.data_gap カラムは data-gap コン セプト退役前に書き込まれたレガシー行のためにスキーマに残って います。新規書き込みは常に 0 です。メトリクス集計器 InstitutionStore.getAnalystStubMetrics はヒストリカル レポーティング向けに今もこれを読みますが、現行リカバリパス では負荷を持ちません。

run 別監査:

# run のすべてのアナリスト行（legacy の retry_count + data_gap 含む）。
minara learning methodology cases --run-id <run_id>