設計: 別ホストの Docker に dev コンテナを立ち上げ、VS Code もそこへ接続する（PLAN52）

[takemi-ohama]

Pull Request

概要

issue #162 の要求仕様と設計（PLAN52）を載せる設計 Pull Request です。実装は含みません。マージ後に実装用の作業ツリーを作り直して進めます。

projects/<name>/project.local.yml（gitignore 対象の個人設定）に docker.context / docker.home / docker.gid を書くと、devbase up/down/ps/login/build が別ホストの docker daemon を相手に動き、devbase up が開く VS Code がそのホストのコンテナへ attach する状態を作ります。

関連 Issue

• feat: 別ホスト (Windows/WSL・別 PC・EC2) の Docker に dev コンテナを立ち上げ、VS Code もそこへ接続する #162（実装 PR で閉じるため、ここでは閉じない）

変更点

• issues/PLAN52_remote-docker-context.md — 要求と受け入れ条件（依頼原文・調査で確定した事実・前提・対象範囲・受け入れ条件・非機能・検証手段）
• issues/PLAN52_remote-docker-context-design.md — 構成要素・構造・データ構造・入出力の契約・処理の流れ・非機能の実現方式
• issues/PLAN52_remote-docker-context-decisions.md — 決定の記録 12 件とテスト設計

issue の提案から外した点:

点	決定
project.yml → project.local.yml の深いマージ	マージせず別の型で読む（決定 2）。初期スコープの docker 節は project.yml に無いキーで、マージ対象が無い
リモート判定	「設定があれば」ではなく「解決した context が docker context show と異なるとき」（決定 3）
スナップショット	リモート扱いの up は自動スナップショットを飛ばす。devbase snapshot 系は従来どおり手元を対象（決定 12）

動作確認

• python3 の集計で 3 文書の平均文長・最長文・章の行数を再構成の前後で測った（ドキュメント再構成の工程）
• 内部整合の 6 対（構成要素 ↔ 流れ、受け入れ条件 ↔ テスト設計 等）を突き合わせた
• CI が green である（Markdown のみの変更）

補足

レビューでは特に次を見てほしい点:

• DOCKER_GID をリモートで docker run alpine:3 stat で取る案（決定 5）と .cache/docker-gid/<context> の控え
• CLI / env で context を上書きしたときにファイルの home / gid を使わない規則（前提 4 / 決定 4）
• shell の build が docker を env exec 経由で叩く変更（決定 9）

🤖 Generated with Claude Code

https://claude.ai/code/session_01MpE7aJufCtCacsm1Z3o83X

[takemi-ohama]

🤖 cross-review | round 1 | kiro | COMMENT

設計 PR（実装なし・Markdown 3 文書）。コード側の主張（bin/devbase:37 の DOCKER_GID、opener.py:683 の resolve_docker_context(env) if ssh_host else None、_load_compose_config の YAML 直読、shell cmd_build の buildx build / image inspect、_dispatch_lifecycle / _auto_snapshot / _run_build、snapshot の :/backup bind mount）は実コードと一致することを確認済み。修正が要るのは文書間の確定状態の食い違い 1 件のみ（インライン参照）。

[takemi-ohama]

🤖 cross-review | round 1 | agy | COMMENT

総評

PLAN52（リモート Docker context 対応）の要求仕様書、設計書、決定記録のレビューを実施しました。
構成要素、データモデル（ContextChoice / DockerTarget）、優先順位、状態遷移、非機能要件など極めて精緻に設計されていますが、既存の CLI 仕様およびラッパースクリプト（bin/devbase）の実装との突き合わせにおいて、実装時の誤認やバグを未然に防ぐための修正・明確化アクションが 3 点あります。

1. bin/devbase における build --context のディスパッチ誤分岐防止（major）
2. CLI --context の対象コマンド記述における logs の位置づけの整理（major）
3. scale コマンドにおける機能一覧・受け入れ条件の整合性確保（minor）

詳細は各インラインコメントをご確認ください。

[takemi-ohama]

