Skip to Content
デザインDaemon Multi-Workspace Phase 1 レジストリ

Daemon Multi-Workspace Phase 1 レジストリ

概要

Phase 1 では、qwen serve 用の内部シングルランタイムレジストリと、issue #6378 で言及されている2つのガードレール（デーモンスコープの ID と、繰り返し可能な --workspace 入力の処理）を導入します。デーモンは引き続き正確に1つのプライマリワークスペースのみを提供します。複数の明示的な --workspace 値が古いシングルワークスペースパスにフォールバックするのではなく、明示的に失敗するようになった点を除き、ルート/API の動作は変更されません。デーモンのログファイル名とテレメトリサービスの instance id も、意図的にワークスペーススコープからデーモンスコープの ID に変更されます。PR のリリースノートでは、この移行について言及する必要があります。

このレジストリは issue #6378 のマルチワークスペースロールアウトに向けた将来の内部境界となりますが、このステップでは意図的にプロトコル/スキーマの拡張を避け、マルチワークスペース CLI 動作は有効化しません。

設計

  • WorkspaceRuntime は、現在のシングルワークスペースの serve オブジェクト（workspaceCwd、AcpSessionBridge、DaemonWorkspaceService、REST ルートファイルシステムファクトリ、および現在の client-MCP sender registry）をラップします。
  • WorkspaceRegistry は primary、list()、および厳密な getByWorkspaceCwd() ルックアップのみを公開します。
  • createServeApp はまず既存の bridge/service/fsFactory スタックを構築し、次にそれをプライマリランタイムとしてラップします。
  • 既存の app.locals.fsFactory と app.locals.boundWorkspace は、現在のファイルルート用にそのまま残ります。app.locals.workspaceRegistry は追加要素です。
  • ルートモジュールは現在のシグネチャを維持します。サーバーアセンブリ層は現在、workspaceRegistry.primary から値を渡します。
  • デーモンのログファイル名とテレメトリサービスの instance id はデーモンスコープです（serve-<pid>.log、daemon:<pid>）。ワークスペースハッシュは、デーモン ID の一部になるのではなく、ログ/テレメトリレコードの属性として残ります。
  • runQwenServe は、workspace が配列である可能性のある yargs ランタイムシェイプを受け入れます。単一の値は引き続き既存のシングルワークスペースと同じように動作します。複数の値は、マルチワークスペースサポートが有効になるまでブートエラーになります。

範囲

  • 繰り返し可能な --workspace のサポートはまだありません。繰り返しの値は拒否されます。
  • /capabilities やデーモンステータスに workspaces[] はありません。
  • SDK 型の変更はありません。
  • 複数の /workspaces/:workspace/... ルートはありません。
  • セッション所有権インデックス、env overlay、maxTotalSessions、またはワークスペース修飾された ACP/voice/channel ワーカー動作はありません。

監査ノート

ルートファイルシステムファクトリは routeFileSystemFactory という名前です。これは、本番環境で現在ブリッジファイルアクセスと REST ルートファイルアクセスを区別しているためです。レジストリはこれらの境界を崩してはなりません。

ClientMcpSenderRegistry は、このフェーズでは現在のプロセススコープのシングルデーモンマップのままです。ランタイムは既存のインスタンスのみを保存します。ワークスペーススコープの client-MCP 分離は、後のマルチワークスペースでの課題です。

SessionArchiveCoordinator と WorkspaceRememberTaskLane は、現在のサーバーアセンブリの協力者としてそのまま残ります。これらは Phase 1 におけるレジストリのコア責任ではありません。

デーモンテレメトリミドルウェアは、Phase 1 でも引き続き常にプライマリに解決されますが、リクエスト時にワークスペース cwd を解決するようになりました。これにより、ワークスペース修飾ルートが導入された後に誤りとなるプライマリワークスペースハッシュクロージャを避けつつ、現在の動作を維持します。

検証

対象のテストは、厳密なレジストリルックアップ、createServeApp の locals 公開、注入されたルートファイルシステムファクトリの保持、既存のファイルルート locals 動作、デーモンスコープのログ/テレメトリ ID、リクエスト時のワークスペースハッシュ化、yargs の単一/繰り返し --workspace シェイプ、シングルワークスペース配列パス、および繰り返し --workspace ブートガードをカバーしています。最終検証では、フォーカスされた serve テストに加えて、リポジトリのビルドと型チェックを実行する必要があります。

Last updated on
Daemon アイドル検出インターフェース設計Phase 2a マルチワークスペースセッション基盤