Skip to content

design: consistent typed interaction response shapes across commands #1111

Description

@thymikee

Follow-up from the July 2026 error-system audit (ADR 0010) and the ADR 0011 response work: interaction responses are now built through a single constructor (buildInteractionResponseData, #1083) but the SHAPES still vary ad hoc across commands — per-command extras with inconsistent naming, ref/selector/point variants exposing different fields, and Record<string, unknown> typing on the client side hiding all of it (see also #: "Interaction responses leak runner uptime internals and default-value noise", which is one symptom).

Task (design-first, then mechanical):

  1. Inventory the actual wire shapes per command × target-kind from src/daemon/handlers/interaction-touch-response.ts, interaction-touch-targets.ts (interactionResultExtra), and the contract fixtures under test/integration/interaction-contract/ — produce a table in the PR description.
  2. Propose ONE consistent envelope: shared core (coordinates, target identity, warning/hint, evidence, settle) + typed per-command extension; name fields consistently (e.g. always ref without @, always x/y).
  3. Implement behind the existing single constructor. Breaking wire changes need a documented migration note in the PR — flag them loudly rather than sneaking compatibility shims.

Constraints: provider-integration verification is REQUIRED for response-shape changes (repo rule); the interaction contract suite's coverage gate and the guarantee matrix must be updated honestly (waivers need trackingIssue URLs); note that the "-550 client types" narrowing (typed returns instead of Record) is a known API-changing follow-up — this issue is the wire-shape prerequisite for it, not the client-typing change itself.

Acceptance: shape table + decision in the PR, contract fixtures updated, provider e2e transcripts proving byte-level intent for at least press/fill/longpress on ref+selector+point paths, all gates green.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions