# Profile presets

A repo usually runs **one** kind of work — its focus/objective and settings.
**Profile presets** let one repo carry **several named work streams** you control
independently: e.g. a `unit-tests` preset that runs nightly, a `solve-issues`
preset you trigger by hand, and an `explore` preset for weekends.

## What a preset is

Each preset is a self-contained run config:

- **name** — e.g. `unit-tests`.
- **enabled** — whether it participates in autonomous runs / round-robin.
- **mode** — `schedule` (runs in its own window) or `manual` (only when you
  trigger it via the Run button, CLI, or API).
- **work type** — `implement` (focus/objective), `explore`, `issue_solving`,
  `issue_scout`, or `pr_watch`.
- **the work bundle** — focus, objective, verify command, auto‑merge, reviews,
  and (for schedule mode) a days/start/end window.

Manage them in **Repo settings → Profile presets** (add · edit · enable/disable ·
delete).

## How a preset gets picked

- **Scheduled runs** — the scheduler considers every *enabled, schedule‑mode*
  preset whose window matches now. If more than one overlaps, it **round‑robins**
  across them so each gets a fair turn.
- **Manual runs** — **Run** with a specific preset, or leave it unset to
  **round‑robin across the enabled presets**. A `manual`‑mode preset never runs on
  its own — only when you ask for it by name.

```
scheduled  → enabled + schedule-mode + window matches now → round-robin if >1
manual Run → --preset <name>, else round-robin across enabled presets
```

Only one run executes per repo at a time, so presets take turns — they never run
concurrently.

## What a run does, per work type

A preset's **work type** decides what running it actually does — and it means the
same thing whether the scheduler runs it or you trigger it manually (Run button,
`run --preset`, or API):

| Work type | Running it… |
|---|---|
| `implement` | spawns the team against the focus/objective → a PR |
| `explore` | kicks a read‑only **scout** that proposes candidates (no PR) |
| `issue_scout` | audits the repo and **files GitHub issues** (no branch, no PR) |
| `issue_solving` | picks the **top queued issue candidate** and solves it → a PR |
| `pr_watch` | syncs and **verifies the top open PR** |

Notes:
- `explore`, `issue_scout`, `issue_solving`, and `pr_watch` require the **Pro plan
  or higher**; `issue_scout`/`pr_watch` also need a GitHub token.
- `issue_solving` and `pr_watch` act on what's already queued — if there's nothing
  (no issue candidates / no open PRs), the run reports *"nothing to do"* rather
  than failing. Scout/sync first to populate them.

## From the CLI / API

This is what lets another agent configure and operate several work streams per
repo:

```bash
am-cloud platform repo preset <id> list
am-cloud platform repo preset <id> add --name unit-tests --work-type implement \
    --mode schedule --schedule-days "[0,1,2,3,4,5,6]" --start 22 --end 8 --focus "raise coverage"
am-cloud platform repo preset <id> enable|disable|remove <name>
am-cloud platform repo run <id> --preset unit-tests     # omit --preset → round-robin
```

REST: `GET/POST /api/repos/{id}/presets`, `PATCH/DELETE /api/repos/{id}/presets/{name}`,
and `POST /api/repos/{id}/run?preset=<name>`.

## Relationship to other settings

- **No presets = today's behavior.** A repo with no presets just uses its
  settings above — nothing changes until you add one.
- **[Playbooks](/docs/playbooks)** are curated focus+verify starting points; a
  preset is a named, schedulable instance bound to a repo (you can seed one from a
  playbook).
- **[Focus](/docs/focus) / [objectives](/docs/objectives)** still apply — a preset
  simply carries its own focus/objective for its stream.

## Costs per preset

Each run records the preset that produced it, so spend can be attributed **per
profile** (e.g. *"how much did the `unit-tests` profile cost on this repo?"*) —
see [Run costs](/docs/run-costs).

## Related

- [Focus](/docs/focus) · [Playbooks](/docs/playbooks) · [Objectives](/docs/objectives)
- [Scheduling](/docs/scheduling) · [Run costs](/docs/run-costs)