feat: non-DW blueprint setup and config-free provisioning via --agent-name

.claude/agents/pr-code-reviewer.md

@@ -688,6 +688,73 @@ When a block of code — a method body, a collection initializer, a sequence of
 
 **Real example (from `users/sellak/blueprintScopes`):** `AllSubcommand.cs`, `AdminSubcommand.cs`, and `PermissionsSubcommand.cs` each contained an identical three-entry block for Bot API, Observability API, and Power Platform API. When `Agent365.Observability.OtelWrite` was added, the new scope had to be written in three places — and would have been missed without manual cross-file inspection. Extracted to `SetupHelpers.GetFixedApiPermissionSpecs(bool setInheritable)`.
 
+### 23. Unconditional Success Log After Multiple Fallible Operations
+
+A success or completion log message is emitted unconditionally after a sequence of independent operations that each have their own `if (!ok)` warning branches. The final message claims the whole step succeeded regardless of which individual operations failed.
+
+- **Pattern to catch**:
+  - A sequence of: `var aOk = await DoA(...); if (!aOk) LogWarning(...); var bOk = await DoB(...); if (!bOk) LogWarning(...); LogInformation("completed successfully");`
+  - The success log appears at the end without checking `aOk && bOk` — it fires even if every preceding operation returned false
+  - Common in multi-grant admin consent flows, multi-step provisioning, and batch operations
+- **Severity**: `high` — users see "completed successfully" in the terminal while one or more required operations silently failed; they have no indication follow-up action is needed
+- **Check**: For every `LogInformation("...success..." or "...completed...")` in the diff, scan backwards to find all `bool`-returning async calls in the same block. Verify each outcome variable is included in a combined guard before the success log.
+- **Fix**: Accumulate outcomes and gate the success log:
+  ```csharp
+  var aOk = await DoA(...);
+  if (!aOk) logger.LogWarning("A failed.");
+  var bOk = await DoB(...);
+  if (!bOk) logger.LogWarning("B failed.");
+
+  if (!aOk || !bOk)
+  {
+      logger.LogError("Step completed with errors. One or more operations failed and follow-up action is required.");
+      throw new InvalidOperationException("Step did not complete successfully for all operations.");
+  }
+  logger.LogInformation("Step completed successfully.");
+  ```
+- **Real example** (`CreateInstanceCommand.cs`): Three separate `CreateOrUpdateOauth2PermissionGrantAsync` calls (MCP scopes, Bot API, Observability API) each had their own `LogWarning` on failure, but a single `LogInformation("Admin consent granted ... completed successfully")` was always emitted at the end. Fixed by computing `adminConsentGrantOk = mcpGrantOk && botApiGrantOk && observabilityApiGrantOk` and throwing if false.
+
+### 24. Expensive Unconditional Startup Code Before Command Dispatch
+
+An HTTP call, token acquisition, subprocess spawn, or other expensive/network-dependent operation runs unconditionally in startup — before `parser.InvokeAsync(args)` and before the user's chosen command is even parsed. This adds latency to every invocation (including `--help`, `--version`, and offline/CI scenarios) and can fail in environments without network access even when the command doesn't require it.
+
+- **Pattern to catch**:
+  - Any `await SomeService.NetworkCallAsync(...)` in `Program.cs` (or equivalent startup file) between `services.BuildServiceProvider()` and `parser.InvokeAsync(args)`
+  - Calls to `configService.TryResolveXxx(graphApiService)`, `graphApiService.AnyMethodAsync(...)`, or `AzCliHelper.*` that are NOT inside a command handler lambda
+  - The call is not guarded by a check of whether the command actually needs the result
+- **Severity**: `medium` — noticeable latency on every invocation; breaks offline/CI scenarios; especially bad for interactive developer workflows where `a365 --help` should be instant
+- **Fix**: Guard with a check of the args array to skip for informational invocations, or move the call inside the command handlers that actually need it:
+  ```csharp
+  // Skip for help, version, and empty invocations — must work offline
+  var isHelpOrVersion = args.Length == 0 || args.Any(a => a is "--help" or "-h" or "--version");
+  if (!isHelpOrVersion)
+  {
+      try { await configService.TryResolveClientAppIdAsync(graphApiService); }
+      catch (Exception ex) { logger.LogDebug(ex, "Pre-resolution skipped: {Message}", ex.Message); }
+  }
+  ```
+  Alternatively, move the call into a `System.CommandLine` middleware so it runs lazily only when a command handler needs it.
+- **Real example** (`Program.cs`): `TryResolveClientAppIdAsync` was called unconditionally before `parser.InvokeAsync(args)`, causing a Graph API call + az token acquisition on every invocation including `a365 --help`. Fixed by guarding with `isHelpOrVersion`.
+
+### 25. Validation Rule Change in Model Not Mirrored in Service-Layer Validator
+
+When a required-field check is added, removed, or relaxed in a model's `Validate()` method, the same change is almost always needed in the service-level `ValidateAsync()` method — and vice versa. Failing to update both is the root cause of "fixed in one place but still broken in the other" bugs.
+
+- **Pattern to catch**:
+  - A diff removes (or adds) a `ValidateRequired(...)` call, or an `if (string.IsNullOrWhiteSpace(...))` guard, inside any `Validate()` method on a model class
+  - The diff does NOT also touch the service-level validator (`ConfigService.ValidateAsync`, or any method named `ValidateAsync` that takes the same model type)
+- **Severity**: `high` — the fix is incomplete; the rule will still fire (or fail to fire) via the other path
+- **Check**: For every model-level validation change in the diff, run `Grep` for the same field name + `"is required"` or `ValidateRequired` in `ConfigService.cs`. If the service-level validator has the same rule and the diff doesn't touch it, flag it.
+- **Fix**: Apply the same change in both validators, or — better — consolidate so `ConfigService.ValidateAsync` calls `config.Validate()` for required-field rules and only adds format checks on top:
+  ```csharp
+  // ConfigService.ValidateAsync — required-field rules delegated to the model
+  var errors = new List<string>(config.Validate());
+  // Format-only checks follow...
+  if (!string.IsNullOrWhiteSpace(config.TenantId))
+      ValidateGuid(config.TenantId, nameof(config.TenantId), errors);
+  ```
+- **Real example**: Removing `"messagingEndpoint is required when needDeployment is 'no'."` from `Agent365Config.Validate()` without removing the parallel `ValidateRequired(config.MessagingEndpoint, ...)` call in `ConfigService.ValidateAsync`. The fix appeared in `Agent365ConfigTests.cs` and `Agent365Config.cs` but not in `ConfigService.cs`, so `a365 cleanup` still failed with `MessagingEndpoint is required` on bootstrap-path projects.
+
 ## Example Invocation
 
 When you receive a request like "Review PR #253", you should:

