management-autopr-review

---
name: management-autopr-review
description: Reviews eligible generated Azure Java management-library AutoPR changes for a narrow set of high-value generation risks.
---

# Management AutoPR Review Rules

Use only for `Azure/azure-sdk-for-java` PRs that are non-draft, target `main`,
originate in the same repository, have a title containing
`[AutoPR azure-resourcemanager-`, and are authored by `azure-sdk`,
`azure-sdk-automation[bot]`, or `app/azure-sdk-automation`.

The review is advisory. It does not approve, merge, modify code, access the spec
repository, or replace other automated and human review.

## Java-change gate

Never review a file whose normalized repository-relative path contains a
`generated` segment (`(^|/)generated(/|$)`). This includes generated samples
and tests.

Review `opened`, `reopened`, and `ready_for_review` only when the PR contains a
changed `.java` file outside a `generated` path. On `synchronize`, review only
when the pushed `before..after` range changes such a `.java` file. POM-only,
CHANGELOG-only, metadata-only, generated-only, and refresh-only pushes produce
no comment.

Once the Java gate passes, supporting POM, CHANGELOG, metadata, and CI files may
be read as evidence, except files under a `generated` path.

## Review rules

### `MGMT-RELEASE-PLAN`: missing release-plan link

- **Severity:** Warning

Normalize casing and Markdown emphasis. Accept both plain
`Release Plan link: https://example.com/release-plan` and formatted
`**Release plan link:** [text](https://example.com/release-plan)`. Require an
HTTP(S) URL.

Report when the PR description contains no accepted release-plan link. Cite the
PR description and continue the remaining review passes so other high-value
concerns are not hidden.

### `MGMT-FOLDER`: service-folder mismatch

- **Severity:** Blocking

For a newly added management module, split its directory name on `-`. The
expected service identity is always the third segment:

`azure-resourcemanager-<service-identity>[-<module-suffix>...]`

Ignore the fourth and later segments when comparing the module with its
`sdk/<service>/` folder. For example,
`azure-resourcemanager-compute-bulkactions` belongs in `sdk/compute`.

Report whenever the folder `<service>` differs from the module's third segment.
Explain that the likely source is the `service-dir` configuration in the
upstream `tspconfig.yaml`, without accessing that repository.

### `MGMT-VERSION`: stable package on a preview API

- **Severity:** Blocking

Read all API versions from the current CHANGELOG entry. A multi-service entry
may use `Package api-version <service-group>: <version>, ...`; use every value
after `:` and do not treat the service-group names as versions. Fall back to
`apiVersions` in the generated `_metadata.json`. When `apiVersions` is an
object that maps service groups to versions, likewise use every object value.
If any extracted version ends in `-preview`, the Java package version must
contain a beta suffix. Report a stable package generated from any preview API,
even when its other API versions are stable.

Do not infer preview status from feature names or dates.

### `MGMT-API-VERSION`: generated API-version context

- **Severity:** Informational

Read the effective API-version set from the current CHANGELOG entry, falling
back to `apiVersions` in the generated `_metadata.json`. For a CHANGELOG
`service-group: version` list or an `apiVersions` object, report the distinct
version values rather than the service-group names. Report the exact version
or versions as review context.

Treat the API-version set as the informational item's state. If a later commit
changes that set, emit `MGMT-API-VERSION` again as `New` with the new values,
even when a prior workflow comment already contains this ID. This provides an
additional guard for `MGMT-API-VERSION-OVERLAP`. Do not request corrective
action.

### `MGMT-LRO`: suspicious generated LRO response shape

- **Severity:** Warning

Report only when the PR newly adds a `<ClientMethod>Response` and a corresponding
`<ClientMethod>Headers` model whose headers include `location` or
`retry-after`. Identify the method and both generated types. Explain that the
shape may indicate incorrect LRO modeling upstream.

Do not report ordinary response wrappers or headers models without those
headers.

### `MGMT-LIST-RETURN`: non-pageable list operation

- **Severity:** Warning

Review newly added user-facing public operations whose name starts with
`list`. When the return type is neither `PagedIterable<T>` nor `PagedFlux<T>`,
inspect the returned model. Report only when that model exposes a
collection-valued `value` property. Identify the method, return type, and
`value` element type, then ask whether the operation should expose the standard
pageable shape.

Do not report `listWithResponse` methods, low-level protocol client methods,
private single-page helpers, or pre-existing operations. A `PagedIterable<T>`
or `PagedFlux<T>` return is valid. Treat a response model without a `value`
property as a genuine non-pageable action response.

### `MGMT-MANAGER-NAME`: suspicious management entry-point name

- **Severity:** Warning

Review a public top-level class ending in `Manager` only when the PR adds or
renames it in the management package's root Java namespace. Report when any one
of these independent signals is apparent:

- a compound service name has an apparent casing boundary error, such as
  `ContainerserviceManager` instead of `ContainerServiceManager`;
