docs: document delay_s for deferred boot services

Author: ThomasFarstrike

docs/apps/creating-apps.md

@@ -88,7 +88,8 @@ Apps can also declare **services** — background components that run at boot ti
     "classname": "MyBootService",
     "intent_filters": [
       {
-        "action": "boot_completed"
+        "action": "boot_completed",
+        "delay_s": 120
       }
     ]
   }
@@ -101,7 +102,7 @@ Each service entry has:
 |-------|-------------|
 | `entrypoint` | Path to the Python file (relative to the app root) |
 | `classname` | Name of the `Service` subclass in that file |
-| `intent_filters` | Array of `{ "action": "..." }` objects. Use `"boot_completed"` to run at startup |
+| `intent_filters` | Array of `{ "action": "...", "delay_s": N }` objects. Use `"boot_completed"` to run at startup. Optional `delay_s` (seconds) defers the import and start of the service; `0` or absent starts immediately |
 
 Services that subscribe to `"boot_completed"` are started automatically during system boot, after the launcher is displayed. See the [Service documentation](../frameworks/service.md) for details on writing and using services.
 

docs/architecture/boot-sequence.md

@@ -19,7 +19,10 @@ MicroPythonOS consists of several core components that initialize and manage the
         - `WifiBootService` — auto-connects WiFi in a background thread
         - `WebServerBootService` — starts the HTTP web server
         - `AIOReplService` — starts the asyncio REPL task
-        - App-specific services (e.g., `OSUpdateService`)
+        - App-specific services with `delay_s: 0` or no delay (e.g., `NostrBootService`, `MeshCoreBootService`)
+    - Schedules **deferred boot services** — services declaring `delay_s` > 0 in their intent_filter are imported and started asynchronously after the delay, keeping non-critical module imports out of the boot path:
+        - `AppStoreService` (120s delay)
+        - `OSUpdateService` (90s delay)
     - Marks the current boot as successful (cancel rollback)
     - Starts the TaskManager (asyncio event loop)
 

docs/frameworks/service.md

@@ -125,7 +125,7 @@ Apps declare services in their `MANIFEST.JSON` under a `"services"` array:
       "entrypoint": "osupdate_boot_service.py",
       "classname": "OSUpdateService",
       "intent_filters": [
-        { "action": "boot_completed" }
+        { "action": "boot_completed", "delay_s": 90 }
       ]
     }
   ]
@@ -138,7 +138,7 @@ Each service entry requires:
 |-------|-------------|
 | `entrypoint` | Path to the Python file (relative to the app root) |
 | `classname` | Name of the Service subclass in that file |
-| `intent_filters` | Array of `{ "action": "..." }` objects. `"boot_completed"` triggers the service at startup |
+| `intent_filters` | Array of `{ "action": "...", "delay_s": N }` objects. `"boot_completed"` triggers the service at startup. Optional `delay_s` (seconds) defers the import and start of the service; `0` or absent starts immediately |
 
 The corresponding service code: