@adhdev/daemon-core 0.9.82-rc.507 → 0.9.82-rc.509

package/src/providers/cli-provider-instance.ts

@@ -56,6 +56,7 @@ import {
     COMPLETED_FINALIZATION_RETRY_MS,
     COMPLETED_FINALIZATION_MAX_WAIT_MS,
     NATIVE_HISTORY_MESH_IDLE_SETTLE_MS,
+    PTY_PARSED_FINAL_ASSISTANT_QUIET_DWELL_MS,
     BACKGROUND_TASK_HOLD_MAX_MS,
     USER_INPUT_ACK_DEDUP_WINDOW_MS,
     STARTUP_GRACE_IDLE_COLLAPSE_WINDOW_MS,
@@ -194,6 +195,40 @@ export class CliProviderInstance implements ProviderInstance {
      */
     private static readonly AUTO_APPROVE_MASK_STALL_MS = 10500;
 
+    /**
+     * AUTOAPPROVE-FLAP-INBOX-MISSING: sticky-approval overlay window. Same time-tick
+     * hold idea as the FALSE-IDLE completion gate — an approval signal that was
+     * DOMINANT within this recent window is re-presented across a momentary busy blip
+     * instead of collapsing.
+     *
+     * RCA (live 2026-07-13): a claude-cli worker sitting at a Bash approval modal
+     * ("Do you want to proceed? ❯1.Yes") flaps waiting_approval↔busy on a ~2-3s period.
+     * The spec `approval→busy` transition fires whenever the footer/modal approval
+     * markers momentarily drop out of their parsed sections while the PRIOR command's
+     * residual spinner text ("✳ Checking vendor drift…") still matches the busy regex.
+     * On the busy frame the adapter reports status='generating', activeModal=null. That
+     * corrupts THREE consumers at once: (1) mesh_active_work samples 'generating' →
+     * collectPendingApprovals never sees 'awaiting_approval' → mesh_list_pending_approvals
+     * count:0 (inbox miss); (2) the auto-approve settle gate is torn down each busy phase
+     * so the 600ms settle never accrues → auto-approve never fires; (3) a mesh_approve
+     * landing on a busy frame hits "Not in approval state". The existing FLAP machinery
+     * (AUTO_APPROVE_FLAP_CONTINUITY_MS) only keeps the settle gate warm while status is
+     * STILL waiting_approval (buttons scrolled out) — it does nothing once the FSM fully
+     * commits to 'busy', and it never stabilises the status the inbox samples.
+     *
+     * Fix: when the raw adapter status flaps to generating/busy/idle but a
+     * waiting_approval WITH a concrete modal was observed within this window, overlay
+     * the cached modal and report status='waiting_approval'. This stabilized status
+     * feeds getState (→ inbox), detectStatusTransition (→ event emission), and
+     * maybeAutoApproveStatus (→ settle gate) uniformly, so the approval both registers
+     * in the inbox and settles for auto-approve across the flap. Bounded (a genuine
+     * resume that never returns to approval unmasks after this window) and scoped at the
+     * call site to autonomous mesh sessions. 4000ms bridges the observed ~2-3s flap with
+     * margin while staying well under AUTO_APPROVE_MASK_STALL_MS (a truly stalled/absent
+     * approval still surfaces).
+     */
+    private static readonly APPROVAL_STICKY_FLAP_MS = 4000;
+
     /**
      * FALSE-IDLE (inter-approval quiet valley): grace window after an auto-approve
      * (or mesh_approve) RESOLVES a modal during which a subsequent generating→idle
@@ -298,6 +333,14 @@ export class CliProviderInstance implements ProviderInstance {
     // signature) while a genuinely closed modal — buttons empty continuously past
     // the continuity window — is still recognised and resets the gate.
     private autoApproveLastModalSeenAt = 0;
+    // AUTOAPPROVE-FLAP-INBOX-MISSING sticky-approval overlay (see APPROVAL_STICKY_FLAP_MS).
+    // The wall-clock of the last frame where the RAW adapter reported waiting_approval with
+    // a CONCRETE modal (buttons present), the cached modal to re-present across a busy blip,
+    // and the approvalEntrySeq at that frame (so a stabilized frame carries the right seq to
+    // the emission-dedup fingerprint). All zero/null when no recent concrete approval.
+    private approvalStickyLastConcreteAt = 0;
+    private approvalStickyModal: { message?: string; buttons?: unknown[]; kind?: string | null } | null = null;
+    private approvalStickyEntrySeq = 0;
     // STATUS-MISMATCH: wall-clock when the CURRENT auto-approve episode (waiting_approval
     // + shouldAutoApprove) first began wanting to mask. Unlike pendingAutoApprovalSince it
     // is NOT reset when the modal signature changes (a still-streaming/flapping prompt) and
@@ -533,7 +576,11 @@ export class CliProviderInstance implements ProviderInstance {
         // in cli-script-runner.ts (CliScriptRunner.detectStatus / parseApproval /
         // parseSession), with provider-loader.ts updated to store script source strings
         // alongside the loaded function references for extended-legacy providers.
-        const adapterStatus = this.adapter.getStatus();
+        // AUTOAPPROVE-FLAP-INBOX-MISSING: apply the same sticky-approval overlay the
+        // FSM path uses so the status this getState() surfaces to the mesh probe (and
+        // thus mesh_active_work → the pending-approval inbox) stays waiting_approval
+        // across a busy flap frame, instead of momentarily reading generating (count:0).
+        const adapterStatus = this.stabilizeFlappingApprovalStatus(this.adapter.getStatus());
         if (Object.prototype.hasOwnProperty.call(adapterStatus, 'activeInteractivePrompt')) {
             this.activeInteractivePrompt = adapterStatus.activeInteractivePrompt ?? null;
         }
@@ -1753,7 +1800,27 @@ export class CliProviderInstance implements ProviderInstance {
                     if (probe?.lastRole === 'assistant' && (probe.contentLen ?? 0) > 0) {
                         return null;
                     }
+                    // (FALSE-IDLE-MIDTURN antigravity) A native-history session whose
+                    // external-native transcript has NO in-turn final assistant bubble yet
+                    // (present=false AND the probe's tail is not an assistant reply) is NOT
+                    // proven done. antigravity previously returned null here — an IMMEDIATE
+                    // clean emit with zero transcript evidence — so a momentary PTY-parser
+                    // idle blip MID-TURN (the parser reads idle while the turn is still in
+                    // flight and the transcript's answer has not landed) fired an early
+                    // agent:generating_completed the coordinator could never correct. Instead
+                    // HOLD for the transcript: re-probe each retry (readExternalCompletionMessages
+                    // runs forceRefresh every call) and clear the block only once the assistant
+                    // turn actually lands (the probe branch above → genuine emit). Non-terminal
+                    // and bounded by COMPLETED_FINALIZATION_MAX_WAIT_MS (30s) so a turn that
+                    // genuinely produced no assistant bubble (tool-only) still force-emits a weak
+                    // completion rather than wedging — preserving the a0fb6b05 "antigravity always
+                    // eventually emits" fix while filtering the mid-turn false-idle. Scoped to
+                    // autonomous mesh sessions (allowMissingAssistantTimeout) so an interactive
+                    // antigravity session, which has no coordinator to misfire at, is untouched.
                     if (this.type === 'antigravity-cli') {
+                        if (allowMissingAssistantTimeout) {
+                            return { reason: 'missing_final_assistant', terminal: false, holdForTranscript: true };
+                        }
                         return null;
                     }
                     // (SETTLE-VALLEY) The inter-approval idle valley: a native-history mesh worker
@@ -1809,6 +1876,40 @@ export class CliProviderInstance implements ProviderInstance {
             }
         } catch { /* defensive: screen text read is best-effort */ }
 
+        // (FALSE-IDLE-MIDTURN codex/PTY) The turn-complete quiet-dwell gate. We only reach
+        // here with finalAssistantEvidence.present === true. For a PTY-PARSED provider
+        // (codex: !adapterOwnsMessagesElsewhere), that "present" verdict is derived from the
+        // on-screen assistant text, which can be a PARTIAL sentence fragment captured mid-stream
+        // when the FSM momentarily read idle. completionHasFinalAssistantMessage accepts the
+        // fragment and hasAdapterPendingResponse can transiently read clean between chunks, so
+        // present flips true mid-turn and this path would clean-emit an early completion. The
+        // flush's lastOutputAt continuity guard only cancels when NEW output ARRIVES during the
+        // settle — it cannot catch a turn that fell quiet just before the arm. Require instead a
+        // minimum QUIET DWELL since the last raw PTY output: a genuinely finished turn's screen
+        // has been stable well past this bound, whereas a mid-stream fragment either just received
+        // output or is about to. Non-terminal HOLD (bounded by COMPLETED_FINALIZATION_MAX_WAIT_MS),
+        // so a real completion re-passes the gate one retry later once the dwell is met; and it
+        // force-emits at the 30s cap rather than wedging. Scoped to autonomous mesh sessions
+        // (allowMissingAssistantTimeout) and PTY-parsed sources only — native-history providers
+        // (antigravity/claude) resolve evidence from the authoritative transcript above, not the
+        // screen, so this dwell does not apply to them and interactive sessions are untouched.
+        if (allowMissingAssistantTimeout
+            && !adapterOwnsMessagesElsewhere
+            && finalAssistantEvidence.source === 'parsed') {
+            try {
+                const outStatus = this.adapter.getStatus({ allowParse: false }) as any;
+                const lastOutputAt = typeof outStatus?.lastOutputAt === 'number' && Number.isFinite(outStatus.lastOutputAt)
+                    ? outStatus.lastOutputAt as number
+                    : undefined;
+                if (typeof lastOutputAt === 'number') {
+                    const quietMs = Date.now() - lastOutputAt;
+                    if (quietMs < PTY_PARSED_FINAL_ASSISTANT_QUIET_DWELL_MS) {
+                        return { reason: 'parsed_final_assistant_quiet_dwell', terminal: false };
+                    }
+                }
+            } catch { /* defensive: dwell read is best-effort — fall through to emit */ }
+        }
+
         return null;
     }
 
