バックテストフィードバックループ

バックテストフィードバックループ (Sprint 6 — online outcome filler)

N 時間前に実行された取引の P&L 結果を計算し、EvaluationLoop + MethodologyStore に戻して、Wilson-LB の卒業機構が実際の勝敗シグナルを蓄積できるようにする定期ジョブです。デフォルトでは完全に無効(dark)です (BACKTEST_ENABLED=false)。過去の取引を再生したり過去の決定を再実行したりはせず、実際にセッション内で実行された行のみを評価します。ロールアウトプロトコル: 1. BACKTEST_ENABLED=true + BACKTEST_DRY_RUN=true で 1 週間 2. shadow_runs WHERE facet='backtest_outcome' を検査 3. 結果が問題なさそうなら BACKTEST_DRY_RUN=false に切り替え 4. 最後に LEARNING_RECORD_USAGE=true に切り替え — Wilson カウンターの更新を有効化

`BACKTEST_ENABLED`

ランナー + スケジューラのマスタースイッチです。 false（デフォルト）= ランナーは一切構築されず、cron タイマーも登録されません。実行時コストはゼロです。 true = ランナーが構築され、スケジューラは BACKTEST_CRON_HOURS 時間ごとに発火します。下記の DRY_RUN は引き続き尊重されます。

形式: true / false.
設定の所在: 設定 → 環境設定（schema キー）

`BACKTEST_DRY_RUN`

true の場合、ランナーは結果を計算して shadow_runs(facet='backtest_outcome') に出力しますが、updateTradeOutcome や recordUsage は呼び出しません。少なくとも 1 回の完全な cron サイクルにわたって shadow 行をスポットチェックしてから、false に切り替えてください。

形式: true / false.
設定の所在: ユーザー向け設定ではありません

`BACKTEST_MIN_TRADE_AGE_MS`

トレードがバックテスト評価の対象となるまでの最小経過時間（ms）です。結果が形になるには時間が必要で、5 分のホライズンではノイズにすぎません。ReviewEngine の minTradeAgeForEvalMs にそのまま渡されます。デフォルトは 86400000（24h）です。

形式: 正の整数（ms）。
設定の所在: ユーザー向け設定ではありません

`BACKTEST_OUTCOME_HORIZON_HOURS`

トレードの created_at から何時間後にアウトカム価格をサンプリングするかを指定します。+5% in 24h なら 24 です。出力されるアウトカム文字列にも反映されるため、評価器はウィンドウ長を認識できます。Sprint 6 では単一のグローバル値です（トレードタイプ別のチューニングは TODOS #9 で追跡）。デフォルトは 24 です。

形式: 正の整数（時間）。
設定の所在: ユーザー向け設定ではありません

`BACKTEST_BATCH_LIMIT`

ランナーが 1 回の発火で取得する保留中の行の最大数です。ReviewEngine の maxEvalsPerBatch にそのまま渡されます。1 回あたりの LLM 支出を抑えるには下げ、保留キューが常に溜まっている場合は上げてください。デフォルトは 20 です。

形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`BACKTEST_CRON_HOURS`

スケジューラの間隔です。ランナーは setInterval(… * 3600_000) で呼び出され、タイマーは unref() を使うため、それ単独でプロセスを生かし続けることはありません。浮動小数点数を指定でき、0.017（1 分）未満の値は切り上げられます。デフォルトは 24 です。

形式: 正の数（時間）。
設定の所在: ユーザー向け設定ではありません

`BACKTEST_PRICE_PROVIDER`

デバッグ用に過去価格ソースを 1 つに固定します。auto はアセットクラスでルーティングします（crypto → Hyperliquid → Yahoo の -USD フォールバック、stock/unknown → Yahoo、stablecoin → 1.0）。Yahoo のシンボル正規化を疑う場合は hyperliquid に、Hyperliquid がレート制限されている場合は yahoo に固定してください。

形式: auto / hyperliquid / yahoo.
設定の所在: ユーザー向け設定ではありません

`BACKTEST_MAX_COST_USD_PER_RUN`

呼び出しごとのハードなコスト上限です。ランナーは evaluatePacked の前後で BudgetTracker.getDailySpend("learning") のスナップショットを取り、その差分がこの値を超えると、実行は status=stopped_budget を返します。0 で上限を無効化します。デフォルトは 2.00 です。

Stackable: BudgetTracker の既存の日次/月次上限は引き続き適用されます。
形式: 非負の浮動小数点数（USD）。
設定の所在: ユーザー向け設定ではありません

`LEARNING_RECORD_USAGE`

true の場合、EvaluationLoop は評価済みトレードごとに trade_history.methodology_ids をチェックします。Phase 1.2a の重複排除 (codex R1 P1) は、いずれかの方法論が紐づいたトレードに対する recordUsage 呼び出しを意図的に抑制します。それらのトレードは代わりに case-attribution.ts によって Wilson 学習されます。現時点で紐づけのないトレードも、この経路からは Wilson シグナルを生成しません。Wilson の更新はもっぱら case-attribution を通じて流れます。

したがってこの環境変数は現在、学習ゲートではなく
可観測性ゲートです。true に切り替えると、紐づけられた
トレードごとに wilson_dedup_skip のログ行が出力され、運用者は本番環境で
重複排除が発火していることを確認できます。従来の「評価済みトレードすべてで
一律に recordUsage する」挙動はなくなりました。
形式: true / false.
設定の所在: 設定 → 環境設定（schema キー）

`LEARNING_TUNING_ENABLED`

src/learning/methodology-store.ts 内の LEARNING_CONFIG のより良い値を探索する、オフラインのベイズ最適化チューニングハーネスのマスターゲートです。このハーネスはオフラインツール（minara learning replay + tools/tuning/ 内の Python BO 経由で実行）であり、リクエストパスの一部には決してなりません。本番で replay CLI が誤って呼び出されるのを防ぐために存在します。

使用箇所: src/gateway/learning-cli.ts — replay サブコマンドは、
これが true でない場合 { skipped: "tuning_disabled" } で
ショートサーキットします。
Exception: minara learning stats は純粋な読み取り専用で（データ準備状況の
レポートのため trade_history + methodologies に対する SQL SELECT）、
このゲートに関係なく実行されます。運用者は、チューニング実行を
正当化できるだけの Sprint 6 データが蓄積されたかどうかを継続的に
把握する必要があります（目標: ≥100 件の評価済みトレードで ≥20 個のユニークな方法論
id をカバー）。
Rollout: これは (a) Sprint 6 のロールアウトが完了し
（LEARNING_RECORD_USAGE=true）、(b) minara learning stats が
READY_FOR_BO=true を報告し、(c) 人間の運用者が明示的に
チューニングセッションを開始するまで false のままです。本番で false のまま
にしておくのがデフォルトで安全な姿勢です。
形式: true / false.
設定の所在: ユーザー向け設定ではありません

Phase 1 — 決定キャプチャ (BUY/SELL/HOLD アドバイス)

決定キャプチャフックは、エージェントループのターン終了時に実行されます。ターンが投資アドバイスを含む場合(9 つのアドバイスシナリオのいずれかが有効、またはエージェントの応答に BUY/SELL/HOLD キーワード + ティッカーが一致するとき)、独立した要約器の LLM 呼び出しが構造化された {asset, decision, confidence, quoted_price} タプルを抽出し、 decision_history に保存します。このデータは Phase 2 のマルチホライズンバックテストと Phase 6 の方法論インスタンス BO チューニングに供給されます。要約器は常に fire-and-forget(非同期)です。ユーザーが体感するターンのレイテンシーは変わりません。失敗時はログを残し、その行を静かに破棄します。

`DECISION_CAPTURE_ENABLED`

Phase 1 キャプチャのマスタースイッチです。false（デフォルト）の場合、ターン終了フックは事前フィルタや LLM 呼び出しを一切実行せずに即座に返ります。decision_history への書き込みを開始するには true に切り替えます。いつでも安全に切り替えられます — データ移行は不要です。

使用箇所: src/learning/decision-capture/capture-hook.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: 設定 → 環境設定（schema キー）

`DECISION_SUMMARIZER_MODEL`

decision summarizer の LLM 呼び出しに使うモデルです。デフォルトはコスト効率のため Claude Haiku 4.5 を対象とします（入力 800 + 出力 200 トークンで 1 ターンあたり約 $0.002）。stats で summarizer のカバレッジ率が 70% 未満の場合は Sonnet に引き上げられます。

使用箇所: src/learning/decision-capture/summarizer.ts.
未設定時: デフォルトは claude-haiku-4-5-20251001。
形式: Anthropic のモデル id。
設定の所在: ユーザー向け設定ではありません

`DECISION_SUMMARIZER_TIMEOUT_MS`

1 回の summarizer 呼び出しに対するハードなタイムアウトです。summarizer は fire-and-forget で実行され、タイムアウト時は警告ログとともに決定を破棄し、リトライはしません。

使用箇所: src/learning/decision-capture/summarizer.ts.
未設定時: デフォルトは 15000。
形式: 正の整数（ms）。
設定の所在: ユーザー向け設定ではありません

`DECISION_CAPTURE_SYNC_MODE`

true の場合、フックから返る前に summarizer を待機します（ターンのレイテンシが増えます）。決定論的なテスト / CI 専用で、本番では false のままにすべきです。

使用箇所: src/learning/decision-capture/capture-hook.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: ユーザー向け設定ではありません

`DECISION_CAPTURE_HEURISTIC_ENABLED`

Tier 2 の正規表現による事前フィルタです。true（デフォルト）の場合、フックは、アドバイスシナリオが有効でなくても、エージェントの最終応答に BUY/SELL/HOLD キーワード + アセットのティッカーが含まれるターンもキャプチャします。キャプチャをアドバイスシナリオのターンのみに厳密に限定するには false に設定します。

使用箇所: src/learning/decision-capture/classify-capture-source.ts.
未設定時: デフォルトは true（有効）。
形式: true / false.
設定の所在: ユーザー向け設定ではありません

`DECISION_CAPTURE_UNIVERSAL_SCAN`

