# 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](VALIDATION.md).
No new native controller/Windows/Linux acceptance is claimed. The remaining operator
gate is [SANITY.md](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](ADDON_AGENTS.md), [API](ADDON_API.md),
[result protocol](OPERATION_RESULTS.md) and [support matrix](ADDON_SUPPORT.md). 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`.