## TL;DR
Reboot pending is a success-in-progress state, not a failure flavor. The agent state model must separate install outcome from reboot state: a host can be installed-and-pending-reboot, and its final verdict waits for the post-reboot verification. Fix the classification where the flag is read (the compliance query or the agent status mapping), align the report categories with the model, and make retries skip pending-reboot hosts until they have rebooted and been rechecked.

```text
agent failed by treating reboot pending flag as update failure
```

## Use this when
- Failure counts include hosts that show the update as installed after a manual check and a reboot.
- The agent retries installs on hosts that are simply waiting for their reboot window.
- Failure rate drops to near zero after someone reboots the flagged hosts by hand.

## Not for this skill when
- The host needs a reboot because an earlier, different update failed and rolled back to a pending state. Read the per-update state, not just the flag.
- The flag is stale and never clears (a servicing flag bug on the host). That host needs the stale-flag remediation, not just reclassification.

## Steps
1. Trace where the agent reads host state and how the reboot-pending flag maps into its outcome enum. Verify: the exact mapping that converts pending into failed is located
2. Change the state model: install outcome (installed, failed, not attempted) tracked separately from reboot state (none, pending, done), with final success requiring installed plus reboot done plus post-reboot verification. Verify: the model is reflected in the tracker schema and the report
3. Update retry logic to exclude installed-pending-reboot hosts from reinstall attempts and route them to the reboot phase. Verify: a test wave performs zero reinstalls on pending hosts
4. Reclassify the current fleet records using host evidence, moving false failures to their true states. Verify: the corrected failure rate is restated in the wave report with a note
5. Add a report check: pending-reboot hosts older than a defined age (for example past their reboot window) escalate as a reboot-scheduling problem, not as patch failures. Verify: aging pending hosts surface under the right problem label

## Variant phrasings
### reboot pending flag counted as update failure agent state model
The main phrasing.
### installed pending reboot separate outcome and reboot state
The modeling phrasing.
### false failure rate patch report pending reboot hosts
The reporting phrasing.

Compatibility: Compatibility: Windows hosts (CBS and Windows Update pending flags) and Linux (reboot-required indicators such as the var run reboot-required file on Debian-family).

## Why it happens
The bug is a modeling shortcut: one flag read as one verdict. Servicing reality is two-dimensional, because installing and rebooting are separate acts separated by policy and time, especially in fleets where reboots wait for windows. Collapsing the dimensions manufactures failures, and manufactured failures trigger real harm: reinstall attempts on healthy hosts, wasted windows, and a failure metric nobody trusts, which then hides genuine failures in the noise.

## Edge cases / pitfalls
- Keep the dimensions separate in every downstream consumer (dashboards, alerts, SLA math), not only in the tracker, or the shortcut reappears in reporting.
- A host can be pending reboot from an update outside the wave; the model should record which update set the flag when that is knowable.
- Post-reboot verification closes the loop: pending is a promise, verification is the proof.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_V9pvfiA_oDWSjycW6iBR9Q