## Context

Platform persists each server's deployment definition, including host paths and lifecycle commands. The normal deployment endpoint intentionally exposes only configured flags, so the editor starts these fields blank. This protects operational data in ordinary reads but prevents an authorized operator from comparing the saved definition with Run behavior.

## Goals / Non-Goals

**Goals:**

- Let an authorized server manager explicitly retrieve and inspect that server's saved deployment inputs.
- Make the editor visibly require this explicit action before it receives raw values.
- Preserve redaction on all existing read projections.
- Expose a safe indication of the latest lifecycle job's deployed revision and whether its leased input contained a deployment definition.

**Non-Goals:**

- No host browsing, direct Run connection, log changes, secret exposure, or changes to the Run protocol.
- No display of runtime-binding credentials.
- No attempt to infer what a previous Run process actually executed from Platform alone.

## Decisions

1. Add a separate authenticated `GET /server-instances/{id}/deployment/reveal` endpoint rather than expanding the existing deployment read response. This makes the security-sensitive action explicit and preserves compatibility for all existing consumers.
2. Reuse server-owner authorization and return only the persisted path/command fields plus non-sensitive deployment metadata. Runtime bindings are excluded because they can contain credential references or secrets.
3. Add a reveal button to the edit workflow. It calls the endpoint only after operator intent, replaces the local blank fields, and provides a clear success/error state. A plain close/reopen returns to the normal redacted form.
4. Derive dispatch diagnostics from the current server's lifecycle jobs. It reports revision and deployment-input presence, not the leased fields themselves. Platform can prove a job was queued with the stored revision; only Run's own safe job result can prove successful execution.

## Risks / Trade-offs

- [An authorized browser session can now read operational paths/commands] → The sensitive response requires explicit owner-authorized access, is not cached in existing list/detail endpoints, and the UI fetches it only after an intentional action.
- [Operators could confuse queued dispatch with successful execution] → Label the diagnostic as dispatch evidence and separately retain Run job state/progress.
- [Sensitive values could linger in a browser tab] → Keep them only in the open workflow state and clear them when the dialog closes.

## Migration Plan

1. Deploy the additive endpoint and frontend reveal action.
2. Roll back by removing the reveal route/UI; existing saved deployment definitions and normal redacted reads remain unchanged.

## Open Questions

- None. The requested scope is explicit authorized display of existing deployment values.