分析 Playbook とフロー構成

Minara は 2026 年 5 月に独立した Scenario Registry を廃止しました。要求のルーティング、分析指針、学習した投資ルールは別々のシステムが担当します。一つの巨大なシナリオカタログをボトルネックにせず、それぞれを独立して進化させられます。

現在のモデル

スキルが要求ルーティングを担う

スキルは、何ができるか、いつ表示されるか、どのツールを公開できるかを記述します。レジストリは直下の SKILL.md パッケージを読み、満たされない環境要件を除外し、ルーターへ小さなカタログを渡します。有効な SkillSession が、そのターンへ入る指針とツールを決めます。

通常のルーティングは機能の近くに置かれます。新しいユーザー要求を扱う場合、一般にはスキルの説明、参照、ツールを改善します。中央のシナリオ定義は不要です。

Institution Playbook が分析内容を担う

Institution Playbook は、安定した名前を持つ調査指針です。一つの役割が、株式、デジタル資産、指数、コモディティなどに応じて別の Playbook を受け取れます。roles.ts が組み込み役割を Playbook ID へ対応させ、テストがすべての参照を確認します。

Playbook は集める証拠、意見の不一致を評価する方法、ライブデータが不完全な場合の進め方を示します。再利用するしきい値は {{methodology:...|default:...}} から取得します。共通の安全と引用規則は共有システムプロンプトに残します。

Roundtable パイプラインが協働を担う

Roundtable Builder は五つのフェーズを組み合わせます。

1. context が制約と過去の判断を明確にします。
2. parallel では独立した専門家が互いに引きずられず証拠を集めます。
3. debate が複数ラウンドの明示的な反論を行います。
4. synthesis では一人の管理者が記録を統合します。
5. final が判断と監視計画を作ります。

パイプラインはフェーズ順、Agent、プロンプト、スキル、反復制限、予算を保存します。検証では ID の一意性、debate に二人以上の Agent、synthesis と final に一人の管理者、末尾に一つだけの final を求めます。実行時にパイプラインのスナップショットを保存するため、後の編集は過去を書き換えません。

利用者はリポジトリを変更せずに自分の Roundtable を作成して保存できます。組み込み Agent、フェーズ、Roundtable テンプレートは builder-templates.ts にあり、レビュー済みの出発点になります。

Deep Research は独自の報告契約を保つ

Deep Research は、理解、計画、収集、分析、可視化、執筆からなる固定の六段階を使います。トピック固有の指針は references/scenarios.md にあります。参照が情報源と統合方法を形作り、スキルが進捗表示と最終成果物を一貫させます。

メソドロジーは独立性を保つ

メソドロジーは証拠、適用範囲、除外条件、監査可能なライフサイクルを持つ独立した投資ルールです。Playbook は昇格済みのルールをプレースホルダーまたは methodology_lookup から利用できますが、信頼度と結果履歴は所有しません。

この分離により、有効なルールを一つのフローから解放できます。昇格条件を満たしていない学習ルールが Institution のプロンプトへ入ることも防ぎます。

貢献者向けガイド

• スキルの追加
• 分析 Playbook の追加
• メソドロジーの追加
• Institution Mode