# Session Interactive Wait Surfaces

CTM models three different "waiting for the user" states. They must not share
one approval UI because they have different risk and action semantics.

## States

- `approval`: the agent is asking permission to run a tool, edit files, or take
  another side-effecting action. This is a security/control-plane decision.
- `choice`: the agent is asking the user to pick from a terminal menu, such as a
  Claude `AskUserQuestion` planning question. This is normal conversation flow,
  not permission.
- `input`: the agent is idle at a free-form composer.

## UI Contract

- Only `approval` may show the desktop `Approval needed` banner with
  Approve/Deny actions.
- `choice` must never show approval wording or Approve/Deny buttons. The live
  terminal menu is the primary UI on desktop; mobile may render a tappable
  `Terminal choice` card that sends `session.select_choice`.
- `input` should not surface an approval or choice card.

## Control Plane

- `approval.respond` is high-risk and step-up gated on remote clients.
- `session.select_choice` is a medium-risk terminal interaction that verifies the
  live menu before pressing Enter.
- Desktop must preserve the same separation: raw `1\r` approval shortcuts belong
  only to approval prompts, not normal choices.

## Regression Invariant

For any `waiting-for-input` event with `reason: "choice"`:

- no `.session-approval-banner` should be visible;
- text `Approval needed` should not be rendered;
- Approve/Deny buttons should not exist for that state.
