feat: 再起動なしで VS Code だけ開き直すコマンドを新設し、devbase list の起動中メニュー先頭へ置く

[takemi-ohama]

何ができないか

一度閉じた VS Code の窓を、コンテナを止めずに開き直す手段が無い。

devbase up は最後の段 [6/6] でエディタを開く（lib/devbase/commands/container.py:951 _maybe_open_editor）。しかしこの経路は cmd_up からしか呼ばれない。窓を手で閉じたあと同じ窓を出し直すには、コンテナが動いているのに devbase up をやり直すしかない。

$ grep -rn "_maybe_open_editor" lib/
lib/devbase/commands/container.py:951:def _maybe_open_editor(project_name: str, open_flag: Optional[bool],
lib/devbase/commands/container.py:1284:        _maybe_open_editor(project_name, open_editor, open_index, scale,

devbase up のやり直しは、動いているコンテナに対して pre-up チェック・自動スナップショット・ボリューム/ネットワークの作成・compose の再生成・deploy フック・ready 待ちを通す（cmd_up → _run_deploy_pipeline）。窓を 1 つ開くためだけに払う手順ではない。

エディタを開く処理そのものは lib/devbase/editor/opener.py:721 open_editor() に閉じており、up の成否とは独立している（開けなくても up は倒さない）。呼び出す入口が無いだけである。

期待する挙動

やること	期待
起動中のプロジェクトでコマンドを打つ	コンテナに一切触らず、dev コンテナへ接続した窓を開く
停止中のプロジェクトで打つ	up を実行して起動し、そのまま窓を開く（devbase up と同じ結果になる）
devbase list の TUI	起動中メニューの先頭（再起動 / 停止 / ログインの上）から同じ操作を選べる

直し方の案

コマンドの新設

devbase open（案。editor / code も候補）を project / container グループとトップレベルのショートカットに足す。

足す場所	内容
lib/devbase/cli.py:137 _add_open_args	--open-index N は既存の定義をそのまま流用できる。--open / --no-open は明示コマンドでは意味を持たないため、open 用には index だけを取る別の登録にする
lib/devbase/cli.py:35 SHORTCUTS	'open': 'open' を足す
lib/devbase/cli.py SUBCMD_MAP / _add_project_parser / _add_container_parser	open を登録する
lib/devbase/commands/container.py:704 の handlers 表	'open': lambda: cmd_open(...) を足す
bin/devbase:407-408	_PROJECT_NAME_SUBCOMMANDS / _NAME_RESOLVABLE_SHORTCUTS へ open を足す（cli.py 側と対で更新する注記がある）

cmd_open 自体は薄くできる。cmd_up の冒頭と同じく project_runtime.current_project_config() で project.yml を読み、_resolve_docker_target(context) で接続先を決め、_maybe_open_editor へ渡す。コンテナが解決できなければ cmd_up を呼び、その [6/6] に窓を開かせる（自前で開き直さない）。

TUI のメニュー

lib/devbase/tui/actions_project.py の 3 か所。

場所	変更
:32 _RUNNING_OPS	("editor 起動 (open)", "open") を先頭に置く
:170 _OP_HANDLERS	"open": lambda root, name: dispatch_lifecycle("open", name, open_index=None)
:44 _BACK_TO_TOP_OPS	足さない。 コンテナの数が変わらないため、実行後はサブメニューに留まる（login / ps と同じ扱い）

決めること

論点	案
既定のハイライトが変わる	_RUNNING_OPS の先頭は Enter 連打で届く位置で、現在は「再起動 (up)」が占めている（:31 のコメントが理由を書いている）。先頭を open にすると、Enter 連打の到達先が再起動から窓を開く操作へ変わる。依頼どおり先頭に置くが、:31 のコメントもあわせて書き替える
DEVBASE_OPEN_EDITOR=0 の端末での扱い	開く。 明示のコマンド・明示のメニュー選択は意思表示であり、up のときの自動オープンの可否とは別に扱う（opener.is_open_enabled を見ない）
index の上限	project.yml の scale ではなく動いているコンテナの数から決める。devbase scale でオンライン変更されていると project.yml の値とずれる。opener.resolve_container_name が docker compose ps を引くため、そこで解決できない index はエラーにする
停止中のときの動き	up を実行する。 コンテナ名が解決できないことをもって「起動していない」と判定し、cmd_up へ委譲して起動から窓を開くところまで通す。窓を出したいという意思表示に対して、起動しているかどうかを利用者が先に確かめなくてよい

検査

• tests/cli/tui/test_profile_menu.py にならい、_RUNNING_OPS の先頭が open であること・_BACK_TO_TOP_OPS に含まれないことを見る
• tests/editor/test_opener.py にならい、cmd_open がコンテナ操作（compose up / ボリューム作成 / フック）を 1 つも呼ばずに open_editor だけを呼ぶことを見る
• 停止中のプロジェクトでは cmd_up へ委譲されることを見る（起動中は cmd_up を呼ばないことと対で見る）

併せて直すか決めること

devbase up の --open / --no-open / --open-index は残す。open の新設は up の自動オープンを置き換えるものではない（起動と同時に開く経路は今までどおり要る）。

由来

devbase up で開いた窓を手で閉じたあと、開き直す手段を探して踏んだ。

振り返り: #197 (comment)

[takemi-ohama]

振り返り（2026-09-18）

対象: issue #197 / 設計 PR #198 / 実装 PR #199

閉じた VS Code の窓を、コンテナを再起動せずに開き直す devbase open [name]（project open / container open）を足し、devbase list の起動中の操作メニューの先頭に置いた。standard として、要求と受け入れ条件 → 設計 PR（#198）→ 実装計画 → テスト駆動 → cross-refactoring → cross-review → 完了判定 → 確定仕様化（docs/specifications/editor-open.md）→ マージ（= 配布）→ リリース後の確認の順に通した。

何が起きたか

観点	事実
受け入れ条件	設計の段階で 2 件足した（19: skip を終了コード 1 にする、20: 状態を取得できないときは up へ進まない）。issue の案「コンテナ名が解決できない → 停止中」は、scale 1 で --open-index 2 を渡すと up が走るため、「動いているインスタンスが 0 個」と「その番号が無い」を分けた
手戻り（設計）	#198 は 2 ラウンド。round 1 で agy が「既存の _running_dev_containers（env token）と同じ責務」、kiro が「container open の [name] と引数登録の共有が矛盾」を指摘し、既存関数を共有へ移す設計（決定 8）に直した
手戻り（実装）	#199 の cross-review は 3 ラウンド。round 2 で codex が major 1 件: argparse の前方一致で open --open 2 が --open-index 2 として通り、受け入れ条件 11 に反していた。値を付けない --open しかテストしていなかったため通っていた。allow_abbrev=False と値付きの回帰テストで直した
構造改善	cross-refactoring はテスト整備 4 件（1 コミット）、構造改善の採用は 0 件。minor の重複（DEVBASE_OPEN_INDEX の読み方）は閾値で見送られたが、差分の内側なので進行側で解消した（fabb77d）
見落とし	リリース後の確認で、open で開いた窓が up のときと違うプロファイルになる場合がある、と利用者が報告した（#201）。devbase は --profile を渡さず、どちらも同じ code --folder-uri を実行する。VS Code 側の選び方と、実行した端末の違いが絡む経路で、非 TTY の手元の検証では踏めなかった
工程	すべての工程を通った。round 1 だけで収束すると codex が見ないため、設計・実装とも final を戻して codex を含むラウンドを回し、実装ではそこで major が出た
道具	agy はレビューで 480 秒止まり、停滞の上限を 1100 秒へ延ばして起動し直した。cross-refactoring の提案で、codex が結果を提出先に書けず NO_RESULT になった（手で取り込んだ）

次に変えること

変えること	落とし先	状態
提案担当が提出先へ結果を書けるようにする（作業ディレクトリの外という指示との衝突を解く）	cross-refactoring の手順	devbasex/ai-plugins#750 として起票
エディタを開く経路を変える設計では、VS Code 側が決める状態（プロファイル・つながる窓）を「未確認のまま残ること」に挙げ、TTY での確認をマージ前の手動確認に入れる	次の変更で試すこと	#201 で扱う
CLI の「受け付けない」条件のテストに、値付きと前方一致の形（--opt VAL / --opt=VAL）を含める	変えない	argparse に固有の穴で、#199 で回帰テストを足して閉じた。Skill へ一般化するほどの頻度は、まだ観測していない

途中で起票した課題

番号	何を見つけたか	見つけた場面
#200	container / ct のサブコマンドが bin/devbase の名前解決を通って [name] を受け付ける（open に限らない既存の動き）	実装レビュー（codex、round 3）
#201	devbase open の窓が up のときと違うプロファイルになる場合がある	リリース後の確認（利用者）
devbasex/ai-plugins#750	cross-refactoring の提案担当が結果ファイルを提出先に書けない	構造改善