# Domain adapters

The swarm protocol is domain-neutral. A domain adapter says what "work", "ownership", "evidence"
and "done" mean for this kind of task. Pick one, combine several, or write a project-specific
adapter in `.swarm/profile.md`. Do not treat these as mandatory pipelines.

## Software / code

- Units: module, feature, crate, service, migration, test cluster.
- Ownership: source + test paths; shared manifests/lockfiles/barrels/schemas are integrator-only.
- Acceptance: build/test/lint commands, typecheck, generated-code compile, runtime smoke.
- Verifier: reruns commands, reads the diff, checks edge cases and API compatibility; no self-review.
- Evidence: command + observed result, test names, compiler output, benchmark numbers.

## Research / analysis

- Units: one question, source cluster, claim set, or section.
- Ownership: one notes/report file per unit; no shared notes file.
- Acceptance: every factual claim has a source URL; dates are explicit; counter-evidence is considered.
- Verifier: samples claims against sources, checks citation resolvability and recency, looks for
  unsupported synthesis.
- Evidence: source URL, quote/paraphrase, access date, confidence, open questions.

## Content / documents / translation

- Units: one section, chapter, page, or locale.
- Ownership: separate section files; the editor/integrator owns the assembled document and style.
- Acceptance: section brief, word/character budget, terminology/glossary, citations, style guide,
  rendered artifact (PDF/HTML/DOCX) where applicable.
- Verifier: reads the rendered artifact, checks structure/voice/term consistency, samples facts.
- Evidence: rendered path, word count, diff, terminology check, citation check.

## Data / analytics

- Units: one dataset, metric, query, notebook, or chart.
- Ownership: input data read-only; one output table/notebook/report per unit; shared schemas need an
  integrator.
- Acceptance: reproducible script with pinned inputs; output schema; row counts; metric definitions;
  checksums or input hashes.
- Verifier: reruns the pipeline on a sample or full dataset; recomputes key numbers; checks nulls,
  duplicates, units and time zones.
- Evidence: command, input hash, output rows, metric values, notebook/report path.

## Design / UX / visual

- Units: screen, component, flow, illustration, design token set.
- Ownership: one source/design file per unit; shared tokens/components/integrator.
- Acceptance: rendered artifact at required sizes/states; accessibility (contrast, focus, keyboard,
  labels); interaction states; visual regression.
- Verifier: renders the artifact in an isolated display; checks default/minimum/empty/error states;
  never accepts a shared-desktop screenshot.
- Evidence: screenshot path, dimensions, command, contrast/focus notes.
- See `visual-testing.md` for isolation and deterministic capture; it is optional for non-visual work.

## Operations / infrastructure

- Units: one service, deployment, migration, runbook, or config change.
- Ownership: infra files and runbooks; live environments are not "write scopes".
- Acceptance: dry-run/plan output, diff, rollback procedure, monitoring/health check, no production
  writes without explicit human approval.
- Verifier: reviews the plan/diff, runs read-only checks, confirms rollback and blast radius.
- Evidence: dry-run output, diff, health check, rollback command, approval record.

## How to adapt without inventing a pipeline

1. Write `.swarm/profile.md` with: domain, artifacts, commands, evidence types, approval boundaries.
2. In `.swarm/brief.md`, replace command-only success criteria with "evidence type + check".
3. In each task card, name the artifact and the verifier action, not the steps.
4. In verification, use the matching adapter above; independent evidence is the invariant.