Separating Project Intent from Runtime Execution in APX Schedules

Описание и применение

Автор разделяет намерения проекта (APC) и выполнение в среде выполнения (APX). Расписания и доставка зависят от состояния машины и не должны храниться в репозитории. Использование флага --project и разделение задач на предварительные команды, выполнение агента и пост-команды упрощает отладку и поддержку.

Задача

Treating scheduled automation tasks as static project truth stored in the repository leads to issues with portability, debugging, and state management across different machines and restarts.

Результат

By separating project intent (APC) from runtime execution (APX), the system becomes more robust, debuggable, and honest about its dependencies. Routines are easier to inspect and modify, and the repository remains clean of machine-specific state.

Рабочий процесс

• Define the routine with a specific project binding using --project to avoid ambiguity.
• Use pre_commands to gather local data or check conditions; emit APX_SKIP if no action is needed.
• Use exec_agent for bounded text generation tasks instead of super_agent to limit tool surface and complexity.
• Use post_commands to handle delivery (e.g., sending via Telegram) using the output from the agent.
• Inspect routine history and logs locally in APX for debugging, rather than relying on committed repo files.

Доказательства

If it needs time, delivery, or daemon state, it lives on the APX side. If it needs to survive as project meaning, it lives on the APC side.

Источник

A routine without a project binding often means one of two things: I have not thought about where the work belongs. I am about to spread machine-specific behavior into something I will later expect to clone cleanly.

Источник