IronCurtain

自律型AIエージェントのためのセキュア*ランタイム。セキュリティポリシーは人間が読める憲法から導出されます。

*「セキュア」と書かれているのを見たら、すぐに疑ってください。ここで「セキュア」が意味するものは？

[!WARNING] 研究プロトタイプ。 IronCurtainは、AIエージェントを実際に有用になる程度に安全にする方法を探求する初期段階の研究プロジェクトです。API、構成形式、アーキテクチャは変更される可能性があります。貢献とフィードバックを歓迎します。

デモ

エージェントはリポジトリをクローンし、変更をプッシュするよう求められます。git_clone と git_push はどちらもポリシーエンジンによって昇格されますが、自動承認者が自動的に承認します — コマンドモード（Ctrl-A）からの信頼された入力が明確な意図を提供したため、手動の /approve は不要でした。

問題

自律型AIエージェントは、ファイルの管理、gitコマンドの実行、メッセージの送信、APIとのやり取りをユーザーに代わって行えます。しかし、今日のエージェントフレームワークは、ファイルシステム、認証情報、ネットワークへの完全なアクセスなど、ユーザーと同じ権限をエージェントに与えています。セキュリティ研究者はこれをアンビエント権限と呼びます。これは、一度のプロンプトインジェクションやマルチターンのドリフトによって、エージェントがファイルを削除したり、データを外部に持ち出したり、悪意のあるコードをプッシュしたりする可能性があることを意味します。

一般的な対応は、エージェントを狭いサンドボックスに制限する（有用性が制限される）か、ユーザーにすべての操作の承認を求める（自律性が制限される）かのどちらかです。どちらも満足のいくものではありません。

アプローチ

IronCurtainは異なる道を選びます。セキュリティの意図を平易な英語で表現し、システムに強制方法を考えさせるのです。

あなたは憲法を書きます。これは、エージェントが何を許可され、何を許可されないかを記述した短い文書です。IronCurtainは、LLMパイプラインを使ってこれを決定的なセキュリティポリシーにコンパイルし、生成されたテストシナリオに対してコンパイル済みルールを検証し、実行時にすべてのツール呼び出しでポリシーを強制します。その結果、ユーザーが自然言語で定義した境界の範囲内で自律的に動作できるエージェントが得られます。

主なアイデア:

• エージェントは信頼されない。 IronCurtainは、LLMがプロンプトインジェクションやドリフトによって侵害されている可能性があると想定しています。セキュリティはモデルが「良い」ことには依存しません。
• 英語を入れて、強制を取り出す。 あなたは意図を書きます（「承認なしの破壊的なgit操作は禁止」）;システムはそれを決定的なルールにコンパイルし、実行時にそれ以上のLLMの関与なしに強制します。
• セマンティック・インターセプション。 エージェントに生のシステムアクセスを与える代わりに、すべてのやり取りはMCPサーバー（ファイルシステム、gitなど）を経由します。すべてのツール呼び出しは、allow、deny、またはユーザーへの承認を求めるescalate が可能なポリシーエンジンを通過します。
• 多層防御。 エージェントコードは、ホストへの直接アクセスがないV8アイソレート内で実行されます。外に出る唯一の方法は、意味的に意味のあるMCPツール呼び出しを介することで、そのすべてがポリシーに対してチェックされます。

アーキテクチャ

IronCurtainは、異なる信頼モデルを持つ2つのセッションモードをサポートしています:

• 組み込みエージェント（コードモード） — IronCurtain自身のLLMエージェントが、V8サンドボックス内で実行されるTypeScriptスニペットを記述します。IronCurtainは、エージェント、サンドボックス、ポリシーエンジンを制御します。すべてのツール呼び出しは、構造化されたMCPリクエストとしてサンドボックスを出て、ポリシーエンジン（allow / deny / escalate）を通過し、その後で実際のMCPサーバーに到達します。
• Dockerエージェントモード — 外部エージェント（Claude Code、Gooseなど）が、ネットワークアクセスのないDockerコンテナ内で実行されます。IronCurtainは外部への影響を仲介します。LLM API呼び出しはTLS終端MITMプロキシ（ホストの許可リスト、偽物から本物へのキー交換）を通過し、MCPツール呼び出しは同じポリシーエンジンを通過し、パッケージインストール（npm/PyPI）は検証レジストリプロキシを通過します。

どちらのモードでも、エージェントは信頼されていません。セキュリティはモデルが指示に従うことに依存せず、境界で強制されます。