Tier 3 のオプトインによる全ターンスキャンです。true の場合、すべてのターンで summarizer を呼び出します（Tier 1/2 をバイパス）。診断用の A/B 実行専用で、恒常的に使うと summarizer の予算が約 4 倍になります。false のままにすることを強く推奨します。

使用箇所: src/learning/decision-capture/classify-capture-source.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: ユーザー向け設定ではありません

Phase 2 — マルチホライズン決定バックテスト

DecisionBacktestRunner は、経過時間が max_horizon(1m ホライズンの場合はデフォルト 30 日)以上の decision_history 行をスキャンし、次を埋めます: (a) HistoricalPriceProvider から取得した real_price_at_decision。ハルシネーションフラグのため agent_quoted_price と比較 (b) decision_outcomes 行 — ホライズンごとに 1 つ {1d, 3d, 1w, 1m} |agent_quoted - real|/real > HALLUCINATION_MAX_PRICE_DELTA_PCT の場合、その決定は state='skipped_halluc' とマークされ、ダウンストリームの学習から除外されます。

`DECISION_BACKTEST_ENABLED`

decision-history のマルチホライズン・バックテスト cron のマスタースイッチです。現在のリリースでは EXPERIMENTAL です。ランナーは ReasoningQualityJudge（src/learning/backtest/reasoning-quality.ts を参照）を組み込むようになり、「エージェントは HOLD と言ったが相場は上昇した」というミスが Wilson を直接更新するのに使われないようにします — そのパターンは直前の相場の動きを追いかけるよう（すなわちプロダクトチームが明確に避けたい個人投資家的な挙動を）エージェントに学習させてしまうためです。Phase 1 では、すべての決定を no_judgment と分類する no-op のデフォルトジャッジを出荷します。つまり現時点でこのフラグを true に切り替えても、decision_outcomes の行を埋めて判定の集計を出力するだけで、この経路から方法論の Wilson カウンタがインクリメントされることはありません。学習のために cron に頼る前に、Phase 2 の EvaluationProvider が本物の LLM-as-judge を実装するのを待ってください。それまでは: - false（デフォルト）: ランナーは no-op です。 - true（dry-run のみ推奨）: decision_outcomes を埋め、実行サマリで判定を集計しますが、Wilson は決して更新しません。

使用箇所: src/learning/backtest/decision-runner.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: 設定 → 環境設定（schema キー）

`METHODOLOGY_LEARNING_CRON_ENABLED`

in-process の方法論 cron オーケストレーター（sweep → 7 日間の case-attribution → synthesis）へのオプトインです。未設定（デフォルト）の場合、エージェントは自動スケジュールしません。運用者は system cron / launchctl / systemd から minara learning cron でループを進めます。true に設定すると、オーケストレーターは METHODOLOGY_LEARNING_CRON_INTERVAL_MS（デフォルト 6h）ごとに実行されます。実行済みトレードの Wilson 学習はこのゲートの下で case-attribution を通じて流れます — シグナルがノイジーにならないよう、インストールがアクティブな asset_class ごとに実ケースを 100 件以上蓄積してからオンにしてください。

使用箇所: src/app.ts + src/learning/methodology-cron.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: 設定 → 環境設定（schema キー）

`METHODOLOGY_LEARNING_CRON_INTERVAL_MS`

METHODOLOGY_LEARNING_CRON_ENABLED=true のときの cron パス間のインターバル（ミリ秒）です。デフォルトは 21600000（6 時間）です。インターバルを小さくすると、より多くのシグナルを生み出すことなく LLM ジャッジの予算をより速く消費します。

使用箇所: src/learning/methodology-cron.ts.
未設定時: デフォルトは 21600000。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_ENABLED`

apps/agent/src/learning/experimental/tuning/ 配下の実験的な方法論チューニング（BO プランナー）サブツリーへのオプトインです。Phase 1.7 でこのコードはデフォルトのエージェント起動パスから外されました。cycle-planner.ts は dry-run プランのみを出力するスタブで、BO を一切実行せず、したがって方法論を変更することもないためです。minara learning tune-methodology --dry-run でプランナーの tunability-score 出力を確認したい場合にのみ true に切り替えてください。実行系（live executor）は将来のフェーズで実装されます。

使用箇所: src/gateway/learning-cli.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: 設定 → 環境設定（schema キー）

`DECISION_REPLAY_ENABLED`

apps/agent/src/learning/experimental/replay/ 配下の実験的な decision-replay サブツリーへのオプトインです。現在の decision-replay.ts の実装は明示的に PLACEHOLDER です（ファイルヘッダーを参照）。単純な加重平均の報酬を返すだけで、しきい値を考慮したリプレイは行いません。その出力を方法論の調整の根拠に頼らないでください。 Phase 6 以降の作業でこのプレースホルダは本物のエンジンに置き換えられます。

使用箇所: src/gateway/learning-cli.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: 設定 → 環境設定（schema キー）

`DECISION_BACKTEST_DRY_RUN`

true の場合、ランナーは decision_outcomes / decision_history に書き込まず、代わりにアウトカムとフラグを shadow_runs(facet='decision_outcome') にログします。ロールアウト初週のプロトコルです。shadow 行が妥当に見えることを確認してから false に切り替えてください。

使用箇所: src/learning/backtest/decision-runner.ts.
未設定時: デフォルトは false。
形式: true / false.
設定の所在: ユーザー向け設定ではありません

`DECISION_BACKTEST_HORIZONS`

<number><unit>（unit は h/d/w/m = 時間/日/週/月）形式のホライズン指定を CSV で列挙します。例: 1d,3d,1w,1m。各ホライズンは、決定ごとに decision_outcomes へ 1 行を生成します。最大のホライズンが、保留中の決定がバックテスト対象になるタイミングを決めます。

使用箇所: src/learning/backtest/decision-runner.ts.
未設定時: デフォルトは 1d,3d,1w,1m。
形式: カンマ区切りのリスト。
設定の所在: ユーザー向け設定ではありません

`DECISION_BACKTEST_CRON_HOURS`

ランナー呼び出し間の間隔です。

使用箇所: src/app/backtest.ts（wireBacktest の interval）。
未設定時: デフォルトは 24。
形式: 正の数（時間）。
設定の所在: ユーザー向け設定ではありません

`DECISION_BACKTEST_MAX_AGE_DAYS`

決定の経過日数に対するハードな上限です。これより古い行は、ホライズンの充足状態に関係なくスキップされ、バックログの際限ない増大を防ぎます。

使用箇所: src/learning/backtest/decision-runner.ts.
未設定時: デフォルトは 60。
形式: 正の整数（日）。
設定の所在: ユーザー向け設定ではありません

`HALLUCINATION_MAX_PRICE_DELTA_PCT`

agent_quoted_price が設定されていて、real_price_at_decision からこの比率を超えて乖離している場合、その決定はフラグ付けされ、下流の学習から除外されます。0.05（5%）は、大きな捏造を捕捉しつつ、ツール出力の陳腐化による誤検知のほとんどを回避します。陳腐なキャッシュが多い場合は 0.03 に厳しくし、HistoricalPriceProvider 自体がノイジーな場合にのみ 0.10 に緩めてください。

使用箇所: src/learning/backtest/decision-outcome-filler.ts.
未設定時: デフォルトは 0.05。
形式: 正の小数（0.01 = 1%）。
設定の所在: ユーザー向け設定ではありません

Phase 3 — 報酬計算

報酬関数は、4 ホライズンのリターンベクトル(Phase 2)を決定ごとの単一スカラーに変換します。3 つのルール: BUY: pct_return の加重平均 (価格上昇で報酬が増加) SELL: -pct_return の加重平均 (価格下落で報酬が増加) HOLD: 線形の中立報酬 — |return| < threshold で正の報酬 (0 で 1、threshold で 0 へ減衰)。threshold を超えると、線形の負(機会費用 / 逃した値動き)。

`DECISION_HORIZON_WEIGHTS_JSON`

報酬合計におけるホライズン別の重みです。{label: weight} を文字列化した JSON オブジェクトです。存在しないラベルの重みは 0 になります。デフォルトは「中期シグナル」重視のバイアスを反映し、1w が最も高く、日次はノイズが多いため 1d が最も低くなっています。

使用箇所: src/learning/decision-reward/reward.ts rewardOptionsFromEnv().
未設定時: デフォルトは {"1d":0.15,"3d":0.25,"1w":0.35,"1m":0.25}。
形式: JSON 文字列。
例（短期をより重視）: DECISION_HORIZON_WEIGHTS_JSON='{"1d":0.35,"3d":0.30,"1w":0.25,"1m":0.10}'
設定の所在: ユーザー向け設定ではありません

`DECISION_HOLD_NEUTRALITY_THRESHOLD`

|pct_return| がこの値未満なら HOLD の勝ちとしてカウントします。0.02 = 2% です。HOLD 報酬を緩める（「変動があっても問題ない」という許容度を上げる）には値を上げ、厳しくする（HOLD はほぼゼロの値動きでなければならない）には下げてください。

使用箇所: src/learning/decision-reward/reward.ts rewardOptionsFromEnv().
未設定時: デフォルトは 0.02。
形式: 正の小数（0.01 = 1%）。
設定の所在: ユーザー向け設定ではありません

Phase 6 — BO チューニングサイクル

(template, asset_class) ごとの方法論閾値に対するオフラインのベイズ最適化です。定期的(cron)に実行され、Phase 1-3 の決定報酬を読み取り、チューニングされた閾値を methodology_instances に書き込みます。完全に無効な状態で安着しており、有効化するまでランタイムコストはゼロです。tools/tuning/ の Python ハーネスが必要です。

`METHODOLOGY_INSTANCE_TUNING_ENABLED`

BO サイクルオーケストレーターのマスタースイッチです。false（デフォルト）の場合、スケジュールされていてもサイクルは no-op です。Phase 1/2/3 のデータが蓄積され、かつ minara learning stats の READY_FOR_BO=true になってからのみ true に切り替えてください。

使用箇所: src/learning/experimental/tuning/cycle.ts（Phase 7 で
配線予定）。
未設定時: デフォルトは false。
形式: true / false.
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_CRON_DAYS`

BO サイクル呼び出し間の日数です。デフォルトは 7（週次）です。値を小さくすると短期の相場ノイズへの過剰適合のリスクがあり、大きくすると学習が遅くなります。

使用箇所: src/app.ts（cron の配線、Phase 7）。
未設定時: デフォルトは 7。
形式: 正の整数（日）。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_MAX_BUCKETS_PER_CYCLE`

サイクルごとの上限です。対象となるバケットは tunability_score でランク付けされ、各サイクルで上位 N 件のみが Python BO ハーネスに渡されます。

使用箇所: src/learning/experimental/tuning/cycle.ts.
未設定時: デフォルトは 10。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_PROFILES_PATH`

アセットクラスのプロファイル JSON を上書きするパスです。クラスごとに BUILTIN_PROFILES へ浅くマージされます。あるクラスの値を null にすると、そのクラスをチューニングから完全に除外します。

使用箇所: src/learning/experimental/tuning/asset-profiles.ts.
未設定時: デフォルトは $MINARA_DATA_DIR/methodology-tuning-profiles.json。
形式: ファイルシステムのパス（存在しない場合もあり — その場合は no-op）。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_MIN_DECISIONS_GLOBAL`

すべてのプロファイルにわたる min_decisions のグローバルな下限です（プロファイルごとの値との最大値を取ります）。不良なロールアウト後など、緊急の引き締めに使います。

使用箇所: src/learning/experimental/tuning/asset-profiles.ts.
未設定時: 下限は適用されません。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_MIN_IMPROVEMENT_REL`

BO 後チェック #1 の相対改善ゲートです（テスト分割の平均報酬がこの比率だけベースラインを上回る必要があります）。0.05 = 5% です。

使用箇所: src/learning/experimental/tuning/cycle.ts Phase 7.
未設定時: デフォルトは 0.05。
形式: 正の小数。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_MAX_SENSITIVITY_DROP_10PCT`

BO 後チェック #2 の狭いピークの棄却です。最良候補の ±10% 近傍のスコアが、この割合を超えて低下してはなりません。0.5 = 50% です。

使用箇所: src/learning/experimental/tuning/cycle.ts Phase 7.
未設定時: デフォルトは 0.5。
形式: (0, 1] の範囲の小数。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_PARAM_BOUND_REL`

テンプレートのデフォルト値に対する倍率として表した BO pbounds の半幅です。0.5 は、各パラメータの範囲 = [default × 0.5, default × 1.5] を意味します。

使用箇所: src/learning/experimental/tuning/cycle.ts Phase 7.
未設定時: デフォルトは 0.5。
形式: 正の小数。
設定の所在: ユーザー向け設定ではありません

`METHODOLOGY_TUNING_MIN_CAPTURE_CONFIDENCE`

BO リプレイハーネスは、capture_confidence がこのしきい値以上の決定のみを考慮します。0.3 は 3 つのティアすべて（advice_scenario、heuristic_match、summarizer_promoted）を含みます。高シグナルの決定のみに限定するには 0.6 以上に上げてください。

使用箇所: src/learning/experimental/replay/decision-replay.ts（Phase 7）。
未設定時: デフォルトは 0.3。
形式: [0, 1] の範囲の小数。
設定の所在: ユーザー向け設定ではありません

選好進化 (M2: Financial Auto-Memory)

最近のユーザーメッセージをスキャンし、モデルにそれらを永続的な選好 (kind ∈ {personal_style, behavioral_preference})へクラスタリングするよう依頼し、クールダウン枠ごとに一度カード形式の卒業リクエストを提示する定期的な LLM 主導の提案器です。AutoClaw の週次進化ループを本にし、週あたり 1〜3 件の卒業というソフト上限を設けています。 M2 の境界: hard_constraint 候補は behavioral_preference に降格され、ツールレベルでは自動適用されません — ツールレベルの施行はキーワードスキャナーとともに M3 で安着します。手動の /preferences approve|reject|deprecate は、運用者のオーバーライドのため、マスターフラグに関係なく動作します。

`PREFERENCE_LEARNING`

M2 の定期プロポーザー + 卒業カードフローのマスタースイッチです。0 の場合、エージェントループはユーザーメッセージをキューに入れず、プロポーザーを発火させず、卒業カードも注入しません。M1 由来の PreferenceStore + REPL/CLI/REST エンドポイントは、このフラグがオフでも手動管理のために引き続き利用できます。

形式: 0 / 1.
設定の所在: 設定 → 環境設定（schema キー）

`PREFERENCE_PROPOSER_INTERVAL`

連続するプロポーザー発火の間のターン数です。プロポーザーは、そのターンのユーザー可視応答が送信された後に fire-and-forget の非同期として実行されるため、これはユーザーのレイテンシではなく償却されるコストです。小さくするほど学習の反応がよくなり、LLM 支出が増えます。デフォルトの 30 は、活発な会話の約 30 分ごとに 1 回に相当します。

形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_WEEKLY_QUOTA`

任意のローリング 7 日間ウィンドウ内で許可される卒業の最大数です。上限に達すると、プロポーザーはそのサイクルをスキップします — 新しい候補はキューに溜まりますが、ユーザーには提示されません。手動の /preferences approve はこのクォータを上書きします（運用者の判断）。AutoClaw の「週に 1〜3 件の深い進化」という原則を踏襲しています。

形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_DEDUP_THRESHOLD`

このスコアを超えると、候補は既存のライブな設定（state ∈ {active, proposed, deprecated}）の重複とみなされ、永続化される前に破棄される TF-IDF コサインスコアです。範囲は [0, 1] です。0.85 は、キーワードを共有する短い記述での誤検知を避けつつ、言い換えを捕捉します。

形式: [0, 1] の範囲の浮動小数点数。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_PROPOSER_BATCH_SIZE`

1 回のプロポーザー LLM 呼び出しに取り込む直近の候補の最大数です。バッチが大きいほど LLM により多くのクラスタリングシグナルを与えられますが、トークンコストが増えます。デフォルトの 200 は、コンテキストの残りを圧迫することなく、意味のあるプロポーザーサイクルを回すのに十分です。

形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_MIN_CLUSTER_SIZE`

提案が永続化される前に、プロポーザーの LLM が単一のクラスタを支持していると報告しなければならない候補メッセージの最小数です。下限を 3 とすることで、単発の観測が設定のノイズを膨らませるのを防ぎます。

形式: 正の整数（≥ 2 が強制される）。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_ASK_COOLDOWN_HOURS`

同一の設定に対する連続した卒業の確認の間の最小時間です。ユーザーが「後で」と返信した（またはまったく返信しない）後、その行は proposed のままですが、このウィンドウが経過するまで確認キューから隠されます。デフォルトの 24h はシナリオフローに合わせています。

形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_ASK_MIN_GAP_TURNS`

同一の REPL セッション内で（異なる設定にまたがる）連続した卒業の確認の間の最小ターン数です。プロポーザーキューが豊富な場合でも、カードの確認が立て続けに出るのを防ぎます。

