muse-crew 0.7.4 → 0.7.6

package/API.md

@@ -214,7 +214,7 @@ Update a dispatch reservation with the real platform workflow run ID. Called by
 | `task_id` | string | Required. The task that was dispatched. |
 | `run_id` | string | Required. The real platform run ID (e.g. `workflow-run-xxx`). Must not be `"pending-dispatch"`. |
 
-Fails closed: throws if no reservation exists for the task (launching without a reservation is forbidden). Returns `{ ok: true, task_id, run_id }`.
+Fails closed: throws if no reservation exists for the task (launching without a reservation is forbidden). Also records a durable platform run -> task mapping (`platform_run_tasks`) — the worker is the only party that ever knows both IDs at once, and the poll loop's platform-failure monitor resolves the task through this mapping, so a dead run is requeued on the next tick instead of waiting out the zombie-session sweep. Returns `{ ok: true, task_id, run_id }`.
 
 ### `clear-reservation`
 
@@ -295,7 +295,7 @@ The platform records workflow run status in `runtime.workflow_runs` — separate
 
 ### `record-platform-failure`
 
-Record a platform workflow run failure. Correlates with a crew telemetry run by timestamp proximity (±60s) if `crew_run_id` is not provided.
+Record a platform workflow run failure. Correlates the task in this order: (1) the durable `platform_run_tasks` mapping written by `acknowledge-dispatch-run`, (2) timestamp proximity (±60s) between `platform_created_at` and crew telemetry launch time (fallback for runs launched before the mapping existed), (3) an explicit `crew_run_id`/`task_id` when provided. A failure that correlates to no task is kept with `task_id: null` and reported as skipped by retry.
 
 | Field | Type | Notes |
 |-------|------|-------|
@@ -324,6 +324,8 @@ Returns `{ ok: true, failures: [...] }`.
 
 Retry a task whose workflow died on a platform failure. Clears the stale reservation, re-queues the task to `todo`, and increments the retry count. If `retry_count` >= `max_retries` (default 3), parks the task instead.
 
+**Supersede guard:** if a newer platform run has been linked for this task since this failure's run, the task is already owned by the successor — the retry is skipped instead of clobbering live work (a late detection of an old dead run never resets a redispatched task).
+
 | Field | Type | Notes |
 |-------|------|-------|
 | `platform_run_id` | string | Required. |

package/lib/crew-api.js

@@ -628,6 +628,17 @@ commands["acknowledge-dispatch-run"] = (db, args) => {
   if (info.changes === 0) {
     throw usageError("no reservation exists for task_id — launch without reservation is forbidden.");
   }
+  // Durable platform run -> task mapping (2026-09-13): the worker is the only
+  // party that ever knows both IDs at once. record-platform-failure resolves
+  // the task through this mapping instead of timestamp proximity, so a dead
+  // platform run is requeued on the next tick instead of waiting out the
+  // 1-hour zombie-session sweep.
+  db.prepare(
+    `INSERT INTO platform_run_tasks (platform_run_id, task_id)
+     VALUES (?, ?)
+     ON CONFLICT(platform_run_id) DO UPDATE SET
+       task_id = excluded.task_id, linked_at = datetime('now')`
+  ).run(args.run_id, args.task_id);
   return { ok: true, task_id: args.task_id, run_id: args.run_id };
 };
 
