ns-langgraph-agents

LangGraph Agents

本番対応の LangGraph.js（Node 24 以降、TypeScript strict、@langchain/langgraph）です。

ランタイムの原則（配置、プロンプト／機能の注入、グラフ仕様との同期）を担います。差分の作成には ns-coder または ns-autonomous を使用します。フレームワークの選定には ns-agent-architecture を使用します。

適用範囲

コンテキスト	原則の強さ
グリーンフィールドの agent-api（新しい LangGraph ランタイム）	必須：ビルドワークフローのゲートに従います。dev-chat、予算、切り詰める前の正規化、個別のスキル上限が対象です。トポロジー：ほとんどの MCP／ツール中心のケースでは plan_execute を推奨します — graph-spec.md に確定しますが、厳格なルールではありません
ブラウンフィールドの既存エージェント	同じ制御への移行を推奨します。オーファンの復旧では、トポロジーが欠けていても Critical-fail にはしません
意図的な MCP の再設計	同じデリバリー内で graph-spec.md と参照情報を同期します — 対象となるトポロジー／予算／エビデンスのセクションには、グリーンフィールドの必須要件を適用します

ブラウンフィールドでは、意図的なトポロジー変更を行うまでは、既存の ReAct を有効とします。グリーンフィールドの必須要件が適用されるのは、新しい agent-api と意図的な MCP の再設計のみです。

ルーティング（最初に確認）

シグナル	アクション
コンセプト設計が未確定（エージェント、RAG、ファインチューニングのいずれか）	停止 → ns-agent-adaptation
フレームワークが未確定／CrewAI が指定されている	停止 → ns-agent-architecture
オーファン／構造の喪失／レイアウトが不明	機能追加の前にオーファンチェックリストを実行します（references/orphan-recovery-checklist.md）
GitLab の ISSUE_URL または SDD のバージョンスコープ	ハーネスの ../../ns-harness/references/code-skill-routing.md に委任します — 引き受けないでください
配置／注入計画の承認が完了し、差分を作成できる状態	実装を ns-coder に引き継ぎます — ただし、グリーンフィールドのブートストラップコピー（references/bootstrap-agent-runtime.md）は除きます

ブート（必須）

../../ns-harness/references/session-boot.md を参照してください — そこで セッションブートを完了してください（ブロッキング）。完了後、次の手順に進みます。

1. ランタイムに触れる場合は {agent_api_root} と graph-spec.md を確認します
2. パスを決定する前に配置／注入の参照情報を読み込みます（references/placement-and-domains.md、references/prompt-and-capability-injection.md）
3. このスキルを続行します

成功： 配置、注入の原則、プロジェクトルール。失敗： フォルダーや外部フレームワークを独自に作成すること。

使用するタイミング

状況	対応
Greenfield agent-api（{agent_api_root}/package.json がない）	ビルドワークフローのフェーズ 0、次にフェーズ 1 のブートストラップ — references/bootstrap-agent-runtime.md
Brownfield／孤立したランタイム	機能開発の前に孤立状態の復旧（references/orphan-recovery-checklist.md）を実行します
新しいファイル／配置先フォルダーが不明	配置決定ブロック + references/placement-and-domains.md
システムプロンプト／スキルの注入／バインド	プロンプト／機能の計画 + references/prompt-and-capability-injection.md
トポロジー／状態／機能／guard_fail_mode の変更	仕様同期ゲート — 同じデリバリーで graph-spec.md を更新します
サーバー／ツールが多い MCP	references/mcp-complex-access.md + references/capability-governance.md を読みます
トークンの急増／ターンの遅延	references/context-window-and-tokens.md を読みます
エージェントにユーザーの記憶（設定、用語、CRUD）が必要	references/user-memory.md を読みます — ユーザーごとのストア、推論して通知、/memories ルート
信頼できない入力／インジェクション／主張された権限	references/guardrail-and-adversarial.md を読みます — スコープ分類器、スキャフォールドのフェイルオープン ≠ ドクトリン
コスト重視の大量利用／モデル階層／キャッシュ	references/model-cascade-and-cache.md を読みます
プロバイダーのメッセージ／推論に関する癖	references/message-content-blocks.md を読みます
HITL／ストリーミング UX	references/streaming-and-hitl.md を読みます
JSON プランナー／アナリストがツールを選択	オペレーター進捗チャネル — templates/contracts/planner-contract.md + references/streaming-and-hitl.md
プロンプト変更／ホップの反復／ループ／「修正済み」の主張	references/turn-flow-gates.md を読みます — フロー優先、終了条件、反復、エビデンスのゲート
マージ前の評価	references/evals-and-gates.md を読みます

基本方針

LangGraph ＝ 制御フローです。MCP／ローカルツール ＝ グラフの下にある機能です。グラフの状態は小さく保ちます（参照、要約）。チェックポインター ＝ 完全な状態、コンテキストウィンドウ ＝ LLM の視点であり、別々のものです。

システムプロンプト： LLM を呼び出すたびに、base_invariant（モーター）＋ injected（製品のペルソナ）を組み立てます。組み立てたシステム／ペルソナテキストを、グラフの状態、チェックポインター、永続的な messages に保存してはいけません。インデックス 0 の要約 SystemMessage は完全なシステムプロンプトではありません — references/prompt-and-capability-injection.md、references/message-content-blocks.md。

ロケール： 会話から観測した turnLocale（人間のメッセージから最初に検出し、必要に応じて意図スロットを補助情報として使用します）。configurable.locale は弱いヒントにすぎません。固定のブートストラップロケールではなく、コード内の Intl フォーマッターを使用します。references/evidence-and-fidelity.md、templates/snippets/conversation-locale.ts.snippet。

オペレーターの進捗（JSON プランナーホップ）： グリーンフィールドでは、構造化された executionPlan を出力するプランナー／アナリストを備えた streaming_sse を使用し（そのホップでは bindTools を使用しません）、AgentState に userFacingIntent（または analysis.userFacingIntent）と executionPlan の両方を必ず保存しなければなりません。userFacingIntent の言語は、現在のユーザーメッセージ（最後の HumanMessage）と一致しなければなりません — そのメッセージが英語でない限り英語にしてはいけません。また、製品のデフォルトロケールにもしてはいけません。機械処理用の intent は監査用に英語のままにします。次のホップのノード開始時に、このフィールドから SSE thinking を出力します — response_streaming ではなく、永続的な messages にも含めません。ホップ 0 では、conversation/presentation/（またはロケール）から、オペレーターと同じ言語の汎用文言を使用します。オープンな ReAct ＋ ToolNode では、tool_started／tool_finished のみを使用します。詳細：templates/contracts/planner-contract.md、references/streaming-and-hitl.md。

モデルにバインドする機能は、次の 3 種類です。

種類	LLM ワイヤー名	内部 ID
ローカルツール	{name}	local:{name}
MCP ツール	mcp__{server}__{tool}	mcp:{server}:{tool}
スキル手順	use_skill__{id}	skill:{id}

ワイヤー名は ^[a-zA-Z0-9_-]{1,128}$ に一致しなければなりません（区切りには __ を使用し、コロンは内部 ID でのみ使用します）。新しいワイヤー名にコロンが含まれている場合、レビューで Critical と判定されます。

変更前のゲート

新しいファイルの作成、または注入／バインドの変更前に、3 項目すべてを完了してください。投稿するまではコードを書いてはいけません。

1. 配置決定ブロック

### Placement Decision Block

- Artifact: …
- Type: …
- Target path: …
- Layer: …
- Refs: placement-and-domains.md
- do_not_create_under: […]

全体のマトリクス：references/placement-and-domains.md。

2. プロンプト／機能計画

### Prompt / Capability plan

- Compose: base_invariant + injected (rebuild per invoke; not in state/checkpointer/durable messages)
- Motor (`base_invariant`): [gather-no-Markdown / sole-writer / tool discipline / JSON planner userFacingIntent is SSE not Markdown / …]
- Product (`injected`): canonical path + persona/tone notes; mode-resolved: yes/no; modes: [...]; resolver: ...
- System layers touched: […]
- Canonical prompt path: …
- Session overlay: yes/no
- Bind list: […]
- Auto-inject skills: […] (exclusive of bind for same id)
- Truncate caps: tool vs skill body
- Bind parity: …
- Spec paths to sync: […]

全体の方針：references/prompt-and-capability-injection.md。計画／モード解決：references/prompt-and-capability-injection-plan-execute.md。

3. 仕様同期ゲート

