diff --git a/reference/operations-api/operations.md b/reference/operations-api/operations.md
index 256d42ac..8f85c924 100644
--- a/reference/operations-api/operations.md
+++ b/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`)
@@ -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
+
+
+
+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
diff --git a/release-notes/v5-lincoln/5.1.md b/release-notes/v5-lincoln/5.1.md
index fe8a2a9a..6452ceea 100644
--- a/release-notes/v5-lincoln/5.1.md
+++ b/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"
}
```