duoduo-runtime-admin

Duoduo ランタイム管理

このスキルは、ホストモードのランタイムフラグ、デーモンの診断、および ~/.config/duoduo/.env に保存される設定を管理します。

最初にランタイムを確認する

1. duoduo daemon status でホストモードになっていることを確認します。
2. 保存される設定を変更する前に、duoduo daemon config を読みます。
3. ユーザーが設定変更を求めているのではなく、動作の問題を調査している場合は、 duoduo daemon logs を使います。

ホストモードの主な設定項目については references/runtime-settings.md を、Codex を有効にする前に references/codex-runtime.md を、Grok を有効にする前に references/grok-runtime.md を、Pi を有効にする前に references/pi-runtime.md を読みます。Pi の「Context and compaction」 セクションでは、1文字だけで応答するようになった pi セッションについても説明しています （モデルの故障ではなく、コンテキストウィンドウが埋まった状態です）。

保存されるホストモード設定

予測可能な結果を得るには、場当たり的にシェルで編集するのではなく、 scripts/update_host_env.py を使って ~/.config/duoduo/.env を編集します。

ユーザーから duoduo 自体が古くなっているか尋ねられた場合は、次を確認します。

duoduo --version
npm view @openduo/duoduo version

その後、変更する前に、実際に更新が必要かどうかを説明します。

一般的なキー：

• ALADUO_DEFAULT_RUNTIME
• ALADUO_LOG_LEVEL
• ALADUO_LOG_RUNNER_THOUGHT_CHUNKS
• ALADUO_LOG_SESSION_LIFECYCLE
• ALADUO_TELEMETRY_ENABLED
• ALADUO_CADENCE_INTERVAL_MS
• ALADUO_SPINE_INDEX_RETENTION_DAYS
• ALADUO_CODEX_SANDBOX（codex は自動検出されます。有効化フラグはありません — codex-runtime のリファレンスを参照）

デーモンの環境設定を変更した後は、次を実行します。

duoduo daemon restart -r "changed <setting>"

ただし、ユーザーが編集のみを明示的に依頼した場合は除きます。

ランタイムの選択

正確に判断してください。

• ランタイムが指定されていない場合、Claude が引き続き保守的なフォールバックになります。
• Claude、Codex、Grok、Pi は、チャネルセッション、ジョブ、および対象となるバックグラウンドパーティションで同等のランタイムです。Codex と Grok は自動検出されます。CLI をインストールしてログインしてください（codex login ／ grok login）。 プローブに失敗しても次のメッセージで再試行されるため、メッセージのルーティングに再起動は不要です。ただし、セットアップカードに表示されるランタイム一覧は起動時のプローブに基づくため、新しいインストールを反映するには duoduo daemon restart が必要です。Pi は duoduo に同梱されており、インストール不要で、常に利用可能と報告されます。ただし、すべての pi セッションには、ジョブのフロントマター、/model、またはパーティションのフロントマターで指定されたモデルポインター（provider/modelId）が必要です。
• ランタイムはアクターごと、チャネル種別ごと、または ALADUO_DEFAULT_RUNTIME（claude、codex、grok、pi）によってグローバルに選択できます。
• duoduo が認識しないランタイム値は拒否され、別のランタイムに置き換えられることはありません。ALADUO_DEFAULT_RUNTIME ではデーモンが起動しません。チャネル記述子では、そのレイヤーが選択するランタイムを使うターンが拒否されます（有効なインスタンス値は、未知の種別値を上書きします）。ジョブは失敗し、パーティションはスキップされます。いずれの場合も、値と有効な値を示す文が表示されます。void は、セッションでモデルを実行しない tether などのプラグイン向けのチャネル値です。デフォルト、ジョブ、パーティションでは拒否されます。
• 作業を Codex にルーティングする前に、codex がインストール済みで、認証済みであることを確認します。Grok では、duoduo はバイナリのみを確認します。作業をルーティングする前に、ログイン状態を自分で確認してください。明示的に指定された codex または grok を利用できない場合は、ハードエラーとなります。そのターンは理由とともに拒否され、Claude では実行されません。Pi も同様です。解決可能なモデルがない pi セッションは、返信に修正方法を示して失敗し、Claude で黙って実行されることはありません。

