Skip to content

feat(tap): Add @eN snapshot refs for capture-driven taps#12

Draft
DouweBos wants to merge 1 commit into
mainfrom
douwe/snapshot-refs
Draft

feat(tap): Add @eN snapshot refs for capture-driven taps#12
DouweBos wants to merge 1 commit into
mainfrom
douwe/snapshot-refs

Conversation

@DouweBos
Copy link
Copy Markdown
Owner

Discussion

capture-ui now assigns each accessible element a short ephemeral ref (@e1, @e2, …) and persists its resolved coordinates per session under ~/.conductor/snapshots/<session>.json. tap-on @e3 resolves through that store and taps the cached point directly — skipping fuzzy text/id matching and a full hierarchy re-query.

Refs are deliberately ephemeral. A snapshot captured >60s ago, or on a different device, emits an advisory warning but the tap still fires; the agent is expected to re-run capture-ui if a tap misses. Explicit --text / --id still win over a bare @eN.

Other small changes folded in:

  • metro-cdp: split resolveDebuggerUrl into a pure selectDebuggerUrl + async target/displayName fetch, so the selection logic is unit-testable.
  • flow-recorder / session: recordingPath is now a real optional field on Session instead of cast-through SessionWithRecording.
  • New test suites: snapshot-ref, metro-cdp, flow-recorder.

`capture-ui` now assigns each element a `@eN` ref and persists its
coordinates per session, so `tap-on @e3` taps the cached point directly.
Stale snapshots warn but still act, since refs are explicitly ephemeral.

Also extracts a pure `selectDebuggerUrl` from `resolveDebuggerUrl` and
types the `recordingPath` field on `Session` directly instead of casting.
@DouweBos DouweBos self-assigned this May 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant