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.

来源