形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_SKIP_IN_CHAT_ASK`

チャット内の卒業カードを完全に無効化します。1 の場合、プロポーザーは引き続き実行され提案を書き込みますが、カードはシステムプロンプトに一切注入されません。運用者は REPL の /preferences pending + approve、または CLI / REST で確認・承認します。非対話的なデプロイで便利です。

形式: 0 / 1.
設定の所在: ユーザー向け設定ではありません

M3: キーワードスキャナー + ツールレベルの制約施行

`PREFERENCE_STYLE_MIN_OBSERVATIONS`

スキャナーが自動的に有効化する前に必要な、（dedup_key による）同一のスタイル設定に対する独立した観測の数です。下限は 1 です。3 以上に上げると、その行が定着する前にユーザーが自分の意見を覆す機会が増えます。

形式: 正の整数。デフォルトは 2。
設定の所在: ユーザー向け設定ではありません

`PREFERENCE_HARD_UNDO_WINDOW_HOURS`

強いシグナルによる自動有効化の後、ユーザーが /preferences undo <id> で取り消せる時間の長さです。このウィンドウ外の行は、代わりに /preferences deprecate <id> で廃止する必要があります。

形式: 正の整数。デフォルトは 24。
設定の所在: ユーザー向け設定ではありません

`MINARA_SKIP_FUND_CONFIRM`

資金移動の確認バイパスです。

制御対象: 統一確認ゲート（ToolEntry の controlPolicy.confirm。 tools/_security/tier-gate.ts が解釈）。資金移動ツール（swap / buy / sell / transfer / perps open-close-cancel / perp-wallet sweep+ transfer / autopilot enable / workflow activate / strategy- studio start+deploy）はプレビューし、ユーザーが確認カード（または他の確認証拠）を承認してから実行します。ハンドラーは実行専用です。
使用箇所: src/tools/_security/tier-gate.ts (confirmFlowHook)。 src/tools/_shared/confirm.ts (isFundConfirmBypassEnvSet) 経由。
設定するタイミング: ヒューマン・イン・ザ・ループが存在せず、呼び出し元が非人間である非対話的なコンテキストでのみ設定します: - バックテストの実行 - ワークフローエンジンの実行（サーバーサイドのオートパイロット、DCA） - 資金移動パスを意図的に通す CI スモークテストこれを設定すると、確認ゲートがプロセス全体でバイパスされます。他にエスケープハッチはありません。LLM はこれを切り替えられず、REPL も切り替えられません。
未設定時: すべての資金移動呼び出しが確認ゲートを通ります。
形式: 1 / true / yes / on で有効化。それ以外は off。
⚠ すべての呼び出し元が非人間であると確信できる場合を除き、対話的な REPL セッションや本番デプロイでは決して設定しないでください。
設定の所在: 設定 → 環境設定（schema キー）

`WORKBENCH_REMOTE_WEB_PTY_ENABLED`

リモート Gateway 経由で対話型ワークベンチ Shell を公開します。

制御対象: Gateway がループバック以外にバインドされている場合、認証済み Web クライアントによる対話型 PTY セッションの作成を許可します。
使用箇所: apps/agent/src/gateway/api.ts と、設定の安全性項目 safety.remoteWebPty。
設定するタイミング: 信頼でき、認証され、対応 OS サンドボックスを備えたホストでのみ設定してください。Web UI からも重大リスクを明示的に確認した後で有効化できます。
未設定時: リモート Web PTY は無効のままです。ループバック Gateway は従来のローカルターミナル動作を維持します。
形式: 1 / true / yes / on で有効化します。ワークスペース境界、環境変数許可リスト、所有権確認、同時実行上限、プロセス寿命制限は維持されます。
設定の所在: 設定 → 環境設定（schema キー）

`WORKBENCH_REMOTE_SHELL_PROFILE_POLICY`

リモートワークベンチターミナルでユーザーの Shell 設定を読み込む方法を制御します。

制御対象: リモートターミナルがユーザーの Shell rc ファイルを読み込む前に確認するか、自動的に読み込むか、常に Minara の組み込み Shell 設定を使うかを決めます。
使用箇所: apps/agent/src/gateway/api.ts と、内部ワークベンチターミナルの capability および作成ルート。
設定するタイミング: ユーザー rc ファイルを実行することが想定された信頼済みリモートホストでのみ user を設定してください。読み込みを禁止するには builtin、ブラウザごとに明示したタブ選択を記憶させるには prompt を使います。
未設定時: リモート Gateway の既定値は prompt です。ループバック Gateway は常にユーザーの Shell 設定を読み込み、確認を表示しません。
形式: 値は prompt、user、builtin のいずれかです。不正な値は prompt に戻り、警告を一度記録します。
設定の所在: ユーザー向け設定ではありません

`MINARA_DANGEROUSLY_SKIP_PERMISSIONS`

⚠ 危険なボタン — 資金以外の認可をまとめてスキップするマスタースイッチです（Claude Code の --dangerously-skip-permissions に相当）。

制御対象: 資金以外の対話的な認可ゲートを一度にオフにし、エージェントの実行がそれらを尋ねるために停止しなくなります: 1. ティアゲート (tools/_security/tier-gate.ts) — terminal、write_file、 execute_code などに対する初回利用 / 高リスク / 自律付与のプロンプト。 2. コマンドガード (tools/_security/command-guard.ts) — シェルコマンドのトリップワイヤー。 3. サンドボックス書き込みエスケープゲート (tools/_security/sandbox-gate.ts)。 4. スクリプトリスク YELLOW 確認 (tools/_security/script-risk-gate.ts)。
What it does NOT control: 資金移動の確認 (tools/_shared/confirm.ts) — swap / buy / sell / transfer / perps はこれが設定されていても引き続き confirm: true を要求します。資金移動は MINARA_SKIP_FUND_CONFIRM によって独立にゲートされます。web-ui の用語では、このスイッチだけなら「Auto」モード（アクションは自動実行、資金移動は引き続き確認）で、両方を設定すると「Full auto」です。
使用箇所: src/tools/_security/permission-skip.ts (isPermissionSkipSet)。ティアゲート、コマンドガード、サンドボックスゲート、スクリプトリスクゲートが読み取ります。
設定されていても 2 つの安全下限は維持されます: - スクリプトリスク RED は依然としてハードな拒否です（RED はプロンプトを出さないため「認可」の面ではありません）。 - ワークフローのテスト実行 (ctx.test_run) は依然として資金を一切動かしません。
設定するタイミング: ヒューマン・イン・ザ・ループが存在せず、すべての呼び出し元が信頼できる、自動テスト / ヘッドレス駆動でのみ設定します。設定方法は 3 通り: - この環境変数、または - --dangerously-skip-permissions CLI フラグ、または - ~/.minara/runtime-preferences.json に永続化された safety.skipPermissions オーバーライド（web UI の設定のデンジャーゾーンでも編集可能、minara settings unlock-critical の背後）。
未設定時: すべてのゲートが有効で、通常どおりプロンプト / 確認を行います。
形式: 1 / true / yes / on で有効化。それ以外は off。
⚠ 完全に制御下にない対話的な REPL や本番デプロイでは決して設定しないでください。LLM はこれを切り替えられません。
設定の所在: 設定 → 環境設定（schema キー）

`MINARA_AUTO_REVIEW`

Smart モード: ユーザーに確認するはずだった非資金の承認をレビュー用エージェントが判断します（Codex AutoReview 相当）。

制御対象: 非資金の「本来なら尋ねる」箇所を InteractionQueue ではなく短い Guardian LLM セッションへ回します: 1. ティアゲートの初回利用 / 高リスク確認（非資金）。 2. サンドボックス書き込みエスケープとコマンドエスケープの確認。 3. スクリプトリスク YELLOW 確認。拒否はメインエージェントへのツールエラーです。確認カードは出しません。タイムアウト / 解析失敗はフェイルクローズ（拒否）です。
What it does NOT control: 資金移動の確認は引き続き人のパスです。Auto / Full （safety.skipPermissions）は確認をスキップし、Smart より優先します。 Coding セッションとオートメーションは Smart を使いません。
使用箇所: src/tools/_security/permission-skip.ts （isGuardianReviewEnabled）と src/guardian/。
設定するタイミング: チャットメニューの Smart /「代わりに承認」をプロセス既定にしたいときに設定します。 web UI は safety.autoReview を runtime-preferences.json にも保存します。
未設定時: Ask モード: ユーザーが非資金アクションを確認します。
形式: 1 / true / yes / on で有効化。それ以外は off。
設定の所在: 設定 → 環境設定（schema キー）

`DISABLE_SCRIPT_RISK_GATE`

⚠ 危険なボタン — スクリプトリスクのキルスイッチです。

制御対象: execute_code（python/node の本体）、terminal（シェルコマンド）、write_file（最終的なファイル内容）、patch（適用後の内容）の前に実行される静的解析のスクリプトリスクゲートです。デフォルトの挙動は、本体を RED（自動拒否）、YELLOW（AskUserQuestion で確認）、GREEN（許可）に分類します。 RED は、大量の rm * / rm -r *、ワークスペース外のパスの削除、 IMDS / SSRF、コンテナエスケープ、認証情報 / ウォレットストアの読み取り、間接的な難読化 + シンクの組み合わせ、リモートの pickle/yaml デシリアライゼーションなどを捕捉します。YELLOW は、資金移動 CLI のシェルアウト（minara swap / cast send / forge --broadcast）、オンチェーンの危険な呼び出し（approve / Permit2 / Safe owner change）、環境汚染（NODE_OPTIONS / LD_PRELOAD / BASH_ENV）、特定パスの rm、git / tarball / 非公式インデックスからのパッケージインストール、 heredoc に埋め込まれたスクリプト、プロセス置換を捕捉します。
使用箇所: src/tools/_shared/script-risk-gate.ts.
設定するタイミング: AskUserQuestion に答える人間がおらず、かつすべての呼び出し元が信頼できる、インシデント対応または完全オフラインの CI 実行でのみ設定します。これは単一のブール値で、RED と YELLOW の両方のチェックをバイパスします。日常的なワークフローの適用除外には、ワークフローごとの script_risk_policy フィールド（workflow_activate 時の body_sha256 + カテゴリの事前承認）を使ってください。単一のワークフローの範囲を広げるためにこの環境変数を設定しないでください。
未設定時: ゲートは有効です。RED はハードに拒否し、YELLOW は AskUserQuestion でプロンプトします。対話セッションのない Cron / ワークフローのコンテキストは、一致する script_risk_policy がない限り script_risk_no_session を返します。
形式: 1 / true / yes / on で有効化。それ以外は off。
Audit: すべてのゲート判定は script_risk_decisions の SQLite テーブルに記録されます — この環境変数を設定すると、その行の bypassed_by 列は env_global となり、運用者が後からバイパスを見つけられます。
⚠ すべての呼び出し元が非人間であることを確認し、大量削除 / 認証情報の窃取パターンがプロンプトなしで実行されることを受け入れる場合を除き、対話的な REPL セッションや本番デプロイでは決してこれを設定しないでください。
設定の所在: 設定 → 環境設定（schema キー）

`DISABLE_OUTPUT_REDACTION`

⚠ 危険なボタン — 出力秘匿化のキルスイッチです。

制御対象: サブプロセス出力に対する秘密情報の秘匿化パスです。 execute_code / terminal の stdout+stderr（ローカルおよび docker）は、モデルコンテキストや永続化されるチャット履歴に入る前に、認証情報の形をした文字列がスクラブされます: ベンダートークンの形式（sk-…、 ghp_…、xoxb-…、AKIA…、完全な JWT）全般、加えて秘密情報らしい名前に紐づく値（KEY=…、"api_key": "…"、Authorization: ヘッダー、 ://user:password@host URL）。一致箇所は [REDACTED] に置き換えられます。
使用箇所: src/tools/_security/redact.ts（src/tools/_shared/subprocess-result.ts と docker 環境で適用）。
設定するタイミング: 実際の認証情報を扱わないセッションで、誤検知（秘匿化器が壊してしまう正当な出力）をデバッグする場合にのみ設定します。このスイッチはプロセス開始時に一度だけ読み取られます — terminal ツール呼び出し内の export ではセッション途中に切り替えられず、変更にはホストの再起動が必要です。
未設定時: 秘匿化はすべてのサブプロセス出力パスで有効です。
形式: 1 / true / yes / on で無効化。それ以外は on。
設定の所在: ユーザー向け設定ではありません

`MINARA_TOOL_RESULT_RETAIN_HOURS`

スピルファイルの保持ウィンドウです。

制御対象: <dataDir>/sandbox/files/.tool-results/ 配下に永続化されたサイズ超過のツール結果が、定期スイープ（6h ごと）に削除されるまで何時間存続するかです。同じ値が起動時スイープと長時間実行スイープの両方を駆動するため、数日間起動し続けるプロセスでも、設定されたウィンドウを超えて蓄積することはありません。
使用箇所: src/core/tool-result-retain.ts。src/app.ts 内の sweepStaleSpillFiles の起動時 + インターバル呼び出しに配線されています。
設定するタイミング: - 24（デフォルト）は、典型的な対話的 REPL や開発作業に適した値です — LLM が以前のターンのスピルを read_file するのに十分な時間を与えます。 - 168（7 日）は、スピルされたツール出力が四半期レビューや規制当局の遡及調査に耐えられるだけ長く存続する必要がある、コンプライアンス要件のあるデプロイに適した監査向けの値です。 - 1 は、一時的な CI 実行向けの積極的クリーンアップの値です。
未設定時: 24h。
形式: [1, 720] の範囲の正の整数（1h〜30 日）。不正な形式 / 範囲外の値は、警告とともに黙って 24h にフォールバックします。
設定の所在: ユーザー向け設定ではありません

──────────────────────────────────────────────────────────────────── パーソナライゼーション再構築 — M3.2 イベント駆動の閾値 ────────────────────────────────────────────────────────────────────

`CHAT_TURN_RECORDING`

(user_message, final_response, tool_calls) をターンごとに chat_turns の SQLite テーブルへ記録する機能を有効化します。

制御対象: エージェントループ内の chatTurnRecorder フック（[src/core/agent-loop.ts]、turn_complete で fire-and-forget）です。この記録はパーソナライゼーションのメモリ抽出リビルダーの入力になります — これがないと rebuildMemories はスキャンする対象がなく、 no_turns を返します。
使用箇所: src/app.ts isChatTurnRecordingEnabled() — フックをエージェントループに登録するかどうかを切り替えます。
設定するタイミング: 本番ではデフォルトの ON のままにします。プライバシーに配慮したデプロイや、パーソナライゼーション層から切り離してターンループをデバッグする場合にのみ 0 に設定します。
未設定時: デフォルトは ON — すべてのターンが永続化されます。
形式: 0 / false / no / off で無効化。それ以外の値（空や未設定を含む）は on のままにします。
設定の所在: 設定 → 環境設定（schema キー）

`FIN_PROFILE_TRADING_SUMMARY_MIN_NEW_TRADES`

trading-summary リビルダーが実行を検討する前に必要な新規トレードの最小数です。2 つのゲートの 1 つで（もう 1 つは下記の最小チェック間隔）、両方が満たされる必要があります。

制御対象: rebuildTradingSummary（[src/memory/personalization-rebuilder.ts]）内の tradingSummaryMinNewTrades しきい値です。スケジューラの 60 分セーフティネットティックにも影響します — ティックが発火しても maxTradeId - last_seen < threshold の場合、リビルドは LLM を呼び出さずに黙って no-op になります。
使用箇所: リビルダー内の rebuildTradingSummary。
設定するタイミング: 小さな swap を多数行い、サマリの更新が頻繁すぎると感じるユーザーは 5 以上に上げます。取引量の少ないユーザーで、どのトレードでも即座にサマリを更新したい場合は 1 に下げます。
未設定時: デフォルトは 3 — 新規トレードが 3 件蓄積されてからのみリビルドします。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_TRADING_SUMMARY_MIN_INTERVAL_MIN`