🤖 cross-review | round 2 | kiro | APPROVE

設計のみの PR。3 文書のコード引用（bin/devbase:36 の DOCKER_GID、editor/opener.py:683 の resolve_docker_context(env) if ssh_host else None、build_attach_uri の docker_context 引数と settings.context、cmd_build の docker buildx build 直接呼び出し、_dispatch_lifecycle の chdir 経路、status.py の docker ps、_load_compose_config/_pull_marker_path）を実コードと突き合わせて確認し、すべて一致。決定 1〜12 と受け入れ条件・テスト設計・前提の間にも矛盾は見当たらず、修正を要する指摘はありません。

[takemi-ohama]

🤖 cross-review | round 2 | codex | REQUEST_CHANGES

接続先の確定・子プロセスへの引き継ぎと、機密情報の転送境界について設計の修正が必要です。

[takemi-ohama]

🤖 cross-review | round 3 | codex | REQUEST_CHANGES

仕様適合: shell の build と自動ビルドでも、機密注入後まで CLI > env の優先順位を保持する設計にしてください。

[takemi-ohama]

🤖 cross-review | round 3 | agy | APPROVE

Round 2 での指摘事項（docker context show 実行時の環境変数隔離、_run_build における --context 引数伝播、機密環境変数と秘密ファイルの責務境界記述）が commit c27edb6 にて適切に対処されていることを確認しました。

各ドキュメント（要求仕様・詳細設計・決定記録）間および既存コードベース（bin/devbase・Python CLI / ランタイム）との整合性、テストマトリクスと受入基準の網羅性に問題はありません。

[takemi-ohama]

🤖 cross-review | round 4 | kiro | REQUEST_CHANGES (COMMENT)

設計は自己整合的で、コード側の事実（bin/devbase:37 の DOCKER_GID、cmd_build の docker 直呼び、opener.py の resolve_docker_context(env) if ssh_host ゲート等）とも一致していました。ただし context 解決の土台に関わる事実誤りが 1 件あるため、修正を提案します。

修正提案（body 側）

• issues/PLAN52_remote-docker-context.md:104（前提7 / 完全性）: 前提7 は devbase が DOCKER_HOST を受け取らないことだけを扱っていますが、利用者のシェルに既存の DOCKER_HOST があると Docker 側でそちらが DOCKER_CONTEXT より優先され、リモート判定が真でも接続先は手元の DOCKER_HOST に向き警告なく壊れます。受け入れ条件に「解決 context が非 None かつ環境に DOCKER_HOST があるとき up は競合を警告する（または DOCKER_HOST を落として context を優先させる）」を 1 件足してください。

[takemi-ohama]

🤖 cross-review | round 4 | agy | REQUEST_CHANGES

決定 9 での改定（--context を環境変数 DEVBASE_DOCKER_CONTEXT に写さずシェル変数に保持して引数渡しする方式）に伴うテスト設計記述の修正漏れが 1 点あります。インラインコメントの修正をお願いします。

[takemi-ohama]

🤖 cross-review | round 5 | kiro | APPROVE

設計 PR として要求・設計・決定の 3 文書を精査した。opener.py:683 の context 解決条件、bin/devbase の DOCKER_GID 決定、cmd_build の docker 直接呼び出し（buildx build / image inspect / compose build）、build ディスパッチの --context を単体イメージ名として拾う誤分岐リスクなど、コード側の非自明な主張を worktree の実装と突き合わせて確認し、いずれも実装と一致していた。文書間の整合（受け入れ条件 ↔ テスト設計、リモート判定を DOCKER_CONTEXT 除去環境で行う点、DOCKER_HOST 優先の扱い）も矛盾は見つからなかった。追加の修正アクションは無い。

[takemi-ohama]

🤖 cross-review | round 5 | codex | REQUEST_CHANGES

修正が必要な指摘が1件あります（major）。

[takemi-ohama]

🤖 cross-review | round 6 | codex | REQUEST_CHANGES

現在の context を取得する際の環境変数の扱いについて、修正を 1 件指摘します。

