---
name: business-delivery
description: Lead-owned least-cost procedure for proving and handing off the accepted business result.
---

# Business Delivery

Use when work must end in the user's accepted outcome rather than activity or a
code-only proxy.

Before implementation, testing or deployment, load the primary checkout's
`.agents/TEST_ACCESS.md` via Git worktree mapping and follow the active package's
`common/protocols/REVIEW_TO_DELIVERY.md` execution-access contract. Reuse/recover
authorized local test access with supported administration; persist only protected
references/scope at handoff. Existing authority permits preparation without reasking;
unknown/revoked operations stay blocked. Sudo alone never grants authority.

## Procedure

1. Confirm the current business claim, accepted MVP Definition of Done, actual
   production consumer path, and shortest real canary.
2. Lead owns the engineering outcome and assigns every engineering step to a native Worker, even when small. A business executor inside the product handles its user task and is not the engineering Worker for this session.
3. Use the cheapest evidence sufficient for the exact business claim.
4. Add Reviewer, Tester, Overseer, Critic, or hardening only when concrete risk
   makes their expected value exceed their cost.
5. Report source/test proof, deployment state, and real-canary proof separately.
6. Stop when the accepted claim is proven and hand off deferred optional work as
   non-blocking.
7. For work crossing an hour or its original maximum, include the time guard's
   completed-task/file, planned-versus-actual, blocker/gate, and route-change
   report.

## Do not

- Do not substitute process completion or technical proxies for the requested
  result.
- Do not silently strengthen an accepted MVP claim.
- Do not skip a role that is genuinely required by current risk, but do not run
  a role merely because a template once made it mandatory.