@rivus/agent 0.14.4 → 0.15.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rivus/agent",
-  "version": "0.14.4",
+  "version": "0.15.0",
   "description": "A local agent daemon core built around a usable agent harness and domain events.",
   "type": "module",
   "license": "MIT",
@@ -50,7 +50,8 @@
       "types": "./dist/bootstrap/pi-feishu.d.ts",
       "import": "./dist/bootstrap/pi-feishu.js"
     },
-    "./plugin/starter": "./examples/rivus-starter.plugin.mjs"
+    "./plugin/starter": "./examples/rivus-starter.plugin.mjs",
+    "./skills/runtime-management/SKILL.md": "./skills/runtime-management/SKILL.md"
   },
   "files": [
     "dist",
@@ -58,7 +59,8 @@
     "examples/*.bootstrap.ts",
     "examples/*.json",
     "README.md",
-    "LICENSE"
+    "LICENSE",
+    "skills/runtime-management/SKILL.md"
   ],
   "publishConfig": {
     "access": "public"

package/skills/runtime-management/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: runtime-management
+description: Use when the user asks what model is active, requests a persistent model change, or asks to restore the previous model; invoke the installed Rivus CLI and report the returned status.
+---
+
+# Runtime management
+
+Use the installed `rivus` executable for the personal Home's model management. The CLI is the source of truth for the
+current revision and the durable request status. It validates an exact `provider/model` submitted by the Host; it does
+not enumerate the supported model catalog. Use a model identifier already confirmed by the Home configuration,
+deployment, the provider's official documentation, or a trusted Host response. Do not guess aliases or infer an
+identifier from a model family name. When the identifier remains ambiguous, ask the user for the exact value; the Host
+performs the final validation before accepting it.
+
+## Query
+
+Run:
+
+```bash
+rivus model status --json
+```
+
+Read `current`, `source`, `revision`, and `pending` from the JSON response. If a request is in progress, keep its
+`requestId` and `reason` visible to the user. Query a known request with:
+
+```bash
+rivus model status --request <request-id> --json
+```
+
+## Set a default model
+
+Use the exact `provider/model` value confirmed by the Host. First obtain the current `revision`, then submit one request
+with a fresh request id:
+
+```bash
+rivus model set --model <provider/model> --expected-revision <revision> --request <request-id> --json
+```
+
+The first response confirms receipt. When the response is `pending`, report its `requestId` and finish the current Run.
+The Host completes validation and activation across the safe boundary and sends the final notification. A later Run can
+query the request to determine whether the final state is `applied`, `failed`, `restored`, or `recovery-required`.
+Keep the same request id after a disconnect instead of submitting the change again with a new id.
+
+## Restore the previous model
+
+Use the same revision and request rules:
+
+```bash
+rivus model rollback --expected-revision <revision> --request <request-id> --json
+```
+
+If there is no previous selection, or the provider no longer supports it, report the returned limitation. Restoring a
+model does not undo messages, memory, or completed business effects.
+
+## Trust and scope
+
+Only a trusted Host Run can authorize `set` and `rollback`. A local client without that context can read diagnostics but
+cannot grant itself permission. Do not add identity, owner, Home, credential, or authorization fields to a command.
+
+When a command reports `failed` or `recovery-required`, preserve the returned error code and request id. Do not infer
+success from process exit code `0`; inspect the JSON business status.