Scheduling Operating Model

Scheduling is the system that turns recurring agent work into durable wiki updates, not just recurring chat threads.

Definition

A heartbeat is the operating contract for scheduled agents. It answers four questions:

1. What should run?
2. When should it run?
3. Where should output be written?
4. Which durable wiki pages, skills, state files, or logs should change?

The scheduler may create a thread, but the wiki only changes when the run writes output, applies promotion criteria, updates state, rebuilds indexes when needed, and appends wiki/log.md. A scheduler thread without that writeback is only an observation.

Control Flow

Sources Of Truth

automations/<slug>.md wins when local scheduler prompts drift. Scheduler prompts should tell the agent to read the canonical automation file, not duplicate the entire task in fragile scheduler text.

Heartbeat Companion Pages

The scheduling model owns the system-level contract. Heartbeat companion pages provide retrieval handles for common operations:

Required Codex Prompt Shape

Every recurring Codex schedule should include this contract, customized only for the slug:

Read AGENTS.md, wiki/HEARTBEAT.md, automations/<slug>.md, and any files directly referenced by that automation. Execute the canonical automation.

Write output to outputs/<YYYY-MM-DD>/<slug>/codex.md. Apply wiki_targets only when the automation's promotion criteria pass; otherwise record "No durable wiki update needed" in the output.

Update state.json under automations.<slug> when the scheduled check completes. Append wiki/log.md with the date, summary, changed files, and whether a durable wiki update was made.

When wiki pages, skills, routing, or indexes change, run the relevant checks from the automation plus npx tsx scripts/build-index.ts and qmd update && qmd embed. Do not send messages, apply destructive fixes, or mutate external systems unless the automation explicitly permits it.

Wiki Writeback Map

Schedule Matrix

Audit Findings On 2026-06-28

The local Codex scheduler had two classes of drift:

1. Legacy active schedules still pointed at ~/Documents/GitHub/my-wiki.
2. Several newer kevin-wiki schedules had thin prompts that returned a report but did not require wiki writeback, state.json, or wiki/log.md.

scripts/check-freshness.ts now checks ~/.codex/automations for legacy cwd schedules and Codex-capable automations that have no active local schedule.

Actions taken:

• Deleted legacy my-wiki Codex schedules for career, content, bugfix, radar, travel, event, project briefing, recruiter, SEO/GEO, language orchestration, and skill maintenance jobs.
• Updated active kevin-wiki schedules to read canonical automations/<slug>.md files and require output/state/log writeback.
• Created missing Codex-local schedules for source-compile, capability-harvest, cross-project-learning, calendar-sync, email-sync, meeting-sync, oss-license-audit, scheduling-audit, and daily-work-summary.
• Archived the stale disk-only source-compile scheduler entry to ~/.codex/automations-archive/source-compile-orphan-2026-06-28.

Recent Output Review On 2026-06-28

Sampled Codex scheduler outputs produced these writeback decisions:

---

Timeline

• 2026-07-01 | Added Generated Surface Contract as the source/projection authority underneath the heartbeat generated-surface refresh checklist. Source: User request, 2026-07-01
• 2026-07-01 | Linked scheduling to the refreshed heartbeat companion pages for freshness interpretation, automation proof, sub-daily cadence, overdue handling, and generated-surface closeout. Source: User request, 2026-07-01; Operational Heartbeat
• 2026-06-30 | Added the every-four-hours Slack/Gmail/X capture loop and required ISO state timestamps for sub-daily schedules. Source: User request, 2026-06-30; automations/slack-sync.md; scripts/check-freshness.ts
• 2026-06-28 | Created the scheduling operating model to define heartbeat semantics, Codex prompt requirements, writeback targets, and schedule audit findings. Source: User request, 2026-06-28; local Codex scheduler audit