セッションのランタイムを切り替える

セッションは、その会話 ID を所有するランタイムに紐付けられています。ランタイムの履歴は相互に置き換えられません。runtime の値（インスタンスまたは種類の記述子、ALADUO_DEFAULT_RUNTIME、ジョブのフロントマター）だけを変更しても、既存のセッションは移行しません。次のターンは拒否され（「Request was not executed」）、紐付け先のランタイム、セッション ID、設定されたランタイムが示されます。

• 認められている唯一の切り替え方法：まずチャンネルのセッションで /clear を実行してから、ランタイムを変更します。古いランタイムで設定した /model のオーバーライドは新しいランタイムでは引き継がれません。同じランタイムで設定した /model のオーバーライドは /clear の後も保持され、/effort も保持されます。
• 書き込み時に拒否：インスタンスでの duoduo session config <target> set runtime=<rt> と、ランタイムを変更するチャンネルの再起動（セットアップカードなど）は、そのチャンネルのセッションが別のランタイムに紐付いている場合は拒否され、該当するセッションが一覧表示されます。それぞれで /clear を実行してから再試行してください。種類スコープ、環境変数、ジョブのフロントマターの変更は書き込み時にはチェックされません。影響を受けるセッションは次のターンで拒否されます。
• 元に戻す場合：ランタイムを紐付け先のものに戻し、メッセージをもう一度送信してください。セッションは通常どおり再開します。
• 以前の作業を保持する場合：実際に切り替える前であれば、古いセッションの履歴は拒否時に示された ID のままディスク上に残っています。サブエージェントにその履歴を探して要約させてから、/clear を実行してください。
• ジョブ：ランタイムが一致しなくなったステートフルジョブは、所有者が判断するまで実行に失敗します（job.fail、所有者が起こされ、失敗時のバックオフ後に再試行）。所有者はランタイムを元に戻すか、新しいジョブで作業を開始します。ステートレスジョブには影響しません。

潜在意識の更新

<kernel>/subconscious/ 配下のパーティションプロンプトは、npm install によるアップグレードでは変更されません。インストールでは不足しているファイルのみがマージされ、ローカルの編集やエージェントによる自己プログラミングは保持されます。新しい duoduo バージョンに同梱された改訂版パーティションプロンプトを使う場合は、明示的に更新する必要があります。

変更を加える前に、references/subconscious-refresh.md を読んでください。事前条件（カーネルの git ツリーがクリーンであること、対象タグの確認）、上書き前に差分を確認する手順、ユーザーが作成したパーティションと同梱パーティションへのローカル編集の扱い、ロールバックポイントとしてコミットを使うパターン、更新後にデーモンの再起動が不要な理由について説明しています。

メモリメンテナンスのうち、LLM を使わない機械的な処理は duoduo memory CLI で行います。パーティションの受信箱に .pending シグナルを送る処理の lint チェックと、孤立データを手動で reclaim するライフサイクルが含まれます。オペレーターまたはパーティションが直接必要とする場合は、references/memory-cli.md を読んでください。

実行間隔とテレメトリ

• 実行間隔を変更する前に、間隔を短くするとバックグラウンドの処理とトークン使用量が増えることを説明してください。
• テレメトリの永続化を無効にすると JSONL の書き込みは停止しますが、プロセス内のデバッグログがすべて抑制されるとは限りません。
• このマシンでのデフォルト値について説明する前に、duoduo daemon config を使って現在の有効値を確認してください。

使用量台帳のメンテナンス

var/usage/<session_key>.jsonl は追記専用で、自動的な保持期間の設定はありません。長期間稼働するホストでは、数百 MB ものデータが蓄積します。ホストのオペレーター（または依頼を受けたこのスキル）が、古いファイルを同階層の var/usage-archive/<bucket>/ にアーカイブします。デーモンの再起動は不要です。usage.get の呼び出しごとに var/usage/ をスキャンします。

確認済みの find -mtime +N | xargs mv の手順、復旧方法、競合が発生しうる時間帯については、references/usage-archive.md を読んでください。

