プロジェクト名の検証の規則が env の export / import・機密の保存先・名前の指定で食い違う

[takemi-ohama]

何を見つけたか

プロジェクト名を検証する規則が、場所ごとに違います。

場所	規則	用途
lib/devbase/env/bundle.py の is_valid_project_name（_VALID_PROJECT_NAME_RE）	^[A-Za-z0-9_][A-Za-z0-9_.\-]*$。先頭に _ を許す	env の export / import の書庫の中の名前
lib/devbase/env/secret_store.py の _validate_project_name	空と、Path(name).name と一致しない値（区切り文字を含む）と、.・.. だけを弾く	機密の保存先のファイル名
lib/devbase/utils/names.py の SINGLE_SEGMENT_NAME_PATTERN	[A-Za-z0-9][A-Za-z0-9._-]*。先頭は英数字	名前の指定（devbase up <name> や TUI の一覧）
lib/devbase/snapshot/manager.py の _VALID_NAME_RE	^[a-zA-Z0-9][a-zA-Z0-9._-]*$	スナップショットの名前

3 つ目は名前の指定が通る入口で、container._resolve_project_name / cli._named_lifecycle_project / container._build_single_image / bin/devbase の maybe_cd_project が使います。bin/devbase の _SINGLE_SEGMENT_NAME_RE が同じ正規表現を文字列で持ち、一致は tests/cli/test_project_name_resolution.py::test_wrapper_name_regex_is_synced_with_python が固定しています。

3 つ目と 4 つ目は文字集合が同じで、別々の定数として 2 重に持っています。

_ 始まりのプロジェクトは、env の export / import はできますが、名前を指定した操作はできません。該当するプロジェクトは今のところ実在しません。

寄せないことは確定仕様になっている

docs/specifications/cli-argument-resolution.md の「運用」が、寄せない方を選んで確定しています。

名前の検証はリポジトリの中で 1 つに寄せていない。env/bundle.py の is_valid_project_name（先頭の _ を許す。env の export / import の書庫の中の名前）、env/secret_store.py の _validate_project_name（機密の保存先のファイル名）、snapshot/manager.py の _VALID_NAME_RE（スナップショットの名前）はそれぞれ別の用途と互換性を持つ。寄せると受け付ける名前が変わる範囲が広がるため、位置引数の解決はこの仕様の規則だけを使う

したがって「3 つの規則を 1 つへ寄せるか」は決着済みです。残っているのは、名前の形に合わないプロジェクトが作られるのを防ぐかどうかです。

修正レイヤー

現象レイヤー: 名前の指定の入口（bin/devbase の maybe_cd_project、lib/devbase/cli.py の _named_lifecycle_project、lib/devbase/commands/container.py の _resolve_project_name）。_foo という名前のプロジェクトが devbase up _foo で操作できない形で現れます。

修正レイヤー: 名前を作る側。lib/devbase/plugin/syncer.py の discover_projects / sync_projects が projects/ に名前を載せる唯一の入口で、今は . 始まりを外すだけで名前の形を検査していません。

def discover_projects(plugin_dir: Path) -> list[str]:
    ...
    return [d.name for d in sorted(projects_dir.iterdir())
            if d.is_dir() and not d.name.startswith('.')]

sync_projects も projects_dir / proj_name へ無検査で symlink を張ります。検証の下流を揃えるのではなく、生成の入口で弾くか警告するのが責務の場所です。入口で防げば、4 つの規則が違うままでも、名前の指定から操作できないプロジェクトは生まれません。

採る手: 移動（move_responsibility）。名前の形の責務を、使う側の検証からプラグインの同期へ移します。

決めること

• プラグインの同期（discover_projects / sync_projects）で名前の形を検査するか。弾くのか、警告に留めるのか
• utils/names.py の SINGLE_SEGMENT_NAME_PATTERN と snapshot/manager.py の _VALID_NAME_RE は文字集合が同じである。この 2 つだけを 1 つへ寄せるか。確定仕様が「寄せない」としたのは用途と互換性が違う 3 つについてで、この 2 つは同じ形をしている

見つけた場所: PLAN61（#146 / #142 / #196 / #200）の設計

進行

モード: standard / 作業ツリー: .worktrees/feature/v3.7.0-snapshot-name / 計画: issues/PLAN66_project-name-validation-impl2.md

• 要求と受け入れ条件 — 2026-09-22 12:12
• 作業場所の用意 — 2026-09-22 12:14
• 設計 — 2026-09-22 12:22
• 素材の収集と出典の確定
• ドキュメント再構成 — 2026-09-22 12:28
• ドキュメントレビュー — 2026-09-22 12:32
• 計画 — 2026-09-22 23:48
• 実装 — 2026-09-22 23:49
• 構造改善 — 2026-09-22 23:58
• 実装レビュー — 2026-09-23 00:23
• 完了判定 — 2026-09-23 00:43
• Pull Request — 2026-09-22 12:34
• 確定仕様化
• 後片付け — 2026-09-22 23:47
• 配布
• 体裁レビュー
• リリース後テスト
• 振り返り

[takemi-ohama]

PLAN66 の設計で範囲外と判断した 4 件を起票した: #226（plugin info の . 始まり）/ #227（env の書庫の名前が末尾の改行を通す）/ #228（別名の形が文書と実装で違う）/ #229（名前の形の文言を定数へ寄せる）。

[takemi-ohama]

構造改善（cross-refactoring、PR #233）は利用者の判断で途中で打ち切った（2026-09-23）。テスト追加のラウンド（570a2fe）までで終え、構造の変更は入れていない。570a2fe の全体テストは 2921 passed。進行の「構造改善」のチェックは打ち切りの時点のもの。