図、レイヤーごとの信頼分析、macOSプラットフォームに関する注意事項を含む完全なアーキテクチャについては、SANDBOXING.mdを参照してください。

クイックスタート

前提条件

• Node.js 22、24、または26 — IronCurtainがテストしている偶数番号のメジャーライン（isolated-vmが必要とします。24と26はビルド済みバイナリをインストールし、Node 22はインストール時にソースからコンパイルするためC/C++ツールチェーンが必要です）。奇数番号のライン（23、25）は実行できますが未テストです — ironcurtain doctor が警告します。
• Docker — 必須ではありませんが、最も強力な隔離を提供するDockerエージェントモードには強く推奨されます。macOS 26+（Appleシリコン）では、Apple containerが代替バックエンドとして機能します（コンテナごとにVM。そのサービスが実行されているときに自動的に使用されます — ironcurtain config の containerRuntime を参照）。
• 少なくとも1つのLLMプロバイダー（Anthropic、Google、OpenAI）のAPIキー

インストール

グローバルCLIツールとして（エンドユーザー向け）:```bash npm install -g @provos/ironcurtain

**ソースから（開発）:**```bash
git clone https://github.com/provos/ironcurtain.git
cd ironcurtain
npm install

初回セットアップ

1. APIキーを設定します:```bash export ANTHROPIC_API_KEY=sk-ant-...

キーはプロジェクトルートの `.env` ファイルに置くこともできます（`dotenv` により自動的に読み込まれます）。また、`ironcurtain config` で `~/.ironcurtain/config.json` に追加することもできます。環境変数は設定ファイルの値よりも優先されます。対応: `ANTHROPIC_API_KEY`、`GOOGLE_GENERATIVE_AI_API_KEY`、`OPENAI_API_KEY`。

**2. 初回起動ウィザードを実行する**（推奨の mux パスを使用する前に明示的に実行してください。非 mux の初回 `ironcurtain start` でも自動的に実行されます）:```bash
ironcurtain setup

GitHubトークンの設定、Web検索プロバイダー、モデル選択、その他の設定について順を追って説明します。選択内容を保存した ~/.ironcurtain/config.json を作成します。

IronCurtainの実行

IronCurtainには、開発者体験を重視したデフォルトポリシーが同梱されています。読み取り専用の操作は許可され、変更(書き込み、プッシュ、PR作成)は人間の承認を求めてエスカレーションされます。セットアップ後すぐに使い始められます。

ターミナルマルチプレクサ(推奨)

IronCurtainを使う際の推奨方法です。IronCurtainがすべてのツール呼び出しをポリシーエンジンを介して仲介する一方で、エージェントの対話型TUI(Claude CodeまたはGoose)の全機能を単一のターミナルで利用できます。```bash ironcurtain mux

**主な機能:**

- **完全なエージェントTUI** — エージェントはネットワークアクセスなしのDockerコンテナ内のPTYで実行されます。ローカルで実行しているのとまったく同じように操作できます。
- **インラインのエスカレーション処理** — ツール呼び出しが承認を必要とする場合、エスカレーションピッカーがビューポートにオーバーレイされ、単一キー操作（a/d/w で承認/拒否/ホワイトリスト登録）が可能になります。`/approve+ N` を使用すると、セッションの残り期間中、ドメインまたはパスをホワイトリストに登録できます。
- **信頼済みユーザー入力** — コマンドモード（Ctrl-A）で入力されたテキストは、コンテナに入る前にホスト側でキャプチャされます。これにより、自動承認者が利用できる検証済みの意図シグナルが生成されます。たとえば、「push my changes to origin」と入力すると、後続の `git_push` エスカレーションが自動承認されます。
- **タブ管理** — 複数の並行セッションを生成（`/new`）、切り替え（`/tab N`、Alt-1..9）、終了（`/close`）できます。複数のmuxインスタンスを並行して実行できます。

完全なウォークスルー（入力モード、信頼済み入力のセキュリティモデル、エスカレーションワークフロー、キーボードリファレンス）については [DEVELOPER_GUIDE.md](https://github.com/provos/ironcurtain/blob/master/DEVELOPER_GUIDE.md) を参照してください。

### 非muxセッション

`ironcurtain start` は、簡単な単発タスク、スクリプト、またはローカルの組み込みエージェントを明示的に使用したい場合に使います。通常のインタラクティブなDockerエージェント作業には、`ironcurtain mux` を使用してください。```bash
ironcurtain start "Summarize the files in ./src"     # Single-shot mode
ironcurtain start -w ./my-project "Fix the tests"    # Single-shot workspace mode
ironcurtain start --agent builtin                    # Local builtin REPL, no Docker
ironcurtain start --persona my-assistant "Check my email"  # Use a persona

