何を見つけたか
devbase build <image> の <image> が $DEVBASE_ROOT/projects/ に実在する名前と一致すると、bin/devbase の先頭にある name 解決がその引数をプロジェクト名として消費します。イメージ指定が消え、そのプロジェクトの compose ビルドへ化けます。
現在の該当は bi-tools です（projects/bi-tools と containers/bi-tools が両方実在します）。
docker と compose_with_secrets をスタブ化して bin/devbase の dispatch だけを実行した結果:
$ devbase build bi-tools --no-cache
DOCKER:buildx build --load -t devbase-base:latest <ROOT>/containers/base --no-cache
COMPOSE:docker compose build dev --no-cache
Shell cwd was reset to <ROOT>
containers/bi-tools は一度もビルドされず、projects/bi-tools の compose ビルドが走っています。エラーも警告も出ません。
どこで見つけたか
bin/devbase の name 解決（_NAME_RESOLVABLE_SHORTCUTS に build が含まれる箇所と、その直前のコメント）。#139 の設計中に、devbase build <image> が全イメージで動くかを確認して気づきました。
bin/devbase のコメントは、この挙動を「トップレベル build/login/scale を『そのプロジェクトを操作』と解釈する意図的設計（存在性ベース判定）のトレードオフであり、挙動としては仕様である」と明記しています。つまり既知です。ただし login の index 衝突と違い、build は同名のディレクトリが containers/ と projects/ の両方に実在するため、衝突が偶発ではなく構造的に起きます。
なぜこの変更の範囲外なのか
#139 の受け入れ条件は、位置引数が docker へそのまま渡って失敗する不具合の修正です。name 解決の設計そのものは触りません。issues/old/PLAN49_build-image-argument.md の「前提 2」で現行挙動の維持を明示し、「対象範囲（含まない）」にも入れています。
直さないと何が起きるか
containers/bi-tools をトップレベルの devbase build bi-tools からビルドできません。逃げ道は devbase project build bi-tools です（project build の位置引数は name 解決の対象外のため）。
黙って別のものをビルドするため、利用者は成功したと思ったまま古いイメージを使い続けます。今後 containers/ と projects/ に同名が増えるたびに同じことが起きます。
対処の候補:
- 衝突時に警告を出し、どちらとして解釈したかを表示する
containers/<image> が実在する場合は build を name 解決の対象から外す--image のような明示フラグを足す
由来
issue #139
進行
モード: standard / 作業ツリー: .worktrees/fix/plan61-name-resolution / 計画: issues/PLAN61_name-resolution.md
何を見つけたか
devbase build <image>の<image>が$DEVBASE_ROOT/projects/に実在する名前と一致すると、bin/devbaseの先頭にある name 解決がその引数をプロジェクト名として消費します。イメージ指定が消え、そのプロジェクトの compose ビルドへ化けます。現在の該当は
bi-toolsです（projects/bi-toolsとcontainers/bi-toolsが両方実在します）。dockerとcompose_with_secretsをスタブ化してbin/devbaseの dispatch だけを実行した結果:containers/bi-toolsは一度もビルドされず、projects/bi-toolsの compose ビルドが走っています。エラーも警告も出ません。どこで見つけたか
bin/devbaseの name 解決（_NAME_RESOLVABLE_SHORTCUTSにbuildが含まれる箇所と、その直前のコメント）。#139 の設計中に、devbase build <image>が全イメージで動くかを確認して気づきました。bin/devbaseのコメントは、この挙動を「トップレベル build/login/scale を『そのプロジェクトを操作』と解釈する意図的設計（存在性ベース判定）のトレードオフであり、挙動としては仕様である」と明記しています。つまり既知です。ただしloginの index 衝突と違い、buildは同名のディレクトリがcontainers/とprojects/の両方に実在するため、衝突が偶発ではなく構造的に起きます。なぜこの変更の範囲外なのか
#139 の受け入れ条件は、位置引数が
dockerへそのまま渡って失敗する不具合の修正です。name 解決の設計そのものは触りません。issues/old/PLAN49_build-image-argument.mdの「前提 2」で現行挙動の維持を明示し、「対象範囲（含まない）」にも入れています。直さないと何が起きるか
containers/bi-toolsをトップレベルのdevbase build bi-toolsからビルドできません。逃げ道はdevbase project build bi-toolsです（project buildの位置引数は name 解決の対象外のため）。黙って別のものをビルドするため、利用者は成功したと思ったまま古いイメージを使い続けます。今後
containers/とprojects/に同名が増えるたびに同じことが起きます。対処の候補:
containers/<image>が実在する場合はbuildを name 解決の対象から外す--imageのような明示フラグを足す由来
issue #139
進行
モード: standard / 作業ツリー:
.worktrees/fix/plan61-name-resolution/ 計画:issues/PLAN61_name-resolution.md