機密ストアのチーム共通と個人単位の置き場を、アカウントグループ（nyle / with / kkg）ごとに分ける

[takemi-ohama]

何をするか

機密ストア（OpenBao backend）のチーム共通と個人単位の置き場を、ボリュームと同じくアカウントグループ（DEVBASE_ACCOUNT_GROUP）ごとに分ける。グループは nyle / with / kkg の 3 つ。

背景

• ボリュームは DEVBASE_ACCOUNT_GROUP ごとに devbase_home_<group> へ分かれている（with-ai-dev は with、project-trygroup-prd は kkg、未設定は default = 実質 nyle）
• 一方、機密のチーム共通は team/global 1 つで、運用: 自分の端末を OpenBao backend へ切り替え、チーム共通の機密を移す #172 の移行後は nyle の値（GCP プロジェクト、BigQuery のサービスアカウント鍵、Slack など）が入っている
• そのため with / kkg のプロジェクトにも nyle の機密がいったん配られ、プロジェクトの env の空上書きで打ち消している（fix: プロジェクトの env による共通機密の打ち消しが効かないことがある #152 と同じ、企業をまたいで混ざる形）
• サーバのポリシーも「チーム共通を読める人は全グループの鍵を読める」ことになり、with / kkg だけの利用者を登録できない
• 運用: 自分の端末を OpenBao backend へ切り替え、チーム共通の機密を移す #172 の単位 5 で GCP_CREDENTIALS_BASE64__default（nyle の BigQuery 用サービスアカウント鍵）を個人単位へ移したが、中身はチームの鍵だった。置き場を決める軸が足りないことの表れ

決まっていること（利用者、2026-09-15）

• グループ名は nyle / with / kkg。いまの default は nyle として扱う
• チーム共通だけでなく、個人単位（users/<user>/…）もグループで分ける（同じ人でも会社ごとに GH_TOKEN や AWS のプロファイルが違う）
• v3.4.0 のマイルストーンで扱う（v3.4.0 は公開済みのため、配布は次の版）

変わるところ（見込み）

