# ADR 0006 — Workflow tier presets (quick / standard / strict)

Status: accepted
Date: 2026-07-02

## Context

Diablo's current topology is intentionally explicit and conservative: a frozen
plan, per-stage design → worker → verifier, measured verification (ADR 0001),
bounded retries, and final whole-feature verification. That is the right default
for medium-to-large work, but it is not the only right level of ceremony.

Some issues are tiny and low-risk (a typo fix, a narrow test fix), where the
full ceremony adds cost without materially improving safety. Other issues are
high-risk (payments, security, core architecture), where the default ceremony is
insufficient and users want explicit human checkpoints plus stronger guarantees.

SwarmForge exposed this as workflow packs (`two-pack`, `four-pack`, `six-pack`).
Diablo needs a similar knob, but reshaped as central-conductor policy presets
rather than decentralized role packs. The same vocabulary should allow users to
say:

```bash
diablo run fix-typo --tier quick
diablo run payments --tier strict
```

A previous run-metrics/reporting issue already landed, so presets can be
compared empirically (wall time, retries, correctness) instead of becoming
unmeasured folklore.

## Decision

Add three named workflow presets:

- `quick`
- `standard`
- `strict`

Workflow presets are **conductor policy presets**, not model presets. The feature
may change ceremony, verification requirements, retry behaviour, and gate
policy. In v1 it must not change the per-role model selection or thinking level,
because those are already independently configurable.

Default = `standard`.

### Preset semantics (v1)

#### `quick`

Intended for small, low-risk changes.

v1 behaviour:

- a separate per-stage design step is skipped (the worker inspects real code and
  makes a minimal inline plan itself);
- approval gate is forced to `none` (fully AFK);
- retry is capped to `min(configured retry limit, 1)`;
- an approved frozen plan is not required; auto-plan remains allowed;
- measured `verify.commands` are not required, though `standard`/project
  validation still warns when they are absent;
- final whole-feature verification is still required;
- event log/reporting must still record which tier was used.

#### `standard`

Intended to be Diablo's current default behaviour.

v1 behaviour:

- preserves existing topology (design → worker → verifier);
- preserves configured gate;
- preserves configured retry;
- an approved frozen plan is not required;
- measured `verify.commands` are not required;
- must be identical to current behaviour unless an explicit ADR changes a
  separate dimension.

#### `strict`

Intended for critical/high-risk work.

v1 behaviour:

- requires measured deterministic `verify.commands` to be configured;
- requires an approved frozen plan (status `planned`);
- forces approval gate to `approval`;
- preserves full ceremony (design → worker → verifier);
- preserves configured retry;
- rejects silent LLM-only verification rather than allowing it.

### Precedence

Resolved from this order:

```text
built-in default standard <- diablo.config.json workflow.tier <- CLI --tier
```

`standard` is the missing-file default.

### Safety rules

- `quick` may reduce ceremony but must never skip final verification.
- `strict` must reject unsafe runs rather than silently downgrading.
- Workflow presets are additive: absent config preserves existing behaviour.

## Rationale

A named workflow preset is valuable because:

- it turns "I am doing a trivial fix" or "this change is risky" into a single,
  inspectable policy rather than scattered manual config tweaks;
- it is benchmarkable once run metrics exist;
- it avoids mixing model configuration with ceremony policy, which would make
  both harder to reason about and harder to measure.

Keeping presets as workflow policy, rather than model presets, preserves the
existing precedence chain (`defaults <- config <- CLI flags`) and avoids
introducing hidden model magic. Model tuning is orthogonal and already available
via `models.*` / CLI model flags.

## Consequences

- Absent `workflow.tier` defaults to `standard`, preserving backward
  compatibility with every existing config and existing run.
- A `--tier` CLI flag overrides the configured tier for one run.
- `quick` must surface its reduced ceremony explicitly in reporting/events so
  future benchmarks can compare tiers fairly.
- `strict` must fail fast on missing measured verification or missing approved
  plan, rather than allowing a risky run to proceed under a stricter-sounding
  name.
- Revisit v1 defaults after a few real runs:
  - if `quick` thrashes on medium work, cap its intended use more narrowly;
  - if `strict` approval is too expensive, expose a separate verified-only
    strict mode once telemetry proves verifier overhead is the bottleneck.