2 回の成功した trading-summary リビルドの間の最小分数です。上記の新規トレードしきい値と対になっています。

制御対象: tradingSummaryMinCheckIntervalMs。従来の tradingSummaryCooldownMs のセマンティクスを置き換えます。
使用箇所: rebuildTradingSummary のゲート 1。
設定するタイミング: サマリを素早く収束させたいパワーユーザーは (10-15) に下げます。 LLM コストを減らすには (60-120) に上げます。
未設定時: デフォルトは 30 分。
形式: 正の整数（分）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_TRADING_SUMMARY_MAX_TRADES`

FULL 再生成モード（コールドスタートまたは force=true）で、リビルドごとに考慮するトレードの最大数です。

制御対象: 以前のサマリが存在しない場合に LLM に渡すトレードの上限です。インクリメンタルマージは、下記の別の INCREMENTAL_MAX_TRADES ウィンドウを使用します。
使用箇所: rebuildTradingSummary の full-regen パス。
未設定時: デフォルトは 100。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_TRADING_SUMMARY_INCREMENTAL_MAX_TRADES`

インクリメンタルマージモード（以前のサマリが存在する場合）で LLM に渡す新規トレードの最大数です。各リビルドを安価に保つため小さくしています。

制御対象: tradingSummaryIncrementalMaxTrades。LLM は (existingSummary, newTrades) を見てそれらをマージします。
未設定時: デフォルトは 50。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_TRADING_SUMMARY_MAX_INCREMENTAL_RUNS`

リビルダーが full regen を強制する前に、連続していくつのインクリメンタルマージを実行できるかです。インクリメンタルモードは新規トレードの差分だけから自身の以前のサマリを書き直すため、小さな誤りや幻の「長期パターン」が多数のマージにわたって蓄積します。定期的な full regen は実際のトレード履歴を読み直し、サマリを再アンカーします。

制御対象: tradingSummaryMaxIncrementalRuns。ユーザーごとのカウンタ（financial_profile.trading_summary_incremental_runs）がインクリメンタルマージのたびに増加し、full regen で 0 にリセットされます。この上限に達すると、次のリビルドは full regen になります。
未設定時: デフォルトは 10。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_MEMORIES_MIN_NEW_TURNS`

rebuildMemories がスキャンする前に必要な新規チャットターンの最小数です。trading-summary の新規トレードしきい値に対応します。

制御対象: memoriesMinNewTurns。メモリ抽出リビルダーの 2 つ目のゲート（最小チェック間隔と並ぶ）です。
使用箇所: rebuildMemories のゲート 2。
設定するタイミング: 事実を素早く生み出すおしゃべりなユーザーは (2-3) に下げます。ゆっくりした単発質問の会話には (10+) に上げます。
未設定時: デフォルトは 5。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_MEMORIES_MIN_INTERVAL_MIN`

2 回の成功したメモリ抽出リビルドの間の最小分数です。

制御対象: memoriesMinCheckIntervalMs.
未設定時: デフォルトは 10 分。
形式: 正の整数（分）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_EVENT_DEBOUNCE_SEC`

イベント駆動の scheduleCheck(dim) 呼び出しのデバウンスウィンドウです。データ書き込みイベントの急激なバースト（例: 500ms で 5 件のトレード）を、ウィンドウ経過後の 1 回のゲートチェック付きリビルド試行にまとめます。

制御対象: eventDebounceMs。リビルダーはディメンションごとに同じ setTimeout を再利用します。ウィンドウ内の新しいイベントはタイマーをリセットします。
使用箇所: PersonalizationRebuilder.scheduleCheck.
設定するタイミング: 多数のシミュレートされたトレードが立て続けに発生するバックテスト / CI のシナリオでは 60 以上に上げます。デバッグ中にほぼ即座のリビルドフィードバックが欲しい開発者は 5-10 に下げます。
未設定時: デフォルトは 30 秒。
形式: 正の整数（秒）。
設定の所在: ユーザー向け設定ではありません

オフエージェント履歴ミラー

パーソナライゼーション再構築器は、現在 3 つのソースを消費します: ローカルの trade_history(セッション内のエージェント)、perps_fills(Minara の /v1/perp-wallets/fills のクロスサブミラー)、external_spot_activities (Minara の /v1/tx/cross-chain/activities)。以下のノブは、ミラーがどのように自らを最新に保つか、そして LLM 再構築器がそのうちどれだけを読むかを調整します。

`FIN_PROFILE_HISTORY_SYNC_WINDOW_DAYS`

ローリング同期ウィンドウの日数です。

制御対象: perps のフィルと spot のアクティビティ両方のカットオフです。 now - WINDOW_DAYS より古いものは一切取得されません。
使用箇所: MinaraHistorySync、および tradingSummaryAggregateWindowDays 経由の trading-summary 集計クエリです。
設定するタイミング: より長期のスタイルを捕捉したいトレーダーは増やします。ミラーが数万行に膨れ上がってしまう高頻度ユーザーは減らします。
未設定時: デフォルトは 90 日。
形式: 正の整数（日）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_MIN_INTERVAL_MIN`

連続する同期トリガーの間のスロットル下限です。ウィンドウ内の複数の scheduleSync() 呼び出しは、最終的に 1 回の実行にまとめられます。すべてのトレードイベントが上流 API への呼び出しになるのを防ぎます。

使用箇所: MinaraHistorySync.scheduleSync + runIfStale.
未設定時: デフォルトは 5 分。
形式: 正の整数（分）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_TIMEOUT_SEC`

1 回の syncAll() 呼び出しに対するハードなタイムアウトです。AbortController を経由するため、基盤の HTTP 呼び出しは放置されるのではなくキャンセルされます。

未設定時: デフォルトは 8 秒。
形式: 正の整数（秒）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_PAGE_HINT`

ページネーションパラメータを持たない perps-fills エンドポイント向けの、上流の「このページはおそらく満杯」ヒューリスティックです。getPerpSubAccountFills がこの行数以上を返した場合、同じウィンドウ内にさらにある可能性があると仮定し、startTime を前方にスライドして再度問い合わせます。

未設定時: デフォルトは 500。
形式: 正の整数（行）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_OVERLAP_SEC`

おそらく切り詰められたページで startTime を前方にスライドする際のオーバーラップ（秒）です。オーバーラップが大きいほど無駄なフェッチが増え、小さいほど境界でフィルをスキップするリスクが高まります。fill_uid の重複排除により二重カウントは無害です。

未設定時: デフォルトは 60 秒。
形式: 正の整数（秒）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_MAX_ROUNDS_PER_SUB`

サブアカウントごとの切り詰めローリングループに対するハードな上限です。このラウンド数を超えると中断し、次の同期がウォーターマークから継続できるようにします。

未設定時: デフォルトは 10。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_MAX_FAILURES`

(source, sub_account_id) ごとの連続失敗しきい値です。この回数以上になると、同期は通常のスケジューリング中にそのキーをスキップします。ウォーターマークはそのまま維持され、次の試行は同じ場所から再開します。このスキップは恒久的ではありません — _FAILURE_COOLDOWN_MIN を参照してください。

未設定時: デフォルトは 5。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_FAILURE_COOLDOWN_MIN`

キーが MAX_FAILURES に達した後、次のプローブ試行は last_synced_at からこのクールダウンが経過することを条件とします。プローブ成功 → カウンタは 0 にリセット、プローブ失敗 → カウンタは増加し続けます。一時的な障害がミラーを恒久的に無効化するのを防ぎます。

未設定時: デフォルトは 30 分。
形式: 正の整数（分）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_SPOT_MAX_PAGES`

