Automation Audit Workflow

Determine which automations actually exist, can run, are scheduled, are fresh, and have proof. A declaration or markdown file is not evidence that a job is active.

State model

State Meaning
Declared A repository definition names the job.
Configured Required command, environment, and owner are present.
Scheduled A real local or cloud scheduler has an enabled entry.
Runnable A bounded invocation reaches its owned interface.
Fresh The last successful proof falls within the declared cadence.
Blocked An exact dependency, credential, runner, or authority is missing.
Retired The definition and discovery surfaces intentionally say the job is no longer active.

Never collapse these states into a boolean active. Source: scripts/audit-automation-readiness.ts; scripts/check-freshness.ts

Run contract

  1. Inventory automation definitions, package commands, runners, scheduler entries, state records, output paths, and last proof.
  2. Classify each job using the state model above.
  3. Run npm run audit:automations and npm run status; retain their exact findings.
  4. For a repairable repository-owned defect, change the smallest canonical owner and rerun the bounded doctor.
  5. Never enable a scheduler, send a message, spend money, or change a production job without the authority that action requires.
  6. Write back the corrected state and proof. Do not advance freshness for a template, dry plan, failed run, or skipped dependency.

The machine-readable owner is automation.audit@1.0.0 in brain/workflows.json. Source: brain/workflows.json

Proof

A run is complete only when the inventory, classification, exact command result, state writeback, and remaining blockers agree. External schedules require a separate scheduler receipt; repository state alone cannot prove them. Source: Workflow Run Contract

Timeline