- the class name has an apparent spelling error, supported by the module name,
  root Java package, or other public symbols; or
- the class-name stem has no meaningful lexical overlap with either the Maven
  module name after `azure-resourcemanager-` or the root Java package identity.

For the lexical-overlap check, split CamelCase and hyphenated identities,
compare case-insensitively, and allow a meaningful class token of at least four
characters to occur within a combined package identity. Ignore generic tokens
such as `azure`, `resource`, `resources`, `manager`, `management`, `service`,
`api`, and `client`.

Do not enforce exact branding, abbreviations, singular versus plural, token
order, or optional suffixes. For example, `ContainerAppsApiManager` is related
to `azure-resourcemanager-appcontainers`. Do not report an oddly named
entry-point that was already present on the base branch. Identify the class and
package evidence, then ask whether the generated entry-point name is intended.

### `MGMT-API-VERSION-OVERLAP`: overlapping API-version generations

- **Severity:** Blocking

Report when the branch contains package output from more than one API-version
generation. Evidence includes either:

- multiple package API-version lines in one release section, or
- regeneration of a release section that was already dated before this PR.

The likely root cause is either an earlier generated package that has not been
released or multiple generation runs targeting different API versions on the
same branch. Use the CHANGELOG as evidence, not as the defect itself. Ask which
API-version generation should remain and whether the earlier package should be
released or removed. Ordinary dependency, POM, or release metadata changes are
expected.

### `MGMT-BREAKING`: generated public API break

- **Severity:** Warning

Use the current CHANGELOG release section as the primary and authoritative
source. For a GA package version, its breaking-change section compares the
release with the previous GA release and can identify a break that entered the
main branch during an earlier beta.

Do not require the current Java diff to contain the break. Cite the CHANGELOG
file and affected release entry. Optionally cite a non-`generated` Java file
when it provides useful corroboration.

For a GA release, report one `MGMT-BREAKING` concern summarizing substantive
breaking items listed in the current CHANGELOG section, including removed
public types or methods, changed access, renamed APIs, and changed public
signatures or return types. Request human confirmation that the GA breaks are
intended.

Do not raise `MGMT-BREAKING` for a beta package version. Beta packages may
break, and their CHANGELOG comparison may be against a prior beta. Additive
items are not breaking.

### `MGMT-NEW-MODULE`: new management module context

- **Severity:** Informational

Report when the PR adds a new
`sdk/<service>/azure-resourcemanager-<module>/pom.xml`. Identify the service
folder and module so human reviewers know the PR introduces a new module and
may warrant broader attention. Do not imply a defect or request corrective
action.

## Verification and output

Use only these severity levels:

| Severity | Meaning |
| --- | --- |
| Blocking | A high-confidence configuration or release inconsistency that requires attention before merge. |
| Warning | A suspicious generated shape or compatibility signal that needs human verification; it is not an assertion that code must be fixed. |
| Informational | Useful context with no requested corrective action. |

`MGMT-FOLDER`, `MGMT-VERSION`, and `MGMT-API-VERSION-OVERLAP` are Blocking.
`MGMT-RELEASE-PLAN`, `MGMT-LRO`, `MGMT-LIST-RETURN`, `MGMT-MANAGER-NAME`, and
`MGMT-BREAKING` are Warning.
`MGMT-API-VERSION` and `MGMT-NEW-MODULE` are Informational.

Every item must cite a repository-relative file and affected symbol or release
entry and state whether it is `New`, `Carried forward`, or `Resolved`.
Blocking and Warning items request one concrete human action or verification.
Informational items provide context without requesting action.
`MGMT-RELEASE-PLAN` cites the PR description. Reuse stable IDs across commits,
except that a changed `MGMT-API-VERSION` value is emitted again as `New`.
When a new head SHA passes the Java gate, include each still-applicable prior
item as `Carried forward` in the replacement current-state comment; do not
restate its question as `New`.

Code-format the complete bracketed concern ID, including the square brackets,
for example `[MGMT-LIST-RETURN]`. Do not wrap the complete finding in
backticks, because evidence may contain its own inline code spans.

Output:

```markdown
## Automated management AutoPR review

- Head SHA: `<sha>`
- Package: `<package>`
- Release type: `<stable|beta>`
- API version: `<version(s)>`
- CHANGELOG: `<release and date>`
- Java changes reviewed: `<summary>`
- Breaking changes: `<none|summary>`
- Decision: `<no high-confidence concerns|human attention requested>`

### Blocking

- `[MGMT-...]` New|Carried forward|Resolved — evidence and requested action

### Warning

- `[MGMT-...]` New|Carried forward|Resolved — evidence and verification request

### Informational

- `[MGMT-...]` New|Carried forward|Resolved — context
```

Order sections as Blocking, Warning, Informational and omit empty sections.
Silence or `noop` is correct when no review state changes.