Merge branch 'rhurey/vl_specs' of https://github.com/rhurey/azure-rest-api-specs into yulin/formats-typo

Author: Yulin Li

.github/CODEOWNERS

@@ -95,10 +95,7 @@
 /specification/containerservice/ @palma21 @weinong @seguler @alvinli222 @justindavies @matthchr @robbiezhang @paulgmiller @yizhang4321 @circy9 @qike-ms
 
 # PRLabel: %Container Service Fleet
-/specification/containerservice/**/fleet/ @circy9 @serbrech @jim-minter @matthchr
-
-# PRLabel: %Container Service Fleet
-/specification/containerservice/Fleet.Management/ @circy9 @serbrech @jim-minter @matthchr
+/specification/containerservice/resource-manager/Microsoft.ContainerService/fleet/ @circy9 @serbrech @matthchr
 
 # PRLabel: %Cosmos
 /specification/cosmos-db/ @pjohari-ms @MehaKaushik
@@ -311,4 +308,5 @@
 /.github/copilot-instructions.md @praveenkuttappan @maririos
 /.github/prompts/                @praveenkuttappan @maririos
 /.github/instructions/           @praveenkuttappan @maririos
+/.github/instructions/*arm*.md   @raosuhas
 /.github/chatmodes/              @praveenkuttappan @maririos

.github/actions/install-deps-github-script/action.yaml

@@ -0,0 +1,15 @@
+name: Install dependencies for github-script actions
+description: Installs dependencies for github-script actions
+
+runs:
+  using: composite
+
+  steps:
+    - uses: ./.github/actions/setup-node-install-deps
+      with:
+        # actions/github-script@v8 uses Node 24
+        node-version: 24.x
+        # "--no-audit": improves performance
+        # "--omit dev": not needed at runtime, improves performance
+        install-command: "npm ci --no-audit --omit dev"
+        working-directory: ./.github

.github/actions/setup-node-install-deps/action.yaml

@@ -4,7 +4,7 @@ description: Uses specified Node version and installs dependencies (typically us
 inputs:
   node-version:
     description: "Node version to use"
-    default: 22.x
+    default: 24.x
   install-command:
     description: "Command to install dependencies"
     default: "npm ci"

.github/copilot-instructions.md

@@ -1,5 +1,9 @@
 version: 2
 updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
   - package-ecosystem: "npm"
     directories:
       - "/"
@@ -20,18 +24,17 @@ updates:
     ignore:
       # Updated manually to align with minimum supported Node version
       - dependency-name: "@types/node"
-      # Updated manually to align with repo microsoft/typespec
-      - dependency-name: "@vitest/coverage-v8"
-      - dependency-name: "prettier"
-      - dependency-name: "vitest"
-      - dependency-name: "typescript"
       # Updated manually by the Liftr team
       - dependency-name: "@azure-tools/typespec-liftr-base"
       # 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"]
     groups:
       # Ships separately from other typespec packages
+      openapi-typespec:
+        patterns:
+          - "@azure-tools/openai-typespec"
+      # Ships separately from other typespec packages
       typespec-client-generator-cli:
         patterns:
           - "@azure-tools/typespec-client-generator-cli"
@@ -57,11 +60,6 @@ updates:
     ignore:
       # Updated manually to align with minimum supported Node version
       - dependency-name: "@types/node"
-      # Updated manually to align with repo microsoft/typespec
-      - dependency-name: "@vitest/coverage-v8"
-      - dependency-name: "prettier"
-      - dependency-name: "vitest"
-      - dependency-name: "typescript"
       # Points to "github:actions/github-script" since package isn't published to npmjs
       - dependency-name: "@types/github-script"
     groups:

.github/dependabot.yml

@@ -1,7 +1,16 @@
+import { defineConfig } from "eslint/config";
 import { defineBaseConfig } from "./shared/eslint.base.config.js";
 
-export default defineBaseConfig({
-  // ensures the tsconfig path resolves relative to this file (so cannot be defined in base file)
-  // default is process.cwd() when running eslint, which may be incorrect
-  tsconfigRootDir: import.meta.dirname,
-});
+export default defineConfig(
+  defineBaseConfig({
+    // ensures the tsconfig path resolves relative to this file (so cannot be defined in base file)
+    // default is process.cwd() when running eslint, which may be incorrect
+    tsconfigRootDir: import.meta.dirname,
+  }),
+  {
+    ignores: [
+      // generated by `vitest --coverage`
+      "shared/coverage/**",
+    ],
+  },
+);

.github/eslint.config.js

@@ -0,0 +1,143 @@
+---
+applyTo: "**/specification/**/resource-manager/*.json"
+---
+
+# ARM OpenAPI (Swagger) Review Instructions
+
+When reviewing Azure Resource Manager (ARM) OpenAPI specifications, ensure compliance with Microsoft API
+Guidelines and Azure RPC contracts. Prioritize Azure RPC requirements when conflicts arise.
+
+## Critical Requirements
+
+### 1. API Guidelines Compliance
+
+- **MUST** follow [Azure REST API Guidelines]
+  (https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md)
+- **MUST** conform to [Azure RPC contracts]
+  (https://github.com/cloud-and-ai-microsoft/resource-provider-contract)
+- Azure RPC takes precedence over general guidelines in case of conflicts
+
+### 2. Breaking Changes Prevention
+
+- **NO breaking changes** in GA (stable) API versions per
+  [Azure Breaking Changes Policy](https://aka.ms/AzBreakingChangesPolicy)
+- Verify no removal/renaming of properties, operations, or parameters in existing versions
+- Check property types remain unchanged (e.g., boolean → string is breaking)
+- Ensure enum values are not removed or renamed
+- New required properties or parameters require new API version
+- URL path format changes require new API version
+
+### 3. ARM Resource Model Requirements
+
+- Resource model name **MUST** match singular form of resource type (e.g., `VirtualMachine` for `virtualMachines`)
+- Top-level resources **MUST** have `ListByResourceGroup` and `ListBySubscription` operations
+- Tracked resources **MUST** have GET, PUT, PATCH (update), and DELETE operations
+- All resources **MUST** include `systemData` property (read-only) with type from common-types
+- Nested resources **MUST** have List operation
+
+### 4. Common Types Usage
+
+- **MUST** reference appropriate common-types version (v3, v4, or v5) for standard ARM types:
+  - `Resource`, `TrackedResource`, `ProxyResource`, `ExtensionResource`
+  - `ErrorResponse`, `ErrorDetail`
+  - Standard parameters: `SubscriptionIdParameter`, `ResourceGroupNameParameter`, `ApiVersionParameter`
+- Use `$ref` to common-types instead of redefining standard ARM structures
+
+### 5. API Versioning
+
+- API version **MUST** follow `YYYY-MM-DD` format
+- Version **MUST** be in path:
+  `/subscriptions/{subscriptionId}/providers/Microsoft.{Namespace}/...?api-version=YYYY-MM-DD`
+- Stable versions in `/stable/` directory, preview in `/preview/`
+
+### 6. Security & Authentication
+
+- **MUST** define `securityDefinitions` with OAuth2 Azure AD authentication
+- **MUST** apply `security` requirement to all operations
+- Scopes should use `user_impersonation` for management plane
+
+### 7. Property & Parameter Correctness
+
+- Mark required parameters as `"required": true` - incorrect marking breaks customers
+- Mark read-only properties as `"readOnly": true` (e.g., `id`, `name`, `type`, `systemData`)
+- Use `x-ms-mutability` to specify create/read/update behavior
+- Collections **MUST** support multiple elements, not artificially limited to one
+- Only define operations/properties/parameters actually supported by the service
+
+### 8. Naming Conventions
+
+- Properties and parameters: **camelCase** (e.g., `resourceGroupName`)
+- Resource types in path: **camelCase** (e.g., `/virtualMachines/{virtualMachineName}`)
+- Resource provider namespace: **PascalCase** (e.g., `Microsoft.Compute`)
+- Model definitions: **PascalCase** (e.g., `VirtualMachine`)
+- Enum values: **PascalCase** preferred
+- Avoid abbreviations in names unless industry-standard
+- Use resource name, not abbreviations, in path parameters: `{virtualMachineName}` not `{vmName}`
+
+### 9. Operations & Operation IDs
+
+- OperationId format: `{ResourceType}_{Action}` (e.g., `VirtualMachines_Get`, `VirtualMachines_CreateOrUpdate`)
+- Operations **MUST** have unique `operationId`
+- Use standard verbs: GET → `Get/List`, PUT → `CreateOrUpdate`, PATCH → `Update`, DELETE → `Delete`, POST → action name
+- Include `x-ms-examples` referencing example JSON files
+- DELETE operations: return 200 (with body), 202 (async), or 204 (no content)
+- Long-running operations: use `x-ms-long-running-operation: true` and return 201 or 202
+
+### 10. Pagination & Collections
+
+- List operations **MUST** use `x-ms-pageable` with `nextLinkName`
+- Collection models **MUST** have `value` array property and optional `nextLink` string
+
+### 11. Documentation Quality
+
+- Every operation, parameter, property, and model **MUST** have clear description
+- Start operation descriptions with verb (e.g., "Gets the virtual machine.")
+- Start with capital letter, end with period
+- Specify units for quantifiable properties (MB, seconds, etc.)
+- Use correct acronym capitalization: "URL" not "Url", "ID" not "Id"
+- Avoid: "Gets or sets...", "Gets...", "Sets..." in property descriptions
+- Document all HTTP status codes in responses
+
+### 12. Error Handling
+
+- Default error response **MUST** reference common-types `ErrorResponse`
+- Include "default" response for all operations
+- Use `x-ms-error-response: true` for error responses
+
+### 13. Extensions & Special Features
+
+- **REQUIRED**: `x-ms-parameter-location: "method"` for common parameters
+  (subscriptionId, resourceGroupName, apiVersion)
+- Use `x-ms-enum` with `modelAsString: true` for extensible enums (allows new values without breaking)
+- Use `x-ms-discriminator-value` for polymorphic types
+- Private/internal operations: mark with `x-ms-visibility: "internal"`
+
+### 14. Customer Usability
+
+Think as a customer: Are parameter names intuitive? Is required vs. optional clear? Are default values
+documented? Can developers understand how to use this API from the specification alone?
+
+### 15. Examples & Testing
+
+- **MUST** include `x-ms-examples` for all operations
+- Example files in `examples/` directory
+- **MUST** test all operations before PR submission
+- Examples **MUST** validate against specification
+
+## Review Checklist Summary
+
+✓ No breaking changes in existing versions  
+✓ Follows Azure RPC contracts  
+✓ Common-types properly referenced  
+✓ Naming conventions (camelCase properties, PascalCase types)  
+✓ Required/readOnly correctly marked  
+✓ Security definitions present  
+✓ Standard ARM operations implemented  
+✓ Pagination on list operations  
+✓ Operation IDs follow pattern  
+✓ Examples provided and valid  
+✓ Descriptions clear and complete  
+✓ API version format correct
+
+Flag violations clearly with line numbers and specific guidance for fixes.
+Once completed always add the following comment : "Copilot used the entire file : .github/instructions/armapi-review.instructions.md for arm api reviews."

.github/instructions/armapi-review.instructions.md

@@ -0,0 +1,18 @@
+# Run SDK generation using pipeline in GitHub coding agent
+
+Run only SDK generation using pipeline and do not run SDK generation using local SDK generation tools. This is applicable only when GitHub copilot coding agent is used to generate SDK and if a Release Plan is available in the context. Run SDK generation tool even if release plan already has SDK generation pipeline URL to support regenerating SDK. 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.
+
+## Additional instructions:
+
+- Run SDK generation pipeline for the given TypeSpec path for all languages mentioned in the description.
+- Identify absolute path of TypeSpec project root path and send it to Run SDK generation MCP tool call.
+- Keep checking the pipeline status every 10 minutes until pipeline is in completed or failed status.
+- Find SDK pull request links from the pipeline run.
+- Do not mark as language as excluded in the release plan just because SDK generation pipeline failed for that language. Inform user about the failure and suggest to check pipeline logs for more information.
+- Do not run verify setup, TypeSpec validation, service label check and analyze pipeline tools when running SDK generation using GitHub coding agent.
+
+## 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/instructions/github-codingagent.instructions.md

@@ -0,0 +1,35 @@
+Use this guidance whenever someone needs to add language emitters to an existing `tspconfig.yaml`, or when SDK generation fails because an emitter block is missing.
+
+- Decide whether the service is ARM or data-plane.
+- Open the matching widget `tspconfig.yaml` template.
+- Copy the entire emitter block for the requested language.
+- Replace every `Widget`/`widget` token with the service name and drop the block under `options:`.
+
+## 1. Identify the service type
+
+- Path contains `/resource-manager/` or linter references `@azure-tools/typespec-azure-rulesets/resource-manager` → ARM
+- Path contains `/data-plane/` or linter references `@azure-tools/typespec-azure-rulesets/data-plane` → Data plane
+
+## 2. Reference the official widget template
+
+- ARM: `specification/widget/resource-manager/Microsoft.Widget/Widget/tspconfig.yaml`
+- Data plane: `specification/widget/data-plane/WidgetAnalytics/tspconfig.yaml`
+
+Always read the template before editing so you follow the canonical configuration.
+
+## 3. Copy and customize the emitter block
+
+- Select the entire block for the language.
+- Only replace service-specific tokens (`Widget`, `widget`, namespaces, package names) with your service name.
+- Leave the rest of the properties (`flavor`, boolean flags, `{service-dir}` placeholders, etc.) unchanged.
+
+## 4. Insert into the project config
+
+- Paste the customized block under `options:` in the target `tspconfig.yaml`, keeping YAML indentation intact.
+- Confirm the `parameters:` section defines `"service-dir"` (for example `sdk/<servicename>`); add it if missing.
+
+**Quick checks**
+
+- Do not mix ARM and data-plane templates.
+- Do not cherry-pick individual properties—copy the whole block or errors will persist.
+- If the SDK pipeline still reports missing configuration, re-open the template and verify every `Widget` reference was replaced.