Problem
The Orcastrator director rule — "the director directs work, it does not implement it (no writing code, no resolving conflicts, no running builds/tests, no merging)" — is currently discipline-only. There is no hard gate enforcing it. Under pressure (e.g. a worker stalls and the only thing left is a one-line lint fix), the rule gets rationalized away, and the director ends up editing code / committing / pushing itself. That defeats the purpose of the director model.
Proposal
Expose Orcastrator capability settings — a per-Orcastrator (and/or global default) config where the user chooses what the director is allowed to do. Candidate capabilities:
- write/edit code (source + tests)
- commit
- push branches
- run builds / tests
- open PRs
- merge / close PRs
- delete or remove worktrees
- touch live systems / secrets
Each is an explicit allow/deny. Different users want different autonomy levels; this makes the boundary a setting, not a convention.
Enforcement (the important half)
A setting that only documents intent repeats today's failure. The director's action path must actually block disallowed actions (and surface "this action is disabled by your Orcastrator settings — dispatch it to a worker instead") rather than relying on the model's self-restraint.
Why now
Came directly out of a real incident: while building the Smart Orcastrators work, the director violated the no-code rule by editing a worker's test file to clear a lint nit after the worker stalled. The user's call: make this a configurable, enforced setting.
Open questions
- Granularity: per-Orcastrator, global, or both (global default + per-Orcastrator override)?
- Where enforcement lives (renderer dispatch layer vs. the orchestration coordinator).
- Default profile for a fresh Orcastrator (strict vs. permissive).
Problem
The Orcastrator director rule — "the director directs work, it does not implement it (no writing code, no resolving conflicts, no running builds/tests, no merging)" — is currently discipline-only. There is no hard gate enforcing it. Under pressure (e.g. a worker stalls and the only thing left is a one-line lint fix), the rule gets rationalized away, and the director ends up editing code / committing / pushing itself. That defeats the purpose of the director model.
Proposal
Expose Orcastrator capability settings — a per-Orcastrator (and/or global default) config where the user chooses what the director is allowed to do. Candidate capabilities:
Each is an explicit allow/deny. Different users want different autonomy levels; this makes the boundary a setting, not a convention.
Enforcement (the important half)
A setting that only documents intent repeats today's failure. The director's action path must actually block disallowed actions (and surface "this action is disabled by your Orcastrator settings — dispatch it to a worker instead") rather than relying on the model's self-restraint.
Why now
Came directly out of a real incident: while building the Smart Orcastrators work, the director violated the no-code rule by editing a worker's test file to clear a lint nit after the worker stalled. The user's call: make this a configurable, enforced setting.
Open questions