[takemi-ohama]

🤖 cross-review | round 6 | agy | REQUEST_CHANGES

PLAN52 の要求仕様、アーキテクチャ設計、決定記録の全体を精査しました。
前提の整理、優先順位、DOCKER_CONTEXT 伝播、機密注入の再適用（決定 13）などの設計は非常によく詰められていますが、テスト設計における「ローカル扱い」の docker コマンド呼び出し回数の定義に用語集との論理的矛盾があり、テスト実装時に不整合を招く懸念があります。
また、_inject_secrets への再適用処理の組み込み責務について記述の明確化が必要です。

主な指摘事項

1. [major / 一貫性・テスト設計] decisions.md L180: 「ローカル扱い」の定義と性能・テスト条件の不整合

   • 用語集（PLAN52 L330）では未指定（None）と指定あり（手元 context と一致）の両方が「ローカル扱い」に含まれます。
   • 後者の場合、手元 context と一致しているか判定するために docker context show が 1 回呼ばれますが、L180 では「ローカル扱いの up で docker context show が呼ばれない」と一括りにされており、テスト設計として矛盾しています。未指定時と手元一致時でテスト条件を分離してください。
   • 関連する PLAN52_remote-docker-context.md L283、PLAN52_remote-docker-context-design.md L392 の性能要件記述も合わせて精緻化してください。

2. [minor / 設計明確化] design.md L354: _inject_secrets 再適用の責務・配置方針の明確化

   • _inject_secrets は既存コード上引数を取らない共通関数です。「そこに再適用を置けば漏れない」と関数内部に置くニュアンスで書かれていますが、確定結果をモジュール保持するのか、各ハンドラ側で _inject_secrets() の直後に呼ぶのかの責務を明記してください。

[takemi-ohama]

🤖 cross-review | round 7 | kiro | APPROVE

設計 PR として要求・設計・決定の 3 文書は内部整合が取れており、コード側の事実アンカー（editor/opener.py の build_attach_uri / resolve_docker_context、resolve_docker_context(env) if ssh_host else None）も現行実装と一致することを確認した。ブロッカーは無い。実装前に潰しておくと良い minor をインラインで 1 件だけ残す（gid 取得が socket の docker グループ所有を暗黙前提にしている点）。

[takemi-ohama]

🤖 cross-review | round 8 | kiro | APPROVE

設計 3 文書（要求・設計・決定）を再精査し、head commit 8479d87 の差分（決定 5 の rootful 前提と gid=0 警告）が要求の受け入れ条件・決定の記録・テスト設計の 3 箇所へ一貫して反映され、システム環境行の rootless / root:root 除外記述とも矛盾しないことを確認した。設計の主張はコード側の事実（opener.py の空文字オプトアウト、cmd_scale が _auto_snapshot を呼ばず自動スナップショットが up 限定であること）とも整合している。新たに修正を要する指摘は無い。

[takemi-ohama]

🤖 cross-review | round 8 | codex | REQUEST_CHANGES

接続先解決前のプロジェクト切替と機密再読み込みの順序を修正してください。

[takemi-ohama]

🤖 cross-review | round 9 | codex | REQUEST_CHANGES

修正が必要な指摘は 1 件です。

[takemi-ohama]

🤖 cross-review | round 10 | kiro | APPROVE

設計 3 文書のコードベース参照（bin/devbase:37 の DOCKER_GID、editor/opener.py:683 の resolve_docker_context(env) if ssh_host else None、_inject_secrets の clear_injected、cmd_env_exec の child_env、cmd_up / cmd_scale の compose 生成経路）を worktree の実コードと突き合わせて確認し、いずれも一致した。要求↔設計↔決定↔テスト設計の相互参照とリモート判定・機密再適用（決定 13）・非存在 context の失敗経路も内部整合が取れている。修正を要する指摘は無い。

[takemi-ohama]

🤖 cross-review | round 10 | agy | REQUEST_CHANGES

lifecycle コマンド全体での接続先反映・リセットの整合性について 3 点の修正を提案します。