ノード、エッジ、状態、機能、recursion_limit、ワイヤー名、または guard_fail_mode を変更する場合は、同じリリースで graph-spec.md を更新します。古いアーカイブは SoT ではありません — 仕様を意図したランタイムに同期し、古いアーカイブにライブコードを無理に合わせてはいけません。

参照先一覧

必要に応じて読み込んでください — ファイル全体を暗記する必要はありません。

参照	次の場合に読みます
references/bootstrap-agent-runtime.md	templates/agent-runtime/ の新規プロジェクトへのコピー
references/orphan-recovery-checklist.md	プロジェクト構成が不明瞭、またはエージェントが「迷子」になった場合
references/runtime-layout.md	スキャフォールディング、リファクタリング、レイヤー違反
references/placement-and-domains.md	ファイルの配置場所、ドメインとグラフと設定の区別
references/prompt-and-capability-injection.md	システムプロンプトのレイヤー、バインドと注入、バインドの同等性
references/prompt-and-capability-injection-plan-execute.md	プロンプト／ケイパビリティの計画、plan_execute における収集とコンポーザー、モードで解決される injected
references/message-content-blocks.md	プロバイダー間での AIMessage／HumanMessage／ToolMessage
references/context-window-and-tokens.md	トリミング、要約、ツールとスキル本文の上限、context_manager
references/mcp-complex-access.md	マルチサーバー MCP、検出、トランスポート、ライフサイクル
references/capability-governance.md	許可リスト、分類、レート制限、ツールの予算
references/evidence-and-fidelity.md	状態に基づく根拠、忠実度ゲート、会話から観測されたロケール
templates/snippets/conversation-locale.ts.snippet	resolveConversationLocale と Intl formatUserFacing
templates/snippets/tool-budget.ts.snippet	ターンごとのツール／MCP 上限、引数フィンガープリントによる重複スキップ
templates/snippets/prepare-llm-messages.ts.snippet	context_manager ヘルパー
references/error-and-reliability.md	ツールエラー、サーキットブレーカー、再試行、補償、並列処理の陳腐化、コスト停止
references/model-cascade-and-cache.md	低コスト優先のカスケード、両方のシグナルで OR エスカレーション、セマンティック／プロンプトキャッシュ。LLM の intent_classify ホップではありません
references/observability.md	Postgres 監査、保持期間 = テナントの時計、テナント＋期間＋1つの判断によるクエリ、コスト予約
references/architectures.md	ReAct、plan_execute（ほとんどの MCP で推奨される開始点）、Reflection の各レベル、その他のトポロジー。ノード ID ≠ 状態チャネル
references/guardrail-and-adversarial.md	スコープ／安全性分類器。fail-open のスキャフォールド ≠ graph-spec のロック。Gateway のルーティングではありません
references/streaming-and-hitl.md	SSE エンベロープ、オペレーターの thinking、interrupted、SSE の再開、interrupt()、Command による再開
references/turn-flow-gates.md	プロンプト／ループのインシデント：フロー優先、終端、繰り返し、ツールエラー、DoD
templates/contracts/planner-contract.md	JSON プランナーのホップ：executionPlan ＋ userFacingIntent
references/user-memory.md	ユーザーごとの長期メモリ：種類、推論して通知する書き込み経路、呼び出しごとの読み込み、/memories CRUD、LGPD
references/evals-and-gates.md	アーキテクチャ、ツール選択、メモリの評価。ゴールデンセットの昇格
references/anti-patterns.md	完了とマークする前のレビューゲート — ホットパス
references/anti-patterns-extended.md	古いプロンプトのコピー、状態／メモリ、信頼性、グラフ、MCP、LLM、運用、プロセス
テンプレート：templates/agent-runtime/（グリーンフィールド用ツリー）、templates/graph-spec.md、templates/contracts/、templates/snippets/（ブラウンフィールド用パッチ）。

セッション入力

変数	必須
{agent_api_root}	デフォルトは agent-api
{task}	構築、修正、またはレビューする内容

孤立状態からの復旧（ブラウンフィールドを優先）

ランタイムが整理されていない、またはチームが作業を進められない場合：

1. references/orphan-recovery-checklist.md を読み、プロジェクトを評価します。
2. ギャップレポートを作成します：構造、配置、コンテキストウィンドウ、inject/bind の整合性、MCP ガバナンス、HTTP、仕様との同期。
3. 修正計画を順序立てて作成します（規模が大きい場合は、メッセージごとに 1 フェーズ）。
4. ns-coder を使って実装します。