スラッシュコマンド（/compact、/model、/effort）

/compact はコンテキストウィンドウをその場で縮小します。すべての ランタイムで動作し、通常のチャネルメッセージパイプライン （spine → mailbox → drain）を通るため、コマンドの完了時にユーザーには 通常のテキスト返信が届きます。

ランタイムのセマンティクス、コマンドが機能していないように見える場合の トラブルシューティング、困惑しているユーザーへの説明については、 references/slash-commands.md を 参照してください。

/model は再起動せずに、実行時にセッションのモデルを切り替えます。 構文、Claude と Codex のタイミングの違い、無効なモデル ID からの復旧方法に ついては、references/model-switching.md を 参照してください。Pi では /model はストアへの保存のみを行い、 次のメッセージで新しいモデルを使ってセッションのワーカーが再構築されます。 詳しくは references/pi-runtime.md を 参照してください。

ユーザーが 1 つのセッションではなく、多くのセッション（チャネル種別の すべてのセッション、またはホスト全体）で使うモデルを希望している場合は、 モデルのデフォルト設定を使用します（claude.model / codex.model / pi.model / grok.model、0.8.1+）。これはグローバル、種別、インスタンスの 各レイヤーで duoduo session config を使って設定します。各レイヤーの説明、 優先順位、/model が現在報告する 2 つの情報（セッションが継承する設定レイヤーと、 直近のターンに実際に応答したモデル）については、 references/model-defaults.md を 参照してください。ユーザーがモデルの設定が「定着しない」、 または「以前のものに戻った」と言った場合は、必ずこのファイルを確認してください。 この 2 行が原因の特定につながります。

サードパーティ製モデルを実行するホストでは、モデルプロファイルを使って duoduo に各モデルの実際のコンテキストウィンドウ、エンドポイントと認証情報 （モデルごとのルーティング）、サブエージェントのティア別エイリアスを設定します （Claude ランタイムのみ。codex にはプロファイルの名前空間はありません）。 プロファイルに関する質問に答える前に必ず references/model-context-profiles.md を 参照してください。このドキュメントは、ユーザーに伝えられる平易な表現を含む 手順書（モデルの追加／エンドポイントへのルーティング／ティアの再マッピング／ トラブルシューティング／エンドポイントのプローブ）として書かれており、 末尾には自分で確認するための仕組みの詳細も記載されています。必ず守ること： シークレットの取り扱い（人間からチャット、環境変数、ファイル経由でキーを受け取る ことはできますが、出力する内容に生の値を含めてはいけません。すぐにプロファイル ストアに保存し、マスクされていることを確認してください）、数値を示す前に根拠を 確認すること、再構築にコストがかかる書き込みの前に確認を取ること。

/effort は、セッションでモデルがどの程度深く推論するかを設定します （low | medium | high | xhigh | max）。これは /model とは独立した軸です。 Claude では即時に反映されます（max をサポートしない Claude モデルでは、 max は high として実行されます）。Codex と Pi では次のメッセージから 反映されます（Pi では各レベルが pi のネイティブな思考レベルに対応します）。 無効な値は即座に拒否されます。Grok では、モデルがサポートするレベルでなければ 変更は拒否されます。references/slash-commands.md の /effort のセクションを参照してください。どちらの設定も CLI から セッションごとに設定できます（0.8.0+）。duoduo session model / duoduo session effort を使います。詳しくは references/session-cli.md を参照してください。

セッション管理（duoduo session …）

これらのサブコマンドを使うと、CLI からセッションを管理できます（人、Bash 経由のエージェント、外部スクリプトのいずれも同じ入口を使用します）。

