Merge latest code, remove immutable backups, update examples for mvu pvc

.github/CODEOWNERS

@@ -42,7 +42,7 @@
 /specification/asazure/ @athipp
 
 # PRLabel: %Authorization
-/specification/authorization/ @darshanhs90
+/specification/authorization/ @jruttle @abaccin @denyspanov-public @chocomochiko
 
 # PRLabel: %Automation
 /specification/automation/ @vrdmr
@@ -290,31 +290,32 @@
 ###########
 # Eng Sys
 ###########
-/.gitattributes     @weshaggard @mikeharder
-/.gitignore         @weshaggard @mikeharder
-/.prettierrc.json   @weshaggard @mikeharder
-/package-lock.json  @weshaggard @mikeharder
-/package.json       @weshaggard @mikeharder
-/tsconfig.json      @weshaggard @mikeharder
-/.azure-pipelines/  @weshaggard @mikeharder @benbp
-/.github/           @weshaggard @mikeharder @benbp
-/.vscode/           @weshaggard @mikeharder @benbp
-/dev/               @weshaggard @mikeharder @benbp
-/eng/               @weshaggard @mikeharder @benbp
+/.gitattributes     @mikeharder @benbp
+/.gitignore         @mikeharder @benbp
+/.prettierrc.json   @mikeharder @benbp
+/package-lock.json  @mikeharder @benbp
+/package.json       @mikeharder @benbp
+/tsconfig.json      @mikeharder @benbp
+/.azure-pipelines/  @mikeharder @benbp
+/.github/           @mikeharder @benbp
+/.vscode/           @mikeharder @benbp
+/dev/               @mikeharder @benbp
+/eng/               @mikeharder @benbp
 /eng/common/        @Azure/azure-sdk-eng
 /eng/tools/typespec-migration-validation @pshao25 @live1206
 /eng/tools/typespec-validation/**/sdk-tspconfig-validation*.ts @marygao @raych1 @maririos
-/scripts/           @weshaggard @mikeharder
-/specification/suppressions.yaml @weshaggard @mikeharder @benbp @raych1 @marygao @maririos @qiaozha
+/scripts/           @mikeharder @benbp
+/specification/suppressions.yaml @mikeharder @benbp @raych1 @marygao @maririos @qiaozha
 /.github/CODEOWNERS @Azure/azure-sdk-eng
 /.github/skills     @Azure/azure-sdk-eng @chunyu3 @lirenhe @ArthurMa1978 @haolingdong-msft
 
 ## Copilot
 
-/.github/copilot-instructions.md @praveenkuttappan @maririos
-/.github/prompts/                @praveenkuttappan @maririos
-/.github/instructions/           @praveenkuttappan @maririos
-/.github/chatmodes/              @praveenkuttappan @maririos
+/.github/copilot-instructions.md         @praveenkuttappan @maririos
+/.github/copilot-review-instructions.md  @ravimeda @praveenkuttappan
+/.github/prompts/                        @praveenkuttappan @maririos
+/.github/instructions/                   @praveenkuttappan @maririos
+/.github/chatmodes/                      @praveenkuttappan @maririos
 
 ## ARM API Reviewer
 
@@ -323,5 +324,10 @@
 /.github/skills/azure-api-review/       @raosuhas @ravimeda @laxmankumar12
 /documentation/api-reviewer-agent.md    @raosuhas @ravimeda @laxmankumar12
 
+## ARM API Modeling Reviewers
+
+/.github/arm-leases/     @raosuhas @tejaswiminnu @akhilailla @msevanhi 
+/.github/workflows/**/arm-*     @raosuhas @tejaswiminnu @akhilailla @msevanhi
+
 # Add owners for notifications for specific pipelines
 /eng/common/pipelines/codeowners-linter.yml

.github/agents/arm-api-reviewer.agent.md

@@ -1,3 +1,3 @@
 ---
 name: ARM API Reviewer
 description: Reviews Azure REST API specification PRs for conformance to Azure REST API Guidelines, ARM RPC rules, and repository conventions. Used by ARM API reviewers to review PRs in azure-rest-api-specs and azure-rest-api-specs-pr.
@@ -163,6 +163,14 @@
 
 **How to fetch previous versions:** Use GitHub MCP `get_file_contents` with `ref: "main"` (or the PR's base branch) to fetch files from the previous API version folder. To discover which prior version folders exist, use `get_file_contents` to list the directory (e.g., `specification/<service>/resource-manager/<ResourceProviderNamespace>/stable/`) on the base branch.
 
+**TypeSpec-required check (TSP-REQUIRED-V1).** While locating the previous version folder, also determine whether the PR is introducing a **new API version directory** (a directory under `specification/**/{resource-manager,data-plane}/**/{stable|preview}/<version>/` that does **not** exist on the base branch). If a new API version directory contains handwritten OpenAPI (`.json`) and **none** of the following compliance signals is present, record a **Blocking** finding for rule `TSP-REQUIRED-V1`:
+
+- A sibling TypeSpec project (a directory containing `main.tsp` and `tspconfig.yaml`) is present in the same service folder.
+- The new swagger file contains the `x-typespec-generated` extension at the top level.
+- The PR also adds or updates `.tsp` source files under the same service folder.
+
+Do **not** flag updates to files inside pre-existing API version directories, even when those files are handwritten OpenAPI. Do **not** flag PRs that only modify example files, `readme.md`, `tspconfig.yaml`, or `.tsp` files. The full rule definition is in [`openapi-review.instructions.md` §2A](../instructions/openapi-review.instructions.md). A deterministic CI check is in development (PR [#42823](https://github.com/Azure/azure-rest-api-specs/pull/42823)); until it ships, this agent rule is the primary enforcement point.
+
 ### Step 4: Systematic Review
 
 For each changed specification file, load the applicable instruction file(s) and work through **every item** in their review checklists. Do not skip sections.
@@ -306,10 +314,10 @@
    The existing comment already covers the exact same rule violation on the same file and line. **Skip posting.** No action needed.
 
    **Scenario B - Same finding, different line, comment was from _this agent or the same engineer running the agent_:**
-   The code has shifted (e.g., lines were added/removed) and the existing comment now points to an outdated line, but the violation still exists at a new location. **Resolve the outdated comment** (to reduce noise) and **post a new comment at the correct line** with the updated finding. In the new comment, reference the resolved thread (e.g., "_(Updated from previous comment at \<url\> - line shifted due to code changes.)_"). To identify whether an existing comment was posted by this agent, check if its body contains the hidden marker `<!-- posted-by: arm-api-reviewer-agent -->`. Comments with this marker are agent-posted; comments without it are from human reviewers (apply Scenario C instead).
+   The code has shifted (e.g., lines were added/removed) and the existing comment now points to an outdated line, but the violation still exists at a new location. **Resolve the outdated comment** (to reduce noise) and **post a new comment at the correct line** with the updated finding. In the new comment, reference the resolved thread (e.g., "_(Updated from previous comment at \<url\> - line shifted due to code changes.)_"). To identify whether an existing comment was posted by this agent, check if its body contains the substring `posted-by: arm-api-reviewer-agent`. Comments with this substring are agent-posted; comments without it are from human reviewers (apply Scenario C instead).
 
    **Scenario C - Same finding, different line, comment was from a _different_ human reviewer:**
-   Another ARM reviewer (not this agent) posted the comment at the old line -- i.e., the comment body does **not** contain `<!-- posted-by: arm-api-reviewer-agent -->`. Do **not** resolve their comment - it is their review thread and they may be tracking the conversation. Do **not** post a duplicate comment. Instead, **add a reply** to the existing thread noting the line shift: e.g., "_The code referenced by this comment has moved. The same violation now appears at `<file>` - line <N>. The issue is still unresolved._" This helps the author and reviewer find the right code without creating duplicate threads.
+   Another ARM reviewer (not this agent) posted the comment at the old line -- i.e., the comment body does **not** contain the substring `posted-by: arm-api-reviewer-agent`. Do **not** resolve their comment - it is their review thread and they may be tracking the conversation. Do **not** post a duplicate comment. Instead, **add a reply** to the existing thread noting the line shift: e.g., "_The code referenced by this comment has moved. The same violation now appears at `<file>` - line <N>. The issue is still unresolved._" This helps the author and reviewer find the right code without creating duplicate threads.
 
    **Scenario D - No new findings beyond what existing comments already cover:**
    If every finding from the current review is already covered by an existing comment (same file, same or nearby line, same rule), **do not post any new comments**. Report to the human reviewer: "_All findings from this review are already covered by existing comments on the PR. No new comments are needed - the existing threads already highlight the required changes._" List the existing comment threads that match, **including the comment URL** for each so the reviewer can click through and verify.
@@ -325,7 +333,22 @@
 5. Every posted comment **MUST** clearly tag the issue as `[NEW]` or `[EXISTING]` with an explanation of the classification (e.g., "This issue also exists in `2025-12-01-preview` at the same JSON path" or "Introduced in this PR - this property did not exist in the previous version").
 6. For `[NEW]` issues, include the severity level: `🔴 Blocking`, `🟡 Warning`, or `💡 Suggestion`.
 7. Use the format: ``**[NEW] 🔴 Blocking** **[<Rule ID>]** `<file-path>` - line <N> - <issue description>`` or ``**[EXISTING]** **[<Rule ID>]** `<file-path>` - line <N> - <issue description>`` followed by the classification reasoning and suggested fix.
-8. Every posted comment **MUST** end with the hidden HTML marker `<!-- posted-by: arm-api-reviewer-agent -->` as the very last line of the comment body. This marker is invisible in rendered markdown but enables querying agent-posted comments via the GitHub API and distinguishing them from manually posted comments during reconciliation. Do not omit this marker.
+8. Every posted comment **MUST** end with a hidden HTML telemetry marker as the very last line of the comment body. The marker format is:
+
+   ```html
+   <!-- posted-by: arm-api-reviewer-agent | rule: <RULE-ID> | severity: blocking|warning|suggestion | classification: new|existing -->
+   ```
+
+   - **`rule`**: The rule ID of the finding (e.g., `RPC-Put-V1-01`, `OAPI027`, `SEC-SECRET-DETECT`). Use `summary` for summary comments that don't flag a single rule.
+   - **`severity`**: One of `blocking`, `warning`, or `suggestion`.
+   - **`classification`**: One of `new` (introduced in this PR) or `existing` (pre-existing technical debt).
+
+   Example: `<!-- posted-by: arm-api-reviewer-agent | rule: RPC-Put-V1-11 | severity: blocking | classification: new -->`
+
+   This marker is invisible in rendered markdown but enables querying agent-posted comments via the GitHub API, computing telemetry (comments per day, top rule violations, new-vs-existing ratio), and distinguishing agent comments from human comments during reconciliation. Do not omit this marker. All fields after `posted-by` are required.
+
+   **Backward compatibility:** To detect whether an existing comment was posted by this agent (e.g., during reconciliation in Scenarios B and C), check if the comment body contains the substring `posted-by: arm-api-reviewer-agent`. This matches both the old simple marker and the new extended marker.
+
 9. Prioritize posting **New** issues first, as these are the PR author's direct responsibility.
 10. **Report a reconciliation summary** to the human reviewer before posting:
     - Findings to **post as new comments** (with line numbers)
@@ -348,6 +371,24 @@
 4. If the PR does not have the `WaitForARMFeedback` label, skip the removal step and only propose adding `ARMChangesRequested`.
 5. Report to the human reviewer which labels were added and removed.
 
+### Step 9: Clean Up Local Workspace
+
+If the review required creating any local artifacts to inspect the PR (typically a Git worktree and/or local branch tracking the PR's head ref - for example, when the PR is too large for `gh pr diff` to handle), **clean these up at the end of the review**, after the comments have been posted (Step 7) and labels updated (Step 8).
+
+1. **Inventory** anything created during this session:
+   - Local branches matching `pr-<number>` or similar patterns created by you.
+   - Worktrees created by you (e.g., `<repo>/../specs-pr-<number>`).
+   - Temporary files written to the workspace root (e.g., `review-payload.json`, `review-body.txt`).
+2. **Confirm the user is not still using them.** If `git status` in the worktree shows uncommitted work, ask the user before removing.
+3. **Remove** the artifacts (PowerShell):
+   - `git worktree remove <worktree-path>`
+   - `git branch -D <branch-name>`
+   - `Remove-Item ./review-payload.json, ./review-body.txt -ErrorAction SilentlyContinue`
+4. **Do not** touch branches, worktrees, or files that pre-existed the review (e.g., the user's working branch, unrelated worktrees, the user's stashes).
+5. **Report** what was cleaned up to the user.
+
+This keeps the user's workspace tidy and prevents accumulation of stale `pr-*` branches across reviews.
+
 ## Constraints
 
 - **Read-only.** This agent does not modify specification files. Its job is to flag issues and suggest fixes, not apply them.
@@ -358,6 +399,7 @@
 - **Clean specs get clean reports.** If after thorough review a specification has no blocking violations, explicitly state that no blocking issues were found. Do not downgrade compliant patterns into violations. For example: a spec that correctly uses common-types, has all required CRUD operations, includes `provisioningState` with the right terminal states, and follows naming conventions should receive a clean bill of health -- not a list of fabricated issues. The absence of findings is a valid review outcome.
 - **Scope boundaries.** Do not review SDK code, pipeline configs, or infrastructure files. Only review specification artifacts (OpenAPI JSON, TypeSpec `.tsp`, `tspconfig.yaml`, examples, readmes for AutoRest config).
 - **Always compare versions.** When a previous API version exists in the repository, load it and check for breaking changes. Do not skip this step.
+- **Clean up after yourself.** Any local branches, worktrees, or temporary files you create to inspect a PR MUST be removed at the end of the review (see Step 9). Never leave stale `pr-*` branches or scratch JSON payloads in the user's workspace.
 
 ## Example Prompts
 

.github/arm-leases/HermesMachinePrototypeRP/Microsoft.HermesMachinePrototype/HermesMachinePrototype/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.HermesMachinePrototype
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P120D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/HermonTsRP/Microsoft.HermonBakery/HermonBakery/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.HermonBakery
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P120D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/ManufacturingPlatformDev/Microsoft.ManufacturingPlatformDev/ManufacturingPlatformDev/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.ManufacturingPlatformDev
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P120D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/README.md

@@ -95,3 +95,56 @@ If your PR check **"ARM Lease Validation"** is failing, review the error message
 - **Invalid duration**: Use a valid ISO 8601 duration that does not exceed 180 days (e.g., `P180D`, `P90D`, `P5M`)
 - **Missing or empty fields**: All fields (`resource-provider`, `startdate`, `duration`, `reviewer`) are required
 - **Disallowed files**: Only `lease.yaml` and `README.md` files are permitted in `.github/arm-leases/`
+
+## Automation Scripts
+
+Scripts are located in `.github/workflows/cmd/`. Run from the repository root.
+
+### Single Resource Provider
+
+**Syntax:**
+
+```bash
+# Without service groups
+node .github/workflows/cmd/arm-lease-generate-lease-files.js --orgName <orgName> --rpNamespace <rpNamespace> --reviewer "@youralias" --startdate <YYYY-MM-DD> --duration <P#D>
+
+# With service groups
+node .github/workflows/cmd/arm-lease-generate-lease-files.js --orgName <orgName> --rpNamespace <rpNamespace> --reviewer "@youralias" --startdate <YYYY-MM-DD> --duration <P#D> --serviceName "<serviceName1>,<serviceName2>"
+```
+
+**Examples:**
+
+```bash
+# Without service groups
+node .github/workflows/cmd/arm-lease-generate-lease-files.js --orgName storage --rpNamespace Microsoft.Storage --reviewer "@johndoe" --startdate 2026-05-01 --duration P90D
+
+# With service groups
+node .github/workflows/cmd/arm-lease-generate-lease-files.js --orgName compute --rpNamespace Microsoft.Compute --reviewer "@janesmith" --startdate 2026-05-01 --duration P180D --serviceName "DiskRP,ComputeRP,GalleryRP"
+```
+
+### Bulk Generation
+
+**Syntax:**
+
+```bash
+# Generate resource provider list (without service groups)
+node .github/workflows/cmd/arm-lease-fetch-resource-providers.js --output <filename>
+
+# Generate resource provider list (with service groups)
+node .github/workflows/cmd/arm-lease-fetch-resource-providers.js --with-service-groups --output <filename>
+
+# Generate lease files from list
+node .github/workflows/cmd/arm-lease-generate-lease-files.js --input <filename> --reviewer "@youralias" --startdate <YYYY-MM-DD> --duration <P#D>
+```
+
+**Examples:**
+
+```bash
+# RPs without service groups (e.g., Microsoft.Storage)
+node .github/workflows/cmd/arm-lease-fetch-resource-providers.js --output rps-simple.txt
+node .github/workflows/cmd/arm-lease-generate-lease-files.js --input rps-simple.txt --reviewer "@johndoe" --startdate 2026-04-16 --duration P180D
+
+# RPs with service groups (e.g., Microsoft.Compute with DiskRP, ComputeRP)
+node .github/workflows/cmd/arm-lease-fetch-resource-providers.js --with-service-groups --output rps-groups.txt
+node .github/workflows/cmd/arm-lease-generate-lease-files.js --input rps-groups.txt --reviewer "@johndoe" --startdate 2026-04-16 --duration P180D
+```

.github/arm-leases/SCOMManagedInstance/Microsoft.OperationsMgr/OperationsMgr/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.OperationsMgr
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P180D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/StorageCopilotTest/Microsoft.StorageCopilotTest/StorageCopilotTest/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.StorageCopilotTest
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P180D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/WhiteBoxCadlProvider/Microsoft.WhiteBoxCadlProvider/WhiteBoxCadlProvider/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.WhiteBoxCadlProvider
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P180D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/WhiteBoxCadlProvider/Microsoft.WhiteBoxCadlProvider/lease.yaml

@@ -0,0 +1,5 @@
+lease:
+  resource-provider: Microsoft.WhiteBoxCadlProvider
+  startdate: "2026-05-08"
+  duration: P180D
+  reviewer: "@tejaswiminnu"

.github/arm-leases/XRPaaSLiveTest/Microsoft.Library/Library/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.Library
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P180D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/XRPaaSLiveTest/Microsoft.Restaurant/Restaurant/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.Restaurant
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P180D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"

.github/arm-leases/XRPaaSLiveTest/Microsoft.Restaurant1/Restaurant1/lease.yaml

@@ -1,5 +1,5 @@
 lease:
   resource-provider: Microsoft.Restaurant1
-  startdate: "2026-04-28"
+  startdate: "2026-05-04"
   duration: P180D
-  reviewer: "@vikeshi26"
+  reviewer: "@tejaswiminnu"