@@ -2342,6 +2443,72 @@ export class CliProviderInstance implements ProviderInstance {
         });
     }
 
+    /**
+     * AUTOAPPROVE-FLAP-INBOX-MISSING sticky-approval overlay. Returns the adapterStatus a
+     * flap-prone claude-cli approval SHOULD present this frame — either the raw status
+     * unchanged, or, when the raw status has momentarily flapped OFF a recently-dominant
+     * concrete approval, a synthetic `waiting_approval` re-presenting the cached modal.
+     *
+     * Records the concrete approval whenever the raw status is waiting_approval WITH
+     * buttons. On a subsequent non-approval frame (the spec `approval→busy` flap), if that
+     * concrete approval was seen within APPROVAL_STICKY_FLAP_MS AND the engine has NOT
+     * resolved a modal since (lastApprovalResolvedAt not advanced past the sticky start),
+     * overlay the cached modal + waiting_approval so the inbox / auto-approve / mesh_approve
+     * all see the stable approval. A genuine resolution (auto-approve or mesh_approve fires
+     * resolveModal → lastApprovalResolvedAt advances) clears the sticky immediately, so a
+     * legitimate post-approval resume is NEVER masked as a lingering approval. Bounded by the
+     * window, and scoped to autonomous mesh sessions (a foreground/attended or non-mesh
+     * session, where a human answers the prompt, is returned untouched).
+     */
+    private stabilizeFlappingApprovalStatus(adapterStatus: any, now = Date.now()): any {
+        // Only autonomous auto-approving mesh sessions are subject to the delegated flap;
+        // never overlay for attended/foreground/non-mesh sessions.
+        if (!this.isAutonomousMeshSession() || !this.shouldAutoApprove()) return adapterStatus;
+
+        const rawStatus = adapterStatus?.status;
+        const resolvedAt = typeof (this.adapter as any)?.lastApprovalResolvedAt === 'number'
+            ? (this.adapter as any).lastApprovalResolvedAt as number
+            : 0;
+
+        if (rawStatus === 'waiting_approval') {
+            // A concrete modal this frame refreshes the sticky anchor; an approval frame
+            // with buttons momentarily scrolled out is left to the existing settle-gate
+            // hysteresis (we do not touch it — status is already waiting_approval).
+            if (hasNonEmptyCliModalButtons(adapterStatus?.activeModal)) {
+                this.approvalStickyLastConcreteAt = now;
+                this.approvalStickyModal = adapterStatus.activeModal;
+                this.approvalStickyEntrySeq = typeof adapterStatus?.approvalEntrySeq === 'number'
+                    ? adapterStatus.approvalEntrySeq
+                    : this.approvalStickyEntrySeq;
+            }
+            return adapterStatus;
+        }
+
+        // Non-approval frame. Overlay only if a concrete approval was dominant within the
+        // window AND no resolution has happened since the sticky anchor (a resolveModal
+        // advances lastApprovalResolvedAt to at/after the anchor → the flap is really a
+        // genuine resume, so drop the sticky and report the raw status).
+        if (this.approvalStickyLastConcreteAt > 0 && this.approvalStickyModal) {
+            const withinWindow = (now - this.approvalStickyLastConcreteAt) < CliProviderInstance.APPROVAL_STICKY_FLAP_MS;
+            const resolvedSinceAnchor = resolvedAt >= this.approvalStickyLastConcreteAt;
+            if (withinWindow && !resolvedSinceAnchor) {
+                return {
+                    ...adapterStatus,
+                    status: 'waiting_approval',
+                    activeModal: this.approvalStickyModal,
+                    ...(this.approvalStickyEntrySeq ? { approvalEntrySeq: this.approvalStickyEntrySeq } : {}),
+                    approvalStickyOverlay: true,
+                };
+            }
+            // Window lapsed or a resolution landed — clear the sticky so a later approval
+            // re-anchors from scratch and a genuine resume surfaces immediately.
+            this.approvalStickyLastConcreteAt = 0;
+            this.approvalStickyModal = null;
+            this.approvalStickyEntrySeq = 0;
+        }
+        return adapterStatus;
+    }
+
     private maybeAutoApproveStatus(adapterStatus: any, now = Date.now()): boolean {
         // Manual-attendance suppression (provider-common): when a human is
         // Manual-attendance suppression (provider-common): when a human is
@@ -2777,7 +2944,12 @@ export class CliProviderInstance implements ProviderInstance {
         // Status-change handling is a hot path: PTY output can fire it many times
         // during long-running CLI sessions. Keep this path on adapter-owned light
         // state only; rich provider parsing is reserved for getState/read_chat.
-        const adapterStatus = this.adapter.getStatus({ allowParse: false });
+        // AUTOAPPROVE-FLAP-INBOX-MISSING: stabilize a flap-prone approval BEFORE it feeds
+        // maybeAutoApproveStatus / newStatus / the waiting_approval emission branch below,
+        // so a momentary busy blip during the flap re-presents the cached modal + status
+        // rather than emitting generating (which would corrupt the inbox and tear down the
+        // settle gate). No-op for non-mesh/foreground/non-approval frames.
+        const adapterStatus = this.stabilizeFlappingApprovalStatus(this.adapter.getStatus({ allowParse: false }), now);
         const adapterProviderSessionId = normalizeProviderSessionId(
             this.provider,
             typeof adapterStatus?.providerSessionId === 'string' ? adapterStatus.providerSessionId : '',

package/src/repo-mesh-types.ts

@@ -388,16 +388,15 @@ export interface RepoMeshRelatedRepo {
  * must satisfy both. Omitting `maxParallel` means this provider is bounded only
  * by the global/taskMode caps (full backward compatibility).
  *
- * Routing is governed exclusively by required_tags (see nodeSatisfiesRequiredTags);
- * this entry carries no routing role. To route work to a specific node, advertise an
- * ordinary capability tag on the node and require it on the task.
+ * Routing is governed exclusively by required_tags (see nodeSatisfiesRequiredTags).
+ * To route work to a specific node, advertise an ordinary capability tag on the
+ * node and require it on the task.
+ *
+ * NOTE: the per-(node, provider) parallelism cap now lives on `slots[].maxParallel`
+ * (see NodeCapabilitySlot). The former `providerRoles` field has been removed; a
+ * persisted meshes.json that still carries it is migrated to `slots` on load
+ * (see migrateLoadedMeshConfig).
  */
-export interface RepoMeshProviderRole {
-    /** Provider type this entry governs (e.g. 'claude-cli', 'codex-cli'). */
-    providerType: string;
-    /** Max concurrent active tasks for this (node, provider). Omit = no per-provider cap. */
-    maxParallel?: number;
-}
 
 export interface RepoMeshNodePolicy {
     readOnly?: boolean;
@@ -413,26 +412,14 @@ export interface RepoMeshNodePolicy {
     schedulingPriority?: number;
     /** Ordered provider preference used when mesh_launch_session omits an explicit type. */
     providerPriority?: string[];
-    /**
-     * Per-(node, provider) parallelism declarations. Each entry binds a
-     * providerType on THIS node to an optional maxParallel cap. maxParallel is
-     * enforced as an additional, stricter-wins constraint on top of the global
-     * maxParallelTasks/taskMode caps. Missing/empty: the node behaves exactly as
-     * before (global caps only). Routing is governed solely by required_tags.
-     *
-     * SUPERSEDED by `slots` (ORCHESTRATION_NODE_SLOTS.md). Kept for back-compat:
-     * when `slots` is absent, providerRoles + providerPriority + the machine-global
-     * difficultyBrains are auto-derived into slots via deriveSlotsFromLegacy.
-     */
-    providerRoles?: RepoMeshProviderRole[];
     /**
      * Node capability slots (ORCHESTRATION_NODE_SLOTS.md) — the ordered "Preferred
      * AI tools" profile that is the single source of truth for task routing, MAGI
      * fan-out, and orchestrator-proposed edits. Each slot bundles provider + model
      * + thinkingLevel + difficulty range + capability tags + per-slot maxParallel.
      * Order = preference. When absent, the scheduler derives slots from the legacy
-     * providerPriority/providerRoles/difficultyBrains (deriveSlotsFromLegacy) so
-     * existing nodes keep working without reconfiguration.
+     * providerPriority/difficultyBrains (deriveSlotsFromLegacy) so existing nodes
+     * keep working without reconfiguration.
      */
     slots?: NodeCapabilitySlot[];
     /**
@@ -696,29 +683,38 @@ export function resolveDelegatedWorkerAutoApprove(
 }
 
 /**
- * Resolve the enforced per-(node, provider) maxParallel cap, or undefined when
- * no finite, non-negative cap is declared for this provider. Used by the queue
- * claim path as a stricter-wins constraint layered on top of the global caps.
- * Case-insensitive, trimmed match on providerType. Defensive against malformed
- * config — non-object entries and blank providerTypes are skipped rather than throwing.
+ * Resolve the enforced per-(node, provider) maxParallel cap from a node's resolved
+ * capability slots, or undefined when no matching slot declares a finite cap. Used
+ * by the queue claim path as a stricter-wins constraint layered on top of the global
+ * caps. Case-insensitive, trimmed match on the slot's provider.
+ *
+ * When a node declares multiple slots for the same provider (e.g. distinct
+ * difficulty ranges), their caps SUM into a single per-(node, provider) pool — the
+ * provider can run up to the total across all its slots. Legacy-derived slots (via
+ * deriveSlotsFromLegacy) produce one slot per provider, so the sum equals that
+ * single slot's cap and behavior is preserved exactly.
+ *
+ * Callers pass the already-resolved slots (explicit policy.slots, else legacy-
+ * derived) — this keeps the resolver free of the difficultyBrains dependency and
+ * usable from any layer.
  */
 export function resolveProviderMaxParallel(
-    nodePolicy: Pick<RepoMeshNodePolicy, 'providerRoles'> | null | undefined,
+    slots: NodeCapabilitySlot[] | null | undefined,
     providerType: string | null | undefined,
 ): number | undefined {
     const wanted = typeof providerType === 'string' ? providerType.trim().toLowerCase() : '';
     if (!wanted) return undefined;
-    const roles = nodePolicy?.providerRoles;
-    if (!Array.isArray(roles)) return undefined;
-    for (const entry of roles) {
-        if (!entry || typeof entry !== 'object') continue;
-        const type = typeof entry.providerType === 'string' ? entry.providerType.trim().toLowerCase() : '';
+    if (!Array.isArray(slots)) return undefined;
+    let total: number | undefined;
+    for (const slot of slots) {
+        if (!slot || typeof slot !== 'object') continue;
+        const type = typeof slot.provider === 'string' ? slot.provider.trim().toLowerCase() : '';
         if (!type || type !== wanted) continue;
-        const raw = Number(entry.maxParallel);
-        if (!Number.isFinite(raw) || raw < 0) return undefined;
-        return Math.floor(raw);
+        const raw = Number(slot.maxParallel);
+        if (!Number.isFinite(raw) || raw < 0) continue;
+        total = (total ?? 0) + Math.floor(raw);
     }
-    return undefined;
+    return total;
 }
 
 // ─── Capabilities ───────────────────────────────
@@ -987,6 +983,11 @@ export interface RepoMeshNodeSchedulingStatus {
     load: number;
     schedulingPriority?: number;
     maxConcurrentSessions?: number;
+    /**
+     * Per-(node, provider) caps + consumption. Field name kept for dashboard
+     * back-compat; the cap source is now slots[].maxParallel (the removed
+     * policy.providerRoles no longer exists).
+     */
     providerRoles?: RepoMeshNodeProviderSchedulingStatus[];
     capReached: boolean;
     capReasons?: string[];