context-foundry

Foundry

計画、構築、レビュー、学習を行う自律型ビルドループです。

Foundry は TASKS.md のタスクリストを読み込み、TUI で Claude Code エージェントを使って順に作業し、完了したタスクごとにコミットします。次に何をするかは、複数の実行モードで制御できます。ディスカバリーを行いながら無期限に実行する（Auto）、完了したら停止する（Sprint）、各タスクの後に人間のレビューを待つ（Review）、またはビルドサービスとして無人で実行する（Service）を選べます。

パイプラインを使う場面： このハーネスは、検証可能なエンジニアリング作業の効果を高めます。つまり、プランナーが根拠として確認できる file:line 参照、監査役がチェックできる制約、そして BUILD または AUDIT がコードに対して実行できる動作を含むタスクです。文章作成（README の更新、ブレインストーミング、アーキテクチャ決定記録、ドキュメントの書き直し）では、検証するものがないため、計画レビューと監査のコストがかかるだけで、追加の効果はありません。こうした作業は直接行ってください。詳しいガイダンスは docs/task-composition.md を参照してください。

デモ

• ループでセカンドブレインを構築する — Foundry が実装計画に沿って自律的に作業し、タスクリストからセカンドブレインアプリを構築します。TUI では各エージェントの出力がリアルタイムで表示されます。
• ループでセカンドブレインを強化する — Foundry が前回の続きから作業を再開し、新しい作業を見つけて、初回の実行で学んだパターンを活用しながらセカンドブレインアプリを反復的に改善する、フォローアップの実行です。
• 技術概要 — パイプライン、デュアルモデルアリーナ、Git 統合、TUI レイアウト、設定、プラグイン、MCP ツールなど、すべてのサブシステムを網羅したアーキテクチャのリファレンスです。
• ラウンドアップ — ソフトウェアアーキテクト向けに Context Foundry を紹介する、テキサスをテーマにしたプレゼンテーションページです。

タスクフロー

Load patterns from ~/.foundry/patterns/
  │
SCOUT → .buildloop/scout-report.md (investigate codebase)
  │
PLAN (+ patterns + scout report) → .buildloop/current-plan.md
  │
IMPLEMENT → build the code, run checks
  │
VERIFY (fresh context) → audit claims, fix issues, write verdict
  │
PATTERN EXTRACTOR → merge into ~/.foundry/patterns/
  │
LOCAL GIT COMMIT → feat(task_id) or WIP(task_id)
  │
OPTIONAL AUTO-PUSH → only if `auto_push_remote` is configured

仕組み

Foundry は Claude Code のハーネスです。各エージェント（プランナー、ビルダー、レビュアー、修正担当、ディスカバラー）は、役割ごとのプロンプトと限定されたツールアクセス権を持つ Claude Code CLI の呼び出しです。Rust バイナリがオーケストレーション、ストリーミング、状態管理を担い、推論とファイル編集はすべて Claude が行います。

ループ

ガードレールがなければ、自律型ビルドループはすぐに劣化します。タスク 3 はタスク 2 の誤りを引き継ぎ、タスク 2 はタスク 1 の誤りを引き継ぎます。エラーは積み重なり、コードベースは意図したアーキテクチャから逸れていきます。

中核となる設計原則は、どのエージェントもほかのエージェントとコンテキストウィンドウを共有しないことです。 すべての段階はクリーンなコンテキストから始まり、前の段階で作成された成果物のうち、厳選されたものだけを受け取ります。スカウトは構造化されたレポートを書きます。プランナーはそのレポートを読み、計画を書きます。ビルダーはその計画を読み、コードを書きます。検証者は、そのコードがなぜそのように書かれたのかを一切知らずにコードを読みます。会話履歴の共有も、推論の蓄積も、見落としの継承もありません。各段階が受け取るのは、ノイズではなく有用な情報です。これにより Foundry は、長いタスクキューを通じてエラーが積み重なるのを防ぎます。

Foundry のループは、2 種類のバックプレッシャーを中心に設計されています。

短期的な対策：検証ゲート。 実装後、ビルダーと履歴を共有しない完全に新しいコンテキストで、検証エージェントがビルドチェック、テスト、構造化されたコード監査を実行して変更を監査します。コードを書いたばかりのモデルは自身の推論を保持しているため、自分の判断に疑問を持ちにくくなります。主張とコードだけを与えられた独立したインスタンスは、作成者が見落としているバグを見つけます。HIGH または MEDIUM の問題が見つかった場合は修正し、検証を再実行します。すべてに合格した場合、タスクは feat(task-id) コミットになります。問題が残っている場合は、WIP(task-id) コミットになります。検証ゲートにより、不適切なコードが検知されずに次へ進むことを防ぎます。 パイプラインの追跡（QRPBA）。 すべてのタスクには、実行されたパイプラインの段階と、それぞれの成功 여부を記録する進捗インジケーターが付いています。このインジケーターは各タスクの横にある TASKS.md に保存され、コードとともにコミットされるため、永続的な監査記録が残ります。

- [x] T1.1: Set up project scaffolding          [QRPBA]
- [x] T1.2: Implement auth flow                 [--PBA]
- [x] T1.3: Add rate limiting                   [QRPBA!]
- [ ] T1.4: Write integration tests             [....]

各文字はパイプラインの段階を表します。

位置	文字	段階	意味
1	Q	クエリ	- = スキップ
2	R	リサーチ	- = スキップ
3	P	プラン	- = スキップ（単純なタスク）
4	B	ビルド	ビルダーを実行
5	A	監査	- = スキップ
接尾辞	!		監査に合格しなかった（WIP コミット）

例：QRPBA = パイプライン全体を実行し、問題なく完了。--PBA = クエリとリサーチをスキップし、計画、ビルド、監査を実施。QRPBA! = パイプライン全体を実行したものの、監査で修正不能な問題が見つかった（WIP コミット）。詳しくは docs/progress-indicators.md を参照してください。

TUI では、タスクキュー内のこれらのインジケーターが色分けして表示されます。また、タスクファイルに直接書き込まれるため、再起動後も保持されます。

キュレーションされたコンテキストが重要な理由。 この分離コンテキストアーキテクチャは、本番環境でのベストプラクティスとして Anthropic の Claude Certified Architect プログラムで説明されている、複数インスタンスによるレビューのパターンと同じです。要点は、エージェント同士が会話履歴を共有するのではなく、構造化されたファイル成果物（.buildloop/scout-report.md、current-plan.md、build-claims.md、review-report.md）を介してやり取りすることです。すべての成果物はキュレーションされた引き継ぎ資料です。プランナーはスカウトのツール呼び出し履歴全体を受け取るのではなく、簡潔なレポートを受け取ります。ビルダーはプランナーの推論を受け取るのではなく、ファイル操作と検証コマンドを含む決定論的な計画を受け取ります。

長期的な改善：パターン学習。 検証済みのタスクを完了するたびに、パターン抽出エージェントがビルド成果物、レビューでの指摘、計画を調べ、再利用可能な教訓（例：「Roblox のパーツを動かすときは Position ではなく CFrame を使う」「文字列をスライスする前に UTF-8 の境界を必ず検証する」）を抽出します。これらは構造化 JSON として ~/.foundry/patterns/ に保存されます。次のタスクでは、どのプロジェクトであっても、一致するパターンが参照データとしてプランナーとレビュアーのプロンプトに挿入されます。3 回以上繰り返し現れたパターンは自動的に昇格（auto_apply）され、一致した際の評価が高くなります。ただし、対象に含めるには、タスクとのキーワードまたは tech_stack の重複が少なくとも 1 つ必要です。こうしてシステムは時間とともに改善されます。一度起きたミスが、あらゆる場所で適用されるチェックになるのです。

複雑さに応じて調整されるパイプライン。 すべてのタスクにパイプライン全体が必要なわけではありません。タスクの複雑度分類器は、説明の長さ、キーワードのシグナル、ファイル数のヒントに基づいて、各タスクを単純、中程度、複雑に分類します。単純なタスクではクエリ、リサーチ、プランナーをスキップし、使用するパターン数を減らし（10 件ではなく 0～2 件）、監査ループ全体を省略してビルダーから直接コミットすることもできます。QRPBA インジケーターはこれを反映します。---B- はクエリ、リサーチ、プランナー、監査をすべてスキップしたことを意味します。複雑なタスクでは常に、すべての工程を実施します。

学習された疑念の信頼度。 疑念ループは、Ollama の埋め込みを使った意味的なクラスタリングにより、タスクの形状ごとに合否の履歴を追跡します。レビューに連続して 5 回以上問題なく合格したタスクの説明は「信頼済み」となり、疑念ループを自動的にスキップします。失敗すると、該当するクラスタはゼロにリセットされます。この仕組みは時間とともに効果を積み重ね、foundry はどの種類の変更を確実に正しく行えるかを学習し、必要な箇所に徹底的なレビューを割り当てます。

並列ビルダー。 複数ファイルにまたがるタスクでは、ビルダーを複数の並列サブエージェントに分割できます。計画の「ファイル操作」セクションを解析して依存関係グラフを作成し、相互参照のないファイルは並列ワークツリーで処理し、依存するファイルは順次処理します。マージによる統合上の問題は、疑念ループで検出します。.foundry.json で parallel_builder: true を指定すると有効になります。 セッションイベントのロギング。 すべてのパイプラインイベント（タスクの開始、エージェントの完了、レビュー結果、コミット、パターンの使用、レート制限）は、JSON 行として ~/.foundry/observatory/events.jsonl に追加されます。これは、今後提供予定の Foundry Observatory 分析ダッシュボード（別プロジェクト）のデータ収集レイヤーです。ベストエフォートで記録し、パイプラインを停止させることはありません。

CCA との整合性

Context Foundry のアーキテクチャは、Anthropic の Claude Certified Architect -- Foundations 試験ガイドに記載された原則に沿っています。55 の原則のうち 43 を実装済みで、3 つは部分的に実装済み（アーキテクチャ上の制約）、未対応の原則は 0 です。各原則と該当するコードの場所を対応付けた完全なクロスリファレンスマッピングは、CCA Alignment Matrix（インタラクティブ版）をご覧ください。

実行モード

Foundry には、タスク間でパイプラインをどのように進めるかを制御する複数の実行モードがあります。起動画面で Ctrl+M を押して切り替えるか、.foundry.json で run_mode を設定します。

モード	動作	新規タスクの検出	PR
Auto（デフォルト）	すべてのタスクを実行した後、新しい作業を検出して無期限に続行します	はい	いいえ
Sprint	すべてのタスクを実行した後、停止します	いいえ	いいえ
Review	一度に 1 つのタスクを実行し、タスクごとに PR を作成して、承認を待ちます	いいえ	はい（タスクごと）
Coach	Scout の前に SPEC.md を明確化するインテーク前チェックを実行し、その後 Auto と同様に進みます	はい	いいえ
Service	無人のビルドサービスモードです。すべてのタスクを実行した後に停止し、WIP／監査失敗のタスクは終了扱いになります（再試行なし）	いいえ	いいえ

Auto は完全自律モードです。ループは自動では停止しません。タスクキューが空になると、検出エージェントがコードベースをスキャンして新しい作業を見つけ、TASKS.md に追加します。デモ動画で紹介されているのはこのモードです。

Sprint は半自律モードです。Auto と同じパイプライン（調査、計画、実装、検証、コミット）ですべての保留中タスクを処理しますが、キューが空になると、新規タスクの検出を行わずに停止します。既知のタスクリストがあり、foundry に新たな作業を見つけさせず、既存のタスクを完了させたい場合に使用します。

Review は、チームのワークフロー向けのヒューマン・イン・ザ・ループモードです。各タスクの完了後、foundry は機能ブランチ（foundry/{task_id}）をプッシュして GitHub PR を作成し、一時停止します。TUI に PAUSED (Review) と表示され、次のいずれかを待ちます。

• ユーザーが Enter キーを押して手動で続行する
• GitHub PR が承認される。foundry は gh pr view をポーリングして承認を検出します（pr_poll_interval_secs で設定可能。デフォルトは 30 秒です）

レビュアーから変更が求められた場合、そのステータスが TUI に表示されます。Review モードを使用するには、gh CLI がインストールされ、認証済みである必要があります。

{
  "run_mode": "review",
  "pr_poll_interval_secs": 30,
  "create_issue_on_wip": true
}

create_issue_on_wip フラグは、どのモードでも使用できます。タスクの検証に失敗して WIP() コミットが作成されると、foundry はレビュー結果を含む GitHub Issue を自動作成します。

