shraga 0.1.93 → 0.1.95

package/src/server/modules/service.ts

@@ -11,6 +11,7 @@
  *    Only state.json answers "is the module on".
  *  - Reconcile is idempotent: write-if-changed skills, upserts preserve enabled/runCount/lastRun.
  */
+import { foldLegacyRuntimePin } from '../scheduler/builtins.ts';
 import { mkdirSync, readdirSync, readFileSync, writeFileSync, existsSync, unlinkSync, renameSync, rmSync, copyFileSync, statSync, appendFileSync } from 'node:fs';
 import path from 'node:path';
 import { dataPath, DATA_DIR, PACKAGE_ROOT } from '../paths.ts';
@@ -305,6 +306,9 @@ function applyModule(rec: InstalledModule): void {
       const t = rendered.task as Record<string, unknown>;
       if (k in t && !t[k]) delete t[k];
     }
+    // A runtime knob is now expressed as the prompt's own `[engine:…,model:…]` directive, not as a
+    // shadow field — fold whatever the manifest templated into it.
+    foldLegacyRuntimePin(rendered.task as Record<string, any>);
     const existing = scheduler.getSchedule(id);
     const now = Date.now();
     const schedule: Schedule = {

package/src/server/scheduler/builtins.ts

@@ -56,6 +56,30 @@ const FAILURE_NOTIFIER_PROMPT = [
 const LEGACY_SESSION_LINE = /^.*<deployment URL>\/\?session=<sessionId>(.*)$/gm;
 const SESSION_LINE_FIX = "  *Session:* <the payload's sessionUrl, verbatim — omit this line if absent>";
 
+/**
+ * One source of truth for a prompt run's runtime: the leading `[engine:…,model:…]` directive of the
+ * prompt. `task.model`/`task.engine` were an INVISIBLE second copy — no UI ever showed them, which
+ * is how nine live schedules drifted to a half-pin (`model` set, `engine` not) that nobody could
+ * see or fix. Fold such a pin into the prompt exactly as runner.ts used to synthesize it, so the
+ * run is byte-identical for a `prompt` task and the selection is now editable where the prompt is.
+ * NOT byte-identical for a `promptFile` task: runner.ts treated `task.prompt` as dead text once
+ * `promptFile` was set, and it now survives as the directive-carrying prefix. No live schedule uses
+ * `promptFile`, and dropping the prefix instead would silently lose the pin these lines exist to
+ * preserve — so the prefix is the deliberate choice, not an oversight.
+ *
+ * Applied to schedules loaded from disk AND to a module's freshly rendered task, so a manifest that
+ * still templates a `model` knob keeps working instead of silently losing its pin.
+ * `bash`/`job` tasks have no prompt to hold a directive, so their (unreadable) pin is just dropped.
+ */
+export function foldLegacyRuntimePin(task: Record<string, any>): void {
+  if (task.kind === 'prompt' && (task.model || task.engine)) {
+    const pins = [task.engine && `engine:${task.engine}`, task.model && `model:${task.model}`].filter(Boolean);
+    task.prompt = `[${pins.join(',')}] ${task.prompt ?? ''}`;
+  }
+  delete task.model;
+  delete task.engine;
+}
+
 export function isSystemSchedule(schedule: Schedule): boolean {
   return schedule.scope === 'system';
 }
@@ -86,6 +110,16 @@ export function backfillScope(schedules: Schedule[]): void {
     if (task.kind === 'job' && task.command === 'bun run summarize:conversations') {
       task.command = SUMMARIZER_CMD;
     }
+    // Undo the `engine: 'claude-code'` pin reconcile stamped onto the failure notifier. It shipped on
+    // a premise the box's own logs disprove — nothing was ever misrouted; the deployment was simply
+    // globally on claude-code then and on agentx now — and it made the alarm the second casualty of
+    // the real failure mode (an org cap on the pinned provider). Narrow on purpose: exactly the
+    // state that clause produced (this id, that engine, no model), so it cannot eat a real choice.
+    if (s.id === FAILURE_NOTIFIER_SCHEDULE_ID && task.engine === 'claude-code' && !task.model) {
+      delete task.engine;
+    }
+    foldLegacyRuntimePin(task);
+
     // Heal a persisted failure-notifier prompt still carrying the un-supplied "<deployment URL>"
     // placeholder — reconcile won't touch task.prompt, so this is the only path that reaches it.
     if (s.id === FAILURE_NOTIFIER_SCHEDULE_ID && typeof task.prompt === 'string') {
@@ -138,11 +172,7 @@ export function ensureBuiltinSchedules(schedules: Schedule[]): Schedule[] {
         match: { status: 'error' },
         throttle: { byFields: ['name', 'error'], windowSec: 21600 },
       },
-      // Pinned to the always-registered engine ON PURPOSE. Left unpinned, this run inherits whatever
-      // agent-config.json's global `engine` happens to be — and an optional engine can simply not
-      // register on a given boot (add-on absent, missing API key), which is exactly the failure this
-      // job exists to report. Its own alert must not be the second casualty.
-      task: { kind: 'prompt', prompt: FAILURE_NOTIFIER_PROMPT, engine: 'claude-code' },
+      task: { kind: 'prompt', prompt: FAILURE_NOTIFIER_PROMPT },
       scope: 'system',
       createdBy: { uid: SYSTEM_UID, email: 'system@shraga.local' },
       createdAt: now,
@@ -167,16 +197,8 @@ export function ensureBuiltinSchedules(schedules: Schedule[]): Schedule[] {
       existing.scope = builtin.scope;
       existing.trigger = existing.trigger ?? builtin.trigger;
       existing.createdBy = builtin.createdBy;
-      // A builtin's stored task is preserved (deployments edit the prompt) — with one exception: an
-      // engine/model pin is only meaningful as a PAIR. A stored task with a `model` but no `engine`
-      // was resolved against whatever the ambient global config was at the time, which is how the
-      // failure notifier ended up pinned to `composer-2.5` while running on claude-code. So when the
-      // builtin pins an engine and the stored task pins NONE, adopt the builtin's pair wholesale.
-      // An explicit stored `engine` is a real operator choice and is left untouched.
-      if (builtin.task.kind !== 'job' && existing.task.kind !== 'job' && builtin.task.engine && !existing.task.engine) {
-        existing.task.engine = builtin.task.engine;
-        existing.task.model = builtin.task.model;
-      }
+      // A builtin's stored task is otherwise preserved — deployments edit the prompt (and with it
+      // the runtime directive), and those edits must survive an upgrade.
     } else {
       schedules.push(builtin);
     }

package/src/server/scheduler/runner.ts

@@ -9,6 +9,17 @@ import type { Schedule, ScheduleRunSummary } from './types.ts';
 import { updateRunLockPid, clearRunningMarker, loadSchedules } from './storage.ts';
 import { readOutcome, clearOutcome, pendingDeadline, outcomePrompt, MAX_PENDING_MS } from './outcome.ts';
 import { addUnread } from '../unread.ts';
+import { splitDirectiveGroups } from '../directives.ts';
+
+/** The prompt a `prompt` task runs, from wherever it is stored. Its leading `[…]` directive is the
+ *  task's runtime selection — there is no separate stored pin.
+ *  With a `promptFile`, `prompt` is a PREFIX rather than dead text: the directive has to live
+ *  somewhere the editor can rewrite, and that must not be someone's workspace file. */
+function taskPromptText(task: { prompt?: string; promptFile?: string }): string {
+  if (!task.promptFile) return task.prompt ?? '';
+  const body = readFileSync(resolvePromptFile(task.promptFile), 'utf-8').trim();
+  return task.prompt ? `${task.prompt.trim()} ${body}` : body;
+}
 
 export interface RunContext {
   sessionId: string;
@@ -194,13 +205,19 @@ export async function runSchedule(
 
   let prompt: string;
   if (resume) {
-    // The original task prompt is already in the conversation from the interrupted run.
+    // The original task prompt is already in the conversation from the interrupted run — but a
+    // resume prompt is a fresh "continue where you left off" string, not the saved original, so the
+    // task's own leading `[engine:…,model:…]` directive has to be carried onto it. Without that the
+    // resumed turn runs on the global default: a different engine, and a different vendor's bill.
     prompt = resume.prompt;
+    const groups = task.kind === 'prompt' ? splitDirectiveGroups(taskPromptText(task), { strict: true }).groups : [];
+    const raw = groups.filter(Boolean).join(',');
+    if (raw) prompt = `[${raw}] ${prompt}`;
   } else if (task.kind === 'bash') {
     const cmd = override || task.command;
     prompt = `Run exactly this bash command and report the result concisely:\n\n\`\`\`bash\n${cmd}\n\`\`\``;
   } else {
-    let base = task.promptFile ? readFileSync(resolvePromptFile(task.promptFile), 'utf-8').trim() : (task.prompt ?? '');
+    let base = taskPromptText(task);
     if (override) base = `${base}\n\n---\nAdditional instructions for this run:\n${override}`;
     if (eventCtx) base = `${base}\n\n---\n${formatEventBlock(eventCtx)}`;
     prompt = base;
@@ -216,15 +233,6 @@ export async function runSchedule(
     prompt = `${prompt}\n\n---\n${outcomePrompt(sessionId)}`;
   }
 
-  // task.engine/task.model ride the same prompt-directive channel users type by hand —
-  // parseDirectives strips them and resolves aliases. Prepending (vs new plumbing) also persists the
-  // choice into the saved prompt, so the session UI shows what the schedule actually requested.
-  // Applied on RESUME too: a resume's prompt is a fresh "continue where you left off" string, not the
-  // saved original, so skipping this here silently dropped the schedule's engine/model pin and let the
-  // resumed turn run on the global default — a different engine, and a different vendor's bill.
-  const pins = [task.engine && `engine:${task.engine}`, task.model && `model:${task.model}`].filter(Boolean);
-  if (pins.length) prompt = `[${pins.join(',')}] ${prompt}`;
-
   // Save the synthesized user prompt to the conversation (skip on resume — task prompt already persisted).
   if (!resume) {
     appendMessage(sessionId, {

package/src/server/scheduler/types.ts

@@ -19,11 +19,16 @@ export interface EventThrottle {
   windowSec: number;
 }
 
-/** `engine`/`model` pin the runtime a run uses (e.g. engine 'agentx' + model
- *  'cursor/composer-2.5'); both ride the prompt-directive channel — see runner.ts. */
+/** The runtime a prompt run uses is NOT a field here: it is the leading `[engine:…,model:…]`
+ *  directive of the prompt itself (or of the promptFile's contents) — one source of truth, editable
+ *  and visible in the same place the prompt is. A separate stored pin shadowed it invisibly, which
+ *  is how nine live schedules ended up half-pinned (`model` set, `engine` not) with no UI to see it.
+ *  `bash` and `job` carry no selector: `bash` has no prompt to hold a directive (its prompt is a
+ *  fixed synthesized wrapper) and `job` never reaches an agent at all — both follow agent config.
+ *  Pin a shell command's runtime by writing a prompt task that runs it. */
 export type Task =
-  | { kind: 'prompt'; prompt?: string; promptFile?: string; model?: string; engine?: string }
-  | { kind: 'bash'; command: string; model?: string; engine?: string }
+  | { kind: 'prompt'; prompt?: string; promptFile?: string }
+  | { kind: 'bash'; command: string }
   | { kind: 'job'; command: string };
 
 /** Visibility: 'system' schedules + their sessions are shared with all whitelisted users; 'user' is private to createdBy. */