A review comment on #1027 raised a concern that introducing `instance_architecture` could cause working instance name collisions when the same platform is built with different architectures (e.g. via `CRAFT_BUILD_ON`). A follow-up question asked whether craft-providers already addresses this via architecture-aware instance naming. ## Findings After reviewing [`lxd_provider.py`](https://github.com/canonical/craft-providers/blob/2a25ff8ac8ededaa35a0f12c0393a34257c815d9/craft_providers/lxd/lxd_provider.py) and `launcher.py`: - **Base instance names** (`base-instance-{tag}-{remote}-{image_name}`) **do** embed architecture, since `image_name` is set to `"{image}/{arch}"` when `instance_architecture` is provided. - **Working instance names** are passed through unchanged from craft-application — architecture is not appended by craft-providers. - Name collisions on working instances are **already mitigated** by `auto_clean=True`: if `launch()` finds an existing instance that fails the compatibility warmup (e.g. wrong arch), it deletes it and rebuilds from the correct arch-specific base instance. ## Conclusion No changes to `_get_instance_name` are needed. The concern is handled gracefully at the craft-providers layer. <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/canonical/craft-application/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo.