Automation Self-Care

Automation Self-Care

Create a native, provider-specific maintenance fleet from one provider-neutral control loop. Preserve the original intent of the ANTIGRAVITY task family while requiring evidence, reversible changes and native readback.

Non-negotiable boundaries

• Treat discovery, planning, approval, mutation and readback as separate phases.
• Use the target app's supported automation API, command or UI. Never assume that editing a storage file changes live app state.
• Read local rules, locks, deletion/suppression logs and existing schedules before proposing a task.
• Do not invent scheduler support. If create/update/readback cannot be proven, produce a manual installation plan and stop before mutation.
• Make at most one independently testable tuning change per care run.
• Protect the care tasks from disabling themselves or reducing their own cadence below the configured recovery floor.
• Preserve the previous prompt, schedule, model, permissions and enabled state so every mutation can be rolled back.
• Count success only after outcome evidence, not merely scheduler start or exit 0.
• Never copy secrets, private prompts or personal data into a shared registry.

Workflow

1. Discover the native automation surface

Inventory the current actor, provider, app class, scheduler surface, supported operations, state files, run history, usage telemetry and readback method. Record capabilities using the profile contract in provider-adapter-contract.md.

Distinguish native desktop-app schedules, CLI/headless execution, OS scheduler or service starter, general scheduler service, workflow engine, and unsupported or UI-only automation. Do not equate the existence of a config file with a supported mutation path.

2. Inventory the fleet