Automation Readiness
A schedule is active only when its commands, local data, authentication, and canonical definition are available. Missing credentials pause a job; they do not become a fake successful run.
Current State
Run the executable audit for current truth:
npm run audit:automations
The machine-readable result is wiki/meta/automation-readiness.json. It contains only capability booleans and scheduler metadata, never tokens or account identifiers.
As of 2026-07-14, the local runtime has Node/npm/npx/pnpm, authenticated GitHub CLI, QMD, the Fieldtheory X extractor and its data, Codex, repository dependencies, agent-browser, Chrome for Testing, and the configured Lightpanda engine. Active Codex jobs that depend only on those surfaces are ready. Source: npm run audit:automations, 2026-07-14
Paused Integrations
| Automation | Missing setup | Reactivation gate |
|---|---|---|
calendar-sync |
Google OAuth client and stored refresh token | Configure OAuth, run the collector successfully, then reactivate. |
email-sync |
Google OAuth client and stored refresh token | Configure OAuth, run the collector successfully, then reactivate. |
meeting-sync |
Circleback token | Provide the token to the scheduled shell and complete a successful read-only sync. |
slack-sync |
Reusable logged-in Slack browser/CDP session | Save a Slack auth profile or expose an authenticated Chrome CDP session, verify read-only access, then reactivate. |
Do not advance syncs.* freshness while one of these integrations is paused or blocked.
Cursor Cloud Boundary
The .cursor-automation.md files are cloud prompt templates, not evidence that a Cursor cloud schedule is enabled. Firecrawl and GitHub MCP access must be verified in Cursor's automation portal before any cloud prompt that declares those MCPs is activated. Local Codex schedules use their installed local CLIs and built-in web access instead.
Daily Brief Activation Boundary
The current readiness audit cannot distinguish proposed definitions from active ones, cannot validate queue delivery or proposal-only authority, and hard-codes several dependency mappings by slug. Therefore the source-drift, workflow-refresh, adversarial-review, brief-compile, approved-apply, workflow-health, and review-learning automation family remains specified but inactive.
Activation requires Workflow Automation V2 Contract plus a healthy
Daily Brief Control Plane. Research jobs must declare proposal-only authority
and daily-brief delivery. The approved apply job must consume an exact durable
approval receipt. No definition or cloud prompt is evidence of readiness by itself.
Retirement Rule
Deleting an automation means deleting its live schedule, canonical definition, cloud prompt, state key, and active routing references. Historical log entries remain historical evidence.
Timeline
- 2026-07-16 | Added the Daily Brief activation gate: automation V2 lifecycle/delivery/authority semantics and a healthy control plane must exist before the new research/approval family is defined as active. Source: User request; local automation implementation audit
- 2026-07-14 | Added executable readiness auditing, installed the missing browser/runtime dependencies, paused four unauthenticated integrations, and removed the obsolete Hawaii and offsites schedules and definitions. Source: User request, 2026-07-14