Pipeline autonomy

The pipeline orchestrators of the Skills plugin — /new-feature and /bug — pause for a human at fixed points. How many pauses a project wants is a decision, so it is declared once in the knowledge base as a policy, not repeated in every conversation. The policy is opt-in: with no policy, every pipeline keeps the most conservative behaviour.

The policy governs conversation gates and orchestration only. It never relaxes broker enforcement, the deploy no-go list, the plugin hooks or the transaction protocol. Someone able to edit it could remove a conversational checkpoint, never run a credentialed operation.

Where the policy lives

An active STD entity tagged scope:pipeline-autonomy at project level, optionally with a component-level override. At start the orchestrator runs exactly one query for it, reads it fresh on every run, and prints the resolved mode in its progress header:

autonomy: zero-gate | single-gate | dual-gate (policy: <STD-id> v<N> | defaults)

Merging is most-conservative-wins, key by key: dual beats single beats none, and a component override may tighten the project policy but never relax it. An unknown value resolves to the most conservative mode, so an older plugin reading a newer policy degrades towards more gating, not less. Edits made while a pipeline runs apply from its next start.

schema_version: 2
gates:
  new-feature: dual      # dual | single | none   (absent => dual)
  bug: default           # default | none         (absent => default)
autonomy_log: true       # record every auto-resolved decision (zero-gate)
backlog_chaining: false  # chain the next open item after activation (zero-gate)

The three modes

• Dual-gate (default, no policy) — two mandatory pauses in /new-feature: one on the requirement, one on the spec.
• Single-gate — exactly one pause, with the requirement, the spec and a recommendation consolidated. Early escalation still stops before planning when something looks wrong.
• Zero-gate (none) — no mandatory conversational pauses. The orchestrator runs the same evaluation as single-gate, but each signal that would ask for review is auto-resolved with the most conservative viable option and recorded in an AUTONOMY_LOG: one line per decision, shown in the progress output and saved with the pipeline's record in the knowledge base (or in the cancel reason if the transaction is cancelled first). Auditing replaces approval; it does not replace evaluation.

The hard floor

Three classes always stop for a human, in every mode. They are not configurable — a floor you can lower is not a floor:

1. any operation on the deploy no-go list — a production deploy, a real registry publish, a vault or allowlist change, a destructive git or cloud operation;
2. an estimated recurring cost impact above 20% of the current budget;
3. a security-tagged change that fails exhaustive validation.

In zero-gate mode a validation criterion that fails three times does not ask: the pipeline records a blocked issue and continues when the criterion is not core, or cancels the transaction when it blocks the spec's core acceptance criteria.

Backlog chaining

With zero-gate and backlog_chaining: true, an invocation that declares a backlog scope — a milestone tag, a roadmap, or an explicit list of issues — picks the next open item after each activation and starts a fresh pipeline for it. It stops when the scope is empty, a hard-floor pause fires, two consecutive items end blocked, or the session budget runs out. Pacing belongs to the harness: run it under /loop (or scheduled wake-ups) for scopes that outlive one session; the skill itself never sleeps or busy-waits.

Rolling back

Set the policy's status to anything other than active, or archive it: the next pipeline start is back to the two default gates. There is no local file to clean up.