Merge branch 'main' into feature/foundry-release-main-merge

Signed-off-by: Vincent Biret <vibiret@microsoft.com>

Author: baywet

.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
 

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

@@ -314,10 +314,10 @@ After presenting the review findings to the human reviewer for approval:
    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.
@@ -333,7 +333,22 @@ After presenting the review findings to the human reviewer for approval:
 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)
@@ -356,6 +371,24 @@ After successfully posting review comments to the PR:
 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.
@@ -366,6 +399,7 @@ After successfully posting review comments to the PR:
 - **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/aigrounding/Microsoft.AIGrounding/AIGrounding/lease.yaml

@@ -0,0 +1,5 @@
+lease:
+  resource-provider: Microsoft.AIGrounding
+  startdate: "2026-05-20"
+  duration: P180D
+  reviewer: "@vikeshi26"

.github/arm-leases/azureresiliencemanagement/Microsoft.AzureResilienceManagement/AzureResilienceManagement/lease.yaml

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

.github/arm-leases/deviceupdate/Microsoft.DeviceUpdate/DuDeviceRegistry/lease.yaml

@@ -0,0 +1,5 @@
+lease:
+  resource-provider: Microsoft.DeviceUpdate
+  startdate: "2026-05-21"
+  duration: P180D
+  reviewer: "@vikeshi26"

.github/arm-leases/migrate/Microsoft.Migrate/NetworkAssessments/lease.yaml

@@ -0,0 +1,5 @@
+lease:
+  resource-provider: Microsoft.Migrate
+  startdate: "2026-05-21"
+  duration: P180D
+  reviewer: "@vikeshi26"

.github/arm-leases/monitor/Microsoft.Monitor/TraceAssociations/lease.yaml

@@ -0,0 +1,5 @@
+lease:
+  resource-provider: Microsoft.Monitor
+  startdate: "2026-05-14"
+  duration: P120D
+  reviewer: "@tejaswiminnu"

.github/arm-leases/paloaltonetworks/PaloAltoNetworks.Cloudngfw/lease.yaml

@@ -0,0 +1,5 @@
+lease:
+  resource-provider: PaloAltoNetworks.Cloudngfw
+  startdate: "2026-05-18"
+  duration: P120D
+  reviewer: "@tejaswiminnu"

…/arm-leases/pki/Microsoft.Pki/lease.yaml …-leases/pki/Microsoft.Pki/Pki/lease.yaml.github/arm-leases/pki/Microsoft.Pki/lease.yaml renamed to .github/arm-leases/pki/Microsoft.Pki/Pki/lease.yaml .github/arm-leases/pki/Microsoft.Pki/lease.yaml renamed to .github/arm-leases/pki/Microsoft.Pki/Pki/lease.yaml

@@ -0,0 +1,5 @@
+lease:
+  resource-provider: Microsoft.ProgramEnrollment
+  startdate: "2026-05-20"
+  duration: P120D
+  reviewer: "@tejaswiminnu"