Ref #03. Refactoring.

adr/ADR-011-device-initiated-update-checks.md

@@ -14,7 +14,7 @@ The request identifies the device, for example by serial number, and includes re
 
 Checking for updates does not automatically start installation. The device can show “Updates available” and wait for an operator, or proceed according to its automatic update settings.
 
-Use scheduled checks and allow a local operator to request a check. Apply connection preferences, such as Wi-Fi-only access, to the relevant checks and downloads.
+For devices with regular power cycles, check once at power-on when a suitable connection is available. Allow a local operator to request a check as well. Devices that run continuously can use scheduled checks. Apply connection preferences, such as Wi-Fi-only access, to the relevant checks and downloads.
 
 ## Decision Drivers
 
@@ -30,16 +30,15 @@ Use scheduled checks and allow a local operator to request a check. Apply connec
 
 - The basic exchange is simple: the device asks and the server responds.
 - No permanent connection is needed to discover updates.
-- Scheduled and operator-triggered checks use the same mechanism.
+- Power-on, scheduled, and operator-triggered checks use the same mechanism.
 - An offline device can check when it reconnects.
 - Finding an update and deciding when to install it remain separate steps.
 
 ### Negative
 
-- A device may not discover a release until its next check.
-- Frequent checks create traffic even when no update is available.
+- For continuously running devices, power-on checks alone are insufficient if updates need to be discovered during operation. Scheduled or manual checks are needed.
+- If frequent scheduled checks are used, they create traffic even when no update is available.
 - Large groups of devices need staggered checks and retry delays to avoid contacting the server at the same time.
-- The server cannot make an offline device check immediately.
 
 ## Special Considerations
 
@@ -61,7 +60,9 @@ A serial number identifies a device; it is not a secret or proof of identity. Wh
 
 ### Connection and Operator Preferences
 
-A device may check automatically after connecting to Wi-Fi, at a scheduled interval, or when an operator selects “Check for updates.” Downloading a large image and restarting the device can have their own conditions.
+For a device that is powered on for each work session, a single check at startup may be enough. If updates are installed only outside normal work, discovering a release during that work may offer little benefit.
+
+A device that stays on continuously needs another trigger, such as a scheduled or operator-requested check. Downloading a large image and restarting the device can have their own conditions.
 
 For example, the device can discover an update now, download it later over Wi-Fi, and ask the operator before restarting. A request to check does not have to mean permission to perform every later step.
 
@@ -69,7 +70,9 @@ For example, the device can discover an update now, download it later over Wi-Fi
 
 If the server is unreachable, keep the current software running and retry later. An unsuccessful check means the device could not obtain current information; it does not mean that no updates exist.
 
-Once an update has been selected, [ADR-012](ADR-012-device-controlled-update-execution.md) describes how the device can manage installation, activation, and recovery without a continuous server connection.
+### After Download
+
+When an update is approved and all required files and verification information are available, the device can manage installation, activation, and recovery locally. For devices that can check their essential functions locally, these steps need not depend on a continuous server connection. The device saves its progress and reports the result when connectivity returns.
 
 ## Applicability