スプリント m8d

[takemi-ohama]

スプリント m8d の課題を main へ取り込む。

利用者向けの変化

• VS Code Server の本体は全コンテナ共通の 1 本のボリュームに置かれ、各コンテナで共有されます。（#463 を実装する（スプリント m8d） #485）
• コンテナを起動すると VS Code Server の bin が用意され、古い版は片付けられます。（#463 を実装する（スプリント m8d） #485）
• 起動の後の処理で VS Code Server の bin の所有者が揃えられます。（#463 を実装する（スプリント m8d） #485）
• 旧形式の VS Code Server ボリュームが残っていると、devbase up がそのことを案内します。（#463 を実装する（スプリント m8d） #485）
• devbase env のシェル補完（bash・zsh）で、サブコマンドの候補に token と backend が出る（#454 を実装する（スプリント m8d） #486）
• 起動の待ちが時間切れになると、それまでに待った巡の回数と実際に経過した秒数が文言に出ます。（#374 を実装する（スプリント m8d） #487）

移行の手順

• devbase: 移す操作はありません。旧形式の VS Code Server ボリュームの中身は共通のボリュームへ写しません。（#463 を実装する（スプリント m8d） #485）
• devbase: この版より前の版へ戻すと、消していない旧形式の VS Code Server ボリュームが前と同じように付きます。共通の VS Code Server ボリュームは残りますが、害はありません。（#463 を実装する（スプリント m8d） #485）

課題と設計

• 課題: VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463 env の補完のサブコマンドの一覧に token と backend が無い #454 起動の待ちの制限時間（60 秒）が実際の時間ではなく巡の回数で数えられている #374
• 無し
• 設計: VS Code Server: コンテナごとのボリュームが本体を重ねて持ち、更新のたびに旧版が溜まる → 本体（bin/）だけを全コンテナで 1 本のボリュームに置いて版の数に上限を置き、拡張と状態はコンテナの書き込みレイヤーに残す（#463） #484

コミット

• feat(VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463): VS Code Server の本体を全コンテナ共通の 1 本のボリュームに置く
• feat(VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463): コンテナの起動で VS Code Server の bin を用意し旧版を片付ける
• feat(VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463): 起動の後の処理で bin の所有者を揃え、up で旧形式のボリュームを案内する
• docs(VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463): VS Code Server の本体だけを共有する構成と移り方を書く
• docs(VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463): 起動の後の処理の順と VS Code Server の困りごとの節を今の振る舞いに合わせる
• Merge pull request #463 を実装する（スプリント m8d） #485 from devbasex/feat/issue-463-m8d
• feat(env の補完のサブコマンドの一覧に token と backend が無い #454): env の補完のサブコマンドの一覧に token と backend を足し、一致テストで比べる
• docs(env の補完のサブコマンドの一覧に token と backend が無い #454): 一致テストが env のサブコマンドの一覧を比べることを確定仕様と CHANGELOG に書く
• Merge pull request #454 を実装する（スプリント m8d） #486 from devbasex/feat/issue-454-m8d
• fix(起動の待ちの制限時間（60 秒）が実際の時間ではなく巡の回数で数えられている #374): 起動の待ちの時間切れの文言に巡の回数と実際の経過の秒数を出す
• docs(起動の待ちの制限時間（60 秒）が実際の時間ではなく巡の回数で数えられている #374): 時間切れの新しい文言を確定仕様と CHANGELOG に書く
• Merge pull request #374 を実装する（スプリント m8d） #487 from devbasex/feat/issue-374-m8d

変更の統計

 lib/devbase/commands/container.py                 |  59 +++++-
 lib/devbase/editor/vscode_server.py               |  72 +++++++
 lib/devbase/utils/docker.py                       |  17 +-
 lib/devbase/volume/compose.py                     |  59 +++---
 lib/devbase/volume/manager.py                     | 110 +++++-----
 tests/cli/test_name_context_consistency.py        |  14 +-
 tests/commands/test_container_context.py          |   3 +
 tests/commands/test_container_post_start.py       | 100 +++++++++
 tests/commands/test_container_scale_order.py      |   8 +-
 tests/containers/test_entrypoint_vscode_server.py | 246 +++++++++++++++++++++-
 tests/editor/test_vscode_server.py                | 117 ++++++++++
 tests/utils/test_wait_for_containers.py           |  43 +++-
 tests/volume/test_compose_vscode.py               | 121 +++++++----
 tests/volume/test_manager_vscode.py               | 180 +++++++++-------
 23 files changed, 1133 insertions(+), 303 deletions(-)

テスト（supervise.py の run のステップ）

ステップ	exit	最後の行
collect	0

集めた実装の PR

• #463 を実装する（スプリント m8d） #485: 変化あり
• #454 を実装する（スプリント m8d） #486: 変化あり
• #374 を実装する（スプリント m8d） #487: 変化あり

閉じる課題

Closes #374
Closes #454
Closes #463

手動確認

• VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463 マージ前: M1。新しい devbase で devbase up が要るため、conductor が P3 の承認を取ってから打つか、利用者が行う。担当は打たない（2026-10-14 conductor が P3 の承認を取って novel・bi-tools で実施、利用者が attach。合格。記録は PR のコメント）
• VS Code Server（~/.vscode-server）をコンテナごとのボリュームに重ねて持ち、更新のたびに旧版が溜まる #463 リリース後テストへ回す: M4・M5。リリース後テストで確かめる

モード: standard / 通した工程: 実装 → Pull Request

conductor の補記

• #463 を実装する（スプリント m8d） #485 の本文の「残した事項」にある docs/user/troubleshooting.md の行は古い。後のステップで、旧形式の VS Code Server ボリュームの消し方の節に直っている（このスプリント PR の差分に入っている）

🤖 Generated with Claude Code

[takemi-ohama]

改修計画 — devbasex/devbase #488

/ndf:cross-refactoring が提案し、改修計画し、適用した改善項目の記録である。
理由と手順は提案の時点でしか残らないため、公開の直前に書き出している。

• 件数: 採用 4・未確認 0・取り消し 1・見送り 1（最終ゲート: passed）
• 公開: ef4a39f を push した
• 書き直した時刻: 2026-10-14T10:36:10
• 対象範囲: CHANGELOG.md, containers/base/entrypoint.sh, docs/specifications/cli-argument-resolution.md, docs/specifications/compose-profiles.md, docs/specifications/post-start.md, docs/user/container-operations.md, docs/user/troubleshooting.md, etc/_devbase, etc/devbase-completion.bash, lib/devbase/commands/container.py, lib/devbase/editor/vscode_server.py, lib/devbase/utils/docker.py, lib/devbase/volume/compose.py, lib/devbase/volume/manager.py, tests
• テストの戦略: local-full（根拠 test.strategy）
• 範囲テストの雛形: env -u DEVBASE_ROOT uv run --locked pytest -q -o junit_family=xunit1 --junitxml=build/ndf/junit.xml {paths}
• 着手前のテスト: env -u DEVBASE_ROOT uv run --locked pytest tests/ -q -o junit_family=xunit1 --junitxml=build/ndf/junit.xml（whole）
• 着手前のテストの結果: 通過（132.4 秒 / HEAD 789fa5a）
• 既存失敗の件数: 0
• 想定最大時間: 30 分 / 改修計画の時点で使えた時間: 9.31 分
• 実装担当: claude

改善項目

I-001 — lib/devbase/volume/manager.py#VolumeManager.ensure_volumes

兆候	手法	重要度	等級	提案元	状態	コミット
duplication	extract_method	major	high	claude / codex / kiro	採用	2

なぜ: 共有ホーム・グループ・VS Code Server・各 work ボリュームで、存在確認→ログ→作成→失敗時 DockerError が4回繰り返される。同じ作成契約の変更を4か所へ反映する必要がある。tests/volume/test_manager_vscode.py は作成・既存・作成失敗、test_manager_group.py は不正グループで Docker に触れないことを保護するが、全種類の失敗とログの同値性は補う必要がある。

手順: 1. VolumeManager に _ensure_volume(name, label=None) を抽出する。label があれば既存の文言 " %s (, exists)" / " Creating %s ()..."、無ければ作業ボリュームの文言 " %s (exists)" / " Creating %s..." をそのまま出す（ログの文言を 1 文字も変えない）
2. 失敗時は従来どおり DockerError(f"Failed to create volume {name}") を送出する
3. ensure_volumes の 4 つの塊を _ensure_volume(HOME_UBUNTU_VOLUME, 'shared home')・_ensure_volume(group_volume, 'account group')・_ensure_volume(VSCODE_SERVER_VOLUME, 'VS Code Server')・ループ内の _ensure_volume(work_volume) に置き換える。呼ぶ順（グループ名の検証 → home → group → vscode → work）は変えない
4. tests/volume/test_manager_vscode.py と tests/volume/test_manager_group.py を走らせる

I-002 — lib/devbase/utils/docker.py#wait_for_containers_ready

兆候	手法	重要度	等級	提案元	状態	コミット
long_method	extract_method	major	medium	codex / kiro / claude	採用	1

なぜ: 1 関数にログ出力・巡ループ制御・1 インスタンスの状態分類 (not_found / exited / ready / pending) ・時間切れの集計が同居し、認知的複雑度 19・分岐 8・71 行。1 インスタンスの判定ロジックが while ループ本体に埋まり単体で読めない。

手順: 1. 1 インスタンス分の分類を _classify_instance(index, container_prefix, ready_file, compose_file) -> ('ready'|'exited'|'not_found'|'pending', Optional[StartupFailure]) として抽出
2. while ループ内の for を、_classify_instance の戻りで ready / failures / still_pending へ振り分けるだけにする
3. 時間切れの StartupFailure 生成はそのまま残す
4. tests/utils/test_wait_for_containers.py を実行し、各経路 (ready / exited / not_found / timeout) が不変であることを確認

I-003 — lib/devbase/volume/manager.py#VolumeManager.__init__

兆候	手法	重要度	等級	提案元	状態	コミット
dead_code	remove_dead_code	minor	medium	claude	取り消し	0

なぜ: #463 で VS Code Server のボリュームが共通の 1 本になり、self.project_name と ensure_volumes(project_name) はどこからも読まれなくなった。docstring も「使わない」と書いて残しており、読む人に名前がボリュームに効くと誤解させる

手順: 1. VolumeManager.init の project_name 引数と self.project_name を消す
2. モジュール関数 ensure_volumes の project_name 引数を消し、VolumeManager() で作る
3. commands/container.py の ensure_volumes(scale, project_name)・ensure_volumes(new_scale, project_name) を ensure_volumes(scale) へ直す
4. tests/volume/test_manager_vscode.py の ensure_volumes(..., project_name=...) と、tests/commands/test_container_scale_order.py の「project_name が ensure_volumes に渡る」現状固定テストを、渡らなくなった形へ直す（test-changes.md に従い、変えた理由をテストに残す）
5. 全体の pytest を走らせる

取り消した理由: テストの期待する振る舞いが変わっています（tests/commands/test_container_scale_order.py, tests/volume/test_manager_ensure_volumes.py, tests/volume/test_manager_vscode.py）。構造改善では期待出力を変えません。振る舞いの変更は別の変更に分けてください

I-004 — lib/devbase/editor/vscode_server.py#bin_fix_script

兆候	手法	重要度	等級	提案元	状態	コミット
scattered_config	centralize_configuration	minor	medium	claude	採用	1

なぜ: VS Code Server の置き場のパスが、vscode_server.py の HOME_ROOT + "/.vscode-server"・"/.vscode-server/bin" と、volume/compose.py の VSCODE_SERVER_TARGET・VSCODE_BIN_TARGET の 2 か所で別々に組まれている。マウント先と所有者を直す先が食い違うと attach が失敗する

手順: 1. VSCODE_SERVER_TARGET と VSCODE_BIN_TARGET を、VSCODE_SERVER_VOLUME と同じ volume/manager.py へ移す（compose.py は manager から import して従来の名前で参照できるようにする）
2. bin_fix_script の既定を manager の 2 つの定数から組む形にし、home_root を渡すテスト用の経路は残す
3. tests/editor/test_vscode_server.py と tests/volume/test_compose_vscode.py を走らせる

I-005 — lib/devbase/commands/container.py#_prepare_vscode_server_bin

兆候	手法	重要度	等級	提案元	状態	コミット
duplication	extract_method	minor	medium	claude	採用	1

なぜ: #463 で足した _prepare_vscode_server_bin は _apply_window_titles と同じ形（_target_indices を回し、opener.resolve_container_name で名前を引き、1 台ずつ try して失敗を debug に落とす）を写している。起動の後の処理にインスタンスごとの付随処理を足すたびに同じループが増える

手順: 1. _for_each_dev_container(project_name, scale, dev_service_name, compose_file, indices, action, what) を抽出する。各番号で名前を引いて action(container_name) を呼び、例外は logger.debug("%s をスキップしました (index=%d): %s", what, index, e) の形で従来の文言を保って落とす
2. _apply_window_titles のループ部をこの関数の呼び出しに置き換える（template の解決と早期 return は呼び出し側に残す）
3. _prepare_vscode_server_bin を同じ呼び出しに置き換える
4. 両関数の debug の文言が変わらないことを確かめ、tests/commands/test_container_post_start.py と window title のテストを走らせる

I-006 — containers/base/entrypoint.sh#devbase_prune_vscode_server_bin

兆候	手法	重要度	等級	提案元	状態	コミット
long_method	extract_method	minor	low	claude / codex	見送り	0

なぜ: 完成版の収集・保持数による削除・保持版にある入れ子の掃除・古い展開途中ディレクトリの掃除という異なる選別規則が1関数に同居する。tests/containers/test_entrypoint_vscode_server.py に同時実行、同時刻の順序、入れ子、古い展開途中、削除不能の振る舞いのテストがある。

手順: 1. 版を数えて古い版を消し、残した版の名前を出す段を devbase_prune_vscode_server_versions として抽出する（kept は標準出力の行で返すか、呼び出し側の配列へ読む）
2. 入れ子の本体を消す段を devbase_prune_vscode_server_nested として抽出する
3. 展開の途中のディレクトリを消す段を devbase_prune_vscode_server_stale として抽出する
4. devbase_prune_vscode_server_bin は 3 つを順に呼ぶだけにし、終了コード 0 を保つ
5. tests/containers/test_entrypoint_vscode_server.py（同時実行の試験を含む）と ShellCheck を走らせる。イメージに入るファイルのため、実機の確認は base の建て直しが要る（AGENTS.md の落とし穴）

取り消した理由: 実装の終わりまでにコミットが無く、残った時間に入らない

指標の測定

• 状態: written / 言語とツールの対応: 既定（.ndf/code-metrics.json は無い） / 所要: 9.3 秒（使えた時間 90 秒 / 上限 90 秒）
• 指標のファイル: /var/folders/qz/qxt0p_y15xv5jg4x77zmtxj80000gp/T/ndf-worktrees/devbasex--devbase/rf488/work/.cross_refactoring/code-metrics-rf488.md

言語	ツール	版	ランナー	ファイル	秒	結果
python	ruff-complexipy	ruff 0.16.9 / complexipy 8.0.1	uvx	214	1.1	測った
shell	—	—	—	2	—	unsupported_language
重複: python	symilar	pylint 4.0.9	uvx	214	6.9	測った（3 箇所）
重複: shell	jscpd	jscpd 4.3.0	npx	2	0.9	測った（0 箇所）

時間の上限

値	中身
提案の枠の終わり（監視の上限 = 残り + 余裕）	2026-10-14T10:26:56+09:00
改修計画の枠の終わり（同上）	2026-10-14T10:29:56+09:00
テストの追加の終わり = 実装の終わり − Σ（採っていて未検証の項目の実装の見積り）	2026-10-14T10:27:21+09:00
実装の終わり = 最終ゲートの修正の打ち切り − バッファ − Σ（採っていて未検証の項目の検証の見積り）	2026-10-14T10:32:13+09:00
直しの試行の打ち切り	2026-10-14T10:41:01+09:00
想定最大時間の終わり H（子プロセスはすべてここまでに止まる）	2026-10-14T10:48:44+09:00
確かめの開始の締め切り = H − 確かめの見込み（最終ゲート修正と打ち切りの後の取り消しもここまで）	2026-10-14T10:46:31+09:00
確かめの見込み（秒。最終ゲートの確かめ 1 回。バッファの最終ゲートの全体テスト）	133
最終ゲート修正 1 回の見込み（秒。バッファの final_fix。起動は今 + この値が確かめの開始の締め切り以前のときだけ）	330
指標の測定の上限（秒。提案の枠の中から割く）	90
着手前のテスト 1 回の上限（秒）	420
範囲テスト 1 回の上限（秒）	398
手元の全体テスト 1 回の上限（秒）	420
CI の待ちの上限（秒）	324
余裕（秒。手順の上限と CLI の上限に足す）	90

入力: 予算 30 分 / 全体テストの所要 w 139.8（ndf-record） / 着手前の実測 x 132.4 / CI の壁時計 c 108.0 / 範囲テストの所要 s None（—） / 戦略 local-full

無音の打ち切りは手順の監視の上限と同じ値である。項目ごとの期限は持たない（実装を止めるのは実装の終わりだけ）。

見送った提案

対象	兆候	理由	根拠（MVV）	補足
lib/devbase/utils/docker.py#wait_for_containers_ready	deep_nesting	duplicate	Vision	C-002 と同じ変更
tests/volume/test_compose_dev_environment.py#project	duplication	budget	Vision / Value 3	見積り 1.1 分が残りに入らない
lib/devbase/editor/vscode_server.py#prepare_bin_dir	duplication	budget	Vision	見積り 1.1 分が残りに入らない
lib/devbase/volume/manager.py#_LEGACY_VSCODE_VOLUME_RE	duplication	budget	Value 2 / Vision	見積り 1.1 分が残りに入らない
lib/devbase/volume/manager.py#get_volume_for_index	duplication	budget	Value 2	見積り 1.1 分が残りに入らない
lib/devbase/commands/container.py#_run_post_start	data_clump	budget	Value 3 / Vision	見積り 1.4 分が残りに入らない
containers/base/entrypoint.sh#devbase_remove_vscode_server_path	duplication	budget	Value 1 / Vision	見積り 1.6 分が残りに入らない
lib/devbase/commands/container.py#_load_project_env	long_method	budget	Value 3 / Value 2	見積り 1.6 分が残りに入らない
lib/devbase/commands/container.py#cmd_down	swallowed_exception	budget	Value 2	見積り 1.6 分が残りに入らない
lib/devbase/volume/compose.py#_rewrite_depends_on	long_method	budget	Value 2	見積り 1.6 分が残りに入らない
tests/containers/test_base_image_font_matching.py#_docker_unavailable	duplication	budget	Vision	見積り 1.8 分が残りに入らない
tests/cli/zsh_completion_harness.py#run_completions	long_method	budget	Vision	見積り 2.4 分が残りに入らない
containers/base/entrypoint.sh#devbase_prune_vscode_server_bin	long_method	not_done	Vision / Value 1 / Value 2	実装の終わりまでにコミットが無く、残った時間に入らない

[takemi-ohama]

🤖 cross-review | round 1 | codex | REQUEST_CHANGES

利用者データの削除に関わる修正提案が2件あります。

[takemi-ohama]

🤖 cross-review | round 1 | kiro | APPROVE

振る舞いを変えない構造改善の PR。4 件の抽出・集約はログ文言・例外の扱い・公開シグネチャをすべて保ったまま重複を除いている。vscode_server.py がモジュール先頭で volume.manager を import する点は循環 import の懸念があったが、manager は env.keys / errors / log しか import せず editor を参照しないため循環は無い（import 成功を確認）。VSCODE_SERVER_TARGET・VSCODE_BIN_TARGET の参照元（compose.py 内の 3 箇所）も解決し、削除した HOME_ROOT への残参照も無い。critical / major の基準に当たる指摘は無い。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 1 | commit f042cc4

対応件数: critical=0 / major=2 / minor=0（合計 2 件）
決着: 2 件 / 見送り: 0 件 / 却下: 0 件
CI: SUCCESS

[takemi-ohama]

🤖 cross-review | round 2 | claude | APPROVE

round 1 の 2 件（片付けがリンクを辿る・旧ボリューム削除で失うものの案内）は f042cc4 で直っている。entrypoint の片付け（set -e 下の分岐・空の一致・リンクの除外）、bin の所有者の直し、旧形式の案内の位置と名前の形、確定仕様（post-start.md・compose-profiles.md）の順序、refactor 4 件の振る舞いの同値性を確かめ、critical / major の基準に当たる指摘は無い。

[takemi-ohama]

🤖 cross-review | round 2 | kiro | APPROVE

振る舞いを変えない構造改善 4 件（I-001 _ensure_volume / I-002 classify_instance / I-004 VSCODE*_TARGET の集約 / I-005 _for_each_dev_container）と、round 1 の major 2 件の修正を確認した。4 件の抽出・集約はログ文言（manager の作成/存在のメッセージ、container の debug スキップ文言）・例外（DockerError）・公開シグネチャ（ensure_volumes の project_name も含む。I-003 は取り消し）をすべて保ったまま重複・長さを除いている。VSCODE_SERVER_TARGET / VSCODE_BIN_TARGET を manager へ移したことで vscode_server.py がモジュール先頭で volume.manager を import するが、manager は env.keys / errors / log だけを import し editor を参照しないため循環 import は無い。round 1 の 2 件（entrypoint の bin 片付けがシンボリックリンクを辿って bin 外の product.json を削除し得る点、container-operations.md の削除案内が ~/.vscode-server 全体の消失を伝えていなかった点）は f042cc4 で修正され、entrypoint は bin 自身・bin/・入れ子のいずれかがリンクなら版に数えず入れ子掃除もしない形になり、CLI の _report_legacy_vscode_volumes の案内も文書の退避手順と一致する。新規テスト（test_manager_ensure_volumes.py の順序・文言・例外の固定、test_entrypoint_vscode_server.py の 2 つのリンク試験）は観測可能な振る舞いを検証している。critical / major の基準に当たる指摘は無い。

[takemi-ohama]

🔧 /ndf:fix サマリ | commit (なし)

対応件数: critical=0 / major=0 / minor=0（合計 0 件）
決着: 0 件 / 見送り: 0 件 / 却下: 0 件
CI: NONE

[takemi-ohama]

手動確認 M1（#463）の結果（2026-10-14）

利用者が P3 を承認し、conductor がメインディレクトリを一時的に origin/sprint/m8d（f042cc4）へ切り替えて実施した。イメージは建て直していない（#463 より前の entrypoint を持つ devbase-base 系のまま）。終わった後に main へ戻した。

確かめたこと	結果
devbase up novel・devbase up bi-tools	2 つとも共通の devbase_vscode-server-bin が ~/.vscode-server/bin に付いた。古いイメージでも bin は ubuntu:ubuntu（起動の後の処理が揃えた）
2 つのコンテナへ VS Code を attach（利用者）	両方の窓が使えた。窓のタイトルはそれぞれ novel-dev-1・bi-tools-dev-1 で始まる（data/Machine/settings.json もコンテナごと）
片方の窓の再読み込み（利用者）	同じコンテナへ繋がり直した
2 つ目の attach が本体を取り直さないか	bin/ は 1 版（2a59476c…）だけ
devbase up novel で作り直した後の attach（利用者）	すぐ使えた。bin/ は残り、extensions/ は消えて既定の拡張（日本語の言語パック）が入り直った
旧形式の案内	devbase up の最後に旧形式 18 本の名前と docker volume rm の行が出た。devbase は消していない

[takemi-ohama]

リリース後テスト

対象の版: main 04f7228（#488 を 2026-10-14 マージ、#489 の確定仕様化を同日マージ。タグは切らない。devbase --version は 4.1.0 のまま）
導入経路: 利用者の devbase（bin/devbase → このリポジトリの main）を origin/main と同じ 04f7228 にした。base・派生イメージ（devbase-base proj-a proj-b、作成 2026-10-14 03:19〜03:22 UTC）の /entrypoint.sh は main の containers/base/entrypoint.sh と md5 が一致（5d297a96…）。建て直しは要らなかった
対象: 本番（main）。追記 05:00: 条件 10 の古いイメージの側を足した。M1 で確かめた f042cc4 と 04f7228 は lib・containers・etc・bin に差が無い（git diff --stat が空）

実のイメージでの確かめは、使い捨てのボリューム rv-m8d-vscbin を ~/.vscode-server/bin に付け、proj-a のイメージを docker run（entrypoint はそのまま、devbase up は打たない）で起動した。本体は共通のボリュームから読み取り専用で 1 版（1.141.0）を写し、版 A（2a59476c…）・版 B（同じ中身を別の commit 名、product.json を 2 日前）とした。終わった後にボリュームは消した。利用者のボリュームには書いていない。

課題	受け入れ条件	実行したこと	実行時刻（UTC）	結果
—	導入の確認	git rev-parse HEAD origin/main・イメージの /entrypoint.sh の md5	2026-10-14 04:57	合格（どちらも 04f7228、md5 一致）
#463	1. 共通の VS Code Server ボリュームは 1 本で、違うプロジェクトでも同じ	M1（コメント 6160308278）＋ docker inspect で 2 プロジェクトのコンテナの ~/.vscode-server/bin の付け先を見た	04:57	合格（どちらも devbase_vscode-server-bin）
#463	2. dev インスタンスは bin に共通のボリュームを付け、~/.vscode-server・data には付けない	M1 ＋ pytest tests/volume/test_compose_vscode.py（main）	04:57	合格
#463	3. 共通の名前が旧形式と重ならない	pytest tests/volume/test_manager_vscode.py（main）	04:57	合格
#463	4. A が置いた bin/<commit> で B の code-server --version が通る	実のイメージで版 A・B を置いたボリュームから起動し、両方の bin/code-server --version を打った	04:56	合格（両方 1.141.0）。M1 で 2 プロジェクトが 1 版を共有したことも確かめ済み
#463	5. プロジェクトが自分で付けていれば足さない	pytest tests/volume/test_compose_vscode.py（main）	04:57	合格
#463	6. 生成した compose に旧形式が現れない	M1 ＋ 同上	04:57	合格
#463	7. 残す数より多い版は新しい順に 5 版だけ残る	実のイメージで 7 版（実物 2・product.json だけの 5、名前は 40 桁）にし、2 つのコンテナを同時に起動した	04:57	合格（新しい 5 版が残り、古い 2 版が消えた。実物の 2 版は残った）
#463	8. 入れ子の本体が消え、bin/<commit>/bin/code-server は残る	実のイメージで bin/<A>/vscode-server-linux-arm64/（product.json を持つ実物の写し）を置いて起動した	04:56	合格（入れ子 0、code-server は残り --version が通る）
#463	9. 消せないものがあっても起動は止まらず WARNING に出す	用意の誤りで中身を root 所有にした状態で起動した（開発ユーザーで消せない）	04:56	合格（WARNING: VS Code Server の片付けで消せなかった: …/vscode-server-linux-arm64 (rm: … Permission denied) の 1 行が出て、片付けの後の処理へ進んだ。止まったのは別の理由＝DEVBASE_ACCOUNT_GROUP を渡していなかったため）
#463	10. 空の（root 所有の）ボリュームでも ~/.vscode-server と bin を開発ユーザーが書ける。古い entrypoint のイメージでも起動の後の処理の後には bin を書ける	新しいイメージ: 根を root:root にしたボリュームで起動した。古いイメージ: #463 より前の entrypoint の派生イメージ（proj-c、/entrypoint.sh に片付けが無い）を使い捨てのボリュームで起動し、main の prepare_bin_dir を実の docker に 2 回打った	04:56・05:00	合格（新: ~/.vscode-server・bin とも ubuntu:ubuntu。古: 起動直後は bin が root:root で書けず、prepare_bin_dir の後は ubuntu:ubuntu で mkdir が通った。2 回目も True。M1 の記録は「イメージは建て直していない」とあるが、proj-a・proj-b のイメージは M1 のコンテナ作成の直前（03:19〜03:22）に建て直されており、M1 は新しい entrypoint で走っていた。古いイメージの側はこの行で初めて実の docker で確かめた）
#463	11. 旧形式があれば名前と消すコマンドを案内し、消さない・付けない・読まない	M1 ＋ docker volume ls（旧形式 18 本が残っている）＋ pytest tests/commands/test_container_post_start.py の該当（スプリント PR で通過）	04:57	合格
#463	12. 旧形式が無ければ案内は出ない	pytest（main。一覧が空・失敗の場合）	04:57	合格
#463	13. スナップショットの対象は変わらない	pytest tests/volume/test_manager_vscode.py（main）	04:57	合格
#463	14. container-operations.md の記述	main の文書（#488・#489 で確かめ済み）	04:57	合格
#463	15. CHANGELOG.md の [Unreleased]	main の CHANGELOG.md	04:57	合格
#463	4.・8. の実機（M4・M5）: 片方の端末の VS Code だけを更新した版の違う 2 窓が同じ bin/ を使え、片付けがどちらも消さない。更新の後に複数窓を一度に開き直しても入れ子が残らない	—	—	保留（理由: 実の VS Code の更新が要る。現在の版 1.141.0 から上がるのは利用者の端末の更新次第。片付けの振る舞いは上の 4・7・8 で実のイメージで確かめた。次に VS Code が更新されたとき、利用者が窓を開き直した後に ls ~/.vscode-server/bin ~/.vscode-server/bin/*/ で 2 版と入れ子 0 を見る）
#454	1. bash の devbase env <TAB> に token・backend が出て、既存は残る	main の etc/devbase-completion.bash を source し _devbase_completions を呼んだ	04:58	合格（18 個。変更前の 16 個はすべて残る。本文の「既存の 17 個」は数え違いで、変更前の一覧は 16 個）
#454	2. zsh の env_subcommands に説明付きで入る	zsh -n etc/_devbase・grep	04:57	合格（exit 0、130 行・135 行）
#454	3. 一致テストが env の一覧も比べる	pytest tests/cli/test_name_context_consistency.py（main）	04:57	合格（落ちることは #486 で確かめ済み）
#454	4. devbase env token -<TAB> で --context が出る	同じく _devbase_completions	04:58	合格（--context）
#454	5. cli-argument-resolution.md	main の文書	04:57	合格
#454	6. CHANGELOG.md	main の CHANGELOG.md	04:57	合格
#374	1. 文言が巡の回数と実際の経過秒を出す	pytest tests/utils/test_wait_for_containers.py（main）・lib/devbase/utils/docker.py:184	04:57	合格（timeout after <n> rounds (<s>s elapsed) …）
#374	2. 数え方と打ち切りを変えない	同上（test_rounds_do_not_exceed_the_limit）	04:57	合格
#374	3. 単調な時計・整数の秒	同上	04:57	合格
#374	4. ほかの文言・例外・引数を変えない	同上	04:57	合格
#374	5. post-start.md	main の文書（123 行）	04:57	合格
#374	6. CHANGELOG.md	main の CHANGELOG.md	04:57	合格

pytest（main 04f7228）: env -u DEVBASE_ROOT uv run --locked pytest -q tests/cli/test_name_context_consistency.py tests/utils/test_wait_for_containers.py tests/containers/test_entrypoint_vscode_server.py tests/volume/test_manager_vscode.py tests/volume/test_compose_vscode.py → 65 passed（exit 0、04:57）

合否: 合格（受け入れ条件 27 件すべて合格。実の VS Code の更新を要る M4・M5 の実機の 1 行は保留）
起票したもの: なし

[takemi-ohama]

構造改善で取り消し・見送った 2 件（コメント 6158923037）は範囲外と判断し、#490 として残した。

[takemi-ohama]

振り返り（2026-10-15）

対象: issue #463・#454・#374 / PR #488（設計 #484、実装 #485 #486 #487、確定仕様 #489）

スプリント m8d（マイルストーン 04、mode standard）。#463 で VS Code Server の本体（~/.vscode-server/bin）を全コンテナ共通の 1 本のボリュームにし、起動のたびに旧版・入れ子の本体・展開の途中を片付けるようにした。extensions/・data/ はコンテナの書き込みレイヤーに残す。#454 で devbase env の補完に token・backend を足し、一致テストで env の一覧も比べるようにした。#374 で起動の待ちの時間切れの文言を巡の回数と実際の経過秒にした。

何が起きたか

観点	事実
受け入れ条件	#463 は承認ゲート 1 で利用者が設計を変えた（data/・extensions/ を共有せず bin/ だけ）。条件 2・3・4・5・10・14・15 を書き換え、M2・M3 は不要になった。#454 の条件 1 の「既存の 17 個」は数え違いで、変更前の一覧は 16 個だった
手戻り	設計 PR #484 は cross-review 2 ラウンド＋承認ゲート 1 での設計の変更による直し 1 回。スプリント PR #488 はレビュー 2 ラウンド（major 2 件を直し、未解決 0）
見落とし	M1（#488 のコメント 6160308278）は「イメージは建て直していない（#463 より前の entrypoint）」と書いたが、proj-a・proj-b のイメージは M1 のコンテナ作成の直前（03:19〜03:22 UTC）に建て直されており、M1 は新しい entrypoint で走っていた。条件 10 の「古い entrypoint のイメージでも起動の後の処理が bin を揃える」は、リリース後テストで古いままの派生イメージ（proj-c）を使って初めて実の docker で確かめた（合格）
リリース後テスト	27 条件すべて合格（#488 のコメント 6161246449）。base の建て直しも devbase up（P3）も使わず、実のイメージと使い捨てのボリュームの docker run で、M4・M5 の片付け（版の違う 2 版が残る・7 版から同時起動で 5 版・入れ子の本体の削除・消せないときの WARNING）を確かめた。実の VS Code の更新が要る 1 行は保留（次に VS Code が更新されたとき利用者が確かめる）
範囲	構造改善は採用 4・取り消し 1・見送り 1。残りの 2 件は振り返りまで起票されておらず、ここで #490 にした
工程	飛ばした工程は無い。設計 → 承認ゲート 1 → 実装 3 本 → 構造改善 → レビュー → M1（P3 の承認）→ 承認ゲート 2 → 確定仕様化 → リリース後テスト

context window の大きさ

層	フェーズ	モデル	件数	固定費の中央値	実作業の中央値	実作業 < 固定費	最大充填の最大	目印
conductor	-	claude-opus-5-5	2	60744	114618	0	222918	割る候補

層	件数	固定費の合計	実作業の合計	総消費
conductor	2	121488	229236	350724

• 割る候補（conductor）: そのままにする。最大充填 222918 は設計から承認ゲート 2 まで通した 1 本目のセッションで、確定仕様化の後のカットポイントで切り、2 本目（リリース後テスト以降）は 127806 に収まった。supervisor・worker はプラン（supervise.py）で流したため、このセッションの測定には出ない

用語集の変化

コンテキスト	足した語	廃止した語	意味を変えた語
editor	共通の VS Code Server ボリューム・コンテナごとの VS Code Server の状態・旧形式の VS Code Server ボリューム	—	—
container-start	入れ子の本体・残す版の数	—	—

承認ゲートの差し戻し

gate-rejections.py count は関門 1・関門 2 とも 0 件。ただし関門 1 で利用者が設計を変え（data/・extensions/ を共有しない）、直した #484 を改めて承認している。差し戻しの記録を付けずに直しのプランを流したため集計に出ない。利用者の判断で上流への起票はしない。

MVV を見直すか

project-mvv.py signals（版 1）: 覆し 0（閾値 3）・判定できない 0（閾値 5、続けて 0 / 3）・流出不具合 0（閾値 3）。兆候が無いため問わない（2026-10-13 の利用者の指示: 兆候があるときだけ問う）。

次に変えること

変えること	落とし先	状態
変えない。M1 の記録とイメージの食い違いは、既存の AGENTS.md の落とし穴（建てる前に docker image inspect の Created を控える）の範囲で防げたと利用者が判断した	—	利用者の判断（2026-10-15）

途中で起票した課題

番号	何を見つけたか	見つけた場面
#490	構造改善で取り消し・見送った 2 件（使われない project_name の引数・VS Code Server の片付けの関数の分割）	構造改善（振り返りで取りこぼしとして拾った）