---
name: delivery-loop
description: Plan, implement, and verify a software feature or bug fix when the user wants end-to-end delivery rather than advice or review only.
---

# Delivery Loop

Carry the requested change through the smallest complete engineering loop. Preserve explicit user choices and do not expand a diagnosis-only or review-only request into implementation.

## Establish the contract

Inspect the repository guidance, current state, relevant code paths, and available test commands. Restate internally what observable behavior must change, what must remain unchanged, and how success can be demonstrated. Ask a question only when a missing choice would materially alter the result.

For architecture-sensitive work, identify affected boundaries, data flow, failure behavior, compatibility constraints, and rollback implications. Prefer the least complex design that fits existing conventions. Record an ADR only when the decision is durable, costly to reverse, and not obvious from the code.

## Execute in tight loops

For a bug, reproduce or establish the failing behavior before changing code. For a feature, begin with the narrowest useful acceptance case. Use test-first development when the repository supports it and the test can exercise meaningful behavior:

1. Add or identify a test that fails for the intended reason.
2. Make the smallest implementation that satisfies it.
3. Refactor only after the behavior passes.
4. Repeat for edge cases that carry real risk.

If the build already fails, inventory the errors before editing. Separate pre-existing failures from changes caused by the task. Fix root causes in dependency order and avoid architectural changes whose only purpose is silencing diagnostics.

## Verify proportionally

Run the most targeted relevant check first, followed by the repository's required broader checks when risk justifies them. Include build, type, lint, unit, integration, or E2E checks only when they exercise the changed behavior. Inspect the final diff for unrelated edits, debug output, accidental generated files, secret material, and missing documentation.

Finish with a concise outcome, changed behavior, commands actually run, and any limitation that remains. Never report a check as passing if it was skipped, unavailable, or failed.

## Boundaries

Do not commit, push, deploy, delete user data, rotate credentials, or mutate external systems unless the user requested that action. Do not hide failures by weakening tests, suppressing errors broadly, or increasing retries without evidence.