対象	変わること
置き場のパス	例: team/<group>/global、team/<group>/projects/<name>、users/<user>/<group>/global、users/<user>/<group>/projects/<name>
重ね順と取得（runtime.resolve()）	プロジェクトのアカウントグループからパスを選ぶ
secrets/backend.yml	パスの項目
env コマンド（list / get / set / delete / edit、--user）	対象のグループの決め方
env backend migrate	グループの扱い（現状はプロジェクトを外すオプションも無い）
サーバ（carmo-cdk）	グループ単位で読み書きを許すポリシー（devbase-team-writer もグループごと）。別途 carmo-cdk に起票する
この端末の置き場	team/global（21 キー）・team/projects/*・users/takemi_ohama/* をグループ別のパスへ移し直す

未決（要求・設計の工程で決める）

• default を nyle と読み替える方法（DEVBASE_ACCOUNT_GROUP の既定値を変えるのか、置き場だけ対応させるのか。ボリューム名 devbase_home_default との関係）
• グループの外に置くもの（全グループ共通の機密）を持つか
• ファイル backend（age / plaintext）でも分けるか
• 移行の順序と、KV v2 の版の履歴に他グループの機密を残さない手順（ops(PLAN53): 自分の端末を OpenBao backend へ切り替え、チーム共通の機密を移した実行の記録 (#172) #181 の記録にある教訓）

関連

• 運用: 自分の端末を OpenBao backend へ切り替え、チーム共通の機密を移す #172 / PR ops(PLAN53): 自分の端末を OpenBao backend へ切り替え、チーム共通の機密を移した実行の記録 (#172) #181（切り替えの実行の記録）、fix: プロジェクトの env による共通機密の打ち消しが効かないことがある #152、feat: 機密ストアの保存先を差し替え可能にする（第一 adapter: OpenBao）(PLAN51) #171（PLAN51）
• docs/specifications/secret-backend.md、docs/user/environment-variables.md「アカウントグループ」

🤖 Generated with Claude Code

進行

モード: standard / 作業ツリー: .worktrees/feat-plan56-secret-group-paths / 計画: issues/PLAN56_secret-group-paths.md

• 要求と受け入れ条件 — 2026-09-15 19:19
• 作業場所の用意 — 2026-09-15 19:33
• 設計 — 2026-09-15 19:33
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-09-15 19:40
• ドキュメントレビュー — 2026-09-15 19:41
• 計画 — 2026-09-15 21:46
• 実装 — 2026-09-16 06:34 / Task 1〜8 を feat: 機密ストアの置き場をアカウントグループごとに分ける (PLAN56) #184 で実装
• 構造改善 — 2026-09-15 23:02
• 実装レビュー — 2026-09-15 23:58
• 完了判定 — 2026-09-16 00:56
• Pull Request — 2026-09-16 01:00
• 確定仕様化 — 2026-09-16 02:00
• 後片付け — 2026-09-16 01:59
• 配布 — 2026-09-16 06:34 / main へのマージが配布（feat: 機密ストアの置き場をアカウントグループごとに分ける (PLAN56) #184 7fe3ad9 / docs: PLAN56 を機密ストアの確定仕様へ取り込む (#182) #186 / ops(PLAN57): この端末の機密をアカウントグループ別の置き場へ移し直した実行の記録 (#182) #187）。タグは溜まった分をまとめて切る運用
• 体裁レビュー
• リリース後テスト — 2026-09-16 06:32
• 振り返り — 2026-09-16 06:32

[takemi-ohama]

振り返り（2026-09-16）

対象: issue #182 / 設計 PR #183 / 実装 PR #184 / 確定仕様 PR #186 / 移し直し（operation）PR #187

機密ストア（OpenBao backend）の置き場を、backend.yml の version: 2 でアカウントグループ（nyle / with / kkg）ごとに分けた（#184）。確定仕様へ取り込み（#186）、この端末の既存の機密を新しい置き場へ移し直して古いパスを版の履歴ごと消した（#187）。サーバ側のポリシーは volareinc/carmo-cdk 側の変更で同時期にグループ単位へ切り替わった。

何が起きたか

観点	事実
受け入れ条件	設計のレビューで 15 → 19 件（5 を 5 / 5a に分割、16〜18 を追加）。追加の理由はいずれも、実装の経路（scale・子プロセスの env init・env backend test）を設計が見落としていたこと。設計の決定は 9 → 13 件
手戻り	#183: クロスレビュー 7 ラウンド・指摘 31 件（うち少なくとも 9 件は既存のコードの形との食い違い）。#184: 4 ラウンド・11 件（10 件対応、1 件は理由を添えて見送り）。#187: 4 ラウンド・4 件（すべて記録の検証の書き方）
見落とし	実装レビューで、グループ別の置き場では env サブコマンドの検証より前に注入が走り、別グループのパスへ要求が出ることが見つかった（e179d97 で修正）。export DEVBASE_ACCOUNT_GROUP= の宣言の読み落としも同じラウンドで見つかった
リリース後テスト	#187 の単位 2〜4 で実サーバに対して確かめた（status / test / 3 プロジェクトの env exec / bao kv get / 古いパスの metadata get）。仕様の手動確認にある devbase up によるコンテナの作り直しは行っていない（env exec の注入結果で代えた）
範囲	サーバのポリシーは範囲外として carmo-cdk へ起票し、実施の直前に反映された。反映後の権限（古いパスは管理者だけが読める）を bao token capabilities で確かめてから移し直した
工程	飛ばした工程は無い。cross-review が round 1 で収束した #187 と、major を直した直後に収束扱いになった #183 / #184 は、final を戻してもう 1 ラウンド回した。agy / kiro の結果ファイルの不備で判定が中断扱いになったラウンドが 3 回あり、投稿された指摘を進行側が取り込んだ
実行	#187 の単位 0 は projects/* がシンボリックリンクのため相対パスの出力先が外れ、1 回目は何も書かれなかった（絶対パスで採り直した）

次に変えること

変えること	落とし先	状態
設計の入出力の契約を、既存のコマンドの引数定義と呼び出し経路に突き合わせる手順を足す	design の手順	devbasex/ai-plugins#686 として起票
cross-refactoring の提案で target に行範囲を添えた提案を捨てない	cross-refactoring の手順	devbasex/ai-plugins#684 として起票
cross-review で申告と実数が食い違っても、届いた指摘を結果として取り込む	cross-review の手順	devbasex/ai-plugins#685 として起票
operation の実行の直前に、依存する外部の変更（今回はサーバのポリシー）の状態を確かめる	変えない	今回は承認の前に権限を確かめ直して計画の前提を書き換えられた。operation-run.md の「実行の範囲を書く」「承認を得る」の順で既に拾える

途中で起票した課題

番号	何を見つけたか	見つけた場面
volareinc/carmo-cdk#363	OpenBao のポリシーをグループ単位にする（サーバ側）	設計（承認時）
#185	置き場に書いた DEVBASE_ACCOUNT_GROUP が注入でボリュームのグループを変えうる	実装中（文書）
#188	env backend test / env list の見出しが読み替え前のグループ名だけを出す	振り返り（#187 の記録から）
devbasex/ai-plugins#684 / #685 / #686	上の「次に変えること」	振り返り

起票しないと判断したもの:

• 既定の ruff 規則の件数の増加（832 → 909 件）: CI の規則（E9,F63,F7,F82）の外で、既存コードと同じ書き方の UP 系だけのため
• with / kkg のプロジェクトの env に残る空の上書き: 打ち消す相手が置き場から無くなり害は無い。消すかは利用者が決める（プロジェクトは plugin リポジトリ側、PLAN57 の「次に変えること」）
• プロジェクトの下位ディレクトリから up したときのボリュームのグループ（設計の未確認）: up はプロジェクト名を実行時のディレクトリ名から決めるため下位ディレクトリからは使われず、version: 2 では食い違いの検査が止める