Bug

When a task representing an outstanding email draft is marked done with cleanupDraft: true (the user fulfilled the obligation another way, e.g. sent an equivalent email manually, so the now-stale Cedar-generated Gmail draft should be deleted), cleanup silently no-ops for a large class of tasks and the real Gmail draft is never deleted.

cleanupDraftForTask() (apps/server/src/services/user-tasks/tasks.ts) and its gating check in updateTaskTool.ts's update-task tool both read draftId/emailHeaderMessageId/threadId , and gate entirely , on the deprecated task_action_data column (taskActionData?.channel === 'email'). Since the Aug-2026 migration, task_output is the canonical location for a produced task's draft pointer and task_action_data is null on the common/default case (see apps/server/src/services/user-tasks/output-predicates.ts, which already reads via COALESCE(task_output->>'draftId', task_action_data->>'draftId') for exactly this reason). cleanupDraftForTask/updateTaskTool.ts never got updated to that pattern, so:

• deleteDraft() is never called for a task whose pointer lives in task_output
• update-task still reports { success: true }
• in updateTaskTool.ts, the gate also fed the "does this write anything real?" no-op check, so a cleanupDraft: true call on an already-done task (nothing else changing) was short-circuited before cleanupDraftForTask was ever invoked
• the stale Gmail draft is left behind indefinitely

Confirmed on a real production task (bf7bd732-46db-4654-97b2-3441965add9f, Zach Moskow / ConcentrateAI): task_action_data IS NULL, task_output = {"kind":"email"}, and a real Gmail draft (r4440516407368735025) created 5 minutes before the task was marked done is still sitting undeleted.

Fix

• cleanupDraftForTask(): read draftId/threadId/emailHeaderMessageId with the same task_output-first, task_action_data-fallback pattern output-predicates.ts already uses for SQL reads, instead of task_action_data exclusively.
• updateTaskTool.ts's cleanupDraft gate: same fallback, so the no-op short-circuit can no longer swallow the call before cleanup runs. Both axes (taskActionData + taskOutput) are written back in sync via the existing producedOutput helper, matching the paired-write convention clearTaskDraftPointer already follows.
• Observability, so this exact investigation dead end can't recur:
  • An unconditional [cleanupDraftForTask] Invoked for task … log at entry, so a run's logs always show whether cleanup was ever called, independent of outcome.
  • A new "delete" cedar.draft.action value, emitted via a new recordDraftDeleted() in services/analytics/draft-analytics.ts from the successful-deletion path, following the exact same cedar.draft.* span/attribute pattern already used for "create"/"send".
• Tests: added coverage in cleanup-draft-pointer.test.ts (draft pointer living only in task_output, emailHeaderMessageId-only, task_output-over-stale-task_action_data precedence, non-email task_output.kind, and the new recordDraftDeleted emission) and in updateTaskTool.test.ts (a cleanupDraft: true call on an already-done task whose pointer lives only in task_output still triggers cleanup instead of being swallowed by the no-op guard).

Verification

• pnpm --filter @zero/server run types , clean
• pnpm --filter @zero/server exec vitest run src/services/user-tasks/__tests__/cleanup-draft-pointer.test.ts src/mastra/tools/task/__tests__/updateTaskTool.test.ts , 73/73 passing
• pnpm deps:check , no dependency violations
• Reviewed the diff against thermo-review's standards (dependency direction, file-size, false invariants, spaghetti/branching, reuse of existing helpers) , no blocking findings; see PR discussion for the full pass.

Out of scope

• Deleting the actual live stale draft in Zach's real Gmail account (separate manual/support action).
• The orphaned-execution-id investigation (