delivery

name	delivery
description	Discover, approve, implement, prove, review, and record a software change.
disable-model-invocation	true
argument-hint	<task>

Delivery pipeline

Use for consequential repository work that must survive handoffs and preserve an evidence trail. The attached delivery-foundation suite proves Base composition and generated-surface integrity. The project must also define and run the behavior-specific verifier suite named in the plan; a verifier is an executable contract, not a prose checklist.

Task: $ARGUMENTS Record harness as claude in the run ledger.

1. Delivery Discover

Run base state context, inspect repository guidance and the owning code, and bound the requested outcome. Before any gate or implementation, atomically create .base/runs/YYYY-MM-DD-<short-kebab-slug>/; if it already exists, retry with the next numeric suffix (-2, -3, and so on). Reserve its empty evidence/ directory. Record assumptions, constraints, acceptance checks, and unresolved proof obligations in that run's task.md. Use this same run slug for every later base approve and base verify --run command.

Assigned agent: delivery-analyst

Delegate this stage to the repository agent delivery-analyst when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

2. Delivery Plan

Write the run plan.md. Name owned files or components, behavior changes, the project verifier suite, migration and compatibility risks, and evidence to retain. Identify the strongest viable alternative and why it is not selected.

Assigned agent: delivery-analyst

Delegate this stage to the repository agent delivery-analyst when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

Gate: plan-approval

STOP after completing this stage. Do not execute until the user explicitly approves the written plan. Request the verdict by writing approvals/plan-approval.md.request in the run folder describing what needs approval, then stop. The verdict is recorded from outside the session: base approve <run-slug> plan-approval (or --deny) writes approvals/plan-approval.md — a standing directive counts only when recorded that way, with --note citing it. Never create the verdict artifact yourself. If the recorded verdict is denied, skip to record with outcome aborted.

3. Delivery Implement

Make the smallest cohesive implementation that satisfies the plan. Preserve unrelated work and approved contracts. Update focused tests and documentation with the behavior they govern.

Assigned agent: delivery-implementer

Delegate this stage to the repository agent delivery-implementer when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

4. Delivery Prove

Run the behavior-specific project verifier named in the approved plan with base verify <suite> --run <run-slug>. The pipeline also attaches the generic delivery-foundation verifier for Base composition and generated-surface integrity. Classify each check as pass, fail, or inconclusive. Record unavailable infrastructure and external gates separately from local proof; do not collapse them into a pass.

Assigned agent: delivery-implementer

Delegate this stage to the repository agent delivery-implementer when native agent delegation is available; otherwise follow that agent's generated contract directly and report the fallback.

Verifier: delivery-foundation

Run base verify delivery-foundation --run <run-slug>. A fail or inconclusive verdict is not passing evidence and must be reported before proceeding.

5. Delivery Review

Review the diff, acceptance checks, retained evidence, upgrade and rollback behavior, and target adapter fidelity. State any residual risk or unverified claim. Update the durable handoff if safe work remains.

Assigned agent: delivery-auditor

Run this stage in a distinct delivery-auditor agent context that did not implement the change. If this target cannot provide separate agent execution, report the review as assisted and do not claim independent maker/checker separation.

6. Record

Always run this stage, including after rejection, failure, or abort. Append exactly one compact JSON object line to .base/history.jsonl with slug, date, pipeline, harness, outcome, and paths. Use completed, aborted, or failed for outcome; never rewrite previous lines.