chore(release): v3.6.0

[takemi-ohama]

Summary

マイルストーン v3.6.0（#141 / #146 / #142 / #196 / #200 / #185）と、先にマージ済みの PLAN59（#197）をまとめて版 3.6.0 として確定する。

• CHANGELOG.md: [Unreleased] を [3.6.0] - 2026-09-19 として確定し、比較リンクを追加
• pyproject.toml / lib/devbase/__init__.py / lib/devbase/cli.py / uv.lock / docs/developer/architecture.md の版数を 3.6.0 へ

配布の記録

段階: 本番（devbase は main へのマージがそのまま配布。実装 PR のマージは 2026-09-19 に承認済み。タグと GitHub Release はこの PR のマージ後に作る）
版: 3.5.0 → 3.6.0（MINOR: 後方互換のある追加と修正。container <sub> <name> が usage エラーになる変更と、機密の置き場の DEVBASE_ACCOUNT_GROUP を使わなくなる変更を含むが、どちらも非推奨の経路と文書で使わないと明記していた値のため MAJOR にはしない）
まとまり: PR #202 / #204 / #205 / #206 / #207 / #210（および先行してマージ済みの #198 / #199）

Test plan

• bash bin/devbase --version → devbase 3.6.0、exit=0
• uv lock で uv.lock の版数が 3.6.0 に更新されることを確認
• CI（この PR のチェック）

🤖 Generated with Claude Code

[takemi-ohama]

リリース後テスト

対象の版: v3.6.0（2026-09-19 にタグと GitHub Release を公開）
導入経路: 利用者と同じ $DEVBASE_ROOT（/Users/takemi_ohama/devbase）で git pull --ff-only 済み。devbase --version → devbase 3.6.0

課題	受け入れ条件	実行したこと	実行時刻	結果
#196	9・10. build --help がビルドを起こさず使い方を出す	devbase build --help（$DEVBASE_ROOT の外で実行）	2026-09-19 12:12	合格 / exit=0。=== Building devbase images === は出ず、--no-cache / --project-no-cache / --expires[=DAYS] / --context NAME / <image> が載る
#146	1. build ../etc が外へ出ない	devbase build ../etc	2026-09-19 12:13	合格 / exit=1。Invalid image name: '../etc'。$DEVBASE_ROOT/etc へは移動しない
#146	2・3. 名前を取るコマンドが形に合わない名前を拒む	devbase up ../etc	2026-09-19 12:13	合格 / exit=1。プロジェクト名に使えない形です: '../etc'
#200	12. container <sub> <name> が usage エラー	devbase container up carmo	2026-09-19 12:13	合格 / exit=2。unrecognized arguments: carmo。projects/carmo へは移動しない
#142	6. 衝突時はイメージが勝ち、知らせが出る	devbase build bi-tools	2026-09-19 12:15	合格 / exit=0。Note: 'bi-tools' is also a project (projects/bi-tools); building image containers/bi-tools... を 1 行出し、containers/bi-tools を実際にビルド
#185	7. env set が拒む	devbase env set DEVBASE_ACCOUNT_GROUP=kkg（OpenBao / version: 2 の実環境）	2026-09-19 12:16	合格 / exit=1。置き場へは書かず、env ファイルへ書くよう案内
#185	4. 置き場に値があれば警告が出る	別の devbase ルート（v3.6.0 の作業ツリー、plaintext 相当の .env に DEVBASE_ACCOUNT_GROUP=kkg と TOKEN=t）で bin/devbase env list	2026-09-19 12:18	合格 / exit=0。Warning: 機密の置き場（グローバル）にある DEVBASE_ACCOUNT_GROUP は使いません…消すには: devbase env delete DEVBASE_ACCOUNT_GROUP（値は出ない）
#185	1・5. 置き場の値が環境変数へ載らない	同ルートで runtime.inject() → os.environ と resolve_account_group() を表示	2026-09-19 12:19	合格。DEVBASE_ACCOUNT_GROUP は None、TOKEN は t、ボリュームのグループは default
#141	1〜4. CI が pytest を実行する	この PR とマイルストーンの各 PR の checks（Pytest (Python 3.10) / (3.13)）	2026-09-19	合格。すべて pass

合否: 合格（9 件すべて実施、保留なし）

未実施: 警告が TUI（devbase list）の画面で埋もれずに読めるか（実環境の置き場に値を書かずに確かめる手段が無く、共有の OpenBao を汚さない判断。CLI では読めることを確認済み）
起票したもの: なし（この工程で新たに見つかった範囲外の課題は無い）

[takemi-ohama]

振り返り（2026-09-19）

対象: マイルストーン v3.6.0（#141 / #146 / #142 / #196 / #200 / #185）と、それを配布した PR #211

6 件を 3 本の Pull Request へ束ねて通した。CI に pytest を足す #141 を light で先に出し（#202）、bin/devbase の位置引数の解決にかかる 4 件（#146 / #142 / #196 / #200）を standard の 1 本（設計 #204 → 実装 #207）、機密の注入から DEVBASE_ACCOUNT_GROUP を外す #185 をもう 1 本（設計 #205 → 実装 #206）にした。確定仕様化は #210、版上げは #211 で、v3.6.0 として公開した。

何が起きたか

束ね方: 4 件を 1 本にしたのは、どれも bin/devbase の name 解決と build) の分岐という同じ数十行を触るためで、分ければ同じ箇所で競合した。触るファイルが重ならない #185 と #141 は分けた。この判断は最後まで持った（3 本の間で競合は起きなかった）。

