Commit Graph

5 Commits

Author SHA1 Message Date
Hubert Gancarczyk 50c9580e30 fix(tools): make a schema failure name the parameter that was sent (#718)
> Stacked on #717.

## The problem

An invalid tool call returned Zod's raw issue array. Someone who wrote
`flow_name` instead of `name` got back, depending on the tool:

```
Invalid params for tool "flow-start-recording": [{"expected":"string","code":"invalid_type","path":["name"]}]
Invalid params for tool "flow-execute":         [{"code":"custom","path":["flow_path"],"message":"Pass exactly one flow source: name or flow_path."}]
```

The first names the parameter the tool **wanted** and never the one the
caller **sent**. The second — flow-execute's, whose `name` is optional
so `flow_path` can stand in — names neither: it is anchored on the one
source field the caller had no reason to send. Either way the mistake is
invisible, and working it out costs a whole turn.

## What changes

**1. `describeParamIssues` — one sentence per bad parameter.**

Missing fields read as `` `name` is required (string) and was not
provided`` rather than as a type error about `undefined`. Unknown keys
are named and path-qualified, so a key nested in `selector` is not
reported as a bare name that contradicts the top-level list printed
beside it. The message closes with the caller's own keys — `You sent:
\`flow_name\`, \`project_root\`.` — which is what makes the mistake
self-evident.

Key names only, never values: this string reaches logs, telemetry and
the agent transcript, and a params object can carry a secret.

Wired into both entry points: the registry's `invokeTool` and the HTTP
boundary.

**2. `flow-execute` accepts `flow_name` as an alias for `name`.**

The tool is called `flow-execute`, so "the flow's name" spells itself
that way; this is a mistake worth absorbing rather than rejecting. The
name is resolved in code rather than by the schema — a Zod `required`
failure would once again name only the field it wanted — and the error
text names the spellings that are silently discarded (`flowName`,
`flow`, `flow_file`), because by then Zod has already stripped them and
the caller has no other way to learn their key was dropped.

**3. A flow DIRECTIVE passed as `command` points at the tool that
records it.**

`command: "echo"` used to come back as a bare "Tool not found". It now
names `flow-add-echo` — and says to call it **directly**, since routing
it through the recorder would write the echo *and* a `tool:
flow-add-echo` step that fails on every replay.

The hint distinguishes directives the recorder **rewrites** from those
it stores **raw** for the polish pass, because promising a rewrite that
does not happen sends the author looking for a directive that is not in
the file. `wait` and `long-press` get their own answers: neither has a
recording tool at all.

Only a genuine not-found is rewritten — a tool that ran and failed still
reports its own error.

**4. A recorder tool as `command` is refused.**

`flow-add-echo`, `flow-add-step`, `flow-start-recording`,
`flow-finish-recording` each mutate the recording itself, and nesting
one reported success either way. Each is refused for its own reason:
`flow-add-echo` would write the echo **and** a replay-breaking `tool:`
step, `flow-start-recording` would **erase** this flow at replay,
`flow-finish-recording` would end the take it is a step in, and
`flow-add-step` cannot record itself. Now nothing is executed and
nothing is written.

---------

Co-authored-by: Hubert Gancarczyk <claude-hubert.gancarczyk@swmansion.com>
2026-08-25 10:48:49 +02:00
Jakub Piasecki 8062da77a5 fix(flow): settle before gestures that resolve no selector (#779)
A selector target settles inside `waitForFrame`, but a target that
resolves nothing skipped the settle altogether: a coordinate
`tap`/`long-press` and a centre-anchored `pinch`/`rotate` dispatched
into whatever motion was in flight, so they could land mid-fling, which
is the exact race the settle exists to close. Every input directive now
settles first, however it is addressed.

The settle is best-effort here, unlike on the selector path: these
gestures read no frame out of the tree, so an outage must not fail them,
which would break the escape hatch coordinates exist to be (an element
the tree cannot see). This is the allowance `snapshot` already makes
before a capture that reads pixels rather than nodes.

Best-effort is not free, though, and the run pays it per gesture. A tree
the run can never read is not only the disconnect mid-run:
`fetchFlowTree` serves no tree at all on `ios-remote`, and an app that
cannot load the instrumentation fails every read off an in-memory list,
an Apple system app being the case in point, which flows drive by
coordinates for exactly that reason, so every step of such a flow is one
of these gestures. Measured against the real fetch on an `ios-remote`
device, a coordinate tap went from 0ms to 3022ms, once per gesture, for
a settle that was never going to arrive.

So a settle that spends its whole window without one successful read
records the outage on the run, against the device that proved it, and a
later gesture rethrows that instead of buying the same verdict again.
Not a shorter budget: any threshold low enough to spare a source that
serves no tree would also abandon the mid-navigation blip the settle's
retry exists for. But the record is a prediction, not a proof of
repetition. One window mints it and nothing re-tests it, and on iOS that
window can be a single stalled read, since the deadline is only tested
after a read returns and `ViewHierarchy.getFullHierarchy` sits on a 15s
RPC tier behind a serial 5s `Application.getState` probe. Being wrong
therefore costs a settle rather than a step, and it is not silent: a
gesture that spends the record warns its step report that it dispatched
unsettled, quoting the source's own reason, so a run whose prediction
was wrong says which of its greens mean the gesture was sent rather than
that it landed.

Every tree read a directive makes now goes through one helper so that a
read which comes back clears the record whichever directive asked for
it. `await`/`assert` and `idle` never settle, and a run that reads the
tree successfully must not keep skipping. A relaunch clears it too,
whether written as a `launch:` directive or as one of the raw `tool:`
steps that perform the same operation, since a relaunch is the repair
the commonest of these errors asks for by name. Two more reads route
through the same helper for uniformity but can never be the clearing
one: `rotate`'s aspect read skips itself while a record stands, and the
`type` focus wait runs only behind a `waitForFrame` whose own settle
already cleared it.

What it costs, in two directions. An outage that lasted a full window,
in a run that then never reads the tree again and never relaunches,
leaves later gestures unsettled even once it clears: a flow of nothing
but coordinate gestures giving up a best-effort settle it never had
before this change, against every one of those gestures otherwise paying
the window for a settle that is not coming. And on a screen that never
holds still, a spinner, a video, a ticking clock, nothing converges, so
every one of these gestures pays the whole window, measured at about
3.05s each. The record buys no relief there by design, because a window
that read the tree proves no outage, and the fingerprint cannot be
narrowed the way `scrollToVisible` narrows its own: a scroll knows the
motion it waits on is its own, inside the containers under its anchor,
while a gesture waits on motion of unknown origin that can move what
sits under the point without touching it. It is the same window every
selector directive already paid on such a screen; what changed is that
coordinate targets pay it too.

Two smaller pieces ride along. A centre-anchored `rotate` skips its
screen-aspect read on a recorded outage as well, degrading to the same
legacy orbit a failed read gives it, so the record actually takes the
window off that directive instead of handing back a 15s-tier RPC. And
the settle's tree read now takes the run's abort signal, so a cancelled
run reports its skip immediately rather than once the source finally
answers. It deliberately takes no time budget: one cut to what is left
of the window would fail the cold start #778 raised that tier to ride
out.
2026-08-17 11:15:47 +02:00
Hubert Gancarczyk 74cddedf50 docs(skills): split argent-create-flow into references and add argent-qa-flows (#730)
> Now rebased directly onto `main`. #728 and #574 have landed, so this
PR carries only its own 13 documentation commits; it still does not sit
on the #715-#726 chain.
>
> Guidance describing behaviour owned by that chain is therefore **not**
carried here: the recorder's refusal of a vacuous `hidden` and of
`await-screen-idle` (#724), its cross-tree re-probe warning (#717), the
per-step `recorded` line (#715), and `type:` failing on unconfirmed
focus (#726). Each of those paragraphs states what this base actually
does instead; they are worth restoring when that chain lands.

## `argent-create-flow`: ~5,000 words to ~900 plus three references

Every word of that skill loaded on every invocation, whether the task
was replaying a two-step fragment or authoring a full regression test.
The core skill now routes to three references read on demand:

- **`live-authoring.md`** - recording a walkthrough
- **`flow-yaml.md`** - the file format and selector vocabulary
- **`reliability-and-recovery.md`** - what to do when a step or a replay
goes wrong

Nothing is dropped in the split - it moves behind a router.

## New skill: `argent-qa-flows`

Turning a **test case, ticket, or acceptance criteria** into a
repeatable regression test is a different job from recording a path
worth replaying, and it was being done by a skill that never asks for
acceptance criteria. It orchestrates `argent-create-flow` as its engine,
records the first walkthrough live, requires every requested screen and
state to be proved with stable evidence, and completes only after the
unchanged flow passes **twice consecutively**.

## Proving a navigation

Spelled out here for the first time, as two element-level checks rather
than a route read:

```yaml
- await: { visible: { id: settings-screen } } # identity: WHICH screen
- await: { idle: true } # readiness: it stopped moving
```

Neither implies the other - a dropped tap leaves the source screen
perfectly idle, and the destination's elements enter the tree while the
transition still animates over them. Both belong after every screen
change, including the one `launch:` performs.

## Routing

The three skills were being confused by name alone, so the rules now
draw the line:

| you want | skill |
| --- | --- |
| a one-off interactive check, nothing saved | `argent-test-ui-flow` |
| a saved, replayable path | `argent-create-flow` |
| a saved test with acceptance criteria and two-pass proof |
`argent-qa-flows` |

"Record a flow" also stops being ambiguous with **screen recording**,
which is video.

## Tests

Every bundled skill's YAML frontmatter is parsed in a test, so a
malformed new skill fails here rather than at install time. The `idle`
doc guards that came with the warn-instead-of-fail change follow the
prose into `references/flow-yaml.md`: they pin the documented defaults,
settle cost and minimum timeout to the constants the parser enforces,
and hold the tool description and the reference to the same account of
what `idle` does. All 43 anchored internal links resolve.

---------

Co-authored-by: Hubert Gancarczyk <claude-hubert.gancarczyk@swmansion.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-10 14:41:23 +02:00
Hubert Gancarczyk 96ea94f87a feat(flow): add an idle condition that waits for the screen to stop moving (#728)
> Stacked on #574. Replaces the route-fingerprint approach that #727 and
#729 carried; both are closed.
>
> Rebased off the #715-#726 chain so it can merge on #574 alone. That
chain owns `DirectiveOutcome.warning` / `StepReport.warning` and the
`indeterminate` scoring rule; the small amount of each that this
condition needs is carried here, scoped to `idle`, and will conflict
textually with #724/#725 for whichever lands second.

## One check a selector cannot express

```yaml
- await: { idle: true }
```

Has the screen stopped moving? Flows were substituting fixed `wait:`
steps for it, which either wait too long on every run or too little on
the run that mattered.

## Why it reads pixels as well as the tree

Each signal is blind to what the other sees.

The tree cannot see presentation-layer motion. An iOS push or modal
dismissal commits its hierarchy up front and then animates a layer for a
few hundred milliseconds; a cross-fade or a scrim moves no node at all.
Measured on a real Android emulator: a page animating a large element
continuously reads as a single static `WebView` node, and the existing
`await-screen-idle` tool called it settled in **465 ms, five times out
of five**. On a deterministic Chromium page whose DOM is byte-identical
across the animation, that tool returned `settled: true` in **407 ms**
while this condition failed 8/8.

Pixels alone would not do either: they cannot see a tree still churning
behind an unchanged surface, and anything animated forever (a video, a
shimmer) would make a pixel-only settle unsatisfiable on a screen the
tree calls ready.

Unlike that tool, this cannot be silently stepped over. Readiness is not
an acceptance criterion — the verdict belongs to the identity and
outcome checks around it — so a screen that never settles still
**passes**, carrying a `warning` that says what the green actually
bought. That is what makes it safe to persist in a flow: it reports on
every run without ever failing one over a video or a shimmer. The only
thing that stops a run is a tree source that cannot be read.

## The rule the design follows

The absence of evidence is never evidence.

- A capture that did not arrive cannot complete the hold.
- Neither can a single agreeing pair. Every animation that reverses has
a turning point, and two samples straddling it come back identical while
the screen is moving. On a live 3 s cross-fade that passed a
default-shaped step on roughly **one run in three**; settling now takes
two consecutive still intervals, so `minStableMs: 0` still means three
reads.
- A round is never started without the budget to observe it with. A
round begun with nothing left neither captures nor reads, and both
absences were otherwise recorded as facts about the device.
- No verdict comes from a latch. A screen that settles and then moves
again, or goes blank, has not settled.

## `timeout:` is a real bound

No describe path takes an abort signal, so the tree read is raced
against what is left of the budget. Without that, a wedged ViewInspector
RPC ran 2.25 s past an 8000 ms budget, and a busy Android screen ran
5.4-6.0 s against a 3000 ms one. A read that runs out of step budget is
the step ending, not the source failing, and only the latter is reported
as an environment problem.

## Failure modes stay apart

They call for opposite responses. A screen that never stopped moving is
a verdict about the app. A tree that could not be read is not, and it
names the foreground check first, because a backgrounded app reads
identically to an uninstrumented one and relaunching is the wrong
repair. A run whose captures never produced a comparable pair still
settles on the tree and says so in a warning, rather than passing off
half a proof as the whole one.

## Capture routing and tolerance

Captures route exactly as the `screenshot` tool routes them, so tvOS and
Vega, which have no simulator-server backend but are perfectly
screenshottable through `xcrun` and the emulator console, are covered
rather than written off.

The pixel comparison owns its tolerance rather than borrowing
`screenshot-diff`'s. That one holds a baseline stored across sessions,
machines and OS versions against a live capture and must absorb real
drift; this one holds two captures one poll apart from a single session,
where a static screen reads back byte-identical (measured: zero changed
pixels across five consecutive pairs on an idle simulator). The margin
is load-bearing, because uniform change is all-or-nothing: at the
baseline tolerance any cross-fade slower than ~2 s counted zero changed
pixels and read as settled mid-animation.

## Not a screen check

A dropped tap leaves the source screen perfectly idle. It belongs after
the element check that names the destination, never instead of one. #730
documents the pairing.

## Verification

- 3307 tests pass; typecheck, `typecheck:tests`, lint and prettier
clean. Eleven mutations applied to the source, all eleven caught by
tests.
- Driven end to end against a real iOS simulator, a real Android
emulator, and a Chromium app through a tool-server built from this
branch: static screens pass with no warning (proving captures ran),
animating screens pass carrying the warning that names the motion, and
the pre-existing tool disagrees exactly where it should.

---------

Co-authored-by: Hubert Gancarczyk <claude-hubert.gancarczyk@swmansion.com>
2026-08-10 11:50:16 +02:00
Hubert Gancarczyk 5ac69349f0 feat(flow): CSS combinator scopes for flow selectors (#569)
## What

Adds the CSS combinators to flow selectors, read off frames. Any action
or condition can now scope its matches by where an element sits relative
to another:

```yaml
- tap:    { text: Delete, within: { id: profile-card } }          # CSS "A B" — inside that container
- tap:    { role: Switch, next: { text: Wi-Fi } }                 # CSS "A + B" — the nearest follower
- assert: { visible: { role: Button, after: { text: Danger zone } } }  # CSS "A ~ B" — any follower
- assert: { hidden: { any: true, within: { id: empty-state } } }  # CSS "*" — the universal selector
```

| Scope | CSS | Reads as |
| --- | --- | --- |
| `within: <sel>` | `A B` | the match's frame sits inside the scope
element's frame |
| `after: <sel>` | `A ~ B` | the match follows the scope element in
reading order |
| `next: <sel>` | `A + B` | as `after`, narrowed to the nearest follower
of each anchor |

Plus `any: true` — the CSS `*` universal selector, accepted only
alongside a scope and never beside `text`/`id`/`role`.

The child combinator `>` has deliberately **no analog**: flow trees
flatten to leaves under one synthetic root, so parent/child structure
does not survive to replay.

## How

- **Geometric, not ancestry-based.** Frames are what survives
flattening, so every scope is resolved from them by `findAll` in
`ui-tree-match`. The synthetic root never counts as a scope element, and
every relation requires a *distinct* node (nothing scopes itself).
- **Reading order is row-band aware.** An element follows the anchor
when it starts below the anchor's bottom edge, *or* shares its row band
and sits entirely to its right. That band rule is what makes `{ role:
Switch, next: { text: Wi-Fi } }` resolve the Wi-Fi row's own switch even
though the taller switch's frame starts a couple of pixels *higher* than
the label's — a raw top-y comparison gets that backwards. `followKind`
is the single classification both the follower test and the nearest-pick
grouping read, so they cannot disagree.
- **`next` is the union over anchors**, exactly as CSS `A + B` is: three
rows on screen give three switches, one per label.
- **Scopes compose and nest**, capped at `MAX_SELECTOR_SCOPES` (6)
counted across the whole relation *tree* — a size bound, not a depth
bound, because three relations branch and the runner's loose-alternative
expansion is exponential in the bare-string scopes it finds.
- **Flow-YAML only.** `await-ui-element`'s strict schema rejects
`within`/`after`/`next`/`any`, so a scope can never be silently dropped
on that path.
- Adding a fourth relation is a **compile error**: `RELATION_RESOLVERS`
is a `Record` keyed by the relation union, so a new scope cannot be
wired through parse/serialize/reporting and then ignored by the match
engine.

## Testing

- **Unit:** full tool-server suite green — **3006 passed / 1 skipped**.
New coverage in `ui-tree-match.test.ts`, `flow-utils.test.ts`,
`flow-selector-scopes.test.ts` (renamed from
`flow-within-selector.test.ts`, now covering all scopes) and a new
`flow-skill-docs.test.ts` that parses every YAML snippet in the skill so
the docs cannot rot. Each fix is mutation-checked: reverting it fails at
least one test.
- **Real-device E2E** (Pixel 3a, Bluesky on Metro 8081, via a branch
tool-server): three flows, 20 steps, all green — geometric ordering both
ways, two `text` asserts that pin `next`'s pick *by identity* out of
five candidates, empty-scope `hidden` semantics, and two observable taps
(`next`-scoped and `any: true`-scoped) that navigated to the *adjacent*
topic rather than the anchor's own.
- **iOS not covered.** Native-devtools does not attach on either booted
simulator in this environment, so *every* flow selector fails there — an
unscoped `{ text: "Video" }` fails identically. Verified environmental,
not caused by this branch: the globally-installed argent reports the
same, direct `SIMCTL_CHILD_DYLD_INSERT_LIBRARIES` injection also fails
to connect, and it survives a forced simulator reboot on both iOS 18.3
and 26.5. Worth re-running the iOS leg once that is healthy.

## Notes for reviewers

Two deliberate deviations from CSS, both documented in the skill:

- **`next` is looser than `+`.** Where `A + B` matches nothing unless
the immediate sibling is a `B`, `next` keeps looking and returns the
nearest match further on. That is what makes it survive the wrapper and
spacer nodes a flattened tree is full of — but a row *missing* the
control you asked for resolves to the next row's rather than failing.
Happy to switch to strict `+` semantics if the loud failure is
preferred.
- **"follows" is not transitive.** Against a tall anchor an element can
follow something that follows the anchor without following it directly,
so nesting `after` scopes is not the same as chaining `~`.

Other things worth a look:

- `nearestAfter` and `afterTester` are direct scans, not indexed. An
earlier sorted index was a *second* implementation of the nearest rule
and the two disagreed on frames near the tolerance; it also measured
2-13x slower than the scan on realistic shapes, with a prune that
provably never fired. The quadratic tail is documented with measured
numbers: 1.2 ms for a single-anchor `next` at the 12k-node tree cap,
~555 ms only when the anchor selector matches essentially every node.
- A bare-string *anchor* cannot self-correct the way the loose fallback
usually does — a decoy `testID` matching your anchor text wins the
identifier pass whenever anything sits after it. The skill tells authors
to spell sibling anchors as maps.
- `MAX_SELECTOR_SCOPES = 6` replaces the previous
`MAX_SELECTOR_WITHIN_DEPTH = 10`, so a `within` chain deeper than 6 that
parsed on the earlier commits of this branch now rejects. Nothing
released depends on it.

---------

Co-authored-by: Hubert Gancarczyk <claude-hubert.gancarczyk@swmansion.com>
2026-07-27 18:25:27 +02:00