その他の実行モード

IronCurtain はセッション再開 (--resume <session-id>)、レガシーな raw PTY/デバッグモード、モバイル承認用の Signal メッセージングトランスポート、そしてスケジュールされた cron ジョブ用のデーモンモードもサポートしています。デーモンには、ブラウザベースの監視とエスカレーション処理のためのオプションの Web UI (--web-ui) があります。詳細は RUNNING_MODES.md を参照してください。

マルチエージェントワークフロー

IronCurtain は構造化されたワークフローを通じて複数の AI エージェントをオーケストレーションします。同梱の 脆弱性発見 ワークフローは、段階的なハーネスパイプライン（Tier 1 単一関数 → Tier 2 複数コンポーネント → Tier 3 フルビルド）を通じてネイティブコードのメモリ安全性とロジックバグを探索し、libFuzzer/AFL++ のカバレッジゲーティング、仮説駆動型の discover/triage 状態、そして最終的な人間によるレポートレビューゲートを備えています。設計とコーディング ワークフローは、計画 / 設計 / 実装 / レビューのサイクルを実行し、こちらも人間によるゲートを備えています。各エージェントは、ロール固有のポリシー境界を持つ独自の Docker コンテナ内で実行されます。エンジンは状態遷移、成果物の受け渡し、クラッシュリジュームチェックポイントを自動的に管理します。オープンソースで、完全にあなたのマシン上で動作し、憲法ベースのポリシーエンジンを介してエージェントごとのセキュリティポリシーを強制し、あらゆる Docker コンテナ化されたエージェントと連携します — コーディングタスクにおいて Amazon Kiro や Google Jules に匹敵する規模ですが、第一級のセキュリティと拡張可能なワークフロー定義形式を備えています。

Web UI は、ワークフロー実行のための想定されたインターフェースです。 デーモンを起動し、表示された URL を開いて、Workflows ページから実行を操作します。上記のステートマシングラフはライブで、エージェントメッセージのタイムラインはマークダウンレンダリング付きでストリーミング表示され、ゲートレビューにはワークスペース + 成果物ブラウザが含まれ、過去の実行は一覧に残ります。```bash ironcurtain daemon --web-ui

CLIアクセスは、スクリプト作成、自動化、デバッグに利用できます:```bash
ironcurtain workflow start vuln-discovery \
  "Find memory-safety bugs in libical" --workspace ~/src/libical
ironcurtain workflow start design-and-code \
  "Build a REST API with authentication"

完全なドキュメントについては WORKFLOWS.md を参照してください。

ポリシーのカスタマイズ

デフォルトのポリシーは一般的な開発に適していますが、ワークフローに合わせて調整できます：

1. 憲法をカスタマイズする（任意ですが推奨されます）：```bash ironcurtain customize-policy

ワークフローに合わせた憲法を生成するLLM支援の会話で、`~/.ironcurtain/constitution-user.md` に保存されます。このファイルを直接編集することもできます。

**2. ポリシーをコンパイルする:**```bash
ironcurtain compile-policy

あなたの憲法を決定的なルールに変換し、テストシナリオを生成して検証します。コンパイル済みの成果物は ~/.ironcurtain/generated/ に出力されます。

ペルソナ

