[Feature]: `winapp new` command to scaffold new projects

[Jaylyn-Barbee]

Is your feature request related to a problem? Please describe.

There is no first-class way to create a new WinUI app from the winapp CLI. Today a developer (or agent) has to install and discover the right templates, scaffold with dotnet new, and wire up Windows packaging/identity by hand. WinUI is not on by default in the .NET toolchain, so onboarding has real friction — exactly what winapp should smooth over.

WinUI now has official dotnet new templates (Microsoft.WindowsAppSDK.WinUI.CSharp.Templates: winui, winui-navview, winui-tabview, winui-mvvm, winui-lib, winui-unittest) that work without Visual Studio. What's missing is a single, opinionated winapp new that gets you from nothing to a running WinUI app in one step.

Scope (per spec review, 2026-07-15): v1 is WinUI-only. winapp new creates a new WinUI app and is the recommended/default Windows app experience. Support for other frameworks (Tauri, Electron, Flutter, Rust) is deferred and revisited if customer demand warrants — the design leaves a clean seam for it.

Current state

• No new/scaffold command exists in winapp today.
• WinUI is scaffolded via the external dotnet new template pack (preview, WASDK-owned: dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates) — not surfaced through winapp.
• Windows packaging/identity (winapp init) is a separate manual step after creation.

Describe the solution you'd like

Add a top-level winapp new command that creates a new WinUI app with a unified, opinionated experience. Its help/description makes clear it creates a WinUI application.

• Interactive picker — choose the WinUI template (blank / navigation view / tab view / MVVM / class library / unit test), then details (name, output, optional "set up Windows packaging/identity" step). Mirrors how winapp init works (interactive by default; auto-defaults in non-interactive environments).
• Non-interactive / agent mode — every prompt has a flag equivalent (plus --use-defaults), with deterministic, machine-readable output for one-shot scaffolding — same pattern as init.
• Wrap the official templates — winapp new owns the orchestration + UX; the dotnet new WinUI pack owns the file scaffolding. No new template content authored here.
• Extensible — leave a clean seam for authoring modes (XAML now, Reactor later) and, if demand warrants, additional frameworks — without reworking the command.

Proposed architecture (for review)

winapp new is a thin orchestration layer: it does not author templates or reimplement packaging. It resolves inputs, delegates scaffolding to the official WinUI dotnet new templates, then optionally runs winapp init:

winapp new
  ├─ 1. resolve inputs (interactive picker  OR  flags / --use-defaults for agents)
  ├─ 2. scaffold → dotnet new <winui template>   (official WASDK WinUI template pack)
  └─ 3. (optional) winapp init → manifest, SDK packages, projections

• Ownership split: winapp new owns input resolution + UX + orchestration; dotnet new owns scaffolding. No new scaffolding or packaging logic is introduced.
• Consistency: mirrors winapp init (interactive/non-interactive) and winapp run (thin wrapper over the .NET toolchain) — a consistent winapp pattern.
• WinUI template pack is an external preview dependency (WASDK-owned); winapp installs/manages it on demand.
• Prerequisite handling: requires .NET installed; if missing, fail fast with a clear, actionable message + guide link rather than a raw error. winapp does not install toolchains itself.

Work breakdown

• P0 winapp new orchestration + UX: WinUI template picker, non-interactive/--use-defaults agent mode (mirrors init), and .NET prerequisite detection.
• P0 WinUI scaffolding — delegate to the official dotnet new WinUI templates.

Open questions

• Command/flag surface for the WinUI picker + non-interactive flags (align with init's conventions).
• Pin the WinUI template pack version vs follow latest (it's preview + externally owned).
• Authoring mode as a level: WinUI → mode {XAML, Reactor} → template (Reactor deferred).
• winapp init chaining: prompted, opt-in flag, or default-on?

Additional context

Deferred (revisit on customer demand)

• Reactor authoring mode (added as a second authoring mode under WinUI).
• Additional frameworks (Tauri, Electron, Flutter, Rust) — delegate to each native scaffolder (npm create tauri-app, npm create electron-app, flutter create, cargo new). Not in v1 scope.