設計(PLAN66): 名前の形に合わないプロジェクトを、作られた時点で知らせる (#203)

[takemi-ohama]

Summary

名前の形に合わないプロジェクト（_foo など）を、projects/ に載った時点で知らせる設計。
弾くか警告に留めるか、SINGLE_SEGMENT_NAME_PATTERN と _VALID_NAME_RE を寄せるかを決めた。
実装は含まない。

• 要求と受け入れ条件: issues/PLAN66_project-name-validation.md
• 設計: issues/PLAN66_project-name-validation-design.md

参照: #203 / release Pull Request #212 / 範囲外として起票した #226 #227 #228 #229

この設計で変わること

devbase plugin install / update / sync と devbase env import に警告が 1 行増える。
作られるものと終了コードは変わらない。 名前の形に合わないプロジェクトを持つ利用者に
移行の作業を求めない（弾かないため、どの操作も今と同じく通る）。

変わるものが 1 つある。スナップショットの名前が末尾の改行を受け付けなくなる
（devbase snapshot create "abc\n" が SnapshotError）。今は通る。

実測（この作業ツリー / release/v3.7.0 の先頭 688efde）

issue #203 の本文の 2 つの記述が事実と違う。

1. 「syncer が projects/ に名前を載せる唯一の入口」は誤り。 隔離した root で
   env/projects/_foo/.env を含む書庫を import すると、projects/_foo/ が実ディレクトリ
   として作られ、終了コード 0 で警告が 1 行も出ない。同期だけを直しても、名前の指定から
   操作できないプロジェクトは生まれる

import rc = 0
projects/ の中身: ['_foo', 'ok-name']
_foo は実ディレクトリか: True symlink か: False
--- 同じ root で名前を解決する ---
list_projects の名前: ['_foo', 'ok-name']
プロジェクト名に使えない形です: '_foo'（英数字で始まり、英数字・'.'・'-'・'_' だけからなる名前）
_foo  -> False

2. 「名前を検証する規則は 4 か所」は過少。 プロジェクト名そのものを見る規則は 6 か所
   （本文の 3 つ + env/_import_merge.py の _PROJECT_ENV_RE + bin/devbase の
   _SINGLE_SEGMENT_NAME_RE + syncer.discover_projects の . 始まりの除外）。同じ文字集合の
   正規表現は他に volume/manager.py の _GROUP_NAME_RE がある

3. 「文字集合が同じ」だが振る舞いは違う。 _VALID_NAME_RE は re.match + $ のため
   末尾の改行を通す。

'_foo'    single: False snapshot: False bundle: True
'abc\n'   single: False snapshot: True  bundle: True   ← 末尾の改行だけが食い違う
'a.b'     single: True  snapshot: True  bundle: True

4. 本文の「今のところ実在しない」は正しい。 登録済み 3 リポジトリ・22 プラグインの
   projects/ 直下 133 件すべてが名前の形に合う（. 始まり 0 件・先頭 _ 0 件・
   ASCII 外 0 件）。読み取りだけで数え、実環境に対して plugin install / update / sync は
   実行していない

5. devbase 自身が名前の形に合わない名前を作れる。 衝突に敗れた側へ張る別名
   <名前>.<owner> の owner は、--link のプラグインでは元パスの basename そのままである。

owner = 'my plugin' → 生成される別名 'carmo.my plugin' 名前の形に合うか: False
作られた symlink の数: 1

既存の利用者に何が起きるか

利用者	何が起きるか
名前の形に合うプロジェクトだけを持つ（この端末の 133 件すべて）	何も変わらない。警告も出ない
名前の形に合わないプラグインのプロジェクトを持つ	同期のたびに警告が 1 行。プロジェクトは今と同じく使える（projects/<名前> へ cd して名前なしに打つ）
_foo を含む書庫を import する	import は今と同じく通り、警告が 1 行増える
スナップショット名の末尾に改行を入れていた	SnapshotError になる（該当する利用者がいるとは考えにくいが、受け付ける名前を狭める唯一の変更）

弾く形を採らなかった理由は設計の決定 1 にある。要点は、symlink を張らないと
env/runtime.py がプロジェクトを projects/ からの相対パスで決めるため、プラグインの
クローンへ cd してもプロジェクトとして扱われなくなることである。同期の全体を失敗させる形は、
1 件の名前でそのプラグインの他のプロジェクトも projects/ から消す（同期は既存の symlink を
全部消してから張り直す）。

実装の分け方

#	名前	依存
1	知らせ（syncer の 3 か所と env import・確定仕様の「運用」の 1 つ目・CHANGELOG）	無し
2	スナップショットの名前を utils/names へ寄せる（確定仕様の「運用」の 2 つ目）	Pull Request 1 のマージが要る（同じファイルの別の箇条書き）

他の束との重なり

• docs/specifications/cli-argument-resolution.md は PR docs: [name] / --context を取るサブコマンドの列挙を揃え、profiles に requires.devbase の手順を足す (#208, #195) #213（未マージ）が触っていない。
  docs: [name] と --context を取るサブコマンドの列挙が 8 か所の文書で古く、rebuild / open が抜けている #208 の調査で「他のショートカット」の節は直す対象でないと確認済み。この束が触るのは
  「運用」の節である
• lib/devbase/commands/container.py は触らない。 G5（container.py: cmd_scale の長いメソッドと compose config 読み取りの重複を整理する #192）の束が同じファイルを触るため、
  文言の定数への寄せは 名前の形を説明する文言を utils/names.py の定数へ寄せる（container.py のインラインの文言） #229 として範囲外に出した
• lib/devbase/env/secret_store.py は触らない。 G4（env backend test / env list の見出しが読み替え前のグループ名だけを出す（グループ default） #188）の束が触るため
• pytest の DEVBASE_ROOT の隔離は PR test: pytest のセッション全体で DEVBASE_ROOT を隔離する (#209) #217（未マージ）が入れる。 この設計のテストは
  PluginRegistry(tmp_path) と import_bundle(tmp_path, ...) だけを使い、DEVBASE_ROOT に
  依存しない

範囲外として起票したもの

番号	内容
#226	plugin info が . 始まりを除外せず、discover_projects と食い違う
#227	env の書庫の名前の検証が末尾の改行を通し、別のメンバーが同じ書き出し先を指しうる
#228	衝突した別名の形が文書と実装で違う（文書は owner--repo、実装はホスト名を含む）
#229	名前の形を説明する文言を utils/names.py の定数へ寄せる（container.py の重複）

決めたこと

issues/PLAN66_project-name-validation-design.md

• 決定 1: 名前の形を検査するが、弾かずに警告に留める
• 決定 2: 検査は projects/ に名前を載せる直前に置き、列挙と集約には置かない
• 決定 3: 下流の検証は残す。責務は「移動」ではなく「前倒し」
• 決定 4: env import の知らせは保存先ごとに文を変え、書庫の名前の規則は変えない
• 決定 5: スナップショットの名前は utils/names の述語を共有する
• 決定 6: 共有した述語が将来広がらないよう、スナップショット側で受理と拒否を固定する
• 決定 7: 知らせの文言の定数は utils/names.py に置き、ログはそこから出さない
• 決定 8: discover_projects の . 始まりの黙った除外は変えない
• 決定 9: 実装は 2 本の Pull Request に分ける

cross-review

6 ラウンド回し、指摘 12 件（major 4 / minor 8）をすべて受け入れて設計を変えた（deferred 0 /
rejected 0 / 未解決 0）。

round	担当	判定	対応
1	agy / kiro	agy=REQUEST_CHANGES (4) / kiro=APPROVE	e207cc7（4 件）
2	codex / kiro	codex=REQUEST_CHANGES (1) / kiro=COMMENT (1)	08414c1（2 件）
3	codex / agy	codex=APPROVE / agy=REQUEST_CHANGES (5)	5233da4・b90dc0a（5 件）
4	agy / kiro	kiro=APPROVE (0) / agy は 2 回とも結果を残さず（実行環境の側）	—
5	codex（1 者へ絞る）	codex=REQUEST_CHANGES (1)	bed1fea・b6ad9b9（1 件）
6	kiro（1 者へ絞る）	kiro=APPROVE (0)	—

round 4 で agy が 2 回とも result.json を残さなかったため、担当を 1 者へ絞って round 5・6 で
埋めた。最終の内容（b6ad9b9）は kiro が指摘なしで承認している。

Test plan

設計の段階で確かめたことを載せる。実装はこの Pull Request に含まれないため、pytest は
実装の Pull Request で回す。

• release/v3.7.0 を base にした Pull Request では CI が 1 件も動かない（ci: リリースブランチ宛の Pull Request で検査ジョブが 1 件も動かない（on.pull_request.branches が main だけ） #216）。
  .github/workflows/ci.yml の on.pull_request.branches が main だけである
• 隔離した root で import_bundle を実行し、projects/_foo/ が実ディレクトリとして
  作られ、_resolve_project_name('_foo') が False になることを確かめた（上の実測 1）。
  実環境の DEVBASE_ROOT には触っていない
• _link_loser_projects を隔離した root で呼び、carmo.my plugin の symlink が
  張られることを確かめた（上の実測 5）
• plugins.yml の 22 プラグインを辿り、projects/ 直下 133 件の名前を re.fullmatch で
  判定した（読み取りのみ。実測 4）。コミット済みの名前も git ls-tree で数え、
  未コミットの手元のディレクトリ 3 件を特定した
• is_single_segment_name と _VALID_NAME_RE の差を入力 12 件で測り、末尾の改行だけが
  食い違うことを確かめた（実測 3）
• _VALID_NAME_RE の使用箇所が _validate_name 1 か所だけで、長さ制限と予約語が
  無いことを確かめた（grep -n "len(name)\|RESERVED\|maxlen" lib/devbase/snapshot/manager.py
  → 0 件）
• 既存の TestSyncProjects が 7 件で、test_real_directory_skipped を含むことを確かめた
  （受け入れ条件 4・14 の土台）
• io_import._build_plans が store.path(ref) で書き出し先を決め、age の backend の
  path() が secrets/projects/<名前>.env.age を返すことを実装で確かめた
  （lib/devbase/env/io_import.py:220 と lib/devbase/env/secret_store.py:294-299）。
  round 2 の codex の指摘のとおり、age 保存では projects/<名前>/ を作らない
• tests/env/test_store_roundtrip.py の root fixture が backend_config を書かず、
  tests/cli/test_env_bundle_backend.py:300 の bc.save(root, bc.BackendConfig(backend='age'))
  が backend を明示する流儀であることを確かめた（round 3 の agy の指摘。受け入れ条件 9 の
  検証先をこちらへ移した）
• ドキュメント再構成の前後の値を測った（下記）

ドキュメント再構成の前後

指標	要求仕様 前	要求仕様 後	設計 前	設計 後
結論が定義される位置	1 行目	1 行目	1 行目	1 行目
平均文長	58.2 字	39.8 字	45.0 字	39.9 字
最長文	249 字	118 字	189 字	91 字
章の数	16	19	22	22
行数	300	326	369	429
40 行を超える章	3	1	2	2

「後」の値は round 1（e207cc7）・round 2（08414c1）・round 3（5233da4 / b90dc0a）・
round 5（bed1fea / b6ad9b9）のレビュー指摘への対応を含む。

目安を超えた項目:

• 要求仕様の最長文 118 字（目安 100 字）。理由: ## 依頼（原文） の引用の中の 1 文で、
  issue プロジェクト名の検証の規則が env の export / import・機密の保存先・名前の指定で食い違う #203 の本文そのままである。採らなかった直し方: 引用を分ける（requirements-design が
  「原文の引用を省かない・要約しない」と定めている）
• 要求仕様の「依頼（原文）」46 行（目安 40 行）。理由と採らなかった直し方は上と同じ
• 設計の「決定の記録」204 行（目安 40 行）。理由: 9 つの決定がそれぞれ結論・理由・
  採らなかった案を持つ。採らなかった直し方: 決定を章へ分ける（設計文書の雛形が
  「決定の記録」を 1 節と定めており、pr-body-decisions.sh もこの見出しの下を読む）
• 設計の「構成要素の関係と文脈」47 行（目安 40 行）。理由: 3 つの図（構成要素・文脈・
  処理の流れのうち 2 つ）と、図に現れない要素の説明が入る。採らなかった直し方: 図を 1 つずつ
  章にする（図の対応が読めなくなる）

行数の増え方: 要求仕様 +7 行（受け入れ条件 12 を 3 つの箇条書きへ、章の分割 3 件）、
設計 +16 行（「変えないもの」の文を 6 行の表へ、「検査を置く 3 か所」の文を 3 行の表へ、
章の分割 1 件）。round 1 の対応でさらに要求仕様 +1 行・設計 +11 行（決定 2 の理由の追加、
「警告の文」の箇条書きの追加）。round 2 の対応で要求仕様 +10 行・設計 +19 行（受け入れ条件
9 の追加、決定 4 の理由と採らなかった案の追加、保存先ごとの文の表）。round 3 の対応で
要求仕様 +2 行・設計 +6 行（出所ごとの案内の表、章の分割 1 件）。round 5 の対応で要求仕様
+6 行・設計 +7 行（受け入れ条件 3-2 の追加、別名の案内の分岐）。

測れなかった指標: なし

再構成の中で別の作業として足したもの: なし

[takemi-ohama]

🤖 cross-review | round 1 | kiro | APPROVE

設計・要求文書 2 件をコードベースに突き合わせて検証した。参照する関数・シンボル（_collect_project_candidates / _link_loser_projects / sync_projects / _extract_owner / discover_projects / maybe_cd_project / _named_lifecycle_project / _build_single_image / _PROJECT_ENV_RE）はすべて実在し、行参照（syncer.py:155-157 の symlink 全削除ループ、snapshot の _VALID_NAME_RE）も一致した。末尾改行の食い違い（_VALID_NAME_RE.match("abc\n") が True・is_single_segment_name は False）、決定 5 が引く SnapshotError 文言、TestSyncProjects が 7 件であること、空文字が述語で弾かれ not name ガードを外せることも実測で確認した。docs/specifications/cli-argument-resolution.md の「運用」の書き換え対象の箇条書きも引用どおり存在する。

実装を含まない設計 PR として、誤ったパス・存在しないシンボル・文書間の矛盾・実装との齟齬・読者を誤らせる記述は見つからなかった。修正アクションのある指摘は無いため APPROVE とする。

[takemi-ohama]

🤖 cross-review | round 1 | agy | REQUEST_CHANGES

プラグイン同期時の警告ロジックおよび env import 時のログ文言に関して、以下の設計・仕様の修正を提案します。

1. プラグイン同期における重複警告と誤報の防止（設計）:
   _collect_project_candidates 内で警告を出力すると、複数プラグイン間で同名プロジェクトが衝突した場合や実ディレクトリ（real_projects）が存在する場合に重複して警告が出力され、さらにスキップされた候補に対しても「projects/ に載りました」と事実と異なる警告が出てしまいます。警告出力は候補収集時ではなく、実際に projects/ にシンボリックリンクを作成する処理（実ディレクトリのスキップ後）で行う設計に見直してください。

2. env import における --dry-run 時の文言整合性（正確性）:
   --dry-run 時や実際のファイル書き込み前に警告を出す設計に対し、文言が完了形の「projects/_foo/ を作りました」と固定されているため、書き込みが行われない dry-run 実行時や書き込みエラー時に実態と矛盾します。作成前や dry-run でも矛盾しない表現への修正が必要です。

3. 要求仕様書におけるテスト対象ファイルの表記是正（正確性）:
   受け入れ条件の検証欄で、既存ファイル（test_repos_core.py, test_io_import.py）が「（新設）」と記載されている箇所をテストケース追加の実態に合わせて修正してください。

[takemi-ohama]

round 1 レビュー指摘の対応（4 件）

コミット e207cc7 で round 1 の指摘 4 件すべてを反映しました。設計文書のみの修正です。

#	ファイル	重要度 / 観点	指摘	対応
1	issues/PLAN66_project-name-validation-design.md	major / 設計	検査を _collect_project_candidates に置くと重複・誤報が出る	検査の位置を「候補の集約」から「sync_projects が winner へ symlink を張る直前（real_projects のスキップより後）」へ移した。構成要素の表・関係の図・処理の流れの図・決定 2（見出しを「検査は projects/ に名前を載せる直前に置き、列挙と集約には置かない」へ変更）・「警告の文」の箇条書きを修正し、決定 2 の理由へ重複と誤報の 2 点を追記
2	issues/PLAN66_project-name-validation-design.md	major / 正確性	projects/_foo/ を作りました が dry-run と矛盾する	知らせの文を完了形にしないことを規約として明記。同期の文を「projects/ に載ります」へ、import の文を「この import が作る projects/_foo/」へ変更し、「起きていないことを書かない」を「警告の文」へ追加
3	issues/PLAN66_project-name-validation.md	minor / 正確性	tests/plugin/test_repos_core.py は既存ファイル	受け入れ条件 1 を「既存の tests/plugin/test_repos_core.py の TestSyncProjects へテストを足す」、受け入れ条件 6 を「既存の tests/env/test_io_import.py へテストを足す」へ変更。設計文書のテスト設計の表も同じ表現へ統一。tests/snapshot/test_manager_name.py と utils/names.py の NAME_FORM_HINT は実際に新設なので「新設」のまま
4	issues/PLAN66_project-name-validation-design.md	minor / 設計	決定 7 の理由が実態と合わない	決定 7 に「共通化するのは名前の形の説明（ヒント文）だけで、出所と対象の名前を含む文の組み立ては同期と import で別々に行う」を明記し、採らなかった案の行を「名前の形の説明（ヒント文）まで呼び出し側へ別々に書く」へ書き換え

内訳

• 対応: 4 件（critical 0 / major 2 / minor 2 / nit 0）
• 見送り (deferred): 0 件
• 却下 (rejected): 0 件
• Resolve 済み thread: 4 件、未解決: 0 件

CI は base を release/v3.7.0 にすると動かないため未実行です（#216）。設計文書のみの変更でコードの差分はありません。

🤖 Generated with Claude Code

[takemi-ohama]

🤖 cross-review | round 2 | codex | REQUEST_CHANGES

import の保存先ごとの挙動に合わせて、警告の契約と検証条件を修正してください。

[takemi-ohama]

🤖 cross-review | round 2 | kiro | COMMENT

設計・要求の事実主張（改行の食い違い、syncer 以外の入口としての env import、別名合成、行番号参照）はコードと突き合わせて確認でき、正確でした。指摘は 1 件のみ（インライン: 2 文書間で同一 parametrize テストの拒否件数が 7 と 8 で食い違う）。それ以外にブロッキングな修正提案はありません。

[takemi-ohama]

cross-review round 2 対応サマリ

round 2 のレビュー指摘 2 件へ対応しました。反映コミットは 08414c1（docs(PLAN66): round 2 のレビュー指摘を反映する (#203)、push 済み）です。

内訳

項目	件数
対応（fixed）	2
見送り（deferred）	0
却下（rejected）	0

重要度の内訳: critical 0 / major 1 / minor 1 / nit 0

対応した指摘

1. major / 正確性（codex、issues/PLAN66_project-name-validation-design.md）— env import の警告文と改名案内を保存先に応じた契約へ変更。知らせを出す位置を _build_plans が返した plans を回す形にし、文を plan.target と plan.ref から選ぶ契約に。ファイル backend の平文だけ projects/_foo/ の作成と改名案内を書き、age・サーバ backend は保存先を名指しして改名案内を書かない。受け入れ条件 9（age backend で projects/_foo/ を作らず secrets/projects/_foo.env.age を書く）を新設し、旧 9〜16 を 10〜17 へ繰り下げ。
2. minor / 整合性（kiro、issues/PLAN66_project-name-validation.md）— 受け入れ条件（繰り下げ後の 11）の拒否リストへ abc\n を足して 8 件に揃え、受理も 4 件と明記。設計の決定 6 とテスト設計の該当行に「受け入れ条件 11 の列挙と同じ集合」と記載して両文書を一致させた。

Resolve 状況

• Resolve した thread: 2 件（round 2 の 2 件）
• 未解決 thread: 0 件

CI

CI は未実行です。この PR は base が release/v3.7.0 のため CI が動きません（#216）。本 PR は設計文書のみの変更で、コードの変更はありません。

[takemi-ohama]

🤖 cross-review | round 3 | codex | APPROVE

要求仕様・設計と現行実装を照合し、修正を求める指摘はありません。

[takemi-ohama]

🤖 cross-review | round 3 | agy | REQUEST_CHANGES

ラウンド 2 での指摘対応（age/サーバ backend 保存時の警告分岐、末尾改行を含むスナップショット名拒否パターンの統一、受け入れ条件の追加）が適切に反映されていることを確認しました。

本ラウンドでは、テスト設計における fixture の前提条件の不一致（major 1 件）および文書・設計の整合性・明確化（minor 4 件）についてインラインコメントで指摘しています。

[takemi-ohama]

round 3 のレビュー指摘への対応（5 件すべて反映）

コミット: 5233da4 docs(PLAN66): round 3 のレビュー指摘を反映する (#203)（push 済み）

内訳

区分	件数
対応 (fixed)	5
見送り (deferred)	0
却下 (rejected)	0

重要度: critical 0 / major 1 / minor 4 / nit 0

対応した指摘

#	重要度 / 観点	指摘	対応
1	major / テスト設計	受け入れ条件 9 の検証が tests/env/test_store_roundtrip.py の fixture を参照しているが、そこでは backend が age に明示されておらず新規参照が平文へ落ちる	前提を「backend_config に backend: age を明示保存した root」へ変更し、検証先を既存の tests/cli/test_env_bundle_backend.py（test_import_into_an_explicit_age_backend_encrypts_new_references と同じ形）へ変更。テスト設計の 9 の行に平文へ落ちる旨を明記、退行しないことの一覧と要求仕様のテスト戦略にも age の流儀を追記
2	minor / 設計整合性	_warn_unusable_name の改名案内が、出所が別名や実ディレクトリのとき実態と矛盾する	警告の文のテンプレート末尾を <出所ごとの案内> にし、出所ごとの案内の表を追加（プラグインのプロジェクト / 別名 / 実ディレクトリ）。別名は devbase が合成しているためプラグイン側の projects/ を改名しても直らないことを明記し、契約に source を案内の選択に使うと記載
3	minor / 要件定義	機能表の F2 が「projects/<name>/ を作るとき」で、決定 4・受け入れ条件 9 の age／サーバ保存と食い違う	F2 を「保存先に応じた内容で 1 行知らせる（平文 projects/<name>/ / age secrets/projects/<name>.env.age / サーバ backend はサーバ側）」へ変更。用語「名前を作る経路」の定義も projects/ 直下か機密の置き場に出現させる処理へ改め、前提 6 を参照させた
4	minor / 実装設計	real_projects は set なのでソートせずに走査すると警告の順が非決定になる	sync_projects の行に sorted(real_projects) で走査すると明記（既存の sorted(project_candidates.items()) と同じ扱い）。処理の流れの図の loop も sorted(real_projects) の名前ごと へ変更
5	minor / 文書整合性	前提の番号が 4 → 6 → 5 の順	前提 5 と前提 6 の順序を入れ替えて昇順に修正

thread の状態

• 返信・Resolve: round 3 の 5 件すべて（thread 合計 11 件 = round 1 の 4 件 + round 2 の 2 件 + round 3 の 5 件）
• 未解決の thread: 0 件

CI

未実行です（#216）。この PR は base が release/v3.7.0 のため CI が動きません。また本 PR は issues/ 配下の設計文書のみの変更で、実装コードの差分はありません。

[takemi-ohama]

🤖 cross-review | round 4 | kiro | APPROVE

設計・要求ともコード（syncer.py / io_import.py / _import_merge.py / secret_store.py / snapshot/manager.py / utils/names.py / ci.yml）と照合し、参照シンボル・行番号・正規表現の挙動・NAME_FORM_HINT の文言一致・保存先分岐（plan.target+plan.ref で平文/age/サーバの 3 経路を過不足なく判別できること）まで確認した。修正を要する不整合は見つからなかった。

[takemi-ohama]

🤖 cross-review | round 5 | codex | REQUEST_CHANGES

別名の改名案内について、修正を求める指摘が 1 件あります。

[takemi-ohama]

cross-review round 5 対応サマリ

round 5 のレビュー指摘 1 件へ対応しました。反映コミットは bed1fea（docs(PLAN66): round 5 のレビュー指摘を反映する (#203)、push 済み）です。設計文書のみの修正です。

内訳

区分	件数
対応 (fixed)	1
見送り (deferred)	0
却下 (rejected)	0

重要度: critical 0 / major 0 / minor 1 / nit 0

対応した指摘

#	ファイル	重要度 / 観点	指摘	対応
1	issues/PLAN66_project-name-validation-design.md	minor / 正確性	別名の案内が、元のプロジェクト名が不正な場合と <owner> が不正な場合を区別していない。_foo.valid-owner はプラグイン側の _foo を改名すれば直るのに、すべての別名に「プラグイン側を改名しても直らない」と断定している	警告の文の出所の表で別名の行を 2 つに分けた。<名前> の側が形に合わないときはプラグイン側の projects/<名前> の改名を案内し、<名前> は形に合うとき（= <owner> の側が原因）だけ「プラグイン側を改名しても直らない」と書く。分かれ目が is_single_segment_name(<名前>) で決まることを明記し、_warn_unusable_name の契約へ base 引数を追加。受け入れ条件 3 を <owner> の側の確認に書き換え、3-2 として <名前> の側（_foo の衝突で警告 2 行、案内がプラグイン側の projects/_foo を指す）を追加。テスト設計の表にも 3 / 3-2 の 2 行を置いた

Resolve と残り

• Resolve した thread: 1 件
• PR 全体の未解決 thread: 0 件

CI

CI は未実行です。base が release/v3.7.0 のままだと動かないため（#216）。

[takemi-ohama]

🤖 cross-review | round 6 | kiro | APPROVE

設計・要求のみの PR。コードは含まない。差分の技術的な主張（syncer.py:155-157 の unlink→張り直し、env/runtime.py:119 の相対パス解決、secret_store.py:294-299 の age 保存先、io_import.py:220 の store.path(ref)、is_single_segment_name の fullmatch と _VALID_NAME_RE の match+$ の差、_PROJECT_ENV_RE の構築、規則 6 か所と _GROUP_NAME_RE の存在、行数指標 設計 429 / 要求 326）を実コードと照合し、いずれも一致した。2 文書間の前提・決定・受け入れ条件・実装分割（PR1/PR2）の対応にも矛盾は無く、範囲外項目は #226〜#229 として起票済み。実装者を誤らせる誤記・不整合・矛盾する指示は見つからなかったため、修正アクションの指摘は無い。