Daily-Ops Desktop Scheduled Routine

← Back to Operating Procedures daily-ops-desktop-routine.md

Daily-Ops Desktop Scheduled Routine

Status: Pilot (initial setup 2026-05-21). Machine: VFT-CommandCtr (always-on desktop; also hosts the NVENC relay). Mechanism: Claude Code Desktop app → Routines → Local task. Owner: Chris.

Purpose

Pre-generate the /daily-ops briefing each morning so Chris wakes to a ready standup at .claude/daily/{today}-standup.md instead of running the command manually.

Why a Desktop task, not a cloud routine

Cloud routines (via the /schedule skill in the CLI) run from a fresh git clone with only claude.ai MCP connectors — they do NOT carry our local .mcp.json (value-first-ops, local HubSpot MCP) or local .env tokens. /daily-ops depends on all of that. Cloud routines for VFT cadence work fire into the void.

Desktop scheduled tasks run locally on VFT-CommandCtr and inherit the full local stack — .mcp.json, .env, every command/skill/agent. That is what makes them actually work. Full diagnosis: memory/project_scheduling_native_routes_local_over_cloud.md.

Setup

In the Claude Code Desktop app on VFT-CommandCtr: Routines sidebar → New routine → Local.

Field Value Why it matters
Type Local (not Cloud) Cloud strands the local stack — the whole reason the previous routines failed
Project / working directory The VFT cockpit project (the directory containing the .mcp.json with value-first-ops + local HubSpot MCP, and the /daily-ops command) This is what gives the task the full stack
Schedule Daily, 5:00 AM local (America/Chicago) Desktop tasks use local time — no UTC conversion
Permission mode Auto (pre-approved / bypass — NOT Ask) /daily-ops spawns Marshal, reads HubSpot, writes files. In Ask mode the run stalls at the first prompt and you wake to a frozen session, not a briefing.
Git worktree isolation Off So the standup file lands in the real .claude/daily/ where Chris reads it
Model Opus (default) Briefing quality; drop to Sonnet later if daily cost matters

Prompt (paste exactly):

Run /daily-ops to generate today's Daily-Ops briefing for Chris.

Complete the full pipeline autonomously — spawn Marshal and whatever
specialists the command calls for, pull live HubSpot and client data
through the local MCP servers, and write the briefing to
.claude/daily/{today}-standup.md exactly as the command specifies.

Do not stop to ask questions — make the standard operating decisions and
finish the run. When done, confirm the path of the standup file you wrote
and give a one-line summary of what's in it.

Three reliability gotchas

  1. Desktop app must be running at 5am. Local tasks only fire while the app is open. (It catches up the most-recent-missed run on next open — older misses are discarded.)
  2. Machine must not sleep at 5am. Confirm Windows power settings don't sleep VFT-CommandCtr overnight.
  3. Permission mode = Auto. Worth repeating — it's the single most important setting.

Test-fire discipline (before trusting the schedule)

Before relying on 5am: hit "Run now" on the routine manually once. Verify it completes, open .claude/daily/{today}-standup.md, confirm the briefing is real and complete. Then let the 5am schedule carry it. Routines that haven't been manually verified ≠ routines that work — that's the lesson from every prior attempt that silently never fired.

Extending the pattern

Once Daily-Ops proves reliable across one week, the same recipe works for other cadence jobs: Pulse, the BU briefs, sentinel checks, the Monday weekly plan. Each becomes another Local routine, same project, Auto permissions, the relevant command in the prompt. Do NOT extend until Daily-Ops has one verified week under it.

What NOT to do

  • Do not try to run /daily-ops as a cloud routine via /schedule. It will fail silently — same failure mode as the prior Emerjent routines.
  • Do not replace Loom (agents/background-workers/) or Emerjent routines based on this pilot alone. Both can coexist; retire either only after a Desktop task earns it on reliability evidence over time.
  • Do not skip the test-fire. Configured ≠ working.

Related

  • memory/project_scheduling_native_routes_local_over_cloud.md — full diagnosis of cloud vs. local + why prior routines failed.
  • memory/project_headless_crm_principle.md — why agents author HubSpot programmatically without VFT humans touching the UI.
  • skills/ai-leadership/INDEX.md — the documented "intended cadences, not guarantees" gap this pilot exists to close.