Merge branch 'main' into upgradeAssessment

Author: bgriddaluru

.github/instructions/arm-api-review.instructions.md

@@ -909,6 +909,7 @@ When reviewing resources that support availability zones, verify: `zones` is a t
 
 - The `name` property in the `checkNameAvailability` request **MUST** have `pattern` and `maxLength` constraints matching the target resource type's name validation rules.
 - At minimum, the `name` field **SHOULD** be constrained to valid ARM resource name characters (alphanumeric, hyphens, underscores, periods). Example: `"pattern": "^[a-zA-Z0-9][a-zA-Z0-9-_.]{0,259}$"`, `"maxLength": 260`.
+- The `pattern` constraint **MUST** use allowlist (positive character class) syntax. Denylist (negated character class `[^...]`) syntax **MUST NOT** be used as the primary character-matching construct (`OAPI-PATTERN-ALLOWLIST`). A denylist such as `^[^<>%&:\\?/]+$` permits emoji, control characters, and non-Latin scripts that the service almost certainly rejects. Severity: **Blocking** for new properties/parameters; **Warning** for existing ones. See [`.github/skills/azure-api-review/references/pattern-validation.md`](../skills/azure-api-review/references/pattern-validation.md) for detection guidance, the severity matrix, and fix examples.
 - If a spec defines a custom `checkNameAvailability` request model with a bare `string` `name` field (no `pattern`, no `maxLength`), flag it as a **security concern** and instruct the author to add constraints.
 - **Why:** Unconstrained string inputs to backend queries are a SQL/NoSQL injection risk. Input validation in the spec provides client-side SDK validation and signals to implementers that the field requires server-side sanitization.
 
@@ -1151,6 +1152,8 @@ When reviewing ARM resource-manager swagger files, verify:
 
 - ✅ `checkNameAvailability` uses common-types `CheckNameAvailabilityRequest` / `CheckNameAvailabilityResponse` — not custom request/response models (CNA-003)
 - ✅ `name` field has `pattern` and `maxLength` constraints — not a bare unconstrained string (CNA-004)
+- ✅ `name` field `pattern` uses allowlist syntax (positive character class) — not denylist (`[^...]`) (OAPI-PATTERN-ALLOWLIST, CNA-004)
+- ✅ All `pattern` constraints across path parameters, query parameters, and body properties use allowlist syntax — no denylist (`[^...]`) as the primary construct (`OAPI-PATTERN-ALLOWLIST`): Blocking for new, Warning for existing
 
 ### Tenant-Level APIs
 

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

@@ -157,6 +157,7 @@ A finding "passes" the rule means the rule does not appear in the findings list
   - Prevention of leading special characters (e.g., `^(?![.-])`) — resource names should not start with `.` or `-`.
   - Allowed character set (e.g., `[A-Za-z0-9_.-]`) that matches the service's actual validation.
   - Example: `"pattern": "^(?![.-])[A-Za-z0-9_.-]{1,128}$"`
+- `pattern` constraints **MUST** use allowlist (positive character class) syntax. Denylist (negated character class `[^...]`) syntax **MUST NOT** be used as the primary character-matching construct (`OAPI-PATTERN-ALLOWLIST`). A negative lookahead (`(?!...)`) used alongside a positive class is acceptable (e.g., `^(?![.-])[A-Za-z0-9_.-]{1,128}$`). Severity: **Blocking** for new properties/parameters; **Warning** for existing ones carried forward from a prior API version. See [`.github/skills/azure-api-review/references/pattern-validation.md`](../skills/azure-api-review/references/pattern-validation.md) for detection guidance, the severity matrix, fix examples, and regression-risk notes.
 - For action operations on a resource, the URL pattern **SHOULD** be: `/<resource-collection>/<resource-id>:<action>`.
 - For action operations on a collection: `/<resource-collection>:<action>`.
 - **DO NOT** use action URLs for standard CRUD operations that map naturally to GET/PUT/PATCH/DELETE.
@@ -644,6 +645,7 @@ When reviewing, systematically check:
 - ✅ No unused/orphaned definitions in `definitions` section (SCHEMA-UNUSED-DEF)
 - ✅ Example files use string placeholders for secrets, SSH keys, and credentials — no realistic-looking sensitive values (EX-SECRET-PLACEHOLDER)
 - ✅ Resource name path parameters include `pattern` constraints with length limits and character restrictions