手戻り: レビューのラウンドは #202 が 4、#204 が 3、#205 が 2、#206 が 3、#207 が 2、#210 が 3。差し戻しの原因は、文書の記述が実装と食い違うもの（build --help が「env を読まない」と書いたが wrapper は起動時に必ず読む、--context=--help が「context 名として渡る」と書いたが下流で usage エラーになる、「そのディレクトリで実行すれば衝突を避けられる」が name 解決は現在地に依らないので成り立たない、projects/* は symlink なので「外へ出ない」保証の範囲が限定される）が 4 件と、テストの環境依存が 4 件だった。実装そのものの差し戻しは 0 件で、設計と仕様の文の精度に集中した。

見落とし: #141 で CI に pytest を足したところ、Linux の CI だけで 3 件落ちた（runner が /usr/bin/gcloud を持つ、tmux の既定 terminal-overrides が版で違う、Python 3.10 の pathlib が os.unlink を束縛済みで monkeypatch が届かない）。手元の macOS では 2682 件すべて通っており、CI を足すまで誰も踏めなかった経路だった。#141 を先に通した判断がそのまま他の 2 本の安全網になった。

工程: 飛ばした工程は無い。light の #202 も実装レビューを通し、そこで uv sync --frozen が lock と pyproject.toml の食い違いを検査しないという指摘（codex）を受けて --locked に変えた。この指摘は #141 の受け入れ条件 2 の意味に直結しており、レビューを通さなければ条件を満たさないまま配布していた。

レビュー担当の偏り: agy がレビューでも適用でも結果を残せない事象が繰り返し起きた（#202 で 2 回、#207 で 2 回、#210 で 1 回、cross-refactoring の適用で 3 回）。いずれも差分に tests/ か CI 設定を含む Pull Request で、agy が自分で uv run pytest tests/（約 2 分）を背景に起動し、完了通知を待ったまま終了していた。そのたびに担当を kiro / codex へ寄せて 1 ラウンド埋めた。

context window の大きさ

層	持ち場	モデル	件数	固定費の中央値	実作業の中央値	実作業 < 固定費	最大充填の最大	印
conductor	-	claude-opus-5	1	29644	434688	0	464332	割る候補
supervisor	その他	claude-opus-5	14	30190	44090	6	211334	割る候補

層	件数	固定費の合計	実作業の合計	総消費
conductor	1	29644	434688	464332
supervisor	14	419201	1049235	1468436
合計	15	448845	1483923	1932768

• conductor が 割る候補: 1 つの窓でマイルストーン全体（要求 → 設計 → 実装 → レビュー → 配布 → リリース後テスト）を通したため、最大充填が 46 万に達した。context-window.md の切れ目（ドキュメントレビューのマージの後、Pull Request を出した後、配布の後）で窓を切っていれば 3 〜 4 本に割れた。次は切る。判断の質が落ちた自覚のある箇所は無いが、目安（1 工程 10 万、遅くとも 20 万）を 2 倍超えている。
• supervisor が 割る候補（14 件中 6 件が実作業 < 固定費）: 固定費が中央値 3 万に対し、実作業が 2 万台の記録が 6 件ある。内訳は cross-review の fix / sweep で、指摘 1〜2 件に対してサブエージェントを 1 つ起動している。cross-review の手順が修正の委譲を必須と定めるため減らせないが、指摘 1 件の文言修正までサブエージェント 1 つを立てるのは固定費が見合っていない。この点は ndf 側の課題として起票する（下表）。
• worker（深さ 2 以上）は使っていないため、持ち場ごとの表は空である。

次に変えること

変えること	落とし先	状態
マイルストーン単位の実行では、設計 PR のマージ後・実装 PR を出した後・配布の後で窓を切る	進め方（次の変更で試す）	次のマイルストーンで実施
agy をレビュー・適用の担当にする前に、差分が tests/ や CI 設定を含むかを見る。含むなら担当から外すか、1 度 NO_RESULT が出た時点で kiro / codex へ寄せる	ndf の cross-review / cross-refactoring の手順	devbasex/ai-plugins へ起票（devbasex/ai-plugins#786）
設計文書の「契約」に「〜しない」と書くときは、その範囲（何に対して成り立たないか）まで書く。今回は 4 件の差し戻しがこの形だった	ndf の design の手順	devbasex/ai-plugins#787
CI に検査を足すときは、手元と CI の環境差（インストール済みのツール・ライブラリの版・Python の版）を先に洗う	進め方	#141 の実施で学んだことを踏襲

途中で起票した課題

番号	何を見つけたか	見つけた場面
#203	プロジェクト名の検証の規則が env の export / import・機密の保存先・名前の指定で食い違う	設計中（PLAN61 の決定 3）
#208	cli-reference/02-project.md の [name] を取るサブコマンドの列挙に rebuild / open が無い	実装中（PLAN61）
#209	openbao_root fixture が DEVBASE_ROOT を setenv しないため、使う側が忘れると実環境を読む	完了判定（PLAN62）

取りこぼしの確認: quality-gates の完了報告で「範囲外と判断したもの」に挙げた 4 項目（#203 / #208 / #209 / docs/specifications/secret-backend.md の古い記述）のうち、最後の 1 件は #210 の確定仕様化で解消済み。レビューで範囲外として resolve した指摘は無い。