ペルソナは名前付きのポリシープロファイルです — それぞれが憲法、コンパイル済みポリシー、永続ワークスペース、セマンティックメモリをバンドルします。これらを使用して、異なるロールやアクセスレベルのエージェントを実行できます。```bash ironcurtain persona create my-assistant # Create a persona ironcurtain persona compile my-assistant # Compile its policy ironcurtain start --persona my-assistant "Check my calendar"

In mux mode, `/new my-assistant` はそのペルソナを使うタブを生成します。ペルソナは cron ジョブにも割り当てられます。スケジュールジョブの設定は [DAEMON.md](https://github.com/provos/ironcurtain/blob/master/DAEMON.md) を参照してください。

ペルソナは [web UI](https://github.com/provos/ironcurtain/blob/master/DAEMON.md#persona-policy-management) からも管理できます — 参照、作成、憲法の編集、ライブ進行でのポリシーのコンパイルが可能です。ポリシーはセキュリティ境界であるため、デーモンが `--allow-policy-mutation`（デフォルトではオフ）で起動されない限り、web UI の変更コントロールは読み取り専用です。

### スキル

SKILL.md パッケージを `~/.ironcurtain/skills/<name>/` に配置すると、目的特化のガイダンス（ヘルパースクリプト、決定的チェック、ドメイン知識）をすべての Docker エージェントセッションで利用できるようにできます。マージされたセットはバンドルごとのホストディレクトリにステージングされ、アクティブなエージェントのネイティブな検出が探索するパスにコンテナへ **読み取り専用** でバインドマウントされます — Claude Code は `--add-dir` でステージングディレクトリを指定され、Goose は `~/.config/goose/skills/<name>/SKILL.md` をスキャンします。エージェントはこれらを自動的に発見し、各スキルの frontmatter の説明に基づいて読み込むタイミングを決定します。SKILL.md _形式_ は Claude Code、Goose、Codex が採用するオープンスタンダードであり、_発見パス_ のみがエージェントごとに異なります。ワークフローはワークフローパッケージ内に状態別スキルを同梱できます — [WORKFLOWS.md](https://github.com/provos/ironcurtain/blob/master/WORKFLOWS.md#skills) を参照してください。

## ポリシー: 憲法 → 強制

あなたは意図を平易な英語で記述し、IronCurtain がそれを決定的なルールにコンパイルします:```
constitution.md → [Annotate] → [Compile] → [Resolve Lists] → [Generate Scenarios] → [Verify & Repair]
                      │              │              │                  │                     │
                      ▼              ▼              ▼                  ▼                     ▼
              tool-annotations  compiled-policy  dynamic-lists   test-scenarios       verified policy
                  .json            .json            .json            .json          (or build failure)

1. Annotate — 各 MCP ツールの引数を役割別（read-path、write-path、delete-path、none）に分類する。
2. Compile — 英語の憲法を決定論的な if/then ルールに変換する。カテゴリ参照（「主要ニュースサイト」「自分の連絡先」）は @list-name シンボリック参照として出力される。
3. Resolve Lists — シンボリックリストを LLM の知識または MCP ツールの利用（例：連絡先データベースの照会）によって具体的な値に解決する。dynamic-lists.json に書き込まれ、ユーザーが編集可能。リストが存在しない場合はスキップされる。
4. Generate Scenarios — 憲法と必須の手書き不変条件テストからテストシナリオを作成する。
5. Verify & Repair — 実際のポリシーエンジンに対してシナリオを実行する。LLM ジャッジが失敗を分析し、的を絞った修復を生成する（最大2ラウンド）。ポリシーを検証できない場合、ビルドは失敗する。

すべてのアーティファクトはコンテンツハッシュでキャッシュされる — 変更された入力のみが再コンパイルをトリガーする。

コンパイルされたルールの例

次のような憲法条項:```markdown

• The agent may perform read-only git operations (status, diff, log) within the sandbox without approval.
• The agent must receive human approval before git push, pull, fetch, or any remote-contacting operation.

コンパイル結果:```json
[
  { "tool": "git_status", "decision": "allow", "condition": { "directory": { "within": "$SANDBOX" } } },
  { "tool": "git_diff", "decision": "allow", "condition": { "directory": { "within": "$SANDBOX" } } },
  { "tool": "git_push", "decision": "escalate", "reason": "Remote-contacting git operations require human approval" }
]

明示的な allow または escalate ルールに一致しない呼び出しは、デフォルトで拒否されます。```bash ironcurtain annotate-tools --server filesystem # Annotate one server (merge with existing) ironcurtain annotate-tools --all # Re-annotate all servers ironcurtain compile-policy # Compile constitution into rules and verify ironcurtain refresh-lists # Re-resolve dynamic lists without full recompilation ironcurtain refresh-lists --list major-news # Refresh a single list

生成された `~/.ironcurtain/generated/compiled-policy.json` を確認してください — これらはランタイムで強制される正確なルールです。

## 設定

IronCurtain は設定とセッションデータを `~/.ironcurtain/` に保存します:```
~/.ironcurtain/
├── config.json              # User configuration
├── constitution.md          # User-local base constitution (overrides package default)
├── constitution-user.md     # Your policy customizations (generated by customize-policy)
├── generated/               # User-compiled policy artifacts (overrides package defaults)
├── personas/                # Persona directories (constitution, policy, workspace, memory)
├── skills/                  # User-global SKILL.md packages, mounted into every Docker session
├── jobs/                    # Cron job definitions, workspaces, and run records
├── sessions/
│   └── {sessionId}/
│       ├── sandbox/         # Per-session filesystem sandbox
│       ├── escalations/     # File-based IPC for human approval
│       ├── audit.jsonl      # Per-session audit log
│       └── session.log      # Diagnostics
└── workflow-runs/           # Shared-container workflow runs (see below)

