Merge branch main into release-app-Microsoft.App-preview/2025-10-02-preview

.github/CODEOWNERS

@@ -208,10 +208,10 @@
 /specification/scheduler/ @pinwang81
 
 # PRLabel: %Search
-/specification/search/data-plane/ @arv100kri @bleroy @BevLoh @giulianob
+/specification/search/data-plane/ @kuanlu95 @BevLoh @giulianob
 
 # PRLabel: %Search
-/specification/search/resource-manager/ @efrainretana @conor-joplin @BevLoh @xiong-qiao @jonathanserbent @Draconicida @kuanlu95 @admayber
+/specification/search/resource-manager/ @efrainretana @BevLoh @xiong-qiao @jonathanserbent @Draconicida @kuanlu95 @admayber
 
 /specification/serialconsole/ @amitchat @craigw @asinn826
 
@@ -225,7 +225,7 @@
 /specification/servicefabric/ @juhacket @samedder
 
 # PRLabel: %SQL
-/specification/sql/ @jamestao @ericshape @jeremyfrosti
+/specification/sql/ @jamestao @ericshape @jeremyfrosti @mitesh-pv @achyuth-ms
 
 # PRLabel: %Storage
 /specification/storage/resource-manager/ @blueww @yifanz7
@@ -287,7 +287,7 @@
 /eng/tools/typespec-migration-validation @pshao25 @live1206
 /eng/tools/typespec-validation/src/rules/sdk-tspconfig-validation.ts @wanlwanl @raych1 @maririos
 /scripts/           @weshaggard @mikeharder
-/specification/suppressions.yaml @weshaggard @mikeharder @benbp @raych1 @wanlwanl @maririos
+/specification/suppressions.yaml @weshaggard @mikeharder @benbp @raych1 @wanlwanl @maririos @qiaozha
 /.github/CODEOWNERS @Azure/azure-sdk-eng
 
 ## Copilot

.github/copilot-instructions.md

@@ -120,7 +120,6 @@ Examples of common errors and warnings that should be addressed after running th
 /** Service api versions **/
 enum Versions {
   /** The 2023-11-01 api version **/
-  @useDependency(Azure.Core.Versions.v1_0_Preview_2)
   v2023_11_01: "2023-11-01",
 }
 
@@ -154,9 +153,10 @@ the context. If there are no TypeSpec project paths in the context, then prompt
 from the list of paths. If user does not have a TypeSpec project, then prompt user to create a new TypeSpec project.
 
 
-### Pre-requisites
+### Prerequisites
 - User should have a GitHub account and should be logged in to GitHub account using GitHub CLI `gh auth login`.
 - run `npm ci` to install the dependencies