レイアウトとガバナンスの基準を満たすまでは、新しいグラフノードや MCP サーバーを追加しないでください。

構築ワークフロー（グリーンフィールド、または復旧後）

フェーズ 0 — 仕様ゲート

graph-spec.md がない場合は、templates/graph-spec.md をもとに作成します。最低限、次のセクションを含めます：固定ヘッダー（framework、architecture、interaction_mode、guard_fail_mode）、ドメインの所有権、プロンプトの構成、状態スキーマ、ノードの表、エッジ、中断、メモリ、capability の bind/inject 表、recursion_limit、HTTP ルート。

ユーザーがまだアーキテクチャを決定していない場合は、作業を止めて、まず ns-agent-architecture を呼び出します。

フェーズ 1 — スケルトン

{agent_api_root}/package.json がない場合は、scripts/bootstrap-agent-runtime.mjs（references/bootstrap-agent-runtime.md）を実行します。その後、{agent_api_root} で npm install && npm test を実行します。

templates/snippets/ からツリーを組み立てないでください。他の製品をコピーしないでください。コピー後は、src/graph/ を graph-spec.md に合わせます。ドメインコードは、後続フェーズまたは ns-coder を使って conversation/ と config/ に配置します。

既存のツリーがあるブラウンフィールドプロジェクトでは、references/runtime-layout.md に従って調整します。スニペットはパッチにのみ使用します。

フェーズ 2 — 状態と永続化

ブートストラップ後、以下が存在することを確認し、再度スキャフォールドしないでください。graph-spec.md との差分のみを埋めます。

• messages リデューサーを備えた AgentState（Annotation.Root または Zod + MessagesZodMeta）。
• 開発環境と本番環境では PostgresSaver を使用し、MemorySaver は tests/setup.ts でのみ使用します。
• 長期メモリ（graph-spec.md で指定されている場合）：thread_id 単位ではなく、ユーザー単位（tenant_id + user_id）にします — references/user-memory.md。
• すべての invoke/stream で、buildRunConfig を介して configurable.thread_id を渡します。
• JSON プランナー／アナリスト（この処理では bindTools を使わない）：graph-spec.md の状態スキーマで executionPlan と userFacingIntent（または analysis 内のネスト項目）を宣言します — templates/snippets/state.ts.snippet。

フェーズ 3 — LLM とメッセージ

• プロバイダー設定は src/llm/ に配置します（インフラのみ — ドメインプロンプトは含めません）。
• モデルの役割ごとに環境変数を 1 つ使用します（例：chat、summarize、embed）。ソースコードにモデル ID をハードコードしないでください。
• 埋め込みモデルを変更するとベクトルインデックスが無効になります。そのため、全件の再シードが必要です。
• グラフ／ノードの単体テストでは、デフォルトのティアでフェイク LLMを使用します。実モデルが必要なプロンプト／ガードレールの動作テストは、ライブティアで実施します（テストティアについては ns-harness → docker-and-testing.md）。
• 構造化ターンには JSON モードと Zod による解析を優先します。OpenAI 互換のローカルサーバーでは withStructuredOutput を避けてください。
• プロバイダーの出力は contentBlocks / content_blocks で正規化します — references/message-content-blocks.md を参照してください。

フェーズ 4 — コンテキストウィンドウ（必須）

references/context-window-and-tokens.md に従って実装します。

• すべての LLM 呼び出しの前に trimMessagesForLlm を実行します。
• ToolMessage が状態に入る前に、normalizeMcpToolResult、続けて truncateToolOutput を実行します。
• スキルの本文には、独立した CONTEXT_SKILL_BODY_MAX_CHARS を使用します（スニペット skillBodyMaxChars）。
• 使用トークン数が CONTEXT_MAX_TOKENS（生のウィンドウ）の**80%**を超えたら要約します。比率は定数とします：トリガーは 0.8、圧縮後は 0.5、要約上限は 0.1。要約倍率の環境変数は使用しません。
• summarizeOlderMessages では、永続化される圧縮（RemoveMessage + 書き換え）を、同じエージェントノードの戻り値内で行います。

モデルに生の state.messages を渡さないでください。

フェーズ 5 — 機能