単一セッションの実行（ironcurtain start、mux タブ、cron ジョブ）は sessions/ 配下に書き込まれます。代わりに、共有コンテナワークフロー実行は workflow-runs/ 配下に書き込まれます — 次のセクションを参照してください。

ワークフロー実行のレイアウト

ワークフロー定義は、その YAML で settings.sharedContainer: true を設定することで、共有 Docker コンテナをオプトインできます。そのモードでは、各エージェント状態は同じ長時間稼働コンテナ内で実行され、1 つのポリシーエンジンインスタンスを共有します。状態間では、オーケストレータがアクティブなポリシーをホットスワップして、各ペルソナが自身のルールを参照できるようにします。実行に関するすべてのアーティファクトは、単一のツリーに配置されます。``` ~/.ironcurtain/workflow-runs// ├── audit.jsonl # Persona-tagged append-only audit ├── messages.jsonl # Orchestrator message log ├── workspace/ # Agent workspace (filesystem MCP root) ├── bundle/ # Shared container support (claude-state, orientation, sockets, escalations, system-prompt.txt) ├── states/ │ └── ./ # session.log + session-metadata.json per invocation └── proxy-control.sock # Coordinator UDS for policy hot-swap

No per-session entries are created under `~/.ironcurtain/sessions/` for a shared-container workflow run. User-visible commands (`ironcurtain workflow start|resume|inspect|list`) are unchanged. See [WORKFLOWS.md](https://github.com/provos/ironcurtain/blob/master/WORKFLOWS.md) for authoring workflow definitions and the full lifecycle.

Edit configuration interactively:```bash
ironcurtain config

主な設定領域: モデルとAPIキー、リソース予算 (トークン/ステップ/時間/コスト制限)、自動承認エスカレーション、ウェブ検索プロバイダー、監査ログの秘匿化、メモリサーバーのLLM設定。完全なリファレンスは CONFIG.md を参照してください。

LLMトラフィックを LiteLLM や OpenRouter などのゲートウェイ経由でルーティングするには (コードモードと Docker エージェントモードの両方)、MODEL_ROUTING.md を参照してください。

Docker エージェントをモデルプロバイダープロファイル (例: OpenRouter 経由の GLM-5.2、サイドカーなし) 経由でルーティングするには、ironcurtain config → モデルプロバイダー を使用して、/new または --provider-profile でプロファイルを選択します — MODEL_ROUTING.md を参照してください。

組み込み機能

IronCurtain には、事前設定済みの6つの MCP サーバーが同梱されています。すべてのツール呼び出し (メモリを除く) は、コンパイル済みポリシーによって管理されます。

読み取り専用操作はデフォルトポリシーで許可されます。変更操作 (書き込み、プッシュ、PR作成) は人間の承認にエスカレーションされます。ツールは server.tool 命名規則を使用します (例: filesystem.read_file、memory.recall)。独自のサーバーを追加するには ADDING_MCP_SERVERS.md を参照してください。

ネットワークパススルー (Docker エージェントモード)

Docker エージェントモードでは、コンテナにはネットワークアクセスがありません。すべてのトラフィックは IronCurtain の MITM プロキシを通過します。デフォルトでは、LLM プロバイダーのドメインのみが到達可能です。エージェントは、proxy 仮想 MCP サーバー (add_proxy_domain) を介して、実行時に追加のドメインへのアクセスを要求できます。各要求は、エスカレーションフローによる人間の承認が必要です。

承認されたドメインには 生のパススルートンネル が与えられます。HTTP、HTTPS、WebSocket 接続は、コンテンツ検査や資格情報の注入なしで転送されます。これによりエージェントの有用性は高まりますが (サードパーティAPIの呼び出し、外部サービスからのデータストリーミングなど)、それらのドメインへのトラフィックは 仲介なし になります。脅威モデルについては SECURITY_CONCERNS.md のセクション 2b-i、使用上の詳細については DEVELOPER_GUIDE.md を参照してください。

セキュリティモデル

IronCurtain は特定の脅威モデルを想定して設計されています: LLM が暴走する。 これは、プロンプトインジェクション (悪意のあるメールやWebページがエージェントを乗っ取る) や、マルチターンの逸脱 (長時間のセッションでエージェントがユーザーの意図から徐々に逸脱する) によって発生する可能性があります。

IronCurtain が強制するもの

• ファイルシステムの隔離 — シンボリックリンクを考慮したパス解決により、パストラバーサルやシンボリックリンクエスケープ攻撃を防ぎます。
• ツール単位のポリシー — 各 MCP ツール呼び出しは、コンパイル済みルールに対して評価されます。ポリシーエンジンは、ツール引数を役割 (read-path、write-path、delete-path) に基づいて分類し、きめ細かい判断を行います。
• 構造的不変条件 — 特定の保護はハードコードされており、憲法によって上書きすることはできません。エージェントは自身のポリシーファイル、監査ログ、または設定を変更することは決してできません。
• 人間によるエスカレーション — ポリシーが「エスカレーション」を指示した場合、エージェントは一時停止し、ユーザーが明示的に承認または拒否する必要があります。オプションとして、LLMベースの自動承認機能が明確なケースを処理します (CONFIG.md を参照)。
• 監査トレイル — すべてのツール呼び出しとポリシー判断は、追記専用のJSONL監査ログに記録されます。
• リソース制限 — トークン、ステップ、時間、コストの予算により、暴走セッションを防ぎます。

既知の制限

これは研究プロトタイプです。既知のギャップは次のとおりです。

• ポリシーコンパイルの忠実性 — LLMベースのコンパイラは、憲法の意図を誤解釈する可能性があります。検証パイプラインは多くのエラーを検出しますが、完全ではありません。常にコンパイル済みの compiled-policy.json を確認してください。
• V8 アイソレート境界 — コードモードはOSレベルの仮想化ではなく V8 アイソレートを使用します。V8 のゼロデイがエスケープを許す可能性があります。
• 送信コンテンツの検査なし — ファイル書き込みを許可されたエージェントは、機密データをエンコードしてコンテンツレベルの制御を回避する可能性があります。計画: 送信コンテンツに対するLLMベースの可読性チェック。
• エスカレーション疲れ — 誤検知によるエスカレーションが多すぎると、習慣的な承認につながる可能性があります。不要なプロンプトを最小限に抑えるために憲法を調整してください。

詳細な脅威分析については docs/SECURITY_CONCERNS.md を参照してください。

トラブルシューティング

開発```bash

npm test # Run all tests npm test -- test/policy-engine.test.ts # Run a single test file npm test -- -t "denies delete_file" # Run a single test by name npm run lint # Lint npm run build # TypeScript compilation + asset copy

[TESTING.md](https://github.com/provos/ironcurtain/blob/master/TESTING.md) に、統合テストのフラグと規約を含む完全なテストガイドがあります。

### プロジェクト構造```
src/
├── index.ts                    # Entry point
├── cli.ts                      # CLI command dispatcher
├── config/                     # Configuration loading, constitution, MCP server definitions
├── session/                    # Multi-turn session management, budgets, loop detection
├── sandbox/                    # V8 isolated execution environment
├── trusted-process/            # Policy engine, MCP proxy, audit log, escalation handler
├── pipeline/                   # Constitution → policy compilation pipeline
├── escalation/                 # Escalation listener: session registry, TUI dashboard, state
├── mux/                        # Terminal multiplexer: PTY bridge, renderer, trusted input
├── persona/                    # Persona management (create, compile, resolve)
├── memory/                     # Memory server integration (config, annotations, path resolution)
├── signal/                     # Signal messaging transport (bot daemon, setup, formatting)
├── daemon/                     # Unified daemon (Signal + cron scheduler, control socket)
├── cron/                       # Cron job management (scheduler, job store, git sync, policy)
├── docker/                     # Docker agent mode, PTY session, MITM proxy, registry proxy
├── workflow/                   # Multi-agent workflow engine (orchestrator, state machine, gates)
├── web-ui/                     # Web UI backend (JSON-RPC dispatch, event bus, workflow manager)
├── servers/                    # Built-in MCP servers (fetch, web search providers)
└── types/                      # Shared type definitions
packages/
└── memory-mcp-server/          # Standalone memory MCP server (publishable npm package)

ライセンス

Apache-2.0