+- To use Azure MCP tool calls, the user must have PowerShell installed. Provide [PowerShell installation instructions](https://learn.microsoft.com/powershell/scripting/install/installing-powershell) if not installed, and recommend restarting the IDE to start the MCP server.
 
 
 ### Basic Rules for SDK Generation from TypeSpec
@@ -187,7 +187,7 @@ from the list of paths. If user does not have a TypeSpec project, then prompt us
     - Exclude changes to the `.gitignore` file and contents within the `.github` and `.vscode` folders from API spec and SDK pull requests.
 
 7. **Working Branch Rule**:
-    - Ensure the TypeSpec project repository and the current working repository are not on the `main` branch:
+    - If the typespec pull request already exists or is merged stay on the `main` branch, otherwise ensure the TypeSpec project repository and the current working repository are not on the `main` branch:
         - Check the current branch name for the cloned GitHub repository:
             - If the current branch is `main`, prompt the user to create a new branch using 
             `git checkout -b <branch name>`.
@@ -201,21 +201,34 @@ from the list of paths. If user does not have a TypeSpec project, then prompt us
 By following these rules, the SDK release process will remain clear, structured, and user-friendly.
 
 ## Steps to generate SDK from TypeSpec API specification
-Follow [typespec to sdk](.\prompts\typespec-to-sdk.prompt.md) to generate and release SDK from TypeSpec API specification. The process is divided into several steps, each with specific actions to ensure a smooth SDK generation and release process.
-Do not skip the step that choose SDK generation method to ensure the user selects the appropriate method for SDK generation, either locally or using the SDK generation pipeline. Do not repeat the steps.
+Follow [typespec to sdk](..\eng\common\instructions\azsdk-tools\typespec-to-sdk.instructions.md) to generate and release SDK from TypeSpec API specification. The process is divided into several steps, each with specific actions to ensure a smooth SDK generation and release process.
+Do not skip the step that choose SDK generation method to ensure the user selects the appropriate method for SDK generation, either locally or using the SDK generation pipeline. Do not repeat the steps. Before using tools, check if user has Powershell installed.
 
 1. **Identify TypeSpec Project**: Locate the TypeSpec project root path by checking for `tspconfig.yaml` or `main.tsp` files.
 2. **Validate TypeSpec Specification**: Ensure the TypeSpec specification compiles without errors.
 3. **Verify Authentication and Repository Status**: Ensure user is authenticated and working in the correct public Azure repository.
 4. **Review and Commit Changes**: Stage and commit TypeSpec modifications, ensuring the current branch is not "main". Do not create pull request yet.
 5. **Create Specification Pull Request**: Create a pull request for TypeSpec changes if not already created. This is required only if there are TypeSpec changes in current branch.
 6. **Choose SDK Generation Method**: Determine how to generate SDKs (locally or via pipeline). Only Python is supported for local SDK generation at this time.
-7. **Generate SDKs via Pipeline**:  Generate SDKs using [run sdk gen pipeline](.\prompts\run-sdk-gen-pipeline.prompt.md), monitor the pipeline status and displaying generated SDK PR links.
+7. **Generate SDKs via Pipeline**:  Generate SDKs using [run sdk gen pipeline](..\eng\common\instructions\azsdk-tools\run-sdk-gen-pipeline.instructions.md), monitor the pipeline status and displaying generated SDK PR links.
 8. **Show generated SDK PR**: Display the generated SDK pull request links for review.
-9. **Create a release plan**: To create a release plan refer to [create release plan](.\prompts\create-release-plan.prompt.md)
-10. **Prompt user to change spec pull request to ready for review from draft status**: Update spec pull request to change it to ready for review.
-11. **Release package**: Release the SDK package using `ReleaseSdkPackage` tool.
-
+9. **Validate Label and then Codeowners**: Validate the service label and codeowners for the created SDK service using both [validate service label](..\eng\common\instructions\azsdk-tools\validate-service-label.instructions.md) and [validate codeowners](..\eng\common\instructions\azsdk-tools\validate-codeowners.instructions.md).
+10. **Create a release plan**: To create a release plan refer to [create release plan](..\eng\common\instructions\azsdk-tools\create-release-plan.instructions.md)
+11. **Prompt user to change spec pull request to ready for review from draft status**: Update spec pull request to change it to ready for review.
+12. **Release package**: Release the SDK package using `azsdk_release_sdk` tool.
 
 ## Release readiness of SDK and information about the release pipeline
-Run [check package readiness](.\prompts\check-package-readiness.prompt.md) to check the release readiness of an SDK package. This prompt will collect the required information from the user, execute the readiness check, and present the results.
+Run [check package readiness](..\eng\common\instructions\azsdk-tools\check-package-readiness.instructions.md) to check the release readiness of an SDK package. This prompt will collect the required information from the user, execute the readiness check, and present the results.
+
+## Instructions for GitHub coding agent to generate SDKs using GitHub.com
+Run only SDK generation step and Update SDK details back in issue description and release plan. Do not run TypeSpec validation, or service label check. This is applicable only when GitHub copilot coding agent is used to generate SDK and if a Release Plan is available in the context.
+Coding agent must wait until all SDK generation pipeline are in completed status and then fetch the SDK details from pipeline run. This is applicable only when a GitHub issue is assigned to GitHub coding agent to generate SDK from a TypeSpec project. This is not applicable when running Copilot from Visual Studio and VS Code.
+
+  steps:
+    - Run SDK generation pipeline for the given TypeSpec path for all languages mentioned in the description.
+    - Keep checking the pipeline status until pipeline is in completed or failed status.
+    - Find SDK pull request links from the pipeline run.
+  constraints:
+    - Do not invoke other steps.
+    - Do not modify main.tsp file or any files in TypeSpec project.
+    - Do not add API version to an existing main.tsp if input API version is not present.

.github/dependabot.yml

@@ -17,9 +17,6 @@ updates:
       - dependency-name: "typescript"
       # Updated manually by the Liftr team
       - dependency-name: "@azure-tools/typespec-liftr-base"
-      - dependency-name: "@types/js-yaml"
-      - dependency-name: "autorest"
-      - dependency-name: "js-yaml"
       # Only allow patch updates for spec-gen-sdk
       - dependency-name: "@azure-tools/spec-gen-sdk"
         update-types: ["version-update:semver-minor", "version-update:semver-major"]
@@ -55,8 +52,6 @@ updates:
       - dependency-name: "typescript"
       # Points to "github:actions/github-script" since package isn't published to npmjs
       - dependency-name: "@types/github-script"
-      # Stay on ^7 until ^10 increases in adoption
-      - dependency-name: "cross-env"
     groups:
       eslint:
         patterns:

.github/instructions/openapi-review.instructions.md

@@ -0,0 +1,36 @@
+---
+applyTo: "**/*.json"
+---
+
+# Copilot Review Instructions for reviewing OpenAPI v2
+
+Please review OpenAPI v2 (Swagger) definition files with the following in mind:
+
+## API Guidelines Alignment
+
+- Ensure the API follows https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md.
+- Validate naming conventions for paths, parameters, and schemas.
+- Confirm consistent use of `x-ms-*` extensions where applicable.
+- Check for proper use of `operationId`, `description`, and `summary` fields.
+
+## Versioning
+
+- Ensure the API version is clearly defined and follows the `YYYY-MM-DD` format.
+- Confirm that breaking changes are not introduced in minor version updates.
+
+## Security
+
+- Validate that security definitions (e.g., OAuth2 scopes) are present and correctly applied.
+- Ensure no unsecured endpoints are exposed unless explicitly documented.
+
+## Documentation
+
+- Flag missing or vague descriptions for operations, parameters, and responses.
+- Recommend examples for request/response bodies where missing.
+
+## Style
+
+- Prefer camelCase for property names.
+- Avoid abbreviations unless industry-standard.
+
+Respond in markdown format with clear suggestions and highlight any violations of the guidelines.