Repository navigation
feat(selectors): export listSelectorChainMatches from agent-device/selectors - #3192
Conversation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 6 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
|
Size Report
Startup median (7 runs, lower is better):
|
…ectors A consumer that needs every node a selector chain matches — to apply its own strictness — gets the same matched-node domain the resolver decided over instead of reimplementing term matching. The function already existed internally; it now leaves through the published AST surface with a public-facing contract doc that names the one way it differs from resolveSelectorChain: that function's default requireUnique refusal can walk past the alternative this one reports. The public-entry test pins the contract through the published module: several matches from one alternative in snapshot-array order (with index order made to disagree), first-alternative selection where find agrees and a uniqueness-refusing resolve does not, requireRect removing candidates before alternative selection, empty chain, and the term semantics the consumer copy drifted on (hittable, text, role, editable, and both visibility arms).
The client-api.md subpath manifest and the packed-package selectors smoke check are the two records that a published subpath symbol exists; both name the new list entry so the exports surface cannot drift from the build. The doc also states the two facts a strictness-applying consumer must not guess: the list is null when nothing matches, and resolveSelectorChain can name a later alternative than the one listed.
f19ce5a to
733536d
Compare
|
This PR is ready at 733536d. The new |
thymikee
added
the
ready-for-human
1 participant
Summary
Closes #3180.
agent-device/selectorspublisheslistSelectorChainMatches, so a runner that must apply its own strictness gets the same matched-node domain the resolver decided over instead of reimplementing term matching (the tester-army/e2e copy has already drifted onhittable,visible,editable,text,role). The function existed internally; it now leaves through the published AST surface with a contract doc, and the doc plus the packed-package smoke check record the new symbol.One asymmetry is documented rather than smoothed over: the list reports the FIRST matching alternative — what
findSelectorChainMatchnames — whileresolveSelectorChainunder its defaultrequireUnique: truecan refuse that alternative and resolve from a later one.6 files, +321/-12.
Validation
pnpm check:affected --runonf19ce5a81: all runnable checks passed, 633 files / 4727 tests. The public-entry test (src/sdk/selectors.test.ts, 8 tests) imports onlysrc/sdk/selectors.ts; deleting theast.tsexport name makes all 8 fail, and each new pin was mutated in isolation to confirm it goes red alone (isNodeVisible's rect arm, post-filterrequireRect, sorting byindex).Risk: none beyond widening a published subpath by one name. No device evidence needed — no runtime dispatch changed.