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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions