@adhdev/daemon-core 0.9.82-rc.566 → 0.9.82-rc.568

package/dist/mesh/mesh-active-work.d.ts

@@ -75,6 +75,10 @@ export interface BuildMeshActiveWorkOptions {
     /** Include terminal direct rows (idle/failed) for handoff/recent-work surfaces. Defaults false. */
     includeTerminalDirect?: boolean;
 }
+export declare function sessionStatusFromNodes(nodes: any[] | undefined, nodeId?: string, sessionId?: string): {
+    status?: MeshActiveWorkStatus;
+    staleReason?: string;
+};
 /**
  * One session awaiting an approval decision — the derived row `mesh_list_pending_approvals`
  * returns and the UI approvals inbox renders. A thin projection of the `awaiting_approval`

package/dist/providers/cli-provider-instance.d.ts

@@ -31,6 +31,15 @@ export declare class CliProviderInstance implements ProviderInstance {
      * keystroke until the modal *content* has settled.
      */
     private static readonly AUTO_APPROVE_SETTLE_MS;
+    /**
+     * APPROVAL-INBOX-BLINDSPOT (Fix A): how long after a LOCAL auto-approve fire the mesh
+     * event forwarder still treats the modal as "being resolved locally" and suppresses the
+     * coordinator notification. Chosen to comfortably cover the resolveModal → PTY absorb →
+     * status-leaves-approval round trip (incl. the win32 CR-resend loop) while staying short
+     * enough that a modal which auto-approve fired at but did NOT resolve re-surfaces to the
+     * coordinator on the next event. Aligned with the adapter's own approval cooldown scale.
+     */
+    private static readonly APPROVAL_LOCAL_RESOLUTION_COOLDOWN_MS;
     /**
      * Busy-side hysteresis for the settle gate. A momentary `generating` flip
      * while the SAME approval modal's button block is still on screen (its
@@ -200,6 +209,7 @@ export declare class CliProviderInstance implements ProviderInstance {
     private autoApproveSettleTimer;
     private autoApproveInactiveSince;
     private autoApproveLastModalSeenAt;
+    private lastAutoApproveFiredAt;
     private approvalStickyLastConcreteAt;
     private approvalStickyModal;
     private approvalStickyEntrySeq;
@@ -315,6 +325,21 @@ export declare class CliProviderInstance implements ProviderInstance {
      * absent from some of them.
      */
     resolveModalParkStatus(): 'waiting_choice' | 'waiting_approval' | null;
+    /**
+     * APPROVAL-INBOX-BLINDSPOT (Fix A): true when this session's approval modal was — or is
+     * being — resolved LOCALLY within the recent cooldown. Two independent positive signals:
+     *   (1) auto-approve fired its resolveModal within APPROVAL_LOCAL_RESOLUTION_COOLDOWN_MS
+     *       (lastAutoApproveFiredAt), or
+     *   (2) the underlying adapter reports isApprovalRecentlyResolved() — its own resolve
+     *       cooldown, which also covers a dashboard / mesh_approve resolution.
+     * The mesh event forwarder uses this to decide whether an agent:waiting_approval from an
+     * auto-approving worker can be safely SUPPRESSED (a local resolution is in flight) or must
+     * be FORWARDED (auto-approve is configured but has NOT actually resolved this modal, so the
+     * coordinator/inbox must be told). Keying suppression on real resolution — not just the
+     * autoApprove *intent* — is the blind-spot fix: a never-resolving worker approval is no
+     * longer silently dropped.
+     */
+    approvalRecentlyResolvedLocally(now?: number): boolean;
     /**
      * NOTIF-HELD-DRAIN: true when this `waiting_approval` is a routine, transient tool-consent
      * of an autonomously-progressing mesh session rather than a genuine human-await modal —
@@ -427,6 +452,7 @@ export declare class CliProviderInstance implements ProviderInstance {
      * the dashboard tail-repair cache — a display value, not a completion decision.
      */
     private lastVisibleAssistantSummary;
+    private lastVisibleAssistantSummaryDetail;
     /**
      * NOTIF Defect-B: the final assistant summary this instance ALREADY parsed and
      * cached for the current turn (lastCompletionSummary), if any. The evidence
@@ -442,6 +468,7 @@ export declare class CliProviderInstance implements ProviderInstance {
      * next turn (see lastCompletionSummary = null on onTurnStarted).
      */
     private cachedCompletionSummaryContent;
+    private cachedInTurnCompletionSummaryContent;
     private completionFinalAssistantEvidence;
     private completionFinalSummary;
     private buildCompletedFinalizationDiagnostic;

package/dist/providers/spec/cli-adapter.d.ts

@@ -143,6 +143,7 @@ export declare class SpecCliAdapter implements CliAdapter {
     writeRaw(data: string): void;
     resize(cols: number, rows: number): void;
     resolveModal(buttonIndex: number): void;
+    resolveModalMatched(buttonIndex: number): boolean;
     resolveAction(data: unknown): Promise<void>;
     setInteractivePromptResponse(response: InteractivePromptResponse): Promise<void>;
     isApprovalRecentlyResolved(): boolean;

package/dist/providers/spec/fsm-driver.d.ts

@@ -119,6 +119,13 @@ export interface ISpecDriver {
     subscribe(listener: (ev: DashboardEvent) => void): () => void;
     start(): void;
     dispatch(cmd: DashboardCommand): void;
+    /**
+     * BUTTON-INDEX-MISMAP (Fix C.3): click a modal button by its FSM display index and report
+     * whether a button was actually matched and its confirm keys dispatched. Unlike the
+     * fire-and-forget `dispatch('click_modal_button')`, callers that need to know the click
+     * landed (mesh_approve → SpecCliAdapter.resolveModalMatched) can observe a miss.
+     */
+    clickModalButton(index: number): boolean;
     updateMeta(meta: Record<string, unknown>, replace?: boolean): void;
     snapshot(): string;
     getCursorPosition(): {
@@ -423,6 +430,17 @@ export declare class FsmDriver implements ISpecDriver {
      */
     private scheduleWin32Submit;
     private handleClickControl;
+    /**
+     * BUTTON-INDEX-MISMAP (Fix C.3): public modal-click entry that returns whether a button
+     * matching the requested FSM display index was actually found and its confirm keys were
+     * dispatched. The old private handleClickModalButton silently `return`ed on a miss (no
+     * modal captured, or no button whose `.index` equals the requested display index), so a
+     * mis-mapped index looked identical to a successful press. Callers that need to know
+     * whether the click landed (mesh_approve → resolveModal) can now observe the miss instead
+     * of reporting success into the void. The generic `dispatch('click_modal_button')` path
+     * keeps ignoring the return (fire-and-forget UI clicks).
+     */
+    clickModalButton(index: number): boolean;
     private handleClickModalButton;
     /**
      * Submit a modal-confirm key sequence (the choice key + its trailing CR).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adhdev/daemon-core",
-  "version": "0.9.82-rc.566",
+  "version": "0.9.82-rc.568",
   "description": "ADHDev daemon core — CDP, IDE detection, providers, command execution",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -47,8 +47,8 @@
   "author": "vilmire",
   "license": "AGPL-3.0-or-later",
   "dependencies": {
-    "@adhdev/mesh-shared": "0.9.82-rc.566",
-    "@adhdev/session-host-core": "0.9.82-rc.566",
+    "@adhdev/mesh-shared": "0.9.82-rc.568",
+    "@adhdev/session-host-core": "0.9.82-rc.568",
     "@agentclientprotocol/sdk": "^0.16.1",
     "ajv": "^8.20.0",
     "ajv-formats": "^3.0.1",

package/src/cli-adapter-types.d.ts

@@ -54,6 +54,7 @@ export interface CliAdapter {
     clearHistory?(): void;
     resolveAction?(data: unknown): Promise<void>;
     resolveModal?(buttonIndex: number): void;
+    resolveModalMatched?(buttonIndex: number): boolean;
     isApprovalRecentlyResolved?(): boolean;
     setOnPtyData?(callback: (data: string) => void): void;
     writeRaw?(data: string): void;

package/src/cli-adapter-types.ts

@@ -15,6 +15,16 @@ export interface CliAdapterStatus {
     activeModal?: {
         message: string;
         buttons: string[];
+        /**
+         * BUTTON-INDEX-MISMAP (Fix C.1): each button's label paired with its real FSM
+         * DISPLAYED index (evaluator's Number(m[1])). `buttons` above is the label-only list
+         * every existing consumer reads (array position === pick order); `buttonMeta` preserves
+         * the index → label mapping so a partial / non-contiguous modal (display indices [1,3,4]
+         * at array positions [0,1,2]) does not lose its true indices once the modal leaves the
+         * adapter. Present only on spec/FSM adapters; absent for adapters that surface labels
+         * alone.
+         */
+        buttonMeta?: { index: number; label: string }[];
         /**
          * Semantic modal class, when the adapter knows it (spec/FSM path):
          * 'approval' = tool/command/trust consent (auto-approve may fire);
@@ -155,6 +165,13 @@ export interface CliAdapter {
     resolveAction?(data: unknown): Promise<void>;
     setInteractivePromptResponse?(response: InteractivePromptResponse): Promise<void>;
     resolveModal?(buttonIndex: number): void;
+    // BUTTON-INDEX-MISMAP (Fix C.3): resolve a modal button by ARRAY POSITION and report
+    // whether a real button was matched (the FSM found a button for the mapped display index
+    // and dispatched its confirm keys). A `false` verdict means the requested position mapped
+    // to no button — the caller (mesh_approve) must then NOT report success. Optional so
+    // legacy adapters that only expose the void resolveModal keep working (the caller falls
+    // back to resolveModal + the resolution-cooldown check).
+    resolveModalMatched?(buttonIndex: number): boolean;
     isApprovalRecentlyResolved?(): boolean;
  // Raw PTY I/O (for terminal view)
     setOnPtyData?(callback: (data: string) => void): void;

package/src/commands/chat-commands-write.ts

@@ -795,7 +795,21 @@ export async function handleResolveAction(h: CommandHelpers, args: any): Promise
             LOG.info('Command', `[resolveAction] CLI PTY → stale_prompt (already resolved within cooldown)`);
             return { success: true, stalePrompt: true, buttonIndex, button: buttons[buttonIndex] ?? button };
         }
-        if (typeof adapter.resolveModal === 'function') {
+        // BUTTON-INDEX-MISMAP (Fix C.3): prefer resolveModalMatched — it maps the array
+        // position to the real FSM display index AND reports whether a button was actually
+        // matched. The old path called the void resolveModal and unconditionally returned
+        // success:true, so a mis-mapped index (partial/non-contiguous modal) that pressed
+        // NOTHING still reported success and left the worker wedged at the modal. When the
+        // adapter tells us no button matched, report failure so mesh_approve / the coordinator
+        // sees the miss instead of a false success. Legacy adapters without resolveModalMatched
+        // keep the prior void-resolveModal behaviour.
+        if (typeof adapter.resolveModalMatched === 'function') {
+            const matched = adapter.resolveModalMatched(buttonIndex);
+            if (!matched) {
+                LOG.warn('Command', `[resolveAction] CLI PTY → no button matched for buttonIndex=${buttonIndex} "${buttons[buttonIndex] ?? '?'}" (modal not resolved)`);
+                return { success: false, error: 'Approval button index did not map to a visible modal button', buttonIndex, button: buttons[buttonIndex] ?? button };
+            }
+        } else if (typeof adapter.resolveModal === 'function') {
             adapter.resolveModal(buttonIndex);
         } else {
             const keys = '\x1B[B'.repeat(Math.max(0, buttonIndex)) + '\r';

package/src/mesh/mesh-active-work.ts

@@ -102,7 +102,7 @@ function elapsedSince(value: string | undefined, now: number): number {
     return Number.isFinite(started) ? Math.max(0, now - started) : 0;
 }
 
-function sessionStatusFromNodes(nodes: any[] | undefined, nodeId?: string, sessionId?: string): { status?: MeshActiveWorkStatus; staleReason?: string } {
+export function sessionStatusFromNodes(nodes: any[] | undefined, nodeId?: string, sessionId?: string): { status?: MeshActiveWorkStatus; staleReason?: string } {
     if (!Array.isArray(nodes)) return {};
     if (!nodeId) return { staleReason: 'direct task has no node id' };
     const node = nodes.find(item => meshNodeIdMatches(item, nodeId));
@@ -365,12 +365,30 @@ export function buildMeshActiveWork(opts: BuildMeshActiveWorkOptions): { activeW
     for (const task of opts.queue || []) {
         if (task.status !== 'pending' && task.status !== 'assigned') continue;
         const { title, summary } = summarizeMessage(task.message || '');
+        const queueNodeId = task.assignedNodeId || task.targetNodeId;
+        const queueSessionId = task.assignedSessionId || task.targetSessionId;
+        // APPROVAL-INBOX-BLINDSPOT (Fix A.2): a queue task previously reported its raw DB
+        // status (pending|assigned) verbatim, while direct dispatches consulted the live
+        // session status via sessionStatusFromNodes. That asymmetry meant a queue-dispatched
+        // worker sitting on an approval modal was recorded as 'assigned', so
+        // collectPendingApprovals (which filters status==='awaiting_approval') never counted
+        // it and mesh_list_pending_approvals returned 0. Overlay the live session status for
+        // an ASSIGNED queue task so an approval (or an active generation) on its bound session
+        // is reflected — the exact promotion the direct-dispatch path already does. A 'pending'
+        // task has no bound session yet, so it keeps its queue status.
+        const queueLive = task.status === 'assigned'
+            ? sessionStatusFromNodes(opts.nodes, queueNodeId ?? undefined, queueSessionId ?? undefined)
+            : {};
+        const queueStatus: MeshActiveWorkStatus = queueLive.status === 'awaiting_approval'
+            || queueLive.status === 'generating'
+            ? queueLive.status
+            : task.status;
         records.push({
             taskId: task.id,
             source: 'queue',
-            status: task.status,
-            nodeId: task.assignedNodeId || task.targetNodeId,
-            sessionId: task.assignedSessionId || task.targetSessionId,
+            status: queueStatus,
+            nodeId: queueNodeId,
+            sessionId: queueSessionId,
             taskTitle: title,
             taskSummary: summary,
             message: task.message,

package/src/mesh/mesh-event-forwarding.ts

@@ -727,25 +727,39 @@ function evaluateMeshEventSuppression(
 }
 
 /**
- * True when the worker session that emitted this event has auto-approve enabled
- * (a MAGI/delegated worker is launched with autoApprove:true). Such a worker
- * resolves its own approval modals locally, so an agent:waiting_approval event
- * from it is transient noise for the coordinator: forwarding it injects a
- * "[System] … is waiting for approval, use mesh_approve" turn that the
- * coordinator cannot usefully act on (the modal is already auto-resolving) and,
- * mid-MAGI-collect, HIJACKS the coordinator's synthesis turn — the observed
- * failure where a replica's repeated auto-approvals drowned out the completion
- * events and the coordinator answered about approvals instead of the RCA. Only
- * suppress when we can positively confirm the source worker auto-approves; a
- * worker that genuinely needs a human/coordinator approval (autoApprove off)
- * still forwards so the coordinator is told.
+ * APPROVAL-INBOX-BLINDSPOT (Fix A): decide whether an agent:waiting_approval from an
+ * auto-approving worker can be SUPPRESSED (never forwarded to the coordinator).
+ *
+ * A MAGI/delegated worker launched with autoApprove:true resolves its own approval modals
+ * locally, so a forwarded agent:waiting_approval is transient noise: it injects a
+ * "[System] … is waiting for approval, use mesh_approve" turn the coordinator cannot usefully
+ * act on (the modal is already auto-resolving) and, mid-MAGI-collect, HIJACKS the
+ * coordinator's synthesis turn — the observed failure where a replica's repeated
+ * auto-approvals drowned out the completion events.
+ *
+ * BUT the OLD gate suppressed on the autoApprove *intent* alone (settings.autoApprove===true),
+ * which is the blind spot: if the worker's local resolveModal never actually fired/resolved
+ * (button-index mismatch, a modal auto-approve declined to answer, an unattended stall), the
+ * event was STILL dropped — so no task_approval_needed ledger row was created,
+ * mesh_list_pending_approvals stayed 0, the coordinator was never told, and the remote
+ * UNKNOWN-grace reclaim eventually tore the worker off its task. This tightens the gate:
+ * suppress ONLY when auto-approve is on AND we can positively confirm the modal was — or is
+ * being — resolved LOCALLY within the recent cooldown (approvalRecentlyResolvedLocally). If
+ * auto-approve is configured but has NOT actually resolved this modal, we FORWARD so the
+ * coordinator/inbox is told and can act.
  */
-function sourceWorkerAutoApproves(components: DaemonComponents, sessionId: string): boolean {
+function shouldSuppressAutoApprovingWorkerApproval(components: DaemonComponents, sessionId: string): boolean {
     if (!sessionId) return false;
     try {
-        const state = components.instanceManager?.getInstance?.(sessionId)?.getState?.();
+        const instance = components.instanceManager?.getInstance?.(sessionId);
+        const state = instance?.getState?.();
         const settings = (state?.settings as Record<string, unknown>) || {};
-        return settings.autoApprove === true;
+        if (settings.autoApprove !== true) return false;
+        // Positive local-resolution signal required to suppress. Absent it, forward so the
+        // coordinator is told and a task_approval_needed ledger row is created.
+        const resolvedLocally = (instance as { approvalRecentlyResolvedLocally?: () => boolean } | undefined)
+            ?.approvalRecentlyResolvedLocally;
+        return typeof resolvedLocally === 'function' ? resolvedLocally.call(instance) === true : false;
     } catch {
         return false;
     }
@@ -1016,14 +1030,18 @@ function injectMeshSystemMessage(components: DaemonComponents, args: {
 
     const eventTimestamp = readEventTimestamp(args.metadataEvent.timestamp);
 
-    // Auto-approving worker: never forward its approval prompts to the coordinator.
-    // The daemon resolves the modal locally, so the "[System] … waiting for
-    // approval" injection is pure noise that hijacks the coordinator's turn — the
-    // observed MAGI failure where a replica's repeated auto-approvals flooded the
-    // coordinator and derailed its final synthesis. A worker without auto-approve
-    // (genuinely blocked on a human/coordinator decision) still forwards.
-    if (args.event === 'agent:waiting_approval' && sourceWorkerAutoApproves(components, eventSessionId)) {
-        LOG.info('MeshEvents', `Suppressed agent:waiting_approval for auto-approving worker session ${eventSessionId || '(unknown)'} (mesh ${args.meshId}) — modal is resolved locally, coordinator not notified`);
+    // Auto-approving worker: suppress its approval prompt ONLY when the modal was — or is
+    // being — resolved LOCALLY within the recent cooldown. The daemon resolving the modal
+    // locally makes the "[System] … waiting for approval" injection pure noise that hijacks
+    // the coordinator's turn (the observed MAGI failure where a replica's repeated
+    // auto-approvals flooded the coordinator and derailed its final synthesis). But a worker
+    // whose auto-approve is merely CONFIGURED on and did NOT actually resolve this modal
+    // (button-index mismatch, an unattended stall, a modal auto-approve declined to answer)
+    // must still forward — otherwise no task_approval_needed ledger row is created, the
+    // coordinator/inbox is never told, and the remote UNKNOWN-grace reclaim eventually tears
+    // the worker off its task (APPROVAL-INBOX-BLINDSPOT, Fix A).
+    if (args.event === 'agent:waiting_approval' && shouldSuppressAutoApprovingWorkerApproval(components, eventSessionId)) {
+        LOG.info('MeshEvents', `Suppressed agent:waiting_approval for auto-approving worker session ${eventSessionId || '(unknown)'} (mesh ${args.meshId}) — modal resolved locally within cooldown, coordinator not notified`);
         traceMeshEventDrop('waiting_approval_auto_approving_worker', traceCtx);
         return { success: true, forwarded: 0, suppressed: true, autoApprovingWorkerApproval: true };
     }

package/src/mesh/mesh-reconcile-loop.ts

@@ -81,6 +81,7 @@ import {
     autoPruneStaleDirectDispatches,
     pollAssignedTaskTerminalEvidence,
 } from './mesh-completion-synthesis.js';
+import { sessionStatusFromNodes } from './mesh-active-work.js';
 
 // Re-export the extracted public API so existing importers (mesh-events.ts barrel;
 // the reconcile-loop test suite) keep their `from './mesh-reconcile-loop.js'` paths.
@@ -726,6 +727,28 @@ export function __resetReclaimUnknownStreakForTests(): void {
     deliveredUnconsumedUnknownStreak.clear();
 }
 
+// APPROVAL-INBOX-BLINDSPOT (Fix A.3): true when the assigned row's bound session is, per the
+// LIVE mesh-node snapshots, sitting at an approval modal (waiting_approval). A REMOTE worker
+// blocked on an approval reads UNKNOWN from resolveSessionBusyVerdict (it is not in THIS
+// daemon's local instance map), so without this guard the delivered-no-turn / delivered-not-
+// consumed UNKNOWN streak advances toward a false reclaim that tears the worker off a task it
+// is legitimately paused on awaiting the coordinator's mesh_approve. The live status is read
+// from the same node session snapshots mesh_status / the active-work builder use, so it is
+// positive cross-daemon evidence (not a local-only observation). When present it HOLDS the row
+// without accruing the streak; the reclaim resumes normally once the approval clears.
+function assignedRowLiveStatusIsAwaitingApproval(
+    mesh: { nodes?: any[] },
+    nodeId?: string | null,
+    sessionId?: string | null,
+): boolean {
+    if (!nodeId || !sessionId) return false;
+    try {
+        return sessionStatusFromNodes(mesh.nodes, nodeId, sessionId).status === 'awaiting_approval';
+    } catch {
+        return false;
+    }
+}
+
 // PHASE 2.5 — assigned-stranded dispatch watchdog (Bug B). claimNextTask atomically
 // flips a row to 'assigned' BEFORE the fire-and-forget dispatch runs. If that dispatch
 // neither rejects (→ no .catch requeue) nor is confirmed delivered — a relay that hangs
@@ -809,6 +832,20 @@ async function recoverStrandedAssignedDispatches(
             } else {
                 if (verdict === 'IDLE_CONFIRMED') {
                     deliveredUnconsumedUnknownStreak.delete(shortStreakKey);
+                } else if (assignedRowLiveStatusIsAwaitingApproval(mesh, row.assignedNodeId, row.assignedSessionId)) {
+                    // APPROVAL-INBOX-BLINDSPOT (Fix A.3): the UNKNOWN (remote) worker is live and
+                    // sitting at an approval modal — it is legitimately paused awaiting the
+                    // coordinator's mesh_approve, NOT a lost delivery. HOLD without advancing the
+                    // streak so a genuine approval-blocked worker is never re-driven out from
+                    // under its pending approval.
+                    traceMeshEventDrop('short_redrive_deferred_awaiting_approval', {
+                        taskId: row.id,
+                        sessionId: row.assignedSessionId,
+                        nodeId: row.assignedNodeId,
+                        meshId,
+                        event: 'agent:waiting_approval',
+                    }, 'live_awaiting_approval');
+                    continue;
                 } else {
                     const streak = (deliveredUnconsumedUnknownStreak.get(shortStreakKey) ?? 0) + 1;
                     deliveredUnconsumedUnknownStreak.set(shortStreakKey, streak);
@@ -899,6 +936,21 @@ async function recoverStrandedAssignedDispatches(
             if (verdict === 'IDLE_CONFIRMED') {
                 deliveredNoTurnUnknownStreak.delete(streakKey);
                 reclaimReason = 'delivered_no_turn_deadline';
+            } else if (assignedRowLiveStatusIsAwaitingApproval(mesh, row.assignedNodeId, row.assignedSessionId)) {
+                // APPROVAL-INBOX-BLINDSPOT (Fix A.3): the UNKNOWN (remote) worker is live and
+                // sitting at an approval modal — legitimately paused awaiting the coordinator's
+                // mesh_approve, NOT a delivered-but-lost completion. HOLD without advancing the
+                // streak so a genuine approval-blocked worker is never reclaimed at the
+                // delivered-no-turn deadline. The reclaim resumes normally once the approval
+                // clears (the live status leaves waiting_approval).
+                traceMeshEventDrop('reclaim_deferred_awaiting_approval', {
+                    taskId: row.id,
+                    sessionId: row.assignedSessionId,
+                    nodeId: row.assignedNodeId,
+                    meshId,
+                    event: 'agent:waiting_approval',
+                }, 'live_awaiting_approval');
+                continue;
             } else {
                 // UNKNOWN — defer and accumulate the consecutive-UNKNOWN streak.
                 const streak = (deliveredNoTurnUnknownStreak.get(streakKey) ?? 0) + 1;