## TL;DR
False success is the worst patch-agent bug because it poisons every downstream decision. The rule: success means verified state, not a happy exit code. After install, the agent must re-query the host (is the KB listed as installed, is the package version the target version, did a post-reboot check pass) and classify outcomes as installed, installed-pending-reboot, failed, or unknown. Know the treacherous codes: Windows 3010 means success plus reboot required, while some installers return 0 for a rollback.

```text
agent reported success on hosts where the update install failed
```

## Use this when
- Audits or vulnerability scans find missing patches on hosts reported patched.
- The agent success rate is implausibly perfect across waves.
- Success was recorded at install time with no post-check.

## Not for this skill when
- The patch installed and verified, then a later update or admin removed it. That is drift after success, handled by reconciliation.
- The host is mid-reboot and genuinely unknowable at report time. It should be unknown, not success.

## Steps
1. List the outcome signals the agent currently trusts and find where verification is absent. Verify: the gap (exit code only, log scrape only) is pinpointed
2. Implement post-install verification per platform: query installed updates or package version, compare against the target set, and record the raw evidence. Verify: verification output is stored per host, not just a boolean
3. Handle reboot-required outcomes as a distinct state and verify again after the reboot completes. Verify: 3010-class results are not counted as final success until the post-reboot check passes
4. Treat verification failure or unreachable-after-install as failed or unknown respectively, never success. Verify: a test with a sabotaged install yields a non-success state
5. Backfill: run verification across the last wave reported successes and report the true rate. Verify: the corrected success rate is published in the wave record

## Variant phrasings
### agent reported success but patch failed verify installed state
The core phrasing.
### exit code 3010 success reboot required misread
The treacherous-code phrasing.
### false success rate patch audit verification step
The audit phrasing.

Compatibility: Compatibility: Windows (installed update queries, DISM, WMI) and Linux (rpm, dpkg version queries); verifier design is platform-specific, the state model is not.

## Why it happens
Installers are optimistic reporters: wrappers swallow errors, exit codes are overloaded, and Windows servicing in particular defers the real verdict until after a reboot completes the transaction. An agent that records the installer opinion instead of the host state will manufacture false confidence at scale, and false confidence in patching becomes unpatched vulnerabilities nobody is looking for.

## Edge cases / pitfalls
- Sample-verify even when full verification is expensive; a 10 percent audit sample catches systematic false success early.
- Keep the distinction between failed and unknown sharp; merging them hides unreachable hosts inside the failure count.
- When a vendor installer is a known liar, wrap it: snapshot state before, install, diff state after, and judge from the diff.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_c9qiMfelx-dKZWQMuVFQIg