• duoduo session list [--kind …] [--named] [--json] — 現在のルートテーブルを表示します。
• duoduo session alias <key> "<name>" — セッションに人が見てわかるラベルを付けます。list で判別できるようになり、notify の宛先としても使えます。名前のないセッションには — が表示されます（キーが自動的にラベルとして付けられることはありません）。
• duoduo session notify <target> -m "<msg>" [--force] — キーまたはエイリアスでセッションに連絡し、送信元タグ付きの通知をすぐに届けます。宛先にできるのは channel／job のみです。潜在意識／カーネルのプレーンは分離されており、拒否されます。1 時間読み取られていないチャンネルセッションへの通知は no_consumer で拒否されます（0.8.2 以降。返信には読み手のいるセッションが示されます。--force で強制できます）。<room> · <device> とタグ付けされた通知は、notify スコープを持つアンビエントデバイス（duoduo-ambient、references/devices.md）から届いたものです。停止するには、そこでデバイスを取り消してください。
• duoduo session wake <target> --in <duration> | --at <iso>（v0.8.1 以降）— 標準入力から読み取ったコンテキストを使って、そのセッションの将来のターンを 1 回だけスケジュールします。Notify は今すぐ届け、wake は後で届けます。宛先のルールは notify と同じで、channel／job のみが対象です。潜在意識／カーネルのプレーンは拒否されます。実行前にキャンセルするには duoduo job archive <wake-id> を使います。
• duoduo session model <target> [<id>|reset] / duoduo session effort <target> [<level>|reset]（0.8.0 以降）— セッションのチャットを開かずに、CLI からチャンネルセッションのモデル／推論の強度を確認または設定します。チャット内の /model と /effort と同じ設定項目です。チャンネルセッションのみが対象です。
• duoduo session archive <key> — セッションのアーティファクトを移動します（削除はしません）。

ユーザーが「このセッションを X と呼んで」／「把这个会话叫 X」と言った場合や、名前で別のセッションからセッションを起動したい場合は、これを使います。詳しい使い方、分離の境界、出力／--json のルール、拒否される理由については、references/session-cli.md を参照してください。

ジョブのライフサイクル（duoduo job …、v0.8.1 から）

スケジュール済みジョブの確認と終了は CLI から行います。セッション内のツールではジョブを作成、一覧表示、読み取りできます。ジョブを終了または再スケジュールする動詞はすべてシェルコマンドなので、ターミナルの人間、Bash を使うエージェント、外部スクリプトのいずれも同じコマンドを使用します。

• duoduo job list [--json] — スケジュール、保留中の単発実行、最終実行、最終結果を含むアクティブなジョブを表示します。保留中のウェイクもここに表示され、セッションが自分自身のためにスケジュールしたものか、オペレーターが duoduo session wake でスケジュールしたものかにかかわらず、wake として種別が示されます。
• duoduo job read <id> [--json] — 1 つのジョブの定義、ミッション、エラーを含む最終実行を表示します。
• duoduo job archive <id> — 今後のスケジュールを停止します。何も削除されません。ジョブのファイルは var/jobs/archive/ に移動され、そのセッションも一緒にアーカイブされます。すでに実行中の処理は最後まで続きます。保留中のウェイクをキャンセルする場合も、このコマンドを使います。
• duoduo job interrupt <id> -r "<reason>" — 進行中の実行を終了するよう要求します。-r は必須です。理由は次回実行時にジョブに伝えられるため、「停止」ではなく、何が変わったのかを記述してください。実行がどう収束するかはコマンドではなく、ジョブ自身のライフサイクルによって決まります。一度限りで再設定されていないジョブはアーカイブされ、所有者には失敗したことが通知されます。それ以外のジョブはスケジュールされたままです。また、順番が来る前に中断された実行は、開始されなかったものとして保持されます。受領通知の「中断済み」を「その実行は終了した」と解釈しないでください。これは要求が受理されたことを意味します。
• duoduo job reschedule <id> <when> — @in 30m またはゾーンを明示した ISO タイムスタンプで、追加の単発実行を設定します。スケジュールの種別は変更されません。

動詞は 2 つで、それぞれ意味が異なります。誤って入れ替えやすいため注意してください。archive は今後の実行を停止し、現在の実行には触れません。interrupt は現在の実行を終了し、スケジュールには触れません。動作が止まった定期実行ジョブでは、通常は両方が必要です。

ユーザーから質問された場合は、interrupt が及ぶ範囲を正確に伝えてください。ランタイムに停止が要求されます。中断シグナルを無視するツールは強制終了されず、実行がバックグラウンドプロセスに切り離した処理には、まったく作用しません。