Service は、Context Foundry ビルドサービス（foundry serve）が使用する無人モードです。Sprint と同様、保留中のタスクをすべて実行した後、新規タスクの検出を行わずに停止します。さらに、WIP／監査失敗のタスクを終了扱いにします。タスクには失敗インジケーター ! と WIP() コミットが記録され、再試行や連続 WIP による停止を行わずに、ループは次のタスクへ進みます。このモードでのヘッドレス実行（--no-tui）では、バックグラウンドでの GitHub 更新チェックもスキップされます。Service は自動化された、実行範囲の限定されたビルドジョブ向けであり、対話的な使用を想定していません。

デュアルモデルアリーナ

Foundry は、異なる AI プロバイダーを使ってタスクを実行できます。起動画面で Ctrl+D を押すか、.foundry.json で dual_selection を設定すると切り替えられます。

設定： builder_models に 2 つのプロバイダーを定義します。

{
  "builder_models": ["claude:opus", "codex:"],
  "dual_selection": "both"
}

各エントリーは provider:model の形式です。たとえば、claude:opus や codex:（モデルを空にすると、プロバイダーのデフォルトが使用されます）です。

選択モードは 3 つあります（Ctrl+D で切り替え）：

モード	動作
最初のみ	パイプライン全体（Scout -> Plan -> Implement -> Verify）を builder_models[0] で実行します
2 番目のみ	パイプライン全体を builder_models[1] で実行します
両方	2 つの完全に独立したパイプラインを、プロバイダーごとに 1 つずつ並列実行します

重要な設計原則：プロバイダーの選択はステージごとではなく、パイプライン全体に適用されます。 「Codex」を選択すると、偵察、計画、実装、レビュー、調査を含むすべてのステージが Codex で実行されます。Foundry は、選択したプロバイダーに属さないモデル名を自動的にクリアします（たとえば、「sonnet」は Claude のモデル名なので、Codex で実行する際は空になり、Codex のデフォルトが使用されます）。これにより、「モデル 'sonnet' は Codex ではサポートされていません」のようなエラーを防ぎます。

**デュアルモード（「両方」）**では、Scout の実行前に 2 つの git worktree に分岐し、完全に独立した 2 つのパイプラインを実行します。

Pipeline A (Claude)                    Pipeline B (Codex)
.buildloop/arena/claude/               .buildloop/arena/codex/
  scout-report.md                        scout-report.md
  current-plan.md                        current-plan.md
  build-claims.md                        build-claims.md
  review-report.md                       review-report.md

各モデルは、それぞれ独自のコードベースを確認し、独自の計画を作成し、独自のソリューションを実装し、その出力を検証します。人間は、同じ計画に基づく 2 つの実装ではなく、独立したアーキテクチャ上の判断に基づく 2 つの完成した成果を比較できます。

デュアルモードでの TUI： 1 を押すとパイプライン A の出力が、2 を押すとパイプライン B の出力が表示されます。タブバーには各ストリームのイベント数が表示されます。パイプライン図には、各パイプラインが現在どのステージにあるかが表示されます。両方が完了すると、アリーナの結果は手動で比較できるよう .buildloop/arena/ に保存されます。foundry が自動的に勝者を選ぶことはありません。

グローバル設定： ~/.foundry/config.json の設定は、すべてのプロジェクトにデフォルトとして適用されます。プロジェクトレベルの .foundry.json のフィールドは、グローバル値を上書きします。これにより、各プロジェクトで設定する代わりに、builder_models と dual_selection をグローバルに一度だけ設定できます。

Docker サンドボックスの分離

Foundry は Docker コンテナー内でエージェントを実行できるため、エージェントにはプロジェクトディレクトリのみが表示され、ホームフォルダー、認証情報、その他のリポジトリにはアクセスできません。Docker が検出されるとサンドボックスはデフォルトで ON になり、Docker がない場合は警告とともに OFF になります。

セットアップ：

1. Docker Desktop（macOS/Windows）または Docker Engine（Linux）をインストールします
2. サンドボックスイメージをビルドします。

   bash docker/build-sandbox.sh
   

3. foundry を通常どおり実行します。イメージは自動的に検出されます

TUI では、ヘッダー（[sandboxed] は緑、Docker またはイメージがない場合の [sandbox degraded] は黄、設定で無効にした場合の [sandbox disabled] は赤）、統計パネル、起動画面にサンドボックスの状態が表示されます。

仕組み： サンドボックスが有効な場合、foundry は各エージェントの CLI 呼び出しを docker run でラップし、プロジェクトディレクトリを /work にバインドマウントします。コンテナーは非 root ユーザー（UID 1000）として実行されます。ANTHROPIC_API_KEY は自動的に転送されます。PTY バックエンドが強制されます（tmux はコンテナー内のエージェントと互換性がありません）。

設定（.foundry.json 内）：

{
  "sandbox": true,
  "sandbox_image": "foundry-sandbox:latest",
  "sandbox_extra_mounts": ["/data:/data:ro"]
}

フィールド	デフォルト	目的
sandbox	true	サンドボックスによる分離を有効／無効にします
sandbox_image	"foundry-sandbox:latest"	サンドボックスコンテナーに使用する Docker イメージ
sandbox_extra_mounts	[]	追加のバインドマウント（共有キャッシュなど）

フォールバック動作： Docker がインストールされていない場合、またはイメージがビルドされていない場合、foundry は TUI に黄色の警告を表示し、ホスト上でエージェントを直接実行します。設定を変更する必要はありません。

Windows： Docker Desktop の WSL2 バックエンド向けにパスが自動的に変換されます（C:\Users\... は /c/Users/... になります）。

パターンのマッチングと注入

各タスクの開始時に、foundry は ~/.foundry/patterns/ からすべてのパターンを読み込み、タスクの説明と照合します。照合にはキーワードスコアリングを使用します。各パターンには keywords フィールドと tech_stack フィールドがあり、タスクの説明内で単語全体が一致するとポイントが加算されます。Ollama がローカルで実行されている場合は、セマンティック（埋め込み）マッチングも再ランキングに使用されます。

マッチしたパターンは整形され、参照データとしてプランナーエージェントとレビュアーエージェントのプロンプトに注入されます。TUI では、これを次の 2 か所で追跡します。

指標	場所	意味
Injected	パターンパネル＋統計行	エージェントのプロンプトにマッチして注入されたパターン
Learned	パターンパネル	ビルド成果物から抽出された新しいパターン
Applied	統計行	キーワードがエージェントの出力に含まれていた注入済みパターン（エージェントがその助言を使用した可能性があります）

3 つのカウンターはいずれもセッション単位です。foundry の起動時にリセットされ、複数のタスクにわたって累積します。同じパターンが複数回注入されることがあります（一致するタスクごとに 1 回）。

Ollama によるセマンティックマッチング

パターンとタスクに明らかな共通用語がある場合、キーワードマッチングはうまく機能しますが、意味的なつながりを見落とすことがあります。「korg 808 emulator を作る」のようなタスクは、オーディオ／DSP の設計パターンと一致するべきですが、パターンのキーワードが「oscillator」「waveform」「sample rate」の場合、これらの単語はタスクの説明に含まれていないため一致しません。厳密なキーワードマッチングで見つけられるのは、あらかじめ検索対象として指定された内容だけであり、一般化はできません。

Ollama がローカルで実行されている場合、foundry は埋め込みベースのセマンティックマッチングを使用して、この差を埋めます。タスクの説明とパターンのテキストはローカルモデルを介してベクトル埋め込みに変換され、コサイン類似度によって、キーワードが一つも共通していなくても概念的に関連するパターンを特定します。セマンティックスコアは、キーワードスコアへの再ランキング用の加点として使われます。キーワードマッチングは常にベースラインであり、セマンティックマッチングがそれを補強します。

セットアップ：

1. Ollama をインストールします
2. 埋め込みモデルを取得します：

   ollama pull nomic-embed-text
   

3. Ollama を起動します（またはバックグラウンドサービスとして実行します）

これで完了です。Foundry は起動時に Ollama を自動的に検出します。デフォルトのセットアップでは設定は不要です。

モデルの選択： nomic-embed-text は、パラメーター数 137M の埋め込みモデル（約 274 MB）です。foundry と併せてどのマシンでも実行でき、リソースへの影響も目立ちません。また、パターンとタスクのマッチングには十分な埋め込み品質を備えています。これはチャットモデルではなく、類似性の比較に使うベクトル埋め込みのみを生成します。

設定（すべて任意で、.foundry.json に記述します）：

{
  "semantic_match_enabled": true,
  "embedding_model": "nomic-embed-text",
  "ollama_url": "http://127.0.0.1:11435",
  "embedding_timeout_ms": 2000
}

フィールド	デフォルト	用途
semantic_match_enabled	true	false に設定すると、セマンティックマッチングを完全に無効にします
embedding_model	"nomic-embed-text"	埋め込みに使用する Ollama モデル名
ollama_url	"http://127.0.0.1:11435"	Ollama API エンドポイント
embedding_timeout_ms	2000	埋め込みリクエストごとのタイムアウト（ms）

グレースフルデグラデーション： Ollama が実行されていない場合、モデルが取得されていない場合、またはリクエストに失敗した場合、foundry はユーザーの操作なしにキーワードのみのマッチングにフォールバックします。サーキットブレーカーにより、失敗後 60 秒間は再試行が抑制されるため、停止中の Ollama インスタンスによってタスクごとに遅延が発生することはありません。TUI には、使用されたマッチングモード（semantic、keyword-only、cooldown）が記録されます。

埋め込みキャッシュ： パターンの埋め込みは ~/.foundry/cache/pattern-embeddings.json にキャッシュされます。キャッシュキーには各パターンの内容の blake3 ハッシュが使われるため、パターンが変更されると自動的に無効化されます。キャッシュが温まっている場合、パターンに対する Ollama 呼び出しは発生せず、埋め込みが必要なのはタスクの説明だけです。

パターンの適用範囲

パターンはデフォルトでグローバルに適用されます。~/.foundry/patterns/ に保存され、マシン上のすべてのプロジェクトで読み込まれます。プロジェクト A の構築で得た教訓は、プロジェクト B の構築時にも利用できます。

プロジェクトごとに分離したい場合は、.foundry.json の patterns_dir にプロジェクト内のパスを設定してください。

検出

Auto モードでは、TASKS.md のすべてのタスクが完了しても Foundry は停止しません。検出エージェントがコードベースをスキャンし、アーキテクチャドキュメントを読み、TODO や FIXME を探し、失敗したテストを確認し、不整合を見つけて、新しいタスクを TASKS.md に追加します。その後、ループがそれらのタスクに取り組みます。検出するものが見つからない場合は、クールダウン時間を段階的に延ばして待機します（discovery_cooldown_minutes で設定可能）。Sprint モードと Review モードでは検出は無効になり、キューが空になるとパイプラインは停止します。

ローカルモデル（LM Studio + opencode）

Foundry は、Claude または Codex の代わりに、ローカルの LM Studio（または Ollama）モデルを通じてビルドパイプラインを実行できます。設定オーバーレイでローカルモデルを選択すると、builder_provider が opencode に切り替わり、起動したエージェントは opencode CLI を通じて実行されます。この CLI は、http://127.0.0.1:1234 にある LM Studio の OpenAI 互換サーバーと通信します。

ローカルモデルの選択。 TUI で ? を押して設定オーバーレイを開きます。「Builder」行には、Claude / Codex のすべての仕様に加え、LM Studio の /v1/models と Ollama の /api/tags から検出されたすべてのモデルが表示されます。LM Studio の項目を選択すると、builder_provider = "opencode" と builder_model = "lmstudio/<id>" が .foundry.json に保存されます。正規の ID 一覧は opencode models lmstudio から取得できます。コマンドラインでこれを実行すると、opencode が受け付ける正確な ID を確認できます。

パイプライン全体のルーティング。 選択したビルダー仕様が opencode:... の場合、Config::for_pipeline()（src/config.rs）はすべての役割のプロバイダーを上書きし、8 つすべてのステージ（scout、query、research、planner、builder、reviewer、fixer、discovery）を opencode に設定して、同じモデルを再利用します。そのため、ローカルモデルの選択は「builder のみ」ではなく、パイプライン全体が選択した LM Studio モデルを通じて実行されます。

n_ctx の必須値。 Foundry のプロンプトと agent_system_directives を合わせると、トークン数が 4096 を超えることがよくあります。LM Studio モデルは n_ctx >= 8192 で読み込んでください。ウィンドウが小さいと [error/ContextOverflow] イベント（src/agent.rs で定義されている AgentErrorKind::ContextOverflow）が発生し、エージェントの実行は中断されます。ほかに、同様に通知される型付きエラーとして、ProviderUnreachable（LM Studio が実行されていない）と ModelNotLoaded（要求されたモデルが LM Studio に読み込まれていない）があります。

スモークゲート。 ローカルモデルの経路を利用する前に、bash scripts/smoke-local-model.sh を実行してください。このスクリプトは一時的なプロジェクトを作成し、foundry run --no-tui --output-format json を実行して、6 項目（終了コード、JSON エンベロープの形式、ログの存在、opencode セッションマーカー、型付きエラーがないこと、QRPBA インジケーター）を検証します。ワークスペースを保持して調査するには、--keep を渡してください。

ヘッドレス JSON エンベロープ。 foundry run --no-tui --output-format json は、tasks、session、config ブロックを含むバージョン付きオブジェクト（schema_version: 2）を出力します。フィールドごとのスキーマと各チェックの失敗の解釈については、docs/local-model-setup.md に記載されています。

空の差分とアイドルタイムアウト。 ローカルモデルでは、ファイルを変更しないエージェント出力が生成されたり、生成中に停止したりすることがあります。Foundry は両方に対処します。EmptyDeliverable ゲートは feat ではなく WIP としてコミットし、アイドルタイムアウト（agent_implement_idle_secs、デフォルトは 60 秒）は停止したサブプロセスを終了します。ローカルモデルのランブックにある「空の差分の WIP とアイドルタイムアウトの動作」セクションを参照してください。

ランブック全体（前提条件、コマンドの記録、失敗の解釈ガイド）については、docs/local-model-setup.md を参照してください。

設定オーバーレイ

TUI で ? を押すと設定オーバーレイが開きます。約 40 個のユーザー設定可能な構成項目が、折りたたみ可能な 11 個のセクションに整理された、90%x80% のモーダルです。どの状態からでも Esc を押すか、モーダルの外側をクリックするか、[ X ] ボタンをクリックすると閉じます。変更は保存確認後に .foundry.json に保存されます。

オーバーレイでは、インライン編集（ブール値は Space/Enter、列挙型は Left/Right、数値は数値入力、文字列は自由入力）と、ステージごとにプロバイダーやモデルを選択できるモデルピッカーのドロップダウンに対応しています。

全体的なリファレンス（セクション、項目、編集ルール、モデルピッカーの動作）については、docs/settings-overlay.md を参照してください。

ステージ別ルーティング

デフォルトでは、すべてのパイプラインステージは Ctrl+D または設定オーバーレイの Builder 行で選択した単一のプロバイダーを経由します。ステージ別ルーティングの上書きを使うと、個々のステージを別々のプロバイダーに固定できます。たとえば、Plan と Audit では Claude Opus を使い、Build では Codex を使えます。

ステージを固定するには、設定オーバーレイの Routing セクションでそのステージのモデルピッカーを開き、モデルを選択します。そのステージは .foundry.json の stage_overrides に追加され、グローバルな Builder の切り替えの影響を受けなくなります。

設定 JSON の形式、実行時の解決方法、具体例については、docs/per-stage-routing.md を参照してください。

インストール

ビルド済みバイナリ

GitHub Releases からダウンロードしてください。

プラットフォーム	ファイル
macOS（Apple Silicon）	foundry-aarch64-apple-darwin.tar.gz
macOS（Intel）	foundry-x86_64-apple-darwin.tar.gz
Linux（x86_64）	foundry-x86_64-unknown-linux-gnu.tar.gz
Windows（x86_64）	foundry-x86_64-pc-windows-msvc.zip

展開し、PATH に含まれるディレクトリに移動してください。macOS/Linux の場合：

tar xzf foundry-*.tar.gz
sudo mv foundry /usr/local/bin/

Windows（PowerShell）の場合：

Expand-Archive foundry-x86_64-pc-windows-msvc.zip -DestinationPath .

Rust がインストールされている場合、%USERPROFILE%\.cargo\bin\ はすでに PATH に含まれています。

Move-Item foundry.exe C:\Users\$env:USERNAME\.cargo\bin\

Rust がインストールされていない場合は、任意の場所に配置し、そのフォルダーを PATH に追加してください。

mkdir C:\tools
Move-Item foundry.exe C:\tools\
[Environment]::SetEnvironmentVariable("Path", $env:Path + ";C:\tools", "User")

新しいターミナルを開けば、どのディレクトリからでも foundry を実行できます。

ソースから（全プラットフォーム）

Rust と Claude Code CLI が必要です。

cargo install --git https://github.com/context-foundry/context-foundry foundry

macOS（Homebrew）

brew tap context-foundry/tap
brew install foundry

Windows（ソースから、手順）

署名されていないバイナリがブロックされる、制限の厳しいマシンでは、ソースからコンパイルしてください。

1. Rust をインストールします（cargo が含まれます）。
2. Visual Studio Build Tools をインストールします（「C++ build tools」ワークロードを選択してください）。
3. PowerShell で実行します。

git clone https://github.com/context-foundry/context-foundry.git
cd context-foundry
cargo install --path .

バイナリはソースからお使いのマシン上でコンパイルされるため、署名されていないダウンロードや SmartScreen の警告はありません。foundry.exe は %USERPROFILE%\.cargo\bin\ に配置されます。

または、Claude Code をお使いの場合は、次のプロンプトを貼り付けてすべて任せることができます。

Context Foundry をクローンしてビルドしてください。実行するコマンド：git clone https://github.com/context-foundry/context-foundry.git && cd context-foundry && cargo install --path .

セルフアップデート

foundry update

使い方

TASKS.md がある任意のプロジェクトディレクトリを foundry に指定してください。

# TUI mode (default)
foundry --dir /path/to/project

# Interactive prompt-driven studio for Claude, Codex, or both
foundry --dir /path/to/project studio

# Headless mode (CI/logs)
foundry --dir /path/to/project run --no-tui

# Check progress
foundry --dir /path/to/project status

# List all tasks
foundry --dir /path/to/project tasks

# Self-update to latest release
foundry update

Studio は、自律型の run ループとは異なるワークフローであるため、docs/foundry-studio-readme.md に別途記載されています。

プロジェクトのセットアップ

開始するには、プロジェクトに 2 つのファイルが必要です。

1. TASKS.md — タスクリスト（foundry が読み込み、完了したタスクに印を付けます）。

   ## Phase 1
   - [ ] 1.1: Set up project scaffolding
   - [ ] 1.2: Implement authentication
   

2. SPEC.md — プロジェクト仕様（説明から自動生成され、エージェントがコンテキストとして読み込みます）

任意：

• .foundry.json — デフォルト設定を上書きします。

  {
    "run_mode": "auto",
    "planner_model": "opus",
    "builder_model": "sonnet",
    "reviewer_model": "opus",
    "fixer_model": "opus",
    "patterns_dir": "~/.foundry/patterns",
    "auto_push_remote": "snedea"
  }
  

• CLAUDE.md — プロジェクトの規約（エージェントはこれも読み込みます）。

引き続き ARCHITECTURE.md と IMPL_PLAN.md を使用している既存のプロジェクトも動作します。両方が存在する場合、foundry は SPEC.md と TASKS.md を優先します。

フック

Foundry は各タスクのコミット後にシェルコマンドを実行できます。.foundry.json で on_task_complete を設定します。

{
  "on_task_complete": "osascript -e 'display notification \"Task done\" with title \"Foundry\"'"
}

HTTP Webhook にも対応しています。

{
  "on_task_complete": "curl -fsS -X POST -H 'Content-Type: application/json' -d \"{\\\"task\\\":\\\"$FOUNDRY_TASK_ID\\\",\\\"status\\\":\\\"$FOUNDRY_TASK_STATUS\\\",\\\"sha\\\":\\\"$FOUNDRY_COMMIT_SHA\\\",\\\"desc\\\":\\\"$FOUNDRY_TASK_DESC\\\"}\" https://example.com/foundry-webhook"
}

コマンドは、cwd をプロジェクトディレクトリに設定して sh -c 経由で実行されます。次の 4 つの環境変数がエクスポートされます。

変数	値
FOUNDRY_TASK_ID	TASKS.md のタスク ID（例：T1.1）
FOUNDRY_TASK_STATUS	doubt に合格した場合は feat、失敗した場合は WIP
FOUNDRY_TASK_DESC	タスクの説明。100 文字で切り詰められます
FOUNDRY_COMMIT_SHA	タスクで生成されたコミット SHA（コミットが作成されなかった場合は空文字列）

このフックは起動後に処理を待たずに続行します。Foundry は tokio::spawn 経由でフックを起動し、完了を待たずに次のタスクへ進みます。ゼロ以外の終了コードはバックグラウンドの警告として記録されます（on_task_complete hook exited non-zero (...)）が、パイプラインが停止することはありません。stdout と stderr は破棄されます。出力が必要な場合は、フック内からファイルにログを記録してください。

フックは、すべての実行モード（auto、sprint、review）で、コミットされたすべてのタスクに対して実行されます。成功（feat(T1.1):）と失敗（WIP(T1.1):）のどちらのコミットでも起動します。成功と失敗で処理を分けたい場合は、フック内で FOUNDRY_TASK_STATUS を使用してください。

実装箇所：src/config.rs:403-409（設定フィールド）、src/app/build.rs:5937-5981（spawn_completion_hook）。

パイプラインのステージ

Foundry のパイプラインは、.foundry.json の pipeline_stages フィールドで設定します。完了したタスクには QRPBA インジケーターが使用されます（docs/progress-indicators.md を参照）。内部のステージ ID は引き続き query、research、plan、implement、doubt です。デフォルトの設定は次のように展開されます。

{
  "pipeline_stages": [
    { "id": "query",     "label": "QUERY",     "enabled": true },
    { "id": "research",  "label": "RESEARCH",  "enabled": true },
    { "id": "plan",      "label": "PLAN",      "enabled": true },
    { "id": "implement", "label": "IMPLEMENT", "enabled": true },
    { "id": "doubt",     "label": "DOUBT",     "enabled": true }
  ]
}

有効なステージ ID は、query、research、plan、implement、doubt の 5 つです。それ以外の ID は、現在ビルドループで認識されません。{"id":"security", ...} を追加すると TUI のリストには表示されますが、エージェントは実行されません。カスタムステージは Phase 29（コンポーザブルカード）で追跡されています。

ステージに enabled: false を設定すると、ビルドループで正しくスキップされます。このスキップは見かけだけではなく、実際に処理が省略されます。

• implement を無効にした場合：ビルダーエージェントは起動されません。ビルドループは Pipeline: implement stage disabled in config -- skipping builder for <task> とログに記録し、合成された StageResult::success("Builder", ...) を使用して doubt に進みます。src/app/build.rs:4612-4626 を参照してください。
• doubt を無効にした場合：監査／レビューのループは省略されます。ビルドループは Pipeline: doubt stage disabled in config -- skipping audit とログに記録し、タスクを検証済みとして扱います。src/app/build.rs:5158-5160 と src/app/build.rs:5186-5190 を参照してください。
• query、research、plan も同じ pipeline_stage_enabled(id) パターンに従います。enabled: false の場合、対応するエージェントは起動されません。

ステージラベルのテキストは見た目にのみ関係し、TUI のパイプライン表示とエージェントプロンプトの STAGE ヘッダーだけに影響します。

並べ替えは表示だけに適用されます。 pipeline_stages で doubt を implement より前に配置すると、TUI の表示順は変わりますが、実行順は変わりません。ビルドループは引き続き内部で query -> research -> plan -> implement -> doubt の順に実行します。実際の並べ替えとカスタムステージハンドラーは Phase 29（コンポーザブルなパイプラインカード）で追跡されています。TASKS.md を参照してください。

短縮キー "stages" は "pipeline_stages" のエイリアスとして使用できます。

実装箇所：src/config.rs:18-74（PipelineStageConfig と default_pipeline_stages）、src/config.rs:530-548（pipeline_stage_label／pipeline_stage_enabled）。

CLAUDE.md と foundry エージェント

