viber-channel 0.8.12 → 0.8.13

package/lib/runner_exec.ts

@@ -291,6 +291,49 @@ export interface ExecDeps {
   writeSpec?: SpecFileWriter;
   /** Injectable local-log writer (tests). Returns the log path. */
   writeLog?: (commandId: string, recap: string) => string;
+  /** Injectable daemon-stderr writer (tests). Defaults to process.stderr. */
+  writeDaemonLine?: (line: string) => void;
+}
+
+/** Where the log lives, as shown to whoever reads the WEB (#506): RELATIVE, so
+ *  it names the file without carrying the machine's absolute path — home
+ *  directory and user name included — to the server. The absolute path stays on
+ *  the daemon's own stderr, which never leaves the machine. */
+export function runnerLogRef(commandId: string): string {
+  return `.viber/runner-logs/${commandId}.log`;
+}
+
+/** What `writeRunnerLog` returns when it could NOT write (unwritable dir, full
+ *  disk). Named, because the remote message must not point at a file that was
+ *  never created. */
+export const LOG_UNAVAILABLE = "(local log unavailable)";
+
+/** The log reference to put in the REMOTE message, or undefined when no log
+ *  exists (#506 review, both reviewers): pointing someone at
+ *  `.viber/runner-logs/<id>.log` when the write failed would be this issue in
+ *  miniature — a component asserting more than it knows, on the very sentence
+ *  this step fixes. Callers fall back to the no-path wording. */
+export function remoteLogRef(commandId: string, logPath: string): string | undefined {
+  return logPath === LOG_UNAVAILABLE ? undefined : runnerLogRef(commandId);
+}
+
+/** The one line of a recap worth putting on the daemon's stderr: its first
+ *  `error:` line, bounded. Already redacted upstream by `redactSecrets`. Falls
+ *  back to the first non-empty line when the CLI printed no `error:` line, so a
+ *  failure is never reported as silence.
+ *
+ *  The result must be ONE line: it is written with a trailing newline onto a
+ *  shared stream, so any control character surviving inside it could forge a
+ *  second log line. Hence splitting on a LONE `\r` too (Codex review — a bare CR
+ *  is what a progress-bar writer emits), and stripping the remaining C0/C1
+ *  controls rather than trusting the split alone. */
+export function firstErrorLine(recap: string, max = 300): string {
+  const lines = recap
+    .split(/\r\n|\r|\n/)
+    .map((l) => l.replace(/[\u0000-\u001f\u007f-\u009f]/g, " ").trim())
+    .filter(Boolean);
+  const line = lines.find((l) => l.startsWith("error:")) ?? lines[0] ?? "(no output)";
+  return line.slice(0, max);
 }
 
 /** Write the full launch recap to a 0600 LOCAL log (never sent to the server —
@@ -303,7 +346,7 @@ export function writeRunnerLog(commandId: string, recap: string, cwd: string = p
     mkdirSync(dir, { recursive: true });
     writeFileSync(path, recap, { mode: 0o600 });
   } catch {
-    return "(local log unavailable)";
+    return LOG_UNAVAILABLE;
   }
   return path;
 }
@@ -447,6 +490,21 @@ export async function executeClaim(
     // marker (older vibe-master, output lost to maxBuffer) we degrade to exactly
     // the previous message rather than inventing a cause.
     const logPath = deps.writeLog ? deps.writeLog(cmd.id, recap) : writeRunnerLog(cmd.id, recap);
+    // #506, the issue's second defect: the remote message sent people to "the
+    // machine's log", and the log they actually open — the daemon's — only ever
+    // said "reconcile: handled 1 command(s)". A failure now states itself where
+    // it is read FIRST. This stream is local, so the ABSOLUTE path belongs here;
+    // what travels to the server is the relative ref below.
+    if (!ok) {
+      const writeDaemonLine =
+        deps.writeDaemonLine ?? ((line: string) => process.stderr.write(`${line}\n`));
+      writeDaemonLine(
+        `[runner] spawn FAILED command=${cmd.id} reason=${reason ?? "unknown"} log=${logPath} ${firstErrorLine(recap)}`,
+      );
+    }
+    // Resolved ONCE: three call sites in a ternary could drift apart under a
+    // later edit, and they must agree on whether a log exists (Opus review).
+    const logRef = remoteLogRef(cmd.id, logPath);
     const finalStatus = await report(
       auth,
       cmd.id,
@@ -456,8 +514,15 @@ export async function executeClaim(
             fencing_token: cmd.fencing_token,
             status: "failed",
             error: reason
-              ? messageForReason(reason, detail, rosterNames(cmd.prefix, cmd.template_spec.roles))
-              : "team spawn failed — see local runner log",
+              ? messageForReason(
+                  reason,
+                  detail,
+                  rosterNames(cmd.prefix, cmd.template_spec.roles),
+                  logRef,
+                )
+              : logRef
+                ? `team spawn failed — see ${logRef} on that machine`
+                : "team spawn failed, and the local log could not be written on that machine",
             ...(reason ? { reason } : {}),
           },
       fetchImpl,

package/lib/spawn_reason.ts

@@ -22,6 +22,7 @@ export const SPAWN_REASONS = [
   "already_running",
   "partial_team",
   "template_invalid",
+  "roster_invalid",
   "codex_unavailable",
   "launch_failed",
   // Emitted by the runner itself
@@ -176,6 +177,7 @@ export function messageForReason(
   reason: SpawnReason,
   detail?: string,
   roster: readonly string[],
+  logRef?: string,
 ): string {
   const safe = keepRosterNames(detail, roster);
   const names = safe ? ` (${safe})` : "";
@@ -197,7 +199,21 @@ export function messageForReason(
       // passes --spec-file. So this means the server's own snapshot could not be
       // read back — a defect. Telling the user to go read a log they cannot open,
       // for a problem they did not cause, would repeat this issue in miniature.
-      return "the roster sent for this spawn could not be read back on the runner machine — this is likely a defect, not something you did wrong; the full error is in the machine's log";
+      // #506, second defect of the issue: this sentence sent the reader to "the
+      // machine's log" WITHOUT naming it — and the log they did open, the
+      // daemon's, said nothing about the failure. `logRef` is the RELATIVE path
+      // (`.viber/runner-logs/<command_id>.log`): it locates the file without
+      // shipping an absolute Windows path — hence the machine's user name — to
+      // the server and onto someone's screen.
+      return `the roster sent for this spawn could not be read back on the runner machine — this is likely a defect, not something you did wrong; the full error is in ${logRef ?? "the machine's log"} on that machine`;
+    case "roster_invalid":
+      // #506: the OTHER half of what template_invalid used to swallow. The
+      // snapshot was read fine — it is the ROSTER that cannot be launched as
+      // written, and that IS the template author's to fix. Two catches, two
+      // reasons: this one says "you can fix this", template_invalid says "this
+      // is a defect on our side". Saying the second for the first sends someone
+      // to read a log for a mistake they could correct in two clicks.
+      return `this team template cannot be launched as written${names} — fix the template, then spawn again`;
     case "codex_unavailable":
       return "codex is not launchable on this machine, so no agent was started — install codex or set VIBER_CODEX_BIN";
     case "launch_failed":

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "viber-channel",
-  "version": "0.8.12",
+  "version": "0.8.13",
   "description": "Voice + text MCP channel between a Claude Code session and the Viber UI (https://viber.dgypx.dev). Push transcripts to Claude; send_message tool delivers text back to the UI.",
   "type": "module",
   "bin": {