+- ✅ All `pattern` constraints use allowlist (positive character class) syntax — no denylist (`[^...]`) as the primary construct (`OAPI-PATTERN-ALLOWLIST`): Blocking for new properties/parameters, Warning for existing ones
 - ✅ PUT operation descriptions use idempotent language ("Creates or updates..." not "Creates a new...")
 - ✅ Operations API display object uses camelCase property names (`provider`, `resource`, `operation`, `description`)
 

.github/instructions/typespec-review.instructions.md

@@ -130,6 +130,17 @@ See the canonical contract in [`.github/skills/azure-api-review/references/revie
   set, and prevention of leading special characters.
   Example: `@pattern("^(?![.-])[A-Za-z0-9_.-]{1,128}$")`
   (Also enforced by: `@azure-tools/typespec-azure-resource-manager/arm-resource-name-pattern`)
+- `@pattern` decorator values and `NamePattern` constraints **MUST**
+  use allowlist (positive character class) syntax. Denylist (negated
+  character class `[^...]`) syntax **MUST NOT** be used as the primary
+  character-matching construct (`OAPI-PATTERN-ALLOWLIST`). A negative
+  lookahead (`(?!...)`) used alongside a positive class is acceptable
+  (e.g., `@pattern("^(?![.-])[A-Za-z0-9_.-]{1,128}$")`). Severity:
+  **Blocking** for new properties/parameters; **Warning** for existing
+  ones carried forward from a prior API version. See
+  [`.github/skills/azure-api-review/references/pattern-validation.md`](../skills/azure-api-review/references/pattern-validation.md)
+  for detection guidance, severity matrix, fix examples, and
+  regression-risk notes.
 - Properties representing UTC timestamps **SHOULD** include a `Utc`
   suffix in the name (e.g., `lastModifiedTimeUtc`).
 - Properties named `<something>Id` **MUST** be specific about what kind
@@ -444,3 +455,4 @@ When reviewing TypeSpec files, verify:
 - ✅ No bearer/OAuth tokens passed in ARM request bodies -- use managed identity or Key Vault
 - ✅ Generated OpenAPI files match `tsp compile .` output
 - ✅ Example files present for all operations, with realistic descriptive values (EX-DESCRIPTIVE-VALUES)
+- ✅ All `@pattern` and `NamePattern` constraints use allowlist (positive character class) syntax — no denylist (`[^...]`) as the primary construct (`OAPI-PATTERN-ALLOWLIST`): Blocking for new properties/parameters, Warning for existing ones

.github/shared/src/sdk-types.js

@@ -46,7 +46,8 @@ export const SpecGenSdkArtifactInfoSchema = z.object({
  *   breakingChange: string | undefined,
  *   breakingChangeApproved: string | undefined,
  *   breakingChangeSuppression: string | undefined,
- *   breakingChangeSuppressionApproved: string | undefined
+ *   breakingChangeSuppressionApproved: string | undefined,
+ *   buildFailed: string | undefined
  * }} SdkLabelInfo
  */
 
@@ -55,7 +56,7 @@ export const SpecGenSdkArtifactInfoSchema = z.object({
  */
 
 /**
- * SDK labels mapping for breaking change labels
+ * SDK labels mapping for breaking change and build-failure labels
  * @type {SdkLabels}
  * */
 export const sdkLabels = {
@@ -64,35 +65,41 @@ export const sdkLabels = {
     breakingChangeApproved: "BreakingChange-Go-Sdk-Approved",
     breakingChangeSuppression: "BreakingChange-Go-Sdk-Suppression",
     breakingChangeSuppressionApproved: "BreakingChange-Go-Sdk-Suppression-Approved",
+    buildFailed: undefined,
   },
   "azure-sdk-for-java": {
     breakingChange: undefined,
     breakingChangeApproved: undefined,
     breakingChangeSuppression: undefined,
     breakingChangeSuppressionApproved: undefined,
+    buildFailed: undefined,
   },
   "azure-sdk-for-js": {
     breakingChange: "BreakingChange-JavaScript-Sdk",
     breakingChangeApproved: "BreakingChange-JavaScript-Sdk-Approved",
     breakingChangeSuppression: "BreakingChange-JavaScript-Sdk-Suppression",
     breakingChangeSuppressionApproved: "BreakingChange-JavaScript-Sdk-Suppression-Approved",
+    buildFailed: undefined,
   },
   "azure-sdk-for-net": {
     breakingChange: undefined,
     breakingChangeApproved: undefined,
     breakingChangeSuppression: undefined,
     breakingChangeSuppressionApproved: undefined,
+    buildFailed: "auto-sdk-build-fix",
   },
   "azure-sdk-for-python": {
     breakingChange: "BreakingChange-Python-Sdk",
     breakingChangeApproved: "BreakingChange-Python-Sdk-Approved",
     breakingChangeSuppression: "BreakingChange-Python-Sdk-Suppression",
     breakingChangeSuppressionApproved: "BreakingChange-Python-Sdk-Suppression-Approved",
+    buildFailed: undefined,
   },
   "azure-sdk-for-rust": {
     breakingChange: undefined,
     breakingChangeApproved: undefined,
     breakingChangeSuppression: undefined,
     breakingChangeSuppressionApproved: undefined,
+    buildFailed: undefined,
   },
 };

.github/skills/azure-api-review/SKILL.md

@@ -43,6 +43,7 @@ Each reference file covers one cross-cutting rule area with:
 | [linter-rule-coverage.md](references/linter-rule-coverage.md)                 | Linter rule ID → instruction file mapping (130+ rules)                                       | --                                                   |
 | [example-quality.md](references/example-quality.md)                           | Example file quality: orphan detection, coverage, descriptive values                         | EX-ORPHAN, EX-COVERAGE, EX-DESCRIPTIVE-VALUES        |
 | [design-decisions.md](references/design-decisions.md)                         | Grey-area design trade-off frameworks (10 decision matrices)                                 | DD-001–DD-010                                        |
+| [pattern-validation.md](references/pattern-validation.md)                     | Allowlist vs. denylist `pattern` constraints; Unicode bypass risk; severity matrix           | OAPI-PATTERN-ALLOWLIST                               |
 
 ## Authoritative External Sources
 

.github/skills/azure-api-review/references/linter-rule-coverage.md

@@ -260,6 +260,21 @@ instruction files.
 | --             | ResourceNameRestriction         | arm-api-review §15.7 (PREFLIGHT-005) | ✅ Covered   |
 | --             | TenantLevelAPIsNotAllowed       | arm-api-review §12A (RPC-Uri-V1-11)  | ✅ Annotated |
 
+## Pattern Constraint Rules
+
+| Linter Rule ID | Name                     | Instruction Coverage                                              | Status               |
+| -------------- | ------------------------ | ----------------------------------------------------------------- | -------------------- |
+| _(none)_       | DenylistPatternDetection | openapi-review §4 (OAPI-PATTERN-ALLOWLIST); pattern-validation.md | ❌ NO AUTOMATED RULE |
+
+> ❌ **No automated linter rule** currently exists for `OAPI-PATTERN-ALLOWLIST`
+> in `@microsoft.azure/openapi-validator`, `@azure-tools/typespec-azure-core`,
+> or `@azure-tools/typespec-azure-resource-manager`. This check is enforced
+> exclusively by the ARM API Reviewer agent during code review. A follow-up
+> issue should be filed to add an automated rule to the OpenAPI validator and
+> TypeSpec linter packages. The existing `ResourceNameRestriction` rule
+> verifies that a `pattern` _exists_ on resource name parameters but does not
+> verify whether the pattern is an allowlist or a denylist.
+
 ---
 
 ## Coverage Summary
@@ -278,3 +293,9 @@ instruction files.
 | R2063   | OperationIdNounConflictingModelNames | openapi-review §7.1  |
 | R4006   | DeprecatedXmsCodeGenerationSetting   | openapi-review §18   |
 | R2001   | AvoidNestedProperties                | arm-api-review §8.2  |
+
+### Missing Automated Linter Rules
+
+| Rule ID  | Name                     | Status               | Follow-Up                                                                                                                                                                                                                                                                                                                               |
+| -------- | ------------------------ | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| _(none)_ | DenylistPatternDetection | ❌ No automated rule | File a follow-up issue to add `OAPI-PATTERN-ALLOWLIST` to `@azure-tools/typespec-azure-core` and `@microsoft.azure/openapi-validator`. Agent-level coverage: `openapi-review.instructions.md §4`, `typespec-review.instructions.md §2.2`, `arm-api-review.instructions.md §21.4`, and [`pattern-validation.md`](pattern-validation.md). |