Correct the deploy_component response, and document the restart a deploy does not do

reference/operations-api/operations.md

@@ -999,10 +999,13 @@ Response:
 ```json
 {
 	"deployment_id": "a3f8c2d1...",
-	"message": "Component deployed successfully"
+	"restartJobId": "b7d41e09...",
+	"message": "Successfully deployed: my-app, restarting Harper"
 }
 ```
 
+`restartJobId` is present only for `"restart": "rolling"`, which is the one path that hands the restart to a separate job. An inline `"restart": true` returns the same message without it, and a deploy that does not restart returns `Successfully deployed: my-app`.
+
 #### Restarting (`restart`)
 
 <VersionBadge type="changed" version="v5.3.0" />
@@ -1015,6 +1018,23 @@ The wait follows the restart's own progress rather than a fixed timeout, so a wi
 
 `drop_component` accepts `"restart": true` and waits for the restart the same way (v5.3.0).
 
+#### Deploying without a restart
+
+<VersionBadge version="v5.2.0" />
+
+A deploy that does not restart (`"restart": false`, or omitting `restart`) flags a restart as needed when it changed something the running process cannot pick up on its own. `get_status`, called with no `id`, then reports `restartRequired: true`.
+
+Two kinds of deploy set it:
+
+- A component that had no directory before this deploy. It has never been loaded, so its routes cannot be live until Harper restarts.
+- A redeploy whose package metadata changed (v5.2.1) — a dependency or module-entry change invalidates loaded code, and package metadata sits outside most plugin file globs, so the component's own watcher does not see it.
+
+An ordinary redeploy sets nothing: the component's watched files are handled by its file watcher, which requests a restart only when the update needs one.
+
+The flag is evaluated per node. A peer applying the replicated deploy checks its own directory state, since whether the component was already active can differ from node to node.
+
+Until the restart happens, a request to a route of a never-loaded component returns a 404 naming the component and saying a restart may be needed, instead of the generic 404. That fuller message is returned only to an authenticated `super_user`. The difference between the two responses would otherwise report which component directories exist on disk.
+
 ### Deployment Operations
 
 Harper records every `deploy_component` call in the `system.hdb_deployment` table, capturing the full lifecycle of a deployment including phase transitions (prepare → load → replicate → restart → success/failed), per-node outcomes, and a bounded event log of install output.
@@ -1403,7 +1423,7 @@ Operations for restarting Harper and managing system state.
 | `restart_service`    | Restarts a specific Harper service                    | super_user    |
 | `system_information` | Returns detailed host system metrics                  | super_user    |
 | `set_status`         | Sets an application-specific status value (in-memory) | super_user    |
-| `get_status`         | Returns a previously set status value                 | super_user    |
+| `get_status`         | Returns one status value, or the instance summary     | super_user    |
 | `clear_status`       | Removes a status entry                                | super_user    |
 
 ### `restart`
@@ -1438,6 +1458,29 @@ Manage in-memory application status values. Status types: `primary`, `maintenanc
 { "operation": "set_status", "id": "primary", "status": "active" }
 ```
 
+`get_status` has two forms, and the one you get depends on whether you pass an `id`.
+
+With an `id`, it returns that one status record:
+
+```json
+{ "operation": "get_status", "id": "primary" }
+```
+
+**Without an `id`, it returns a summary of the instance** rather than a status value:
+
+```json
+{ "operation": "get_status" }
+```
+
+| Field              | Description                                                                                                                                                               |
+| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `systemStatus`     | Every status record set with `set_status`                                                                                                                                 |
+| `componentStatus`  | Per-component health, aggregated across threads: `name` plus a `status` of `healthy`, `warning`, `error`, `loading`, or `unknown`                                         |
+| `restartRequired`  | Whether a restart is pending on this node — set by a deploy that did not restart (see [Deploying without a restart](#deploying-without-a-restart)) and cleared on restart |
+| `middlewareChains` | The resolved HTTP, upgrade, and WebSocket middleware order (v5.2.0). Present only when the request passes `middleware: true`                                              |
+
+`restartRequired` is per node: it reports the node that served the request, not the cluster.
+
 ---
 
 ## Agent

release-notes/v5-lincoln/5.1.md

@@ -152,7 +152,7 @@ The response from `deploy_component` now includes a `deployment_id`:
 ```json
 {
 	"deployment_id": "a3f8c2...",
-	"message": "Component deployed successfully"
+	"message": "Successfully deployed: my-app"
 }
 ```