# Help

Answer without mutating files, Beads, branches, PRs, or sessions.

## What dirtyloops Does

Dirtyloops v2.2 compiles an accepted plan into a Beads-canonical execution loop bound to Codex or Pi and to an explicit ownership profile. The default `adaptive` profile lets the run-time orchestrator choose ownership. `orchestrator-callback` keeps the control thread orchestrator-only and requires separate implementation and review owners. Model tier, effort, helper missions, and concurrency remain evidence-driven in both.

Planning stays outside dirtyloops:

```text
Planning
  -> investigate and decide
  -> produce or accept PLAN.md

$dirtyloops create from PLAN.md        # Codex default
$dirtyloops create pi from PLAN.md     # Pi
$dirtyloops create orchestrator-callback for codex from PLAN.md
  -> validate and materialize Beads plus phase docs

$dirtyloops run
  -> execute adaptively until complete or blocked
```

## Commands

- `$dirtyloops help`: explain usage; read-only.
- `$dirtyloops create from PLAN.md`: validate an accepted plan and compile an adaptive Codex-bound loop.
- `$dirtyloops create orchestrator-callback for codex from PLAN.md`: compile a Codex-bound loop with mandatory callback ownership.
- `$dirtyloops create pi from PLAN.md`: compile the same portable loop with a Pi binding.
- `$dirtyloops convert <codex|pi>`: transactionally replace generated harness surfaces while preserving protected state. A missing target reports usage without mutation.
- `$dirtyloops run`: execute ready phases adaptively. Use `--once` for one phase.
- `$dirtyloops update`: dry-run, archive, migrate, and idempotently verify an existing v1 loop using the bundled migration helper, then update Beads contract metadata without changing the plan graph or lifecycle state.
- `$dirtyloops inspect`: report Beads and loop state without mutation.
- `$dirtyloops closeout`: verify completion and generate the storyboard.

Harness and profile are separate bindings. The harness selects the runtime adapter. The profile selects ownership topology. During `run`, stage owners choose evidence-driven helper missions from certified capabilities and current evidence.

Implementation and review strongly encourage useful helper agents, with at most 20 missions per stage. Actual active concurrency is bounded by the user's configured limit, certified runtime capacity, and available slots; Dirtyloops does not assume an undocumented default such as 6.

## What Remains Fixed

- Beads authority
- accepted outcomes and constraints
- one owner per mutable checkout
- correct repo/worktree/branch launch
- concrete run-time callback binding when callbacks are used
- mandatory orchestrator-only ownership when `orchestrator-callback` is selected
- evidence-driven helper fanout with a 20-mission per-stage ceiling
- independent review and resolved CI
- one turn doc per phase
- narrow phase scope and explicit follow-ups
- run-until-complete default

## Good Help Answer

Lead with planning -> `create` -> `run`, state that creation defaults to adaptive Codex and accepts profile and harness explicitly, explain the two profiles in one paragraph, then name `convert`, `inspect`, `update`, and `closeout`. Point to `plan.html` and `examples/adaptive/` when useful.