Ansible/scripts/docs/ADDON_SUPPORT.md

AIM 3.3.0rc8 support matrix

Service/wire/event 1.0 is stable and additive. Implementation status and controller qualification are different. Use live capabilities; the JSON file alongside this guide is only a default capability snapshot. VALIDATION.md is the sole current evidence record.

Capability	Implementation	Activation/qualification
Discovery/catalog/explicit prepare	Supported	Required OS group/filesystem access
Inventory hierarchy v1	Supported, read-only	No independent inventory semantics in add-ons
Staging preflight v2	Supported	Test both applicable homes inside the real sandbox
Native execution	Supported same-UID profile	Explicit config opt-in; ansible-core 2.19.11 and ansible.windows >=3.8.0,<4.0.0
Private credentials	Supported one-run provider/FD	Not generic request JSON; no native prompt automation
Detailed progress v1	Supported opt-in	Canonical callback/target acceptance required
Per-target outcomes v1	Supported summary/detail	Native final stats, not application-completion inference
Purposeful operation reports v1	Implemented candidate	Nine per-host schemas; native acceptance pending
Global operation report transport	Implemented candidate	No shipped global publisher; separate native qualification
Parsed Checkmk user config	Implemented candidate	Restricted basename/size; recognized secrets and commands redacted
Custom credentials / password-only verification	Unsupported	Supplied passwords remain native defaults
Cross-UID broker, key export, automatic owner migration	Unsupported	Independent execution identity must already be authorized
API inventory/Vault mutation or bootstrap	Unsupported	Existing terminal workflows remain available
Arbitrary debug/stdout/stderr/results	Unsupported	Only explicitly declared validated report data
Automatic replay after launch	Unsupported	Explicit new operator decision required

A structured result is operational data and can reveal host inventory/configuration choices even after credential redaction. Add-ons must restrict access, safely render text and bound retention. Core does not implement their browser RBAC/CSRF/session policy.

OS patch presentation in 3.3.0rc8

Add-ons obtain reboot delay/message and Windows post-reboot continuation from normal catalog metadata; no private UI contract is required. The os_patching_rescan_after_reboot default is false. A normal Windows patch run submits one selected update wave to native ansible.windows.win_updates with reboot: false, then applies AIM reboot policy after the wave returns. Show continuation_required: true as a request for a new operator-approved run, not as a Core failure and not as permission to submit another job automatically.

If remaining_updates_known is false, do not infer the post-reboot patch state from the pre-reboot queue. If true, pending is a read-only final discovery. For Windows Update failures, render the bounded failed_updates fields; do not parse raw task/event text. install_not_allowed can mean an active installer or mandatory reboot, while preexisting_reboot_required is a distinct AIM preflight result.

Veeam O365 plugin relocation

The Checkmk Veeam O365 script destination changed in Core 3.3.0rc8, but this is not an add-on API change. Consumers continue to use Core catalog/execution/results and must not reconstruct Checkmk filesystem paths independently.