mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-23 05:35:40 +00:00
465cc66283
A workflow agent that spawns child runs forces every dispatch through an operator checkpoint, even for dispatcher workflows whose whole purpose is unattended fan-out. The only workaround today is out-of-band approval hooks that poll the runs API and click approve from the host, which needs a server token inside the worker host and leaves the decision recorded nowhere near the run it approved. Give the platform a first-class policy path instead: a child start is auto-approved only when the server enables `[server.approvals] allow_child_auto_approval` and the spawning parent's registered `workflow.toml` opts in with `[run.children] auto_approve`. Both defaults stay false, so nothing changes for existing workflows. The decision is read from the parent's persisted spec at start time, so a config reload affects future starts only, reassigning a run's parent link cannot change the policy, and `RunIntentArgs.auto_approve` keeps its existing meaning (the child's own agent-interaction posture) without ever bypassing the lifecycle checkpoint. A worker start outside its own parentage fails closed to the operator gate. Auto-approved children record a distinct `auto_approved` lifecycle transition and project `approval.state = approved` with a decision timestamp in one pass, so lifecycle history is auditable and no transient pending state is ever observed. Note: this commit depends on lithoscomputer/petri accepting the platform-only `[run.children]` workflow.toml section; the Cargo.lock bump to the merged rev lands with that PR. |
||
|---|---|---|
| .. | ||
| administration | ||
| agents | ||
| api-reference | ||
| changelog | ||
| core-concepts | ||
| examples | ||
| execution | ||
| getting-started | ||
| human-tools | ||
| images | ||
| integrations | ||
| languages | ||
| logo | ||
| reference | ||
| tutorials | ||
| workflows | ||
| .mintignore | ||
| docs.json | ||
| dot-highlight.js | ||
| favicon.svg | ||
