[Initiative] 🏗️ App model for Azure

## Problem statement

Azure developers use a rich set of tools: CLIs, IDE extensions, dashboards, and infrastructure-as-code providers. Today, each has its own install path, UX patterns, and update cadence. There's an opportunity to tie these together into a more cohesive experience.

For example, `azd tool` can give developers a single command to discover and install everything they need, instead of following multi-page setup guides. A redesigned `azd init` can offer smarter template selection and let extensions participate in the flow. A lightweight local dashboard can show deployed services and health without switching to the Azure Portal. And Terraform users can get first-class support through the extension model.

This scope is the developer experience layer: the tools, surfaces, and UX patterns that make Azure development feel like one product instead of a dozen.

## Vision

Azure developers have a seamless platform experience: one command to set up their toolchain, a consistent UX across every `azd` interaction, local visibility into their running apps, IDE extensions that build on `azd` instead of duplicating it, and infrastructure-as-code support that meets developers where they are.

## Who this helps

- **Developers setting up a new environment** can run `azd tool` and get a guided walkthrough of what's installed, what's missing, and how to get it. No more following multi-page setup guides.
- **Developers running `azd init` for a new project** get a smarter experience: better template selection, collision detection, and the ability for extensions to participate in the init flow.
- **Developers who just ran `azd up`** can see their deployed services, resource health, and logs in a local dashboard without opening the Azure Portal.
- **VS Code extension teams** can use `azd` as the resource creation layer instead of maintaining their own ARM/Bicep calls, which means consistent behavior across extensions.
- **Terraform users** get improved `azd` support (through the extension model with community ownership of the Terraform-specific implementation?).

## Goals (in scope)

- Ship `azd tool` as the unified entry point for Azure developer tooling
- Redesign the `azd init` experience with smarter defaults, agentic flows, and published UX guidelines
- Prove the VS Code re-platforming model with a PoC extension using `azd` for resource creation
- Deliver a local view for app resources and status
- Move Terraform support into the extension model via provisioning providers

## Non-goals (out of scope)

- Building a package manager; leverage native installers (winget, brew, apt)
- Full re-platform of all VS Code extensions; this is PoC scope
- Building a custom local view from scratch; evaluate existing options first
- Feature parity between Terraform and Bicep in core `azd`
- Owning ongoing Terraform or VS Code extension-side maintenance; community and partner teams own that

## Success criteria

- [ ] `azd tool` ships with discover, install, and manage commands across Windows, macOS, and Linux
- [ ] `azd init` redesign ships with smarter template selection and agentic init; UX guidelines published
- [ ] At least one VS Code extension PoC validates `azd` as the resource creation layer
- [ ] Local view approach decided and lightweight version shipped or integration validated
- [ ] Terraform extension prototype runs on provisioning providers framework
- [ ] `azd tool` and first-run completion rates tracked and improving

## Dependencies

- **Extension framework GA**: Terraform extension and VS Code re-platform depend on stable extension APIs
- **`azd ai` GA**: Dashboard and init flows need to account for AI workloads
- **VS Code extension team**: Azure extension strategy change requires partnership and agreement from extension owners