# Core 3.3.0rc3 integration review

This is a source-based review of the user-supplied Core archive, not a native Windows
Update qualification. AIM Core remains separately deployed and unmodified.

## Source basis

Authoritative Core topics: `ADDON_AGENTS.md`, `AGENTS.md`,
`scripts/docs/RELEASE_NOTES.md`, `RELEASE_HANDOFF.md`, `ADDON_SUPPORT.md`, `ADDON_API.md`,
`OPERATION_RESULTS.md`, `PLAYBOOKS.md`, `VALIDATION.md`, `SANITY.md`,
`scripts/docs/INSTALLATION.md`, and `deploy/README.md`.

The supplied Core ZIP contains 200 files under `aim-core-3.3.0rc3/`. Its sidecar and
ZIP integrity were checked before extraction. Archive hashes and unchanged-source
comparison are in this release's verification record.

Compared with the supplied Core 3.3.0rc1 (the actual previous WebGUI integration),
there are three added files: two Windows patch-cycle tasks and the Core installation
guide. No files were removed in that comparison. The source-version/metadata,
patch runbook/filter/catalog/schema and documentation changed. The semantic catalog
difference is confined to `maintenance_patch_os`; eight other reporting schemas are
byte-identical. Core's runtime, credentials, service transport, target-outcome,
hierarchy and staging implementations are unchanged in this comparison. This is not
an assertion that the new patch runbook was executed successfully here.

## Existing public boundaries retained

Service/wire/event API remains 1.0. Reports still use `aim_output_v1` publication and
`aim_operation_result_v1` final results, with `result_contract` captured at review.
Reports arrive at finalization, not as raw debug/stdout. Detailed progress remains
`play_task_host_v1`; native target outcomes and the two-home staging preflight remain.
No new execute-request field, credential channel, service or filesystem access is needed.

## New rc2/rc3 patch metadata consumed

Core's catalog provides reboot delay (minutes, 0..1440), reboot message and the
Windows-only `os_patching_rescan_after_reboot` boolean. Its catalog hint is `false`.
The WebGUI obtains these options and constraints from public discovery, not a
parallel defaults table. Unchanged controls are omitted to preserve inventory/role
precedence; a catalog hint is not a resolved effective inventory setting.

Windows now discovers a deterministic queue, installs one discovered update per
native invocation and stops a wave at a reboot boundary. With continuation disabled,
an AIM-performed reboot can end a successful run with `continuation_required: true`
and `remaining_updates_known: false`. An explicitly reviewed true continuation value
allows Core to rediscover after reboot, bounded to 12 cycles. This is within one Core
operation, not permission for the add-on to create more jobs.

A wave finishing without reboot can perform a final read-only search; this does not
extend the approved installation queue. When `remaining_updates_known` is true,
`pending` is the recorded final discovery only. When false, the WebGUI must not show
a pre-reboot queue or zero-length list as the established next-wave state.

The patch report adds pre/post reboot observations, delay, deferred state and a stop
reason (introduced in Core rc2). Windows adds optional continuation, cycle and
remaining-update-knowledge fields in rc3. Individual failed updates carry Core's
unsigned/hex HRESULT, reason and bounded safe message. `install_not_allowed` is not
proof of a pending reboot; `preexisting_reboot_required` is an independent Core
preflight observation. The UI displays provided codes; it does not parse fatal text,
Windows logs or native error messages.

## Consumer changes made

- Qualify exact Core 3.3.0rc3 in adapter/executor/CLI/deployment metadata, while keeping
  live capability negotiation and version rejection intact.
- Surface all catalog-driven patch controls and platform hints, with a review note
  separating reboot from continuation and preserving explicit true/false vs inherited.
- Add a report presentation model for continuation, deferred reboot, pre-existing
  reboot and bounded-cycle stop conditions. This never changes the job/Core verdict.
- Present remaining updates according to the new knowledge flag; keep raw *structured
  report JSON* available separately, not unrestricted process output.
- Preserve historical schemas and data. The same `patch_summary_v1` identifier has a
  larger closed shape now: newly added reboot fields and failure `message`/hex fields
  are required where declared. Old jobs render with their recorded schema, never
  revalidated against today's catalog or backfilled with invented false values.
- Retain journal, reports, modal, owner/admin visibility and existing retention limits.

## Qualification boundary

Core's current VALIDATION.md records static/filter/schema and disposable deployment
checks, not native Ansible 2.19.11/Windows Update/service-sandbox acceptance of rc3.
WebGUI test outcomes are recorded independently in VERIFICATION.md. Source tests and
synthetic report fixtures do not certify Windows servicing ordering, reboots, pending
update state, Server 2012 R2, or every delegated service environment.