Nemoclaw Maintainer Fix E2E Failures

<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->

<!-- SPDX-License-Identifier: Apache-2.0 -->

Continuously Fix E2E Failures on Main

Continuously inspect automatic E2E results for main. Coordinate ownership and merge decisions through GitHub.

Set the Operating Rules

1. Start without a scheduled end time. Do not infer an end time from local time, a shift change, a passing run, or an empty queue.
2. Keep release operations out of scope. Never change, retag, publish, or otherwise touch a release, tag, or release artifact during this workflow. Route release work to the existing release workflow.
3. Confirm maintainer authorization. Merge only when the request grants it. Otherwise, leave the PR approval-ready and continue the loop.
4. Check Git and GitHub access. Follow Git and GitHub Access Hard Stop on access failure.

Do not declare success or end the loop because the queue is empty or the newest run passes. Wait for the next automatic main result.

Keep the Queue

Read Queue and Ownership before the first scan. Keep one table grouped by root cause:

Use only these states: unclaimed, active, waiting-ci, waiting-review, approval-ready, merged, obsolete, and blocked.

Track each observed workflow run by run ID, attempt, status, conclusion, and job set. Re-read an in-progress or queued run when its state changes. Do not reanalyze an unchanged completed run.

Run the Loop

Repeat these steps continuously while the loop remains authorized:

1. Refresh origin/main. List automatic E2E runs for that commit SHA and later main commit SHAs.
2. Inspect only new or changed runs. Load nemoclaw-maintainer-classify-ci-failure to read one failed job's bounded logs and optional retained artifact before identifying the earliest actionable product, test, workflow, runner, or cleanup failure.
3. Group failures that share the same causal signature. Do not equate a job name with a root cause.
4. Apply E2E selection and authoring before repairing a test failure. Keep live evidence only for a distinct live contract.
5. Reconcile each group with open PRs before editing. If another maintainer owns it, record that PR and take the next unowned group.
6. Prefer a peer E2E maintenance PR that needs review or a final merge decision before starting another fix.
7. Select one unowned root cause. Claim it before the product fix with a draft PR whose initial diff contains evidence for only that root cause.
8. Work on only that root cause. Add the diagnostic or regression evidence that should have caught an escaped defect.
9. When the PR waits for CI or peer review, stop editing it. Review a peer PR or take the next unowned root cause. Edit only one fix at a time.
10. Revisit waiting and blocked groups during each scan. Rescan after a run, check, review, PR, or merge state changes. Rescan for each new automatic main result.

If nothing is actionable, use the available wait or monitoring mechanism. Resume when a relevant result changes.

Apply Common Decisions

• If Linux and macOS jobs have the same stable readiness signature, group them in one claim.
• If the latest PR commit changes, discard the review of the prior commit. Claim and review the latest PR commit before approval.
• If a later automatic main run proves that another merge removed the root cause, close the open fix as obsolete. Credit only the superseding fix.

Claim One Root Cause

Before changing product code:

1. Apply the ambiguous GitHub write rule in Review and Merge to every GitHub write.
2. Search open PR titles and bodies using the run ID, job ID, stable error signature, affected component, and likely fix area.
3. Read plausible matches. A different job with the same cause is already owned; a similar symptom with a different cause is not.
4. Create a branch from refreshed origin/main.
5. Add one diagnostic or regression test for the root cause when feasible. If no test can demonstrate only that root cause before the fix, mark the group blocked. Do not edit product code or add an unrelated placeholder diff.
6. Immediately before creating the draft, re-read open PRs and agent coordination for the root-cause key. Recount the author's open PRs under the policy from refreshed origin/main. Run both checks immediately before the write.
7. If a matching claim exists or the new PR would exceed the limit, do not create it. Record the existing owner or limit state and rescan.
8. Otherwise, open a draft PR assigned to its author. Follow nemoclaw-contributor-create-pr for the template, verified commits, and DCO declaration.
9. Put the root-cause key, source workflow URL, source run ID, failed job names and IDs, and failure signature in the PR body. Fix exactly one root cause in that PR.

Do not begin a second active fix for the same agent. Waiting PRs may accumulate only within the open-PR limit.

Review and Merge Peer PRs

Read Review and Merge before reviewing, approving, refreshing, or merging an E2E maintenance PR.

• Never approve your own PR. After an independent approval of the latest PR commit, either the author or another maintainer may perform the final merge.
• Independently review another maintainer's commit under review. Do not exchange approvals without reviewing correctness, security, tests, and scope.
• Do not duplicate an active peer review. Respect an explicit review claim for the same commit SHA in agent coordination, a PR comment, or a submitted review.
• Do not manually request reviewers unless the current user or repository-owned configuration authorizes the request. Follow Follow Up on PR CI and Reviews.
• Require at least one approval of the latest PR commit from an account that did not open, author, or co-author the PR.
• Require the maintainer gate checker, all GitHub-required checks, and any applicable security review to pass.
• Refresh a branch only at the final merge gate and only when the decision table requires it. Refresh before approval because the new commit invalidates earlier approval and CI evidence.
• Re-read the PR and rules immediately before merge. Never use an administrator bypass.