@@ -735,11 +746,19 @@ commands["record-platform-failure"] = (db, args) => {
   if (!args.platform_run_id) throw usageError("platform_run_id is required.");
   if (!args.error_message) throw usageError("error_message is required.");
   if (!args.platform_created_at) throw usageError("platform_created_at is required.");
-  // Try to correlate with a crew telemetry run by timestamp proximity (±60s).
-  // The workflow doesn't know its platform run_id, so we match on launch time.
+  // Correlate with a crew task. First the durable platform_run_tasks mapping
+  // (written by acknowledge-dispatch-run — the worker is the only party that
+  // ever knows both IDs at once). Timestamp proximity is the fallback for
+  // runs launched before the mapping existed.
   let crewRunId = args.crew_run_id || null;
   let taskId = args.task_id || null;
   let workflow = args.workflow || null;
+  if (!taskId) {
+    const link = db.prepare(
+      "SELECT task_id FROM platform_run_tasks WHERE platform_run_id = ?"
+    ).get(args.platform_run_id);
+    if (link) taskId = link.task_id;
+  }
   if (!crewRunId) {
     const match = db.prepare(
       `SELECT run_id, task_id, workflow FROM workflow_runs
@@ -803,6 +822,25 @@ commands["retry-platform-failure"] = (db, args) => {
   if (!failure.task_id) {
     return { ok: true, action: "skipped", reason: "no task correlated" };
   }
+  // Supersede guard: if a newer platform run was linked for this task after
+  // this failure's run, the task is already owned by the newer run —
+  // requeueing here would clobber live work. Skip instead of retrying.
+  // (Without this, a late Step-0 detection of an old dead run could reset a
+  // task its successor is already working.)
+  const myLink = db.prepare(
+    "SELECT linked_at, rowid AS rid FROM platform_run_tasks WHERE platform_run_id = ?"
+  ).get(args.platform_run_id);
+  if (myLink) {
+    const newer = db.prepare(
+      `SELECT platform_run_id FROM platform_run_tasks
+       WHERE task_id = ? AND platform_run_id != ?
+         AND (linked_at > ? OR (linked_at = ? AND rowid > ?))
+       ORDER BY linked_at DESC, rowid DESC LIMIT 1`
+    ).get(failure.task_id, args.platform_run_id, myLink.linked_at, myLink.linked_at, myLink.rid);
+    if (newer) {
+      return { ok: true, action: "skipped", reason: "superseded by newer run " + newer.platform_run_id };
+    }
+  }
   if (failure.retry_count >= maxRetries) {
     // Park the task — transient failures are not resolving.
     const task = db.prepare("SELECT * FROM tasks WHERE id = ?").get(failure.task_id);

package/lib/schema.sql

@@ -161,3 +161,14 @@ CREATE TABLE IF NOT EXISTS platform_run_failures (
 );
 CREATE INDEX IF NOT EXISTS platform_run_failures_task_id_idx ON platform_run_failures(task_id);
 CREATE INDEX IF NOT EXISTS platform_run_failures_detected_at_idx ON platform_run_failures(detected_at);
+
+-- Durable platform run -> task mapping (2026-09-13). The poll worker is the
+-- only party that ever knows both IDs at once, so acknowledge-dispatch-run
+-- records the pairing here. record-platform-failure resolves the task through
+-- this mapping; the old timestamp-proximity match is a fallback only.
+CREATE TABLE IF NOT EXISTS platform_run_tasks (
+  platform_run_id TEXT PRIMARY KEY,
+  task_id         TEXT NOT NULL REFERENCES tasks(id) ON DELETE CASCADE,
+  linked_at       TEXT NOT NULL DEFAULT (datetime('now'))
+);
+CREATE INDEX IF NOT EXISTS platform_run_tasks_task_id_idx ON platform_run_tasks(task_id);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "muse-crew",
-  "version": "0.7.4",
+  "version": "0.7.6",
   "description": "Opinionated orchestration for Muse — workflows, identities, and tooling for autonomous software development.",
   "license": "UNLICENSED",
   "private": false,

package/seed/cron-body-template.md

@@ -13,7 +13,7 @@ You are the dispatch trigger for Muse Crew. Run the authoritative dispatcher wor
      WHERE w.created_at > now() - interval '15 minutes' AND w.status = 'failed'
      ORDER BY w.created_at DESC
      ```
-   - For each failed run, record it in the crew DB (correlates by timestamp with our telemetry):
+   - For each failed run, record it in the crew DB (correlates via the durable platform run -> task mapping written at acknowledge time; timestamp proximity is the fallback for pre-mapping runs):
      `node {crewHome}/lib/crew-api.js --crew-home {crewHome} record-platform-failure --json '{"platform_run_id": "<run_id>", "error_message": "<error>", "platform_created_at": "<created_at>"}'`
    - Then retry each failure (clears stale reservation, re-queues task, or parks after 3 attempts):
      `node {crewHome}/lib/crew-api.js --crew-home {crewHome} retry-platform-failure --json '{"platform_run_id": "<run_id>"}'`
@@ -36,24 +36,21 @@ You are the dispatch trigger for Muse Crew. Run the authoritative dispatcher wor
 
    If the dispatcher returned no claims or the claims array is empty, report: NO_DISPATCH and exit.
 
-5. **Monitor launched workflows (launcher stays alive — platform workaround):** The platform ties async workflow subagent authorization to the launcher's lifetime. If you exit now, the workflow's next `agent()` call may fail with "subagent bootstrap is no longer authorized." You are the monitor — stay alive until each workflow reaches a terminal state.
-   - For each launched run_id, poll its status every 2 minutes via muse.db:
+5. **Monitor launched workflows within this tick (tick-bounded — 2026-09-13):** The platform ties async workflow subagent authorization to the launcher's lifetime: when THIS tick ends (120s timeout), any still-running workflow's next `agent()` call may fail with "subagent bootstrap is no longer authorized" / "subagent reservation owner is terminal". You cannot prevent that by staying alive — this tick WILL end at 120s, so a "stay alive until terminal" monitor is fiction. The design that survives launcher death is per-tick recovery: watch while you live, and let the next tick's Step 0 continue through the durable platform run -> task mapping.
+   - For each launched run_id, poll its status every ~20 seconds via muse.db (you have ~100s of monitoring budget — leave margin before the 120s kill):
      ```sql
      SELECT status, error FROM runtime.workflow_runs WHERE run_id = '<run_id>'
      ```
    - **If status is `completed`:** Done. Log success and stop monitoring this run.
    - **If status is `failed`:** Check if it's a platform `agent()` error (error contains "subagent bootstrap", "reservation owner is terminal", "bootstrap was cancelled", or "workflow agent call failed"):
-     - **Platform error:** Record it and retry:
-       1. `node {crewHome}/lib/crew-api.js --crew-home {crewHome} record-platform-failure --json '{"platform_run_id": "<run_id>", "error_message": "<error>"}'`
-       2. `node {crewHome}/lib/crew-api.js --crew-home {crewHome} retry-platform-failure --json '{"platform_run_id": "<run_id>"}'`
-       3. If the retry result says `requeued` and you have retries remaining (max 3 per task per tick):
+     - **Platform error:** Record it and retry immediately (same two commands as Step 0). If the retry says `requeued` AND you have at least ~40s left in this tick AND retries remain (max 3 per task per tick):
           - Re-acquire the reservation: `node {crewHome}/lib/crew-api.js --crew-home {crewHome} reserve-dispatch --json '{"task_id": "<task_id>"}'`
           - If `acquired` is true, re-launch via workflow_launch_async with the same scriptPath and args, acknowledge with the new run_id, and continue monitoring the NEW run_id.
           - If `acquired` is false, stop — another dispatcher claimed it.
-       4. If the retry result says `parked` (3 attempts exhausted), stop monitoring this task.
+       If the retry result says `parked` (3 attempts exhausted), stop monitoring this task.
      - **Task-level error (not a platform error):** The workflow's own error handling applies. Stop monitoring this run.
    - **If status is `running` or `paused`:** Continue polling.
-   - **Timeout:** If a workflow hasn't reached terminal state after 90 minutes, log it and stop monitoring (the next tick's Step 0 will catch it if it failed). The monitor timeout MUST exceed the longest workflow `agent()` timeout (currently 60 minutes for the work phase) — otherwise the launcher shuts down mid-workflow and the bug recurs.
+   - **Tick end:** At ~100s elapsed, stop monitoring and exit. Do NOT try to outlive the 120s timeout — the monitor's job is not to prevent launcher death (impossible) but to recover from it fast. Anything that dies after you leave is caught by the next tick's Step 0 via the mapping, at most ~3 minutes later. That is the designed recovery path, not a fallback.
    - When all launched workflows are terminal or retry-exhausted, exit silently.
 
 6. Exit silently.