mirror of
https://github.com/software-mansion/argent.git
synced 2026-09-14 19:27:14 +08:00
Ignacy Łątka
2db75eb575
The recorder derives a tap's selector from the tapped node identifier first, then text, then role. That order is right on average and wrong whenever the identifier is positional (`row-3`) and the visible text is the durable part: the step replays green until the list reorders. Which of the two fields is stable is a judgement the caller holds and the tree does not carry, so today the only way to record it is to record the tap, read the warning-free `recorded` line, notice the derived selector is the brittle one, and hand-edit the YAML after finishing. flow-add-step now accepts `selector` alongside `args`. The coordinates still dispatch the tap; the selector only decides what the step matches on at replay. It is checked, not trusted - it goes through the same two guards a derived one does, resolving against the tree the RUNNER reads (not the agent-facing describe tree the caller read it off), so a selector matching nothing, or one landing on an element that does not cover the tapped point, is refused and the step keeps coordinates with a warning naming which of the two happened. Passed anywhere it cannot be applied - another command, or a `gesture-tap` carrying `delayMs`, which suppresses selector capture - it records nothing and says why rather than being silently dropped, which would leave a step matching on something nobody asked for. The three CLI test files that hand-copy this schema are updated with it, as flow-tools.test.ts's drift guard requires; `selector` is the schema's first object field, so run-help also pins that it renders as `--selector-json <json>`.