Spine の検査（duoduo spine …、0.8.0+）

イベントログ（Spine WAL）は、JSONL パーティションを直接開くのではなく、CLI 経由で読み取ります。1 日分で 10～30 MB に達することがあり、ツールの実行結果がメガバイト単位になる場合もあります。また、生の行の 92% は、読み手に不要なツール処理の記録です。

• duoduo spine cat --date <yyyy-mm-dd> [--session <key>] [--type <t>]… [--kind external|all] [--from … --to …] [--after <id>] [--json] — 簡潔な トランスクリプトを出力します。人間とエージェントのテキストは全文を表示し、ツール呼び出しは use=／res= の詳細表示用アンカー付きの 1 行にまとめます。複数の件数を正確に示すヘッダーと、 END spine フッターも表示します（フッターがない場合、読み取りは途中で切り詰められています）。 --date の既定値は今日です。時刻はすべて UTC で、範囲の端は常に (from, to] です。 --from/--to には、オフセット付きの絶対 ISO 時刻（2026-08-31T08:29+08:00）も指定でき、 その範囲は複数日にまたがることがあります。--after <id> は同じ範囲内のイベントの直後から 厳密に再開するため、同じ読み取り結果の後続部分を出力します。
• --kind external はターン単位の指定であり、ソースのフィルターではありません。外部から届いた イベントに加えて、残された各 channel.message が開始したターン内の内部行も保持します。 ジョブセッションは展開されません。既定値は all です。
• duoduo spine cat --interval '<date>[t1,t2]' … — 機械処理向けの範囲指定読み取り（サブコンシャスが 使用する形式）を行います。1 つのパーティションを対象とし、範囲の端は同じく (t1, t2] です。 インターバルは必ず引用符で囲んでください。zsh は角括弧をグロブとして扱うため、CLI の実行前に エラーになります。
• duoduo spine cat … --sessions — セッションごとの概要（正確なキー、イベント数、最初と最後の ts）を 表示します。イベントの多い日にセッションキーを探すときに使用します。
• duoduo spine cat … --count-only — 本文を表示せず、サイズのみを出力します。大きな範囲を エージェントのコンテキストに取り込む前に確認してください。
• duoduo spine show <event-id> [--date <yyyy-mm-dd>] — 1 件のイベントを、省略なしの完全な JSON で 表示します。行 ID は表示時に短縮されますが、show には一意なプレフィックスを指定でき、 曖昧な場合は候補が一覧表示されます。ID インデックスは、起動時に圧縮される直近のイベント用 キャッシュです。古い ID だけを指定した場合は、パーティション全体をスキャンします。 --date はそのスキャン範囲を狭めるだけで、WAL の行は変更されません。
• 絞り込みなしで本文を出力する cat は、--unfiltered を指定しない限り拒否されます。これは エージェントのコンテキストウィンドウを保護するためのものであり、アクセス許可ではありません。 --count-only と --sessions は本文を出力しないため、この制限の対象外です。1 日分全体の サイズ確認にこのフラグは必要ありません。
• ヘッダーの missing_partitions=／skipped_malformed= はエラーではなく、情報の開示です。イベントの ない日はパーティションファイルが作成されず、最後の行が途中で切れているのは通常のクラッシュ時の 生成物です。

運用ルール

• 設定値が古いドキュメントと食い違う場合は、duoduo daemon config を優先してください。
• ホストモードでは、~/.config/duoduo/.env を永続的な信頼できる情報源として扱ってください。
• ユーザーがインストール済みの @openduo/duoduo パッケージを更新した場合は、実行中のデーモンが 別個のバックグラウンドプロセスであるため、duoduo daemon restart も必要だと伝えてください。
• 設定、再起動、ログを確認しても実行時の動作に問題がある場合は、duoduo のバグである可能性が高いと 考え、 ../duoduo-admin/references/issue-reporting.md に記載された 公開の問題報告手順を利用してください。
• 依頼の内容が実際にはチャンネルのインストール／起動／プロンプト／ワークスペースに関する作業である 場合は、duoduo-channel-admin に引き継いでください。