spot のページネーションループに対するハードな上限です。上流が常にページ満杯の応答を返す場合に、暴走するページネーションを止めます。

未設定時: デフォルトは 20。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_HISTORY_SYNC_SPOT_PAGE_SIZE`

spot のページネーションのバッチサイズです。limit として Minara に転送されます。上流 API がサポートしている必要があり、100 がドキュメント上のデフォルトです。

未設定時: デフォルトは 100。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_TRADING_SUMMARY_PERPS_RECENT_FILLS`

直近の perps フィルのうち何件を LLM リビルドに送るかです。シンボルごとの集計は常に全量が送られます。このノブは生フィルのログを制限するだけです。

未設定時: デフォルトは 30。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_TRADING_SUMMARY_SPOT_RECENT_ACTIVITIES`

spot についても同様です。

未設定時: デフォルトは 20。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_TRADING_SUMMARY_AGGREGATE_WINDOW_DAYS`

LLM リビルドに渡すシンボルごと / ペアごとの集計のウィンドウです。通常は HISTORY_SYNC_WINDOW_DAYS と等しくしますが、直近の挙動に焦点を当てるために小さくすることもできます。

未設定時: デフォルトは 90。
形式: 正の整数（日）。
設定の所在: ユーザー向け設定ではありません

`FIN_PROFILE_MEMORY_SOFT_DELETE_RETENTION_DAYS`

ソフト削除されたメモリが、30 分ごとのパージ cron に物理的に削除されるまで復元可能でいる期間です。web UI の「削除を元に戻す」トーストは 5 秒以内に復元します。このノブは行を残しておくことで、より長期の誤削除に備え、CLI レベルの復元でも呼び戻せるようにします。

未設定時: デフォルトは 30 日。
形式: 正の整数（日）。
設定の所在: ユーザー向け設定ではありません

`MINARA_HL_DEX_DISCOVERY`

perps のポジション、注文、履歴を同期する際に、ライブの Hyperliquid perpDexs ディスカバリを有効化します。

制御対象: perps スナップショットと履歴同期における、スイープごとの dex ファンアウトです。デフォルトでは、現在のユーザーコホートがポジションを保有していることが分かっている 2 つの dex（"" デフォルト + "xyz" 株式/コモディティ）のみをクエリします — スイープあたり 16 件の HL リクエストで、HL の IP あたりレート制限に十分収まります。このフラグがオンの場合、スナップショットは HL perpDexs（10 分間キャッシュ）も呼び出し、返される名前付き dex すべて（xyz、flx、vntl、hyna、km、abcd、cash、para、 ...）にファンアウトします。典型的な 4 サブのユーザーでは、これによりスイープあたりの予算が約 72 リクエストに押し上げられ、公開 /info エンドポイントで確実に 429 になります。
設定するタイミング: "" / "xyz" のペア以外の名前付き dex（例: flx、vntl）に実際にポジションを保有している場合にのみ設定します。ほとんどのユーザーはこれをオフのままにすべきです。
未設定時: 既知の正常なペア ["", "xyz"] のみがクエリされ、サブごとの clearinghouseState + frontendOpenOrders ファンアウトは HL のレート制限予算内に収まります。
形式: 1 / true / yes / on で有効化。それ以外（または未設定）はディスカバリを無効のままにします。
設定の所在: 設定 → 環境設定（schema キー）

`WORKFLOW_HEARTBEAT_CHECK_MS`

ワークフローのハートビートモニターのスイープ間隔です。制御対象: HeartbeatMonitor.checkIntervalMs （[src/workflow/heartbeat.ts]）。最後のステップの updateInstance が MAX_SILENCE_MS より古い実行中のインスタンスは、 status="canceled" cancel_reason="timeout" とマークされます。

設定するタイミング: ハングを素早く表面化させるには dev/staging で短く（例: 5000）、 SQLite のスキャン負荷を減らすには本番で長くします。
未設定時: デフォルトは 30 000 ms（30 秒）。
形式: 正の整数（ミリ秒）。数値でない / 正でない値はデフォルトにフォールバックします。
設定の所在: ユーザー向け設定ではありません

`WORKFLOW_HEARTBEAT_MAX_SILENCE_MS`

実行中のワークフローがタイムアウトとみなされるまでの無音しきい値です。

制御対象: HeartbeatMonitor.maxSilenceMs。last_heartbeat_ms は commitStepAdvance のたびに更新されるため、許容できる単一ステップの最大時間も制限します。
設定するタイミング: 長い agent_turn ステップや外部 API フェッチを持つワークフローでは、デフォルトの 300 000 ms より上げます。
未設定時: デフォルトは 300 000 ms（5 分）。
形式: 正の整数（ミリ秒）。
設定の所在: ユーザー向け設定ではありません

`WORKFLOW_MAX_QUEUE_DEPTH`

定義ごとの cron/イベント発火キューの上限です（[src/workflow/triggers.ts]）。各ワークフロー定義は独自の FIFO を持ち、キューが満杯だと最も古い保留中の発火を破棄します。

設定するタイミング: トリガーが正当に単一実行の所要時間を上回ることがあり、キャッチアップを重視するワークフローでは上げます。最新のシグナルだけが重要な場合は 1 に下げます。
未設定時: デフォルトは 10。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`MINARA_SS_CODEGEN_MAX_ITER`

オフラインの strategy-codegen サブエージェントが、ベンチマーク実行ごとに許可される「コード生成 → 一時バックテスト → リファイン」の反復回数です。

制御対象: runStrategyCodeSubagent（[src/core/strategy-code-subagent.ts]）内の codegen ループのステップ予算です。サブエージェントはこのステップ数まで実行されます。その予算内で、いつバックテストし、いつ停止するかはモデルが決めます。復帰時、成功は最終バックテストから再計算されます（status COMPLETED + 非ゼロのトレード + ドローダウン < 0.95）。
使用箇所: src/core/strategy-code-subagent.ts 内の runStrategyCodeSubagent。 strategy-rl ベンチマークランナーによって駆動されます（オフラインチューニングのみ。チャット向けのツールではありません）。
未設定時のデフォルト: 3
クランプ範囲: [1, 10]
形式: 正の整数
運用者は、llmClient が高速かつ安価（例: Haiku）で、より良い収束を求める場合にこれを上げます。低速 / 高価なモデルを使い、より悪いコードを受け入れる場合は (1–2) に下げます。
設定の所在: ユーザー向け設定ではありません

`MINARA_STRATEGY_SKILL_RL_ENABLED`

Strategy Studio の Skill RL / 自己進化する Skill テキストのオプトインパイロットです。

制御対象: ストアに裏打ちされた Strategy Studio のスキルバージョン、ユーザーごとの戦略設定オーバーレイ、ロールアウトのトレース、およびオフライン codegen ベンチマークループの報酬ロギングです。
未設定時のデフォルト: 無効です。無効の場合、bootstrap は strategy_skill_* テーブルを作成せず、本番の Strategy Studio のスキルプロンプトや codegen ポリシーを変更しません。
有効な真値: 1 | true | yes | on
Scope: このパイロットでは Strategy Studio のみです。すべてのスキルを対象とするグローバルな RL ハーネスではありません。
設定の所在: 設定 → 環境設定（schema キー）

`MINARA_STRATEGY_CONTEXT_RL_ENABLED`

Strategy Studio の Context Policy RL のオプトインパイロットです。

制御対象: バージョン管理された外部コンテキスト選択ポリシー、ポリシーを考慮したコンテキスト収集、3 アームのリプレイベンチマーク、および明示的な昇格 / ロールバックの監査記録です。
未設定時のデフォルト: 無効です。MINARA_STRATEGY_SKILL_RL_ENABLED=1 が必要です。無効の場合、bootstrap は strategy_context_policy_* テーブルを作成せず、外部コンテキストプロバイダは変更されません。
有効な真値: 1 | true | yes | on
Scope: Strategy Studio の外部コンテキスト選択のみです。
設定の所在: 設定 → 環境設定（schema キー）

`MINARA_SKILL_ROUTER_RL_ENABLED`

Skill Router のポリシー進化のための、汎用 Agent Harness RL のオプトインパイロットです。

制御対象: バージョン管理されたスキルランキングポリシー、オフラインのルーティングベンチマークケース、範囲を限定したポリシー探索、明示的な昇格 / ロールバック、および昇格されたポリシーによるターンごとの Skill カタログの並び替えです。
未設定時のデフォルト: 無効です。bootstrap は skill_router_* テーブルを作成せず、 Skill カタログは既存の優先順位のままで、組み込みの did-you-mean ルーティングの挙動は変わりません。
有効な真値: 1 | true | yes | on
Scope: 汎用の Skill 発見/ルーティングのみです。Skill テキスト、ツールの権限ティア、安全ゲート、モデルの重みを変更することは決してありません。
設定の所在: 設定 → 環境設定（schema キー）

───────────────────────────────────────────────────────────────── Institution Mode (マルチエージェントの会社シミュレーション) ───────────────────────────────────────────────────────────────── minara_institution_analyze ツールは、高リスクの単一資産分析のために 6 段階パイプライン(4 名のアナリストが並列 → ブル/ベアのリサーチ討論 → リサーチマネージャー → トレーダー → 3 者リスク討論 → ポートフォリオマネージャー)を招集します。TradingAgents (https://github.com/TauricResearch/TradingAgents) を本にしています。ラウンド数のデフォルト値は TradingAgents の default_config.py に合わせています。タイムアウト / トークン上限は Minara の慣行(deep-research ステージの予算、エージェントループの max_tokens)に従います。以下のすべての変数はエージェントループのインフラであり、プロジェクトの env-var 命名規則に従って MINARA_ 接頭辞はありません。

`INSTITUTION_MAX_DEBATE_ROUNDS`

強気 vs 弱気の交互ラウンド数です。

制御対象: institution パイプラインの Phase 2 における完全なラウンド数です。 1 ラウンド = 合計 2 ターン（強気 1、弱気 1）。多いほど → 議論が豊かになり、LLM コストが増えます。
使用箇所: src/tools/institution/orchestrator.ts 内の runInstitution
Surfaced via tool: minara_institution_analyze（max_debate_rounds 引数は 1 回の呼び出しに対してこれを上書きします）
未設定時のデフォルト: 1 （TradingAgents の max_debate_rounds: 1 に一致）
クランプ範囲: [1, 5]
形式: 正の整数
設定するタイミング: 強気と弱気を 2 回対戦させたい確信度の高いトレードでは 2 に上げます。ルーチンの分析ではコストを抑えるために 1 のままにします。
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_MAX_RISK_ROUNDS`

アグレッシブ/コンサバティブ/ニュートラルのローテーションラウンド数です。

制御対象: Phase 5 における完全なラウンド数です。1 ラウンド = 合計 3 ターン（Aggressive → Conservative → Neutral）。多いほど → リスク精査がより徹底し、LLM コストが増えます。
使用箇所: src/tools/institution/orchestrator.ts 内の runInstitution
Surfaced via tool: minara_institution_analyze（max_risk_rounds 引数は 1 回の呼び出しに対してこれを上書きします）
未設定時のデフォルト: 1 （TradingAgents の max_risk_discuss_rounds: 1 に一致）
クランプ範囲: [1, 5]
形式: 正の整数
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_WALL_CLOCK_TIMEOUT_MS`

1 回の institution 実行に対するグローバルな実時間予算です。

制御対象: 単一の minara_institution_analyze 呼び出しの総経過時間に対するハードな上限です。超過すると、オーケストレーターは実行中のフェーズをすべてショートサーキットし、完了した分に加えて meta.truncated: true を返します。個々のサブ LLM 呼び出しの呼び出しごとのタイムアウトは INSTITUTION_PER_CALL_TIMEOUT_MS（下記参照）によって制御され、この実時間を決して超えないようにクランプされます。
使用箇所: src/tools/institution/orchestrator.ts 内の runInstitution
未設定時のデフォルト: 1200000（20 分 — 5 分の呼び出しを 2 回連続で行い、さらにパイプラインの残りを実行できる十分な余裕を与えます）
クランプ範囲: [60000, 1800000]
形式: 整数のミリ秒
設定するタイミング: 部分的な結果を許容する、より安価 / 高速な実行では下げます（例: 600000 = 10 分）。ディープモデルで大規模な議論を実行する場合は上げます（例: 1800000 = 30 分）。
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_PER_CALL_TIMEOUT_MS`

institution パイプライン内の LLM 呼び出しごとのタイムアウトです。

制御対象: すべてのサブ LLM 呼び出し（アナリスト、討論者、マネージャー、構造化出力のリトライ）に適用される呼び出しごとの中断シグナルです。 2〜3 個のデータツールを呼び出し、単一のサブエージェントループで構造化された AnalystReport を書く必要があるアナリストは、厳しい上限より長くかかるのが普通です — 従来の 60 秒デフォルト（wallClock/10）は書き込みの途中で中断していました。新しい 300 秒デフォルトは、詰まったプロバイダを防ぎつつ、その作業に十分な予算を残します。
使用箇所: src/tools/institution/orchestrator.ts 内の perCallTimeoutMs （runInstitutionSubagent にも受け渡されます）
未設定時のデフォルト: 300000（5 分）
クランプ範囲: [5000, INSTITUTION_WALL_CLOCK_TIMEOUT_MS]
形式: 整数のミリ秒
設定するタイミング: 高速なクイックモデルで実行し、実時間を浪費するよりアナリストをフェイルファストさせたい場合は下げます（例: 60000 = 1 分）。プロバイダの応答が遅い場合は、実時間も合わせて引き上げたうえでのみ上げます（例: 600000）。
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_MAX_OUTPUT_TOKENS_PER_TURN`

LLM 呼び出しごとの出力上限です。

制御対象: institution パイプライン内のすべての LLM 呼び出し（アナリスト、討論者、マネージャー、構造化出力のリトライ）に一律に適用される max_tokens の上限です。挙動を変えるノブではなく、コストの上限として機能します。各ロールのプロンプトはいずれにせよ簡潔な出力を求めます。これは暴走した生成を防ぐだけです。
使用箇所: src/tools/institution/ 内の runInstitution および runInstitutionSubagent
未設定時のデフォルト: 4096（エージェントループのデフォルトの max_tokens に一致）
クランプ範囲: [1024, 16384]
形式: 正の整数
設定するタイミング: 実験中のコスト管理には下げます。PM が executive_summary を切り詰め続ける場合は上げます。
設定の所在: ユーザー向け設定ではありません

───────────────────────────────────────────────────────────────── Institution Mode v2 — 自己学習 (PR 1 + PR 2) ───────────────────────────────────────────────────────────────── 永続化 + Phase B のリフレクションラダー + Phase 0 の振り返りリフレッシュ。ランタイムデータは Minara の他の部分と同じ SQLite db に保持されます。リフレクションの alpha 数値は PR 4 の方法論卒業フィードバックループに供給されます(後続で安着)。

`INSTITUTION_LEARNING_ENABLED`

v2 の自己学習パス（institution_runs / institution_role_outputs / institution_reflections の永続化）のマスタースイッチです。

制御対象: オンの場合、すべての minara_institution_analyze 実行は完全な構造化アーティファクト（PM 評価 + 論拠 + ロールごとの出力 + 方法論の参照）を fire-and-forget で永続化します。オフの場合、キャプチャフックは no-op となり、institution_* テーブルは空のままです。
使用箇所: src/learning/institution/capture-hook.ts 内の captureInstitutionRun
未設定時のデフォルト: on
形式: on | off | 1/true/yes — それ以外（未設定を含む）→ on
設定するタイミング: institution の行をディスクに一切書き込みたくない、一時的な / CI / dev の実行でのみ off に設定します。本番ではこれをオンのままにします。永続化された行は、下流の Phase B のリフレクション + 方法論の卒業に供給されます。
設定の所在: 設定 → 環境設定（schema キー）

`INSTITUTION_RETROSPECT_ENABLED`

Phase 0 の遅延リフレッシュのマスタースイッチです。

制御対象: オンの場合、すべての新しい minara_institution_analyze 呼び出しは、同じ (ticker, asset_class) の直近の実行をたどり、最新のリフレクションが陳腐化しているものに lazy_refresh リフレクションを書き込みます。運用者は /institution-history でそれらを確認できます。
使用箇所: src/tools/institution/index.ts 内の runSingleTicker （Phase 0 ブロック）、src/learning/institution/reflect.ts 内の runLazyRefresh
未設定時のデフォルト: on
形式: on | off
設定するタイミング: YahooFinance へのネットワーク呼び出しが価値なく実行を遅くする CI / バッチテストではオフにします。標準の cron リフレクション（スケジュールされている場合）は独立して動作し続けます。
設定の所在: 設定 → 環境設定（schema キー）

`INSTITUTION_RETROSPECT_LIMIT`

Phase 0 の履歴の深さです。

制御対象: Phase 0 が、どれを遅延リフレッシュするか決める前に、 (ticker, asset_class) ごとに取得する過去の実行の最大数です。
使用箇所: src/tools/institution/index.ts 内の runSingleTicker
未設定時のデフォルト: 10
クランプ範囲: [1, 50]
形式: 正の整数
設定するタイミング: 呼び出しごとのレイテンシを抑えるため、複数ティッカーを扱うおしゃべりなユーザーは (3-5) に下げます。小さなティッカー集合で、鮮度よりもリフレクティブなコンテキストが価値を持つ場合は (20+) に上げます。
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_RETROSPECT_TIMEOUT_MS`

Phase 0 の実時間です。

制御対象: institution 呼び出しごとに Phase 0 が遅延リフレッシュの書き込みに費やす合計時間に対するハードな上限です。実効タイムアウトは、 5 秒の下限付きで min(this var, INSTITUTION_WALL_CLOCK_TIMEOUT_MS / 2) です — Phase 1 開始時に、オーケストレーター（Phase 1-6）が宣言された実時間予算の少なくとも 50% を持つことを保証します。この上限がないと、60 秒のツール呼び出し予算が合計で 180 秒以上かかることがありました (codex review round 2)。
使用箇所: src/tools/institution/index.ts 内の runSingleTicker
未設定時のデフォルト: 120000（2 分）
クランプ範囲: [5000, INSTITUTION_WALL_CLOCK_TIMEOUT_MS / 2]
形式: 正の整数のミリ秒
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_LAZY_REFRESH_STALE_HOURS`

Phase 0 の陳腐化しきい値です。

制御対象: 過去の実行の最新のリフレクションは、その evaluated_at がこの時間数より古い場合に「陳腐」（かつ遅延リフレッシュの対象）とみなされます。小さい値は呼び出しごとに多くのリフレッシュを書き込みます（= コスト増 + より新しい PM コンテキスト）。大きい値は、鮮度の維持を日次 cron に頼ります。
使用箇所: src/learning/institution/reflect.ts 内の shouldWriteLazyRefresh
未設定時のデフォルト: 24
クランプ範囲: [1, 168]
形式: 正の整数の時間
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_LAZY_REFRESH_DEDUPE_HOURS`

Phase 0 の書き込み重複排除です。

制御対象: 同じ実行に対する連続した lazy_refresh 書き込みの間の最小時間です。 10 分間に 3 回呼び出された /institution BTC が、ほぼ同一のリフレクションを 3 つ生成するのを防ぎます — 2 回目と 3 回目の呼び出しは最初の行を再利用します。
使用箇所: src/learning/institution/reflect.ts 内の shouldWriteLazyRefresh
未設定時のデフォルト: 6
クランプ範囲: [1, 48]
形式: 正の整数の時間
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_AUTO_STALE_DAYS`

自動陳腐化への昇格しきい値です。

制御対象: open な institution 実行は、確定されないまま経過日数がこの日数を超えると auto_stale に昇格します。auto-stale の実行は引き続き Phase B のリフレクションを受け取りますが、PM の past_context 注入では重みが下げられます（PR 2 の下流配線）。
使用箇所: src/learning/institution/reflect.ts 内の runScheduledReflections
未設定時のデフォルト: 90
クランプ範囲: [30, 365]
形式: 正の整数の日数
設定の所在: ユーザー向け設定ではありません

`INSTITUTION_BENCHMARK_CRYPTO` / `INSTITUTION_BENCHMARK_STOCK` / `INSTITUTION_BENCHMARK_FOREX`

アセットクラスごとのアルファのベンチマークです。Phase B リフレクションのアルファは、同じウィンドウで raw_return - benchmark_return として計算されます。設定された価格ソースが解決できるティッカー（デフォルトは Yahoo）を設定します。

Defaults when unset: crypto → BTC stock → SPY forex → DXY
（commodity / stablecoin / unknown には意図的にベンチマークがありません
— それらのクラスではアルファは null として記録されます。）
形式: ティッカー文字列
設定の所在: ユーザー向け設定ではありません

アナリスト復旧

各 Phase-1 アナリストスロットは、モデルを自由なツール呼び出しループで実行し、続いて HEADLINE / KEY FINDINGS / CONFIDENCE 形式の構造化された散文要約を求める単一の統合ターンを実行します。オーケストレーターはその散文を直接 AnalystReport にパースします — 強制サブミットの toolChoice ステップも、リトライハーネスもありません。統合結果が空またはパース不能な場合、オーケストレーターは常に使用可能なレポートを出力する buildSubagentSummaryReport にフォールバックします(ツールが成功したときは生のツール出力から、そうでないときはロールのデフォルト推論で)。ダウンストリームの各段階は常に使用可能な要約を受け取り、従来の data_gap フラグは廃止されました。運用者がチューニングできる env 変数はありません — 契約は「常に使用可能な何かを生成する」であり、チューニングする予算はありません。

`INSTITUTION_FORCE_RESOLVER_PREFLIGHT`

常時オンの正規プリフライトです。

制御対象: デフォルトでは、サーバーサイドの正規アイデンティティプリフライトは classifyAsset(ticker) === "unknown" の場合にのみ実行されます。これを true に設定すると、すべてのティッカーでプリフライトを強制します。これは運用検証（リゾルバは有名なティッカーでも正しく動作するか？）に役立ちます。わずかなレイテンシコストがあります（キャッシュヒット約 50ms、キャッシュミス約 200-500ms）。
使用箇所: オーケストレーターのプリフライト段階です。
未設定時のデフォルト: false
指定可能な値: true / false / 1 / 0
設定の所在: ユーザー向け設定ではありません

Canonical Asset キャッシュ

canonical-asset リゾルバーは SQLite キャッシュを介して write-through するため、エージェントが 2 回目に同じティッカーを見たときは CoinGecko / CMC / DexScreener に再アクセスしません。TTL は結果ごとです — 一意の解決は曖昧なものより長くキャッシュされ得ますし、空の結果は速やかに期限切れになるため、プロバイダーがより多くのデータを公開した後で再試行します。

`CANONICAL_ASSET_CACHE_TTL_RESOLVED_DAYS`

outcome: "resolved"（単一の正規 chain+contract または native+chain）の TTL です。

使用箇所: src/learning/canonical-asset-cache.ts
未設定時のデフォルト: 30
形式: 正の整数の日数
設定の所在: ユーザー向け設定ではありません

`CANONICAL_ASSET_CACHE_TTL_MULTI_DAYS`

outcome: "multi"（マルチチェーン展開、例: 20 チェーン上の USDC）の TTL です。運用者/ユーザーによる曖昧性解消が特定のチェーンにピン留めする可能性があるため、resolved より短くなっています。

使用箇所: src/learning/canonical-asset-cache.ts
未設定時のデフォルト: 14
形式: 正の整数の日数
設定の所在: ユーザー向け設定ではありません

`CANONICAL_ASSET_CACHE_TTL_AMBIGUOUS_DAYS`

outcome: "ambiguous"（プロバイダの結果が食い違う、複数のトークン候補）の TTL です。プロバイダのデータが収束するか、ユーザーのオーバーライドがピン留めした後に再解決できるよう短くしています。

使用箇所: src/learning/canonical-asset-cache.ts
未設定時のデフォルト: 7
形式: 正の整数の日数
設定の所在: ユーザー向け設定ではありません

`CANONICAL_ASSET_CACHE_TTL_NONE_DAYS`

outcome: "none"（どのソースもデータを返さなかった）の TTL です。非常に短いです — プロバイダは日次で更新されるため、否定的な結果をキャッシュするより、早めに新たな試行を行いたいためです。

使用箇所: src/learning/canonical-asset-cache.ts
未設定時のデフォルト: 1
形式: 正の整数の日数
設定の所在: ユーザー向け設定ではありません

`CANONICAL_ASSET_CACHE_TTL_USER_DAYS`

ユーザー提供のエントリ（minara assets pin またはバナー CTA による運用者オーバーライド）の TTL です。ユーザーがどの正規を望むかを明示的に伝えているため長くなっています。ピンのエントリはプロバイダの解決に優先します。

使用箇所: src/learning/canonical-asset-cache.ts
未設定時のデフォルト: 365
形式: 正の整数の日数
設定の所在: ユーザー向け設定ではありません

`CANONICAL_ASSET_CACHE_FALLBACK_TO_EXPIRED`

陳腐なフォールバックのポリシーです。

制御対象: ライブアグリゲーターが失敗した場合（全プロバイダがダウンまたはレート制限）、リゾルバは (a) from_expired_fallback: true を付けた期限切れのキャッシュエントリを返す（true、デフォルト）か、 (b) その失敗を outcome: "none" として扱う（false）かのいずれかができます。数日前のトークン解決では、通常、陳腐なデータでもデータなしよりましです。デプロイがいかなるドリフトも許容できない場合は false に設定します。
使用箇所: src/learning/canonical-asset-resolver.ts
未設定時のデフォルト: true
指定可能な値: true / false / 1 / 0
設定の所在: ユーザー向け設定ではありません

ハイブリッドメモリ検索

これら 4 つの変数は、埋め込みで拡張されたメモリ検索を有効にします。 EMBEDDING_PROVIDER が disabled(デフォルト)の場合、ストアは全行の embedding_state='pending' と NULL の embedding カラムをそのままにし、 searchMemoriesHybrid は Phase-A 以前の BM25 経路にフォールバックしてバイト単位で同一の結果を返します。運用者はセマンティックリコールの向上を望むときにのみこれを有効化します — その時点から、すべての writeMemory / writeRoleMemory は queueMicrotask を介して非同期の埋め込みをスケジュールします(書き込み経路のレイテンシーコストなし)。失敗は決して呼び出し側に throw されません: embedding_state カラムが 'failed' / 'skipped' に移るため、minara doctor が滞留を検出でき、 minara doctor --fix --apply が後でバックフィルできます。

`EMBEDDING_PROVIDER`

どのプロバイダを呼び出すかです。

使用箇所: src/memory/embedding-provider.ts 内の createEmbeddingProviderFromEnv
Surfaced to: MemoryStore.searchMemoriesHybrid、 MemoryStore.scheduleEmbedding、MemoryStore.backfillEmbeddings
指定可能な値: disabled | openai | voyage
未設定時のデフォルト: disabled
disabled の場合、ファクトリは null を返します — ハイブリッドのコードパスは
完全に不活性で、Phase A 以前のコードと同じ挙動になります。EMBEDDING_API_KEY も
設定されている場合にのみ実際のプロバイダを設定してください。そうでなければ、
ファクトリは依然として null を返します（警告がログされます）。
設定の所在: ユーザー向け設定ではありません

`EMBEDDING_API_KEY`

設定されたプロバイダのベアラートークンです。

OpenAI: https://platform.openai.com/api-keys から取得します（sk-...）。
Voyage: https://dash.voyageai.com/api-keys から取得します（pa-...）。
未設定時のデフォルト: （プロバイダは null を返し、ハイブリッドパスは不活性）
形式: 不透明な文字列。引用符は不要です。
設定の所在: 設定 → API キー

`EMBEDDING_MODEL`

モデル識別子です。

デフォルトは各プロバイダで最も安価な 1536 次元モデルを追従し、vec0 テーブルの
サイズが EMBEDDING_DIM のデフォルトと揃うようにします: - openai → text-embedding-3-small - voyage → voyage-3
次元が EMBEDDING_DIM と一致することを検証した場合にのみ上書きしてください。
不一致は埋め込み時に拒否され（警告がログされ、
行は 'failed' のままになります）。
設定の所在: ユーザー向け設定ではありません

`EMBEDDING_DIM`

ベクトルの次元数です。

モデルと一致する必要があります。デフォルト: 1536。起動時に vec0
仮想テーブル（memories_vec、role_memory_vec）を宣言するために使われます —
既存の DB でこれを変更するには、vec0 テーブルの手動マイグレーションが
必要です（drop + 再作成。埋め込みは非権威的なため、
doctor --fix --apply で損失を復元できます）。
形式: 正の整数。
設定の所在: ユーザー向け設定ではありません

`EMBEDDING_BASE_URL`

プロバイダの HTTP エンドポイントの任意の上書きです。

未設定時のデフォルト: プロバイダネイティブの URL です。 - openai → https://api.openai.com/v1/embeddings - voyage → https://api.voyageai.com/v1/embeddings
セルフホストのゲートウェイやプロキシに使います。形式: /embeddings で
終わる完全な URL です。
設定の所在: ユーザー向け設定ではありません

`SQLITE_VEC_EXTENSION_PATH`

sqlite-vec のロード可能な拡張バイナリへの明示的なパスです。

使用箇所: src/memory/memory-store.ts 内の MemoryStore.tryEnableVec
未設定時のデフォルト: sqlite-vec npm パッケージにバンドルされたプラットフォーム
バイナリ（getLoadablePath() で解決）です。運用者は、バイナリを
自己管理する場合（例: 共有システムパス、カスタムビルド、または兄弟の
sqlite-vec-<platform>-<arch> パッケージを node_modules から取り除く
Docker レイヤー）にのみこれを設定します。
形式: .so/.dylib/.dll への絶対ファイルシステムパスです。ロードの失敗は
致命的ではありません — ハイブリッドパスは黙って純粋な BM25 に劣化します。
設定の所在: ユーザー向け設定ではありません

バックテストフィードバックループ

目次