# Deployment Impact Handoff Guidance

## Background

Clinic is a multi-module, multi-image repository. A source package, HTTP Service name, executable, Clinic CD component, Kubernetes workload, and app-delivery application do not always share the same name. Reporting deployment scope from a changed directory or Service name alone can therefore select the wrong component or omit a required image.

The development workflow already requires plans, focused validation, and accurate PR descriptions, but it does not explicitly require a post-implementation deployment-impact summary.

## Goal

Require every completed code change to report both the source modules affected and the exact components that must be built and deployed, using verified executable and delivery mappings.

## Current Behavior

- The module overview documents source-to-image and app-delivery mappings.
- PR descriptions must mention affected modules and deployment impact.
- The final-report checklist records release artifacts that actually ran.
- There is no explicit handoff step requiring a deployable component list after implementation.

## Target Contract

After implementation and relevant local validation, the agent must:

1. Trace each changed runtime path to its owning Go module or non-Go tool, executable, image, Clinic CD component value, app-delivery application, and Kubernetes workload.
2. Report two separate lists:
   - affected source modules and executables;
   - required deployment components and environments.
3. Avoid deriving deployment scope from filenames, package names, route prefixes, Kubernetes Service names, or conversational shorthand alone.
4. Explicitly report that no deployment is required for documentation-only, test-only, or development-tooling-only changes when that is the verified result.
5. Include the same verified deployment impact in the PR description and use it to select staging and production workflow inputs.

## Affected Files

- `AGENTS.md`, under Clinic backend development, testing, and release guidance.
- No source module, executable, image, workflow, route, or app-delivery mapping changes.
- `docs/clinic-module-overview.md` remains accurate and does not require modification.

## Implementation

1. Add a development-workflow section describing how to determine deployment impact from the actual build and delivery chain.
2. Define the required affected-module and deployment-module handoff format.
3. Add deployment impact to the final reporting checklist.
4. Preserve existing authorization, staging, merge, and production release boundaries.

## Exclusions

- No application code or configuration change.
- No workflow, image, Kubernetes, or app-delivery change.
- No deployment or release action.
- No attempt to maintain a second static component mapping inside `AGENTS.md`; the module overview and current workflow/app-delivery source remain authoritative.

## Compatibility

This is documentation-only guidance. It changes future agent reporting and deployment selection behavior but does not change Clinic runtime behavior.

## Validation

- Review the new wording against `docs/clinic-module-overview.md` and current Clinic CD component inputs.
- Confirm examples distinguish source module, executable/image, Service name, and deployable component.
- Run `git diff --check`.

## Release Boundary

No deployment is required. Commit, push, and PR creation require separate user authorization.