Check the compatibility matrix at verification, at boot and after rollback #56

Summary

Refuse version combinations the application and model declare incompatible, and re-check after boot and rollback.

Problem / intent

An application and a model each declare what they need; running a combination they do not support must never happen.

Proposed solution

Compare declared contract ranges and minimum OS version between channels at verification, at every boot and after every rollback, reading the active manifests from disk so the check works before the application starts. Reject and report on mismatch; never run anyway.

• Depends on: Persist per-channel update state atomically and resume after reboot #50
• Can proceed in parallel with: Verify detached CMS signatures against an on-device trust root and revocation list #54, Validate manifest channel, version floor, upgrade path, file paths and hashes #55, Periodic health checks with warm-up and application-supplied probes #59

Contract

Declared fields, read from the active manifests on disk so the check also works before the application has started:

• Open: where runtime_contract and feature_set_version sit in a model artifact's manifest.

A combination is compatible only when all of these hold:

• the model's runtime_contract is inside the application's supported range;
• the model's feature_set_version is in the application's supported list;
• the application's min_os_version is not higher than the running image version. Versions are MAJOR.MINOR.PATCH, each part compared as a number, with no pre-release or build metadata.

When the check runs and what a failure does:

• At verification, as the last verification step, after file hashes: a new application's supported range and list must cover the active model; a new model's needs must fall inside the active application's range and list; a new application's min_os_version must not be higher than the running image. On failure the result is rejected_incompatible; the update does not enter switching and the current version is untouched.
• At every boot, after unfinished switches and rollbacks are completed, trial reboot failures are counted (with any rollback they trigger) and, on a new image's first boot, signatures are re-checked. The application is started only if the check passes; resuming downloads or verification comes after it.
• After every rollback, including a dependent rollback.
• A failure at boot or after a rollback never runs the combination: the device is unhealthy and the channels return to the most recent combination in which every channel was safe (Atomic directory switch and rollback for directory-based channels #57, rolled_back_dependency). When no retained version is compatible, that channel stays stopped and reports rejected_incompatible until a compatible version is delivered.
• A rejection reports which declared field failed.
• Open: the exact shape of the application's supported runtime_contract range and feature_set_version list in its manifest
• Open: how the check treats a channel that has no current version, such as a model channel to which no model has been delivered yet
• Open: the public API of the check: its inputs, its result, and how the failing field is reported

Acceptance criteria

• Unit test: a model whose runtime_contract is outside the application's supported range is rejected with rejected_incompatible, and the result names runtime_contract
• Unit test: a model whose feature_set_version is not in the application's supported list is rejected with rejected_incompatible, and the result names feature_set_version
• Unit test: an application whose min_os_version is higher than the running image version is rejected with rejected_incompatible; an equal version passes; 1.10.0 compares higher than 1.9.0
• Unit test: a combination that meets all three rules passes
• Unit test: at verification, a rejected new application or new model leaves the current version untouched and does not enter switching
• Unit test: the boot check reads the active manifests from a temporary directory while the application is not running, and the application is not started when the check fails
• Unit test: the check runs after a rollback, and a failing combination is reported instead of run
• Each Open item above is defined in the pull request and documented in the repository
• No deployment-specific content (organisation, site, equipment model, point table, register map or data sample) in code, tests or docs
• make verify passes

Area

• area:update — Update channels, artifact delivery, atomic switch and rollback