# Existing-peer mail team few-shot

This example uses only peers already present in the AMQ roster.

## Objective

Implement a bounded transport change and obtain an independent sign-off.

## Driver dispatches implementation

Send one `kind=todo` task to the implementer with:

- role charter: implement the named transport behavior; do not review your own result;
- scope: exact files or module ownership;
- acceptance criteria: observable outcomes and failure semantics;
- hard constraints: authority boundaries, prohibited mutations, and stop conditions; and
- evidence: exact tests, logs, or artifacts the report must cite.

The implementer replies to that exact envelope with the outcome, fresh test evidence, unrun checks, and residual risk. A status-only message is progress, not completion.

## Driver verifies and dispatches audit

The driver inspects the change and reruns the decisive checks instead of forwarding the implementer's claims. Then send a separate `kind=todo` task to an auditor in a different context with:

- role charter: audit correctness and contract compliance, not implementation style;
- the authoritative diff or artifact paths;
- the same acceptance criteria and hard constraints; and
- a required approve/reject verdict backed by fresh evidence.

The implementer and auditor are never the same context.

This existing-peer mail pattern does not create worker-runtime state. When the local worker tools are used instead, preserve the five-domain split—Contract, Ledger, Lease/launch, Gate, and Delivery—and never treat a requested capability as a launch grant. A worker is `blocked` only after a correlated typed wait fact; running-only stall observations do not imply action.

## Threaded authorization

After resolving audit findings, reply approve/reject in the original implementation task thread. The verdict reply is the authorization record for that task. Detached mail, presence, drained receipts, and worker self-reports do not authorize landing.