.claude/skills/review-staged/README.md

@@ -56,6 +56,7 @@ The skill analyzes:
 - **Security**: Secrets, input validation, error handling
 - **Standards**: Coding conventions, file organization
 - **Context**: CLI vs GitHub Actions (different standards apply)
+- **Full file content**: Every staged file is read in full — not just the changed lines. This catches issues in unchanged sections such as duplicate hardcoded values, parallel code structures that should use a shared helper, or dead code that the diff didn't touch.
 
 ## Review Severity Levels
 

.claude/skills/review-staged/SKILL.md

@@ -109,9 +109,15 @@ The skill uses **Claude Code directly** for semantic code analysis (same as revi
 2. Claude Code reads `.github/copilot-instructions.md` for coding standards
 3. Claude Code gets staged files: `git diff --staged --name-only`
 4. Claude Code gets staged changes: `git diff --staged`
-5. Claude Code performs semantic analysis using its own capabilities
-6. Claude Code identifies specific issues with line numbers and code references
-7. **Claude Code runs the full test suite with per-test timing:**
+5. **Claude Code reads the complete current content of every staged file** (not just diff lines) to enable full-file semantic analysis. This is critical for catching issues that exist in unchanged sections of modified files, such as:
+   - Duplicate hardcoded constants or magic values that already exist elsewhere
+   - Parallel code structures that should be consolidated (e.g., a method building the same spec list as a shared helper)
+   - Unused or dead code that was already there but not touched by the diff
+   - Missing calls to shared helpers — where the diff adds a new use but existing code still has the old duplicate pattern
+   For each file path returned in step 3, Claude Code must `Read` the full file before performing analysis.
+6. Claude Code performs semantic analysis using its own capabilities
+7. Claude Code identifies specific issues with line numbers and code references
+8. **Claude Code runs the full test suite with per-test timing:**
    ```bash
    cd src && dotnet test tests.proj --configuration Release --logger "console;verbosity=normal" 2>&1
    ```

.gitignore

@@ -1,5 +1,11 @@
 # Internal working documents
 docs/plans/
+docs/Permissions-Review.md
+docs/Testing.md
+scripts/skills/
+
+# IDE launch profiles (developer-specific)
+**/Properties/launchSettings.json
 
 ## A streamlined .gitignore for modern .NET projects
 ## including temporary files, build results, and

CHANGELOG.md

@@ -37,13 +37,19 @@ a365 setup admin --config-dir "<path-to-config-dir>"
 - `a365 cleanup azure --dry-run` — preview resources that would be deleted without making any changes or requiring Azure authentication
 - `AppServiceAuthRequirementCheck` — validates App Service deployment token before `a365 deploy` begins, catching revoked grants (AADSTS50173) early
 - `a365 setup admin` — new command for Global Administrators to complete tenant-wide AllPrincipals OAuth2 permission grants after `a365 setup all` has been run by an Agent ID Admin
+- `setup all --agent-name <name>` — config-free non-DW setup. No `a365.config.json` required. TenantId is auto-detected from `az account show`; ClientAppId resolved by finding an Entra app registration named `"Agent 365 CLI"` in the tenant.
+- `setup all --tenant-id <id>` — override tenant auto-detection when using `--agent-name`.
+- `cleanup --agent-name <name>` — config-free cleanup. No `a365.config.json` required. Loads resource IDs from the global generated config written by bootstrap setup. Tenant ID is auto-detected from `az account show` or overridden with `--tenant-id`.
 - MCP V1/V2 migration support — `a365 setup permissions mcp` and `a365 setup blueprint` now handle mixed manifests containing both V1 (`McpServers.*.All` / ATG audience) and V2 (`Tools.ListInvoke.All` / per-server audience) entries; scopes are written additively to the blueprint so agents on either SDK version continue to work
 - `--remove-legacy-scopes` flag for `a365 setup permissions mcp` — removes shared ATG audience scopes from the blueprint once V2 SDK is confirmed live across all agents
 - `a365 develop get-token` now acquires one token per audience when using manifest-based scope resolution — V2 entries receive a token scoped to their specific server AppId, V1 entries continue to use the shared ATG AppId
 - `a365 develop get-token` now writes per-server bearer tokens to `.env` (Python/Node.js) and `launchSettings.json` (.NET) — V2 servers are written as `BEARER_TOKEN_<SERVER_NAME>` (e.g. `BEARER_TOKEN_MCP_WORDSERVER`), V1 shared-audience token continues to be written as `BEARER_TOKEN` for backward compatibility; local dev samples can now run correctly with V2 multi-audience manifests without needing agentic auth
 - `a365 setup permissions mcp --remove-legacy-scopes --dry-run` now shows both what would be removed (shared ATG audience entries) and what would remain after removal, instead of only showing what would be configured
 
 ### Changed
+- `setup all --dry-run` output is now column-aligned for readability
+- `setup infrastructure` now defaults `deploymentProjectPath` to the current directory when not specified in config
+- `setup all` now defaults to the non-AI Teammate (blueprint) flow. Use `--aiteammate true` to run the Digital Worker (AI Teammate) setup flow.
 - `a365 setup blueprint` now sets `managerApplications` on the blueprint application to enable platform manageability. After May 1, blueprints without `managerApplications` will no longer be accepted, and must be recreated (delete and re-run `a365 setup blueprint`) or manually patched via Graph API to include this value.
 - `New-Agent365ToolsServicePrincipalProdPublic.ps1` updated to support MCP V1 and V2 provisioning — adds `-Mode` (`V1`/`V2`/`All`, default `All`), `-ManifestPath` (auto-extracts V2 per-server AppIds from `ToolingManifest.json`), and `-V2AppIds` (explicit list) parameters; script is now idempotent across all AppIds (re-run safe) and covers the migration period where V1 and V2 servers coexist in the same tenant
 - `a365 publish` updates manifest IDs, creates `manifest.zip`, and prints concise upload instructions for Microsoft 365 Admin Center (Agents > All agents > Upload custom agent). Interactive prompts only occur in interactive terminals; redirect stdin to suppress them in scripts.
@@ -64,6 +70,7 @@ a365 setup admin --config-dir "<path-to-config-dir>"
 - macOS/Linux: device code fallback when browser authentication is unavailable (#309)
 - Linux: MSAL fallback when PowerShell `Connect-MgGraph` fails in non-TTY environments (#309)
 - Admin consent polling no longer times out after 180s — blueprint service principal now resolved with correct MSAL token (#309)
+- `a365 cleanup --agent-name` no longer stalls — interactive browser auth failure in embedded terminals now automatically falls back to device code flow (same as Conditional Access fallback)
 - `ConfigFileNotFoundException` now derives from `FileNotFoundException` so existing catch sites continue to work (#309)
 - `a365 develop list-available` no longer displays `Required Scope: null` for servers that return a `"null"` string scope from the V2 catalog endpoint
 - `a365 develop add-mcp-servers` no longer writes the literal string `"null"` as a scope value in `ToolingManifest.json` when the V2 catalog returns `"scope": "null"` — the field is omitted, allowing correct fallback to name-based scope mapping

docs/agent365-guided-setup/README.md

@@ -0,0 +1,48 @@
+# Agent 365 Guided Setup — Index
+
+> **If you are a coding agent (Claude Code, GitHub Copilot, Devin, or similar):**
+> Read this file first, identify the task below, then **immediately open and follow ONLY the linked instruction file**. Open **one file only** — do NOT read both instruction files. Do NOT explore the codebase, fetch web pages, or run commands until you have read the instruction file. The instruction file is your complete guide.
+
+---
+
+## Which file do I need?
+
+### "Make my agent A365 compliant" / "Set up my agent for Agent 365" / "Run agent setup"
+
+**→ Open and follow: [a365-setup-instructions.md](a365-setup-instructions.md)**
+
+Use this file when the user asks to:
+- Make an agent A365 compliant
+- Set up, provision, or configure an agent for Agent 365
+- Run `a365 setup` or provision Azure / Entra resources
+- Deploy an agent application
+
+### "Add observability to my agent" / "Set up logging / telemetry / tracing"
+
+**→ Open and follow: [a365-observability-instructions.md](a365-observability-instructions.md)**
+
+Use this file when the user asks to:
+- Add observability, telemetry, logging, or tracing to their agent
+- Integrate OpenTelemetry or the Agent 365 observability stack
+- Monitor agent activity or usage
+
+---
+
+## If the intent is unclear
+
+If the user's request matches more than one category, or you are unsure, ask:
+
+> "Are you looking to (1) set up your agent for Agent 365 compliance, or (2) add observability/telemetry to an existing agent?"
+
+Wait for the answer, then open the appropriate file above.
+
+---
+
+## What NOT to do
+
+- Do NOT open both instruction files. Open the one file that matches the task and follow it exclusively.
+- Do NOT treat "make my agent A365 compliant" as including observability. Setup and observability are separate tasks with separate instruction files.
+- Do NOT glob, search, or read files in the broader repository before reading the instruction file.
+- Do NOT fetch external URLs or documentation before reading the instruction file.
+- Do NOT ask clarifying questions beyond the one above if the intent is clear.
+- Do NOT start writing code or running commands until the instruction file tells you to.