1. src/tools/ 内のローカル StructuredTool。
2. MCP：ガバナンスに準拠したクライアント — 検出 → ローカル許可リスト → ワイヤー名 → シングルトンのクライアントライフサイクル（references/mcp-complex-access.md）。
3. スキル：skills/*.md を自動検出 → use_skill__{id} または自動注入（ID ごとにいずれか一方）。

bindTools の前に references/capability-governance.md と references/prompt-and-capability-injection.md を適用してください。バインドの整合性を徹底してください。MCP または外部ツールをバインドする場合は、templates/snippets/tool-budget.ts.snippet を使って、ターンごとのツール／MCP の予算を設定してください。

フェーズ 6 — HTTP とインタラクションモード

モード	要件
sync_json	POST /threads、POST /threads/:id/message
streaming_sse	references/streaming-and-hitl.md に準拠した SSE エンベロープ；コンポーザーの返信では 必ず model.stream() と累積型の response_streaming ティックを使用する（invoke のダンプは不可）；SSE のフラッシュは即時実行；dev-chat はティックごとに flushSync を使用；新規開発では必ずスタイル適用済みの React GET /dev-chat（DEV_CHAT_ENABLED、ローカルのみ）と GET /dev-chat/app.js を提供する；JSON のプランナーホップではオペレーター向けの thinking を 必ず出力する；Docker アーティファクト（Dockerfile、エージェント専用 compose）を提供する
HITL	interrupt() + POST /threads/:id/resume（Accept SSE の場合は SSE）と Command({ resume })；常にエスカレーションする場合は approver_id + approver_role を 必ず送信する；一時停止されたグラフ → 終端状態の interrupted

ユーザーメモリを有効にする場合は、呼び出し元スコープの /memories CRUD（references/user-memory.md §5）を使用します；user_id の取得元は認証情報のみです。

既存システムに dev-chat がない場合は、追加を推奨します — Critical ではありません。Postman は稼働中のルートと同期してください。

フェーズ 7 — 可観測性

references/observability.md に従って、initDb、runStorage、logLlmCall、logToolExecution を接続し、turn_decisions を永続化してください。LangSmith と OTel はオプトインです。

フェーズ 8 — 評価とレビュー

• references/evals-and-gates.md に従ってテストスイートを追加します。
• {agent_api_root} で npm run build && npm test を実行します。
• 差分に対して ns-reviewer を実行します。差分が agent-api に触れる場合は、配置、注入、ワイヤー名、バインドの整合性に関するアンチパターンを検証するよう依頼します。

メンテナンスワークフロー

継続的な作業（新規開発ではない場合）：

1. 3 つの 変更前ゲート
2. 変更後の graph-spec.md が意図したグラフと一致すること
3. レイヤー：グラフノード、会話、MCP、メモリ、HTTP
4. 編集前に対応するリファレンスを読む
5. 配置／注入の引き継ぎを含めて ns-coder で最小限の差分を作成する
6. HTTP ルートの変更時は Postman を更新する
7. 変更に関係する孤立項目チェックリストを再実行する

MCP の複雑なアクセス（簡易ルール）

複数の MCP サーバーがある場合、カタログが重複している場合、または大規模な場合：

• 検出フィルター — バインド前に許可リストに基づいて tools/list をフィルタリングする
• ローカル分類 — read | write | destructive | admin；サーバーの読み取り専用フラグは決して信頼しない
• シングルトンクライアント — プロセスごとに MultiServerMCPClient を 1 つだけ使用する；本番環境ではリクエストごとの stdio を使用しない
• トランスポート — デプロイ環境では Streamable HTTP を使用する；stdio はローカルの単一ユーザー開発のみ
• エラー — MCP の isError: true は回復可能な ToolMessage の status: "error" とする；プロトコル障害では中断し、HTTP/SSE の failed を返してもよい
• シークレット — env または configurable／リクエストペイロードのみを使用する；state や checkpointer には決して保存しない

詳細：references/mcp-complex-access.md。

ns-coder への引き継ぎ

実装が承認されたら、次の内容で委任します：

## LangGraph implementation task

- Root: {agent_api_root}
- Spec: path/to/graph-spec.md
- Phase: [number and name from this skill]
- target_paths: […]
- layer: […]
- do_not_create_under: […]
- injection_notes: [layers / bind vs auto-inject / caps]
- spec_paths_to_sync: […]
- References to apply: [list]
- Acceptance: build + test pass; orphan checklist items [n] resolved; placement + inject + bind parity verified
- Review: ns-reviewer after tests — must check placement, inject, wire names (`:`), bind parity (load ns-langgraph-agents anti-patterns when diff touches agent-api)

診断、仕様、配置、ガバナンス設計、新規開発のブートストラップ用コピーはここで続けてください。機能差分には ns-coder を使用します。バージョンに依存する機能には ns-spec-driven を使用します。

停止条件

条件	対応
graph-spec.md がなく、ユーザーが今すぐコードを求めている	仕様を作成するか、architect を起動する
スニペット／別の製品ツリーからグリーンフィールドを組み立てている	停止し、scripts/bootstrap-agent-runtime.mjs を実行する
配置マトリックス外のパス／フォルダーを新たに作成しようとしている	停止し、許可されたパスを提案する
ドメイン／ロケール／コピーが graph/ または llm/ に入っている	停止し、conversation/config に振り分け直す
パリティのない bind（ディスパッチ可能だが未バインド）	停止し、bind を修正するか、未バインドであることを文書化してテストする
新しいワイヤー名に : が含まれている	停止し、__ 区切りを使用する
Skill の自動注入と同じ ID の bind が明示的な決定なしに併用されている	停止し、どちらかのモードを選択する
CrewAI が要求されている	適切なスキルに誘導する
計画なしで変更が 3 層を超える範囲に及ぶ	1 行の段階的な計画を提示し、承認を待つ
重大なセキュリティ上の欠陥（状態内のシークレット、ガバナンスのない MCP）	機能開発をブロックし、まずガバナンスを修正する

関連スキル（担当範囲）

スキル	担当範囲
ns-langgraph-agents	原則、配置、注入計画、graph-spec、グリーンフィールドのスキャフォールド
ns-coder	機能差分とレビューの反復（初期スキャフォールドのコピーは担当しない）
ns-reviewer	判定。差分が agent-api に触れる場合、このスキルの配置・注入・ワイヤー名・bind パリティに関するアンチパターンを適用する
ns-agent-adaptation	アーキテクチャ設計前の概念的な適応設計
ns-agent-architecture	ロック解除後、Phase 0 より前のフレームワーク選定
ns-spec-driven	スキャフォールド作成後（または最初のタスクがブートストラップの場合）の機能のバージョン管理
ns-investigator	ランタイムのデバッグ

禁止事項

• プランナーの userFacingIntent を response_streaming として、または messages 内の Markdown として出力すること（SSE の thinking のみ。Markdown を書き込むのは composer のみ）
• composer の応答に model.invoke を使うこと、またはターン終了時に response_streaming を一括出力すること。SSE のバッファリング、クライアント側のタイプライター表示、ティックの描画遅延（references/streaming-and-hitl.md）
• userFacingIntent を現在のユーザーメッセージと異なる言語で記述すること（例：オペレーターがポルトガル語で書いたのに、英語で進捗を伝える）
• 構成済みのシステム／ペルソナプロンプト（base_invariant + injected）、またはシークレット／API キーを、グラフの状態、チェックポインター、永続化される messages に保存すること（invoke ごとにシステムテキストを再構築する）
• 長期的なユーザーメモリのキーに thread_id を使うこと、会社／テナントの情報やシークレットをユーザーメモリに保存すること、レンダリング済みのメモリブロックを状態／チェックポインターに永続化すること、または通知する代わりに各メモリについてユーザーに確認を求めること（references/user-memory.md）
• ブートストラップ／.env／configurable.locale を主要なロケールの SoT として扱うこと、またはスレッドに固定されたロケールを永続化すること（会話から観測した turnLocale と Intl を使用する）
• 上限のないツール／MCP の出力を state.messages に渡すこと
• スキル本文にツール／MCP の切り詰め上限を適用すること（CONTEXT_SKILL_BODY_MAX_CHARS を使用する）
• セキュリティ分類に MCP ツールのメタデータを信頼すること
• 本番環境で HTTP リクエストごとに stdio MCP サブプロセスを起動すること
• memory/ で StateGraph をコンパイルすること
• ドメインの適格性確認／会話プロンプトを src/llm/ に配置すること
• ロケール／表示処理を graph/ に配置すること
• ナッジを偽の HumanMessage として扱うこと
• テストを src/ 配下に配置すること
• スニペットや別の製品をもとにグリーンフィールドのツリーを作ること — templates/agent-runtime/ のみを使用すること