mixdog 0.9.2 → 0.9.3

package/src/ui/statusline.mjs

@@ -425,6 +425,16 @@ function renderNativeStatusline({
     const label = `Running ${n} Shell${n === 1 ? '' : 's'}`;
     addL2(`${spin} ${B}${label}${R}${elapsedSuffix(shellStatus.elapsedLabel)}`);
   }
+  // Memory cycle segment — single unified "Memory" wording for all states:
+  // running -> "⠋ Memory · 12s"; backlog warning -> "⠋ Memory · backlog 512"
+  // (yellow). Nothing when idle (no L2 pollution).
+  const memStatus = memoryCycleStatus();
+  if (memStatus?.kind === 'running') {
+    const elapsed = formatElapsed(Date.now() - memStatus.startedAt);
+    addL2(`${spin} ${B}Memory${R}${elapsedSuffix(elapsed)}`);
+  } else if (memStatus?.kind === 'backlog') {
+    addL2(`${spin} ${B}Memory${R} ${D}·${R} ${YLW}backlog ${memStatus.pending}${R}`);
+  }
   const l1 = l1Parts.join(sep) || 'mixdog';
   const l2 = l2Parts.join(sep);
   return l2 ? `${l1}\n${l2}` : l1;
@@ -767,6 +777,45 @@ function maintenanceLabel(tag) {
 }
 
 function shellJobsStatus({ clientHostPid } = {}) {
+  return _shellJobsStatusImpl({ clientHostPid });
+}
+
+// Memory cycle L2 segment source. The memory daemon writes
+// data/memory-cycle-state.json on every cycle start/finish (index.mjs
+// _writeCycleStateFile) — no HTTP call from the statusline path. Cached at
+// the same 1s cadence as the shell segment. Shows a single unified "Memory"
+// segment: running (spinner + elapsed) or backlog warning (yellow count).
+let _memoryCycleSegmentCache = { at: 0, value: null };
+const MEMORY_CYCLE_SEGMENT_CACHE_MS = 1000;
+const MEMORY_CYCLE_BACKLOG_WARN = 500;
+function memoryCycleStatus() {
+  const now = Date.now();
+  if (now - _memoryCycleSegmentCache.at < MEMORY_CYCLE_SEGMENT_CACHE_MS) {
+    return _memoryCycleSegmentCache.value;
+  }
+  let value = null;
+  try {
+    const p = join(dataDir(), 'memory-cycle-state.json');
+    if (existsSync(p)) {
+      const state = JSON.parse(readFileSync(p, 'utf-8'));
+      const running = state?.running || null;
+      const backlog = state?.backlog || {};
+      // Stale-file guard: a daemon that died mid-run leaves running set —
+      // ignore anything not refreshed in the last 10 minutes.
+      const fresh = Number(state?.updatedAt) > now - 10 * 60_000;
+      if (fresh && running?.cycle && Number(running.started_at) > 0) {
+        value = { kind: 'running', startedAt: Number(running.started_at) };
+      } else if (fresh) {
+        const pending = Math.max(Number(backlog?.unchunked) || 0, Number(backlog?.cycle2_pending) || 0);
+        if (pending > MEMORY_CYCLE_BACKLOG_WARN) value = { kind: 'backlog', pending };
+      }
+    }
+  } catch { value = null; }
+  _memoryCycleSegmentCache = { at: now, value };
+  return value;
+}
+
+function _shellJobsStatusImpl({ clientHostPid } = {}) {
   const ownerPid = positiveInt(clientHostPid);
   const empty = { count: 0, elapsedLabel: '' };
   if (!ownerPid) return empty;

package/src/workflows/default/WORKFLOW.md

@@ -26,16 +26,23 @@ Lead supervises: delegates, coordinates, judges, decides. Route by complexity:
    - SEQUENTIAL within a single complex scope — split it into ordered steps
      rather than handing it off in one shot, with a build/test-green gate
      between steps.
-   - Reuse the existing agent (same tag) for follow-up on the same scope; spawn
-     new only for a separate scope. Write briefs per the lead-tool brief
-     contract (token-optimized labeled fragments).
+   - Write briefs per the lead-tool brief contract (token-optimized labeled
+     fragments).
    - After spawning async agent(s), END THE TURN — do not poll, guess, or start
-     dependent work until the completion notification resumes you (status/read
-     are manual recovery only). Then wait and continue automatically.
+     dependent work until the completion notification resumes you. Then wait
+     and continue automatically.
 3. Review — pair one reviewer 1:1 with each implementation scope, spawned in the
-   same turn. Cross-check implementation and review results yourself before
-   acting on them. Send fixes back to the original scope and repeat until clean.
-   Skip review only for simple, low-risk tasks.
+   same turn; never defer or batch the reviewer call — wait for its result.
+   Fact-check the agent response and cross-check implementation and review
+   results yourself before acting on them. Send fixes back to the original
+   scope and loop verify -> fix -> re-verify until clean. Skip review only for
+   simple, low-risk tasks. If the user asks for debugging, or a bug survives
+   2+ fix cycles, have the debugger investigate first instead of another fix
+   round.
 4. Report — deliver the final report: synthesize results (outcome + key
    evidence; never forward raw agent output), state the final state, and ask the
-   user whether to ship/deploy when relevant.
+   user whether to ship/deploy when relevant. Only after user feedback with no
+   issues prepare deploy/build/commit.
+
+On any major change or direction shift mid-work, pause and re-consult the user
+before continuing.

package/src/workflows/sequential/WORKFLOW.md

@@ -29,18 +29,23 @@ Lead supervises: delegates, coordinates, judges, decides. Route by complexity:
    - SEQUENTIAL within a single complex scope — split it into ordered steps
      rather than handing it off in one shot, with a build/test-green gate
      between steps.
-   - Reuse the existing agent (same tag) for follow-up on the same scope; spawn
-     new only for a separate scope. Write briefs per the lead-tool brief
-     contract (token-optimized labeled fragments).
+   - Write briefs per the lead-tool brief contract (token-optimized labeled
+     fragments).
    - After spawning an async agent, END THE TURN — do not poll, guess, or start
-     dependent or subsequent work until the completion notification resumes you
-     (status/read are manual recovery only). Then wait and continue
-     automatically.
+     dependent or subsequent work until the completion notification resumes
+     you. Then wait and continue automatically.
 3. Review — after each implementation scope completes, pair one reviewer 1:1
-   with that scope (spawned on its own turn, not batched). Cross-check
-   implementation and review results yourself before acting on them. Send fixes
-   back to the original scope and repeat until clean. Skip review only for
-   simple, low-risk tasks.
+   with that scope (spawned on its own turn, not batched); never defer the
+   reviewer call — wait for its result. Fact-check the agent response and
+   cross-check implementation and review results yourself before acting on
+   them. Send fixes back to the original scope and loop verify -> fix ->
+   re-verify until clean. Skip review only for simple, low-risk tasks. If the
+   user asks for debugging, or a bug survives 2+ fix cycles, have the debugger
+   investigate first instead of another fix round.
 4. Report — deliver the final report: synthesize results (outcome + key
    evidence; never forward raw agent output), state the final state, and ask the
-   user whether to ship/deploy when relevant.
+   user whether to ship/deploy when relevant. Only after user feedback with no
+   issues prepare deploy/build/commit.
+
+On any major change or direction shift mid-work, pause and re-consult the user
+before continuing.

package/src/workflows/solo/WORKFLOW.md

@@ -14,7 +14,11 @@ agents:
 3. Verify — Lead checks the result directly, fixes issues directly, and repeats
    until the work is clean or a blocker must be reported.
 4. Report — Lead summarizes the final state, verification result, and any
-   remaining risk or requested next step.
+   remaining risk or requested next step. Only after user feedback with no
+   issues prepare deploy/build/commit.
+
+On any major change or direction shift mid-work, pause and re-consult the user
+before continuing.
 
 Delegation rule:
 - Do not delegate, spawn, send, or ask any agent to perform work.