Revert last change; remove Step 2 (Note first on-board) instead of polling step

Agent-Logs-Url: https://github.com/Azure/azure-sdk-for-go/sessions/7fe3e166-c9ef-48ba-8748-bac9b3044f62

Co-authored-by: tadelesh <1726438+tadelesh@users.noreply.github.com>

Author: Copilot

.github/workflows/mgmt-review.md

@@ -47,13 +47,15 @@ Fetch the PR details. If the PR is in **draft** state, mark it as ready for revi
 
 1. Fetch PR details and changed files using GitHub MCP tools.
 2. Identify the module path from the changed files (e.g., `sdk/resourcemanager/<service>/arm<package>/`).
-3. Determine if this is a **first on-board service** (first beta version): check whether the PR adds a new `ci.yml` file under the module path (i.e., `ci.yml` appears in the changed files with status `added`). If so, mark this PR as a first on-board service for Step 2.
+3. Determine if this is a **first on-board service** (first beta version): check whether the PR adds a new `ci.yml` file under the module path (i.e., `ci.yml` appears in the changed files with status `added`). If so, record this for the Step 5 comment.
 
-### Step 2 — Note first on-board service
+### Step 2 — Wait for all pipeline checks to complete
 
-> **This step only applies when Step 1 identified a first on-board service.** Skip this step entirely otherwise.
+Before analyzing CI results, ensure all pipeline checks have finished running.
 
-For a brand-new service, release pipelines do not exist yet. The service team must create them by commenting `/azp run prepare-pipelines` on the PR. Record that this is a first on-board service so that the Step 5 comment includes instructions for the service team. This does **not** block the remaining steps — proceed to Step 3 immediately.
+1. Fetch **check runs** for the PR head commit. Find the `go - pullrequest` parent check and its child jobs (`go - pullrequest (Build <job_name>)`). These are **Azure DevOps pipeline** results — do NOT call `get_job_logs` (returns 404).
+2. If the `go - pullrequest` parent check or any of its child jobs have a `status` of `queued` or `in_progress`, poll check runs periodically (e.g., every 60 seconds) until **all** pipeline checks reach a **completed** status. If checks have not completed within **30 minutes**, stop waiting and analyze whatever results are available — note incomplete checks in the Step 5 comment.
+3. Once all checks are completed, read success/failure from the `conclusion` field and extract the `target_url` for ADO log links. NEVER fabricate ADO URLs.
 
 ### Step 3 — Check for manual edits to auto-generated files
 
@@ -69,7 +71,7 @@ Auto-generated Go files contain the comment `// Code generated by Microsoft (R)
 
 If the PR is mergeable (`Squash and merge` enabled), skip to Step 5 and comment `## PR is ready to merge`.
 
-Otherwise, fetch **check runs** for the PR head commit and classify every blocking check using the reference table below. These are **Azure DevOps pipeline** results — do NOT call `get_job_logs` (returns 404). Read success/failure from the `conclusion` field and extract the `target_url` for ADO log links. NEVER fabricate ADO URLs. Also inspect the PR's changed files directly when useful (e.g., reading code for compile errors) and note any `Merging is blocked` messages.
+Otherwise, classify every blocking check using the reference table below. Also inspect the PR's changed files directly when useful (e.g., reading code for compile errors) and note any `Merging is blocked` messages.
 
 #### CI Check → Failure → Fix Reference
 
@@ -114,7 +116,7 @@ Post **exactly one** PR comment via `add_comment`. Include the marker `<!-- gh-a
 ## PR is ready to merge
 ```
 
-**If this is a first on-board service** (detected in Step 2), include this block in the comment:
+**If this is a first on-board service** (detected in Step 1), include this block in the comment:
 
 ```markdown
 ## ⚠️ First On-Board Service — Pipeline Setup Required