@bli-cockpit/cli 0.2.66 → 0.2.67

package/dist/commands/jarvis-answer-envelope.js

@@ -59,6 +59,7 @@ export const JARVIS_ANSWER_ENVELOPE_KEYS = [
     "thread_id",
     "trace_thread_id",
     "proposal_id",
+    "next_action",
     "degraded",
     "degraded_reasons",
 ];
@@ -195,6 +196,7 @@ export function buildJarvisAnswerEnvelope(input) {
         thread_id: input.thread ?? null,
         trace_thread_id: input.traceThread ?? null,
         proposal_id: input.proposalId ?? null,
+        next_action: input.nextAction ?? null,
         degraded: reasons.length > 0,
         degraded_reasons: reasons,
     };

package/dist/commands/jarvis-turn.js

@@ -158,6 +158,9 @@ export async function sendOneTurn(context, prompt, io) {
                 revised: body.revised,
                 trace,
                 proposalId: body.proposalId,
+                // BLI-3787: the sentence beside it — what a person must do next when
+                // the arm proposed something, and when it refused instead.
+                nextAction: body.nextAction,
                 // BLI-3770: the door's own structured citations. Absent from a
                 // dashboard that predates it, and the envelope falls back to
                 // reading the answer's own `Source:` lines when it is.

package/dist/commands/local-help-commands.js

@@ -254,7 +254,8 @@ export function localSubcommandHelp(command) {
                 "Trace lines arrive live while JARVIS works; pass --no-stream to wait for the whole answer in one piece instead.",
                 "--json writes one machine-readable response (including trace and model) to stdout; operational metadata stays on stderr. A --json run never streams fragments, whichever mode it is in.",
                 "A --json turn is treated as an AGENT surface: if it proposes a coding task, JARVIS answers with proposal_id and NOT the eight-character approval code, because a code a program can read is a code it could approve with. The person fetches the code themself — a Tower browser tab, their Slack DM, or an interactive `cockpit jarvis` — and hands it back. Pass --show-approval-code when a script really is driving a dispatch for a person; the run says on stderr that it did.",
-                "That object carries answer, sources (the Source: lines inside it), turn_id (pass it to --trace), thread_id (pass it to --thread), proposal_id (the coding-arm proposal this turn made, or null), degraded and degraded_reasons — the SAME shape the bli-tower MCP server's jarvis_ask tool returns, so a script and an agent read one contract. reply/thread/traceId/model/trace/latency are still there beside it and still mean what they always meant.",
+                "That object carries answer, sources (the Source: lines inside it), turn_id (pass it to --trace), thread_id (pass it to --thread), proposal_id, next_action, degraded and degraded_reasons — the SAME shape the bli-tower MCP server's jarvis_ask tool returns, so a script and an agent read one contract. reply/thread/traceId/model/trace/latency are still there beside it and still mean what they always meant.",
+                "proposal_id carries the coding-arm proposal a turn made, and is null when it made none — including when the arm refused. next_action is the sentence that says which of those it was and what a PERSON has to do about it: fetch the approval code for that proposal (a Tower tab, their Slack DM, or their own interactive `cockpit jarvis`), or approve a refused one where a person reads. A null proposal_id is never on its own. Do not send a proposal_id back on a --json turn: this is the surface the code was withheld from, and reading it back is refused here.",
                 "A turn that outlives the dashboard's own ceiling is reported as turn_timed_out — an incomplete answer is never printed as a finished one.",
                 "The command uses the existing paired device identity. It cannot override the caller, team, role, or person scope.",
                 "A thread is SINGLE-WRITER: two turns in the same conversation at the same time can read each other, and one can answer the other's question. Your own terminal is one conversation, named main, and stays that way. A --json turn is a program's, so it gets a FRESH conversation per call unless --thread names one, and the answer's thread_id is the name it used — pass that back with --thread to continue it deliberately. On a --json turn, --thread main asks for the shared default nobody chose, so it is treated as naming nothing and a fresh conversation is minted anyway.",

package/dist/commands/public-root.js

@@ -15,7 +15,7 @@ export async function runCockpitCli(argv, io) {
   }
 
   if (command === "--version" || command === "-V" || command === "version") {
-    writeLine(io?.stdout ?? process.stdout, "0.2.66");
+    writeLine(io?.stdout ?? process.stdout, "0.2.67");
     return 0;
   }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bli-cockpit/cli",
-  "version": "0.2.66",
+  "version": "0.2.67",
   "private": false,
   "type": "module",
   "bin": {
@@ -28,7 +28,7 @@
   },
   "dependencies": {
     "@bli-cockpit/memory-mcp": "0.1.9",
-    "@bli-cockpit/mcp": "0.1.8",
+    "@bli-cockpit/mcp": "0.1.9",
     "@bli-cockpit/telemetry-core": "0.1.30"
   }
 }