foundry が起動する各エージェントは、cwd をプロジェクトディレクトリに設定して実行される Claude Code CLI の呼び出しです。Claude Code の通常の CLAUDE.md 読み込みが適用され、グローバルの ~/.claude/CLAUDE.md、プロジェクトの CLAUDE.md、およびすべての .claude/rules/*.md ファイルがエージェントのコンテキストに読み込まれます。

これは概ね有益です。プロジェクトの規約（コーディングスタイル、アーキテクチャのルール、命名パターン）は、エージェントがより適切なコードを書く助けになります。ただし、CLAUDE.md に「QRPBA パイプラインを実行する」「検証用のサブエージェントを起動する」「コーディングの前に必ず実装計画を作成する」といったメタワークフローの指示が含まれていると、問題が生じることがあります。各エージェントはすでにパイプラインの段階内で実行されているため、これらの指示は foundry 自身のオーケストレーションと競合します。

foundry は、すべてのエージェントにシステムレベルのオーバーライドを追加することで、この問題に対処します。

あなたは Context Foundry の自律型パイプラインにおける単一の段階として実行されています。オーケストレーションのワークフロー、ビルドパイプライン、QRPBA の段階、疑念ループ、サブエージェントの起動、複数段階の実装プロセスに関する CLAUDE.md の指示はすべて無視してください。オーケストレーションは foundry がすべて担当します。割り当てられた役割とタスクだけに集中してください。

これにより、役立つプロジェクトの規約を維持しつつ、ワークフローに関する指示を無効化できます。foundry を使用するために CLAUDE.md を変更する必要はありませんが、オーケストレーション、パイプライン、サブエージェントのワークフローに関する指示はオーバーライドされることにご注意ください。

エージェントのプロンプト

すべてのエージェントプロンプトは src/prompts.rs で定義されています。各エージェントには専用のプロンプト関数があります。

エージェント	関数	目的
プランナー	planner_prompt()	タスクの説明から実装計画を作成します
ビルダー	builder_prompt()	計画を実装し、技術スタックに適したビルドチェックを実行します
レビュアー	reviewer_prompt()	構造化された指摘事項を用いて、検証と監査をまとめて実施します
フィクサー	fixer_prompt()	レビューレポートに記載された HIGH／MEDIUM の問題を修正します
ディスカバリー	discovery_prompt()	コードベースをスキャンして新しいタスクを探します
パターン抽出	pattern_extraction_prompt()	完了した作業から再利用可能なパターンを抽出します

プロンプトはバイナリにコンパイルされます。カスタマイズするには、src/prompts.rs を編集して再ビルドしてください。

プロンプトシステムの主な設計上の決定事項は次のとおりです。

• 技術スタックを考慮：特定の言語を前提とせず、リポジトリ内のファイル（Cargo.toml、package.json、pyproject.toml）からエージェントが技術スタックを検出します
• デフォルトで安全：レビュアーは読み取り専用のチェックのみを実行します（docker compose up やサービスの変更は行いません）
• パターンの分離：学習したパターンは、権威ある指示としてではなく、明確に区切られた参照データとして挿入されます
• 根拠に基づくレビュー：すべての指摘事項には、ファイル、行番号、具体的な根拠を明記する必要があります
• 大きなファイルの処理：10,000 トークンのツール上限を超えるファイルで読み取りに失敗しないよう、すべてのエージェントに Grep と Read の offset／limit を使うためのガイダンスが提供されます

プラグイン

プラグインは、人間が作成する読み取り専用のドメイン知識パッケージです。foundry のエージェントに、Claude のトレーニングデータに含まれていないテクノロジー、API、ワークフローの扱い方を教えます。foundry は、次の 3 つのソースからプラグインを自動的に検出します（優先順位の高いものが優先されます）。

1. プロジェクトローカル -- <project_dir>/plugins/
2. 祖先ディレクトリ -- プロジェクトディレクトリから上位へたどり、各親ディレクトリに plugins/ サブディレクトリがないか確認します（最も近い祖先が優先されます）
3. グローバル -- ~/.foundry/plugins/

祖先ディレクトリの検出により、ネストされたサブディレクトリから foundry を実行しても、ツリーの上位に定義されたプラグインが見つかります。たとえば、plugins/flowise/hackathon/ から実行すると、plugins/extend/ のような兄弟プラグインも検出されます。

プラグインは、CLAUDE.md（ドメインルール）と、1 つ以上の SKILL.md ファイルを含む skills/ ディレクトリ（Anthropic Agent Skills 形式）で構成されるフォルダーです。たとえば、Roblox プラグインでは、パーツを移動する際に Position ではなく CFrame を使うようエージェントに教えたり、Workday Extend プラグインでは、WID がテナント固有であることを記載したりできます。

プラグインとスキルの違い

プラグインとスキルはどちらもエージェントのプロンプトに知識を追加しますが、目的は異なります。

	プラグイン	スキル
内容	ドメイン知識パッケージ（CLAUDE.md と 1 つ以上のスキル）	Anthropic Agent Skills 形式の個別の SKILL.md ファイル
作成者	人間 -- foundry のパターン抽出機能でもスキルを生成できます	各タスクの後に Foundry のパターン抽出機能が作成するか、人間が作成します
選択方法	手動 -- ユーザーが起動画面で選択します	自動 -- タスクごとにハイブリッド検索（BM25 + nomic-embed コサイン類似度 + テレメトリー）を行います
注入方法	CLAUDE.md をそのままビルダーとレビュアーのプロンプトの先頭に追加します	関連するパイプラインステージに、スコア上位 N 件のスキルを注入します
適用範囲	プロジェクトごと（ユーザーが適用するものを選択します）	グローバル（すべてのスキルがすべてのタスクと照合されます）
常時適用	はい -- 選択されていれば、タスクに関係なくビルダーとレビュアーに全文が渡されます	いいえ -- 検索機能が十分に高く評価したスキルのみが適用されます

プラグインには、独自のスキルを plugins/<name>/skills/ に含めることができます。これらのプラグインスキルはグローバルなスキルプールに統合され、同じ検索機能で評価されます。つまり、プラグインには 2 つの要素が含まれます。選択時に常に注入される必須のドメインルール（CLAUDE.md）と、タスクごとに検索機能が評価する任意のドメイン固有スキル（SKILL.md ファイル）です。

プラグインのコンテキスト

起動画面では、検出されたすべてのプラグインとそのスキル数を一覧表示するチェックボックスパネルが表示されます。ビルドに関連するプラグインを選択します。

┌ Plugins ─────────────────────────────────────────┐
│ [ ] extend (1s) Workday Extend orchestrations    │
│ [x] flowise (2s) Flowise AgentFlow v2 workflows  │
│ [ ] recon (2s) Fleet ops, iDRAC                  │
│ [ ] roblox (2s) Roblox world gen, Lune scripting │
└──────────────────────────────────────────────────┘

選択したプラグインは、ビルダーとレビュアーのプロンプトにコンテキストとしてプログラムによって注入され、プロンプトの先頭に追加されます。トークンを節約するため、Scout と planner へのプラグイン注入は省略されます。Scout と planner はドメイン固有のルールなしで調査と計画を行い、コードを作成および監査するエージェントにはプラグインのコンテキスト全体が渡されます。これは、エージェントが従うかどうかを選べる提案ではなく、決定論的な適用です。

ステータスバーには、アクティブなプラグインが常に表示されます。例：Plugins: flowise (1 active) または Plugins: none。

選択内容は .foundry.json の plugins キーに保存されます。"extensions": [...] を使用する古い設定も serde エイリアス経由で引き続き読み込まれ、次回の保存時に "plugins" に書き換えられます。

{
  "plugins": ["flowise"]
}

プラグインの作成

plugins/your-domain/
├── CLAUDE.md                                       # Domain rules (injected into every agent prompt)
├── skills/your-domain-pitfalls/SKILL.md            # Learned pitfalls (Anthropic Skills format)
└── docs/                                           # Supporting documentation

CLAUDE.md には、エージェントがドメイン内で正しく作業するために必要なルールを記述します。プラグインを選択すると、そのプラグインのスキルは自動的にグローバルなスキルプールに統合されるため、手動で統合する必要はありません。

ビルダーの実行前に、前提条件のゲートがプラグインを検証します。プラグインが設定されているにもかかわらず CLAUDE.md が見つからない場合は、明確なエラーが表示され、ビルドがブロックされます。

アーキテクチャ

• config.rs — serde のデフォルト値を使った設定（後方互換性のある JSON）
• agent.rs — リアルタイムストリーミング用に、PTY で Claude CLI を起動します
• patterns.rs — 学習済みパターンの読み込み、照合、整形、マージ、抽出
• prompts.rs — エージェント用プロンプト（プランナー、ビルダー、レビュー担当、修正担当、発見、パターン抽出）
• studio/ — ワークスペースの分離、成果物の取得、モジュール化された Studio アプリ／状態／UI コードを備えた、プロンプト駆動のマルチモデル TUI
• update.rs — チェックサム検証を伴う GitHub Releases からの自己更新
• sandbox.rs — Docker サンドボックスの検出、設定、コマンドのラップ
• tmux.rs — エージェントバックエンド用の Tmux セッション管理
• app.rs — ビルドループのオーケストレーション、レビューループ、パターン抽出
• tui.rs — エージェントの出力をリアルタイム表示する Ratatui ターミナル UI
• task.rs — TASKS.md のタスクリストを解析します
• git.rs — コミットとプッシュのヘルパー

.claude/ ディレクトリ

このリポジトリには、.claude/ に 2 種類の Claude Code 設定が含まれています。

ルール（.claude/rules/*.md）は、編集しているファイルに応じて Claude Code が自動的に読み込むコンテキストです。各ルールには適用範囲を指定する paths: フロントマターがあり、patterns.md は src/patterns.rs を編集すると有効になり、rust.md はすべての .rs ファイルで有効になります。ルールはプロジェクトの規約を Claude に伝え、それに沿ったコードを作成できるようにします。

スキル（.claude/skills/）は、必要に応じて実行するスラッシュコマンド（/audit、/scout、/extract-patterns）です。それぞれが、制限されたツールアクセスを持つフォークされたコンテキストで実行されます。これらは foundry のパイプラインが自動で実行する処理と同じもので、対話的に使える手動コマンドとして提供されています。

ルールとパターンは、どちらもエージェントの動作に影響しますが、別のものです。ルールはリポジトリにチェックインされた静的なプロジェクト規約です。パターンは foundry が実行時に発見する、学習された問題と解決策の組み合わせで、~/.foundry/patterns/ に保存され、キーワードと意味的類似性によってタスクごとに照合されます。

今後の方向性

Context Foundry には 2 種類のメモリがあります。パターンストアは、「Position ではなく CFrame を使う」「スライスする前に UTF-8 の境界を検証する」といったコードレベルの教訓を記憶します。次の層はプロセスレベルのメモリです。パイプライン自体の動作を学習し、時間の経過とともにその挙動を適応させます。

適応型パイプライン

現在、パイプラインはすべてのタスクに対して全ステージを実行します。次の段階では、観測されたシグナルに基づいて作業量を調整します。

観測する項目： タスクの所要時間、再試行回数、レート制限の頻度、レビューでの指摘の深刻度、タスクあたりのコスト、パターンのヒット率、デュアルモードでのプロバイダーの勝率、タスク形状ごとの疑念チェックの合否履歴（Ollama の埋め込みを使ってクラスタリング）。

適応する項目： プランナーの詳細度（単純なタスクではスキップ）、疑念チェックを実行するかどうか（あるタスク形状で 5 回以上連続して問題なく通過した場合はスキップし、失敗があればリセット）、デュアルモードを使うかどうか、エージェント間の待機時間、人間によるレビューにエスカレーションするタイミング。

具体例： 名前変更のタスクでは、クエリ、調査、プランナーをスキップし、パターンを 10 件ではなく 2 件取得し、監査を省略して直接コミットします。これにより、10 分ではなく 30 秒で完了します。一方、認証システムの書き換えでは、10 件のパターンを使い、監査を必須とする QRPBA パイプラインをすべて実行します（出荷済みの）複雑度分類器が大まかな振り分けを担い、学習された疑念の確信度が細かな調整の層を加え、実行のたびに改善されます。

Foundry Observatory

すべてのプロジェクトのパイプライン実行を追跡する、セルフホスト可能な分析ダッシュボードです。SQLite バックエンドを採用した軽量なウェブサーバーで、クラウドへの依存はありません。

表示内容： セッション履歴（タスク、モデル、成功／失敗、コスト、所要時間）、パターンの有効性（注入されたパターンと適用されたパターン、まったく適用されないパターン）、重大度別の疑念発見の傾向、プロバイダーの比較（プロジェクトごとの Claude と Codex のコスト、速度、信頼性）、複雑度分類の精度。

生成内容：

• セッションの振り返り：「レビューで失敗したことのないタスクについて、この実行ではコストの 40% を疑念に費やしました。」
• 設定の推奨：「pause_between_agents_secs を増やしてください。8 件中 6 件のタスクでレート制限に達しています。」
• TASKS.md への追加提案：「パターン #47 は 200 回注入されていますが、適用されたのは 3 回です。このパターンを廃止または改善するタスクを検討してください。」

対話型インターフェース。 ビルド履歴とチャットできます。「先週失敗したものは？」や「health-ai での Claude と Codex のコストを比較して」と質問できます。会話は保存されます。foundry の動作を理解するためにパターンストアを活用する、同じ原則に基づいています。チャットから新しいタスクを提案したり、イシューを作成したりできます。これらは助言的な提案として記録されます。observatory が TASKS.md への追加を提案し、人間が確認して承認すると、次回の実行に反映されます。observatory が提案し、人間が承認します。

技術スタック： 小規模な Rust または Python のサーバー、自己完結型のフロントエンド、履歴保存用の SQLite。同じマシン上で foundry と一緒に実行するか、Docker コンテナとして実行します。

以前のバージョン

この Rust への書き換えに先立つ Python MCP サーバーとデーモンは、以下にアーカイブされています。

• タグ： v1.0-python
• ブランチ： archive/python-mcp