devbase: env sync の AWS の経路・bash の補完・偽の OpenBao・テストの補助に、同じ式の重なりと長い関数が 15 件残る → 11 件を振る舞いを変えずに直し、4 件は直さない理由を残す（#452）

[takemi-ohama]

#452 の設計を文書として置きました（スプリント m8e）。要求と受け入れ条件の写しも添えています。コードの変更はありません。

利用者向けの変化

• 無し

移行の手順

• 無し

変更の要点

• issues/issue-452-requirements.md を追加しました（200 行）。PR #450 の構造改善で時間の枠を超えて見送った提案の残り 15 件（_aws_plan の重複・補完の分岐の連なり・テストの補助の重複など） #452 の要求と受け入れ条件の写しです。
• issues/issue-452-design.md を追加しました（615 行）。PR #450 の構造改善で時間の枠を超えて見送った提案の残り 15 件（_aws_plan の重複・補完の分岐の連なり・テストの補助の重複など） #452 の設計です。
• 変更は上の 2 ファイルの追加だけです（合わせて 815 行の追加）。

テスト

supervise.py の run の各ステップの結果です。

ステップ	exit	結果
glossary	0	ok：「宣言と用語集が揃っている」
requirements-check	2	要求の文書を書く前の判定（ファイルがまだ無い時点。想定どおり）
requirements-recheck	0	ok：課題の本文と issues/issue-452-requirements.md の写しが一致
glossary-check	0	ok（用語チェックは語の一覧が無く、当たりの検査はしていない）
review（cross-review）	0	3 ラウンドで収束。指摘 2・修正 2・未解決 0、最終は全員承認

• CI はすべて通った（Pytest 3.10/3.13 を含む 10 件）。

モード: standard / 通した工程: 設計 → 要求と受け入れ条件 → ドキュメントレビュー

🤖 Generated with Claude Code

決めたこと

issues/issue-452-design.md

• 決定 1: 15 件を片付けるため、11 件を「直す」、R4・R6・R7・R8 の 4 件を「直さない」に分ける
• 決定 2: 要求の基準をそのまま使い、数値と定義の場所を設計で変えない
• 決定 3: R1〜R3 は env.py の中で閉じる最小の形にし、R2 は関数を足さず、R3 は _aws_whole_plan を足す
• 決定 4: ホームのパスを 1 か所にするため、manager.py の先頭に CONTAINER_HOME を置き、compose.py が取り込む
• 決定 5: R8 は「直さない」にする。既存のテストが etc/_devbase の case の入れ子を字面で辿るため
• 決定 6: devbase_root の解決は、呼び出し元の local devbase_root へ入れる関数にする（標準出力で返さない）
• 決定 7: _devbase_completions は語の位置で振り分け、位置 3・4 はグループごとの関数へ移す
• 決定 8: 補完を実行する補助は tests/cli/conftest.py に置き、2 つのファイルは元の名前で取り込む
• 決定 9: DEVBASE_MANAGED は tests/volume/conftest.py へ移して取り込む
• 決定 10: 偽の OpenBao の do_GET は、拒否と注入の _refuse_read と、応答の組み立ての _read_secret に分ける
• 決定 11: tests/containers/ の補助は test_ で始まらないモジュールに置き、各ファイルの関数は薄い入口として残す
• 決定 12: bash の補完の各分岐を縛る現状固定のテストを、R9・R10 の前に足す
• 決定 13: コミットを 3 つに分け、PR #488 の構造改善で取り消し・見送った 2 件（使われない project_name の引数・VS Code Server の片付けの関数の分割） #490 とは manager.py の先頭の定数だけで接する

[takemi-ohama]

🤖 cross-review | round 1 | codex | APPROVE

指定のモデル段の範囲では、critical / major に該当する修正指摘はありません（判断の根拠: Vision・Value 3・C1・C3）。

[takemi-ohama]

🤖 cross-review | round 1 | kiro | REQUEST_CHANGES

ドメインモデルの集約の表で、「スケールで作るファイルの dev サービス」の持ち主が compose.py と宣言されているが、同じ値オブジェクトに含める CONTAINER_HOME（新）・VSCODE_SERVER_TARGET・VSCODE_BIN_TARGET は構成要素の表と決定 4 では manager.py に置く定義で、持ち主の宣言が設計内で食い違う。

[takemi-ohama]

🤖 cross-review | round 2 | claude | REQUEST_CHANGES

受け入れ条件の確かめ方（tests/ の assert の行が増減しない）が、R11・R14 で補助の assert を 1 か所へ寄せる設計と食い違う。確かめ方をテスト関数の assert に絞って書き直す。

[takemi-ohama]

🤖 cross-review | round 2 | kiro | APPROVE

round 2: 範囲の 2 ファイル（issue-452-design.md / issue-452-requirements.md）を精査。実装者が別物を作る食い違い・利用者経路の誤動作・秘密/データに触れる問題は、round 1 で kiro と takemi-ohama の両者が既に挙げた『集約の表で「スケールで作るファイルの dev サービス」の持ち主を compose.py としているが、値オブジェクトに含む CONTAINER_HOME（新）・VSCODE_SERVER_TARGET・VSCODE_BIN_TARGET は決定 4 と構成要素の表で manager.py に置く定義で矛盾する』以外には見つからなかった。この既出の指摘は compose.py が既に from .manager を取り込み（compose→manager）、CONTAINER_HOME を compose.py に置くと循環取り込みになる決定 4 の根拠を実コードで確認したうえで、実在する critical/major 相当と裏取りできたが、スナップショットに同一指摘が 2 件あるため重複として本ラウンドでは再掲しない。決定 4 と manager.py の先頭定数（49・51 行）・#490 の VolumeManager（236 行以降）との非重複、確定仕様 vscode-server-volume.md の『名前とパスの定数』行が manager.py のまま変わらない点、R15 の接尾の対応も確認し、新規の critical/major は無い。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 2 | commit fcda883

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

[takemi-ohama]

🤖 cross-review | round 3 | claude | APPROVE

round 3: fcda883 の 2 か所（集約の表の持ち主を manager.py / compose.py に分けた行、assert の確かめ方をテスト関数の中と補助の移動に分けた行）は、構成要素の表・決定 4・R5・R11・R14 の行と一致する。新しい critical / major は無い（根拠: Vision・Value 3）。

[takemi-ohama]

🤖 cross-review | round 3 | codex | APPROVE

指定差分 1 ファイルに新規の critical / major 指摘はありません（根拠: Vision。定数の持ち主と assert の検証範囲を、決定 4・8・11 および既存コードと照合）。

[takemi-ohama]

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

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