Ansible/scripts/docs/RELEASE_HANDOFF.md

AIM 3.3.0rc8 Core and add-on handoff

• AIM-owned documentation is centralized under scripts/docs/; the installation-root README.md is operator-owned and preserved.

3.3.0rc8 final Windows Checkmk script placement

• citrix_sessions_customized.ps1, veeam_o365_status.ps1, and veeam_backup_status.ps1 are AIM-managed custom plugins under $CUSTOM_PLUGINS_PATH$.
• veeam_backup_license_status.ps1 is a VBR-detected local check under $CUSTOM_LOCAL_PATH$.
• AIM emits exact custom-plugin rules before the generic plugin rules and no longer needs to place these custom scripts in Checkmk's built-in plugin tree.
• Selected custom-plugin deployment removes only known legacy AIM-managed copies from the historical local directory and, where applicable, the historical built-in plugin directory. Unknown/custom files remain untouched.
• Service/wire/event API 1.0 and the existing Checkmk structured result schemas are unchanged.

Release status

Candidate implementation is complete for the nine agreed reporting operations. Local validation and limitations are maintained only in VALIDATION.md. No new native controller/Windows/Linux acceptance is claimed. The remaining operator gate is SANITY.md. Do not relabel older successful runs as candidate tests.

What independent teams consume

The stable boundary remains aim.services.v1 / aimctl, not private callbacks or UI modules. Inspect operation_results, then catalog result/prepared result_contract. Consume final operation_result in either progress mode. No add-on source was inspected, modified or required. Existing adapters continue to receive previous fields; an updated adapter renders the additional data without reconstructing it from task events.

Read the authoritative add-on guide, API, result protocol and support matrix. Exact payload shapes live in playbooks/schemas/ and are included in public catalog metadata.

Keep overall Core status, native per-target outcomes and report availability separate. A native exit 0 plus missing required output yields Core result_validation failure. A native failed job can still provide useful report data. Do not replay either case without an explicit new operator decision, approval and fresh credentials.

Implementation map for future Core work

• integrations/output_policy.py: standalone JSON schema subset and data validator.
• playbooks/catalog.py: resolve/validate catalog-owned schemas.
• integrations/callbacks/aim_safe_events.py: verify set_stats provenance/no_log, reconcile final custom stats and send bounded private chunks.
• runtime/outputs.py: reassemble/revalidate, apply known-secret suppression and construct final report availability. Independent of detail/summary mode.
• services/v1: optional metadata/final result fields and unchanged lifecycle controls.
• playbooks/filter_plugins/aim_reports.py: runbook-owned normalizers, no Core dispatch.
• playbooks/schemas: nine static data shapes. Add new schemas without Core branches.

Deployment

Use the full replacement ZIP and checksum with the normal operational deployer. Prefer automatic existing-interpreter discovery; do not require a remembered AIM_PYTHON variable. Review retirement/removal entries as well as writes. Quiesce before apply and preserve recovery data. The narrow executor staging exceptions remain necessary. Core does not modify unit files or prove another service account can use its paths/keys/collections.

Open qualification and limits

Native set_stats/callback behavior on 2.19.11, real Windows/Linux reports and package manager tests remain controller gates. Global transport is implemented but no bundled operation uses it; native global/serial-run_once behavior needs separate qualification. Config filtering is an explicit safety subset, not a universal secret scanner. Package snapshots describe net observed changes, not an exhaustive transaction journal. No raw result API, Custom credential overrides, key export or automatic permission migration.

3.3.0rc8 native-module baseline

The canonical controller remains ansible-core 2.19.11, but Windows playbooks now require ansible.windows >=3.8.0,<4.0.0 so Core can use the collection-owned win_reboot_info detector. Existing 3.2.x installations must update that collection explicitly before rc5 acceptance. aimctl capabilities advertises the floor and readiness rejects older versions.

The audit also moved Checkmk file reads to win_stat/slurp, Linux package snapshots/version queries to package_facts, and Linux Checkmk final service reporting to service_facts. Reviewed custom commands remain only where current native modules do not preserve AIM's required semantics. See RELEASE_NOTES.md.

3.3.0rc8 patch-runbook delta

The public Core API remains 1.0. os_patching_rescan_after_reboot and the additive Windows fields in patch_summary_v1 remain catalog/result-driven. Do not hard-code UI defaults.

rc4 removes rc3's AIM-owned per-update queue. Each Windows patch wave is one native ansible.windows.win_updates install invocation with the selected categories and reboot: false. This intentionally delegates update ordering/coordination inside the wave to the collection and Windows Update Agent while preserving AIM ownership of the reviewed reboot message, delay, and whether another post-reboot wave is authorized.

The default continuation remains false. After any AIM-performed reboot, including a pre-existing-reboot preflight, the run stops unless the operator explicitly enabled post-reboot continuation. A failed wave is never automatically replayed. Explicit continuation remains defensively capped at 12 waves.

Per-update records returned by win_updates are still normalized into bounded installed and failed records. 0x80240016 remains install_not_allowed, not proof of a reboot; the independent preflight remains the source for preexisting_reboot_required.