This audit compares the documented behavior in the official SikuliX API docs with the current Go port implementation in packages/api/pkg/sikuli and packages/api/internal/grpcv1.
Scope:
packages/api/pkg/sikuli/*.go, packages/api/proto/sikuli/v1/sikuli.proto, packages/api/internal/grpcv1/server.go.The largest parity gap is architectural: SikuliX documents Screen, Region, and Match as live, action-capable desktop objects. The current Go port exposes image-scoped search primitives in pkg/sikuli and moves live desktop work into a separate gRPC server plus controller types.
That means the Go port currently differs from the SikuliX docs in four material ways:
Region API is image-driven, not live-screen-driven.Screen type is only a descriptor, not a live monitor/search/input surface.Match is a value object, not a Region-like object with direct action methods.| Area | SikuliX Docs Describe | Current Go Port | Impact |
|---|---|---|---|
Region runtime model |
Region is a live search and action surface on the desktop |
Region methods require a source *Image; live-screen behavior exists only behind gRPC screen RPCs |
High |
Screen surface |
Screen extends region behavior, represents monitors, supports capture and monitor selection |
Screen is only {ID, Bounds} in pkg/sikuli; no public capture/search/action methods |
High |
Match semantics |
Match behaves like a Region and can be clicked/hovered/used directly |
Match is a plain struct (Rect, Score, Target, Index) |
High |
| Action methods | Direct click, doubleClick, rightClick, hover, dragDrop, type, paste, wheel/mouse/key state operations |
Input is split into InputController plus gRPC RPCs; many direct convenience methods are absent |
High |
| Iteration model | Finder.findAll() uses hasNext()/next() and destroy() lifecycle |
Go returns []Match; no iterator state or destroy() |
Medium |
| Exception/null semantics | find() throws FindFailed; exists() returns null; setThrowException changes behavior |
Go uses (Match, bool, error) and sentinel errors; ThrowException / FindFailedThrows exist but are not wired into search behavior |
High |
| Multi-target helpers | findAnyList, findBestList, getAll, related helper families are documented |
No equivalent helpers in pkg/sikuli or gRPC surface |
Medium |
| OCR helper surface | Docs describe text(), findText(), collectLines(), collectWords() and related text workflows |
Go exposes ReadText and FindText only |
Medium |
| App/window model | Docs describe richer App / Window workflows (window(), focusedWindow(), allWindows()) |
Go exposes Open, Focus, Close, IsRunning, ListWindows only |
Medium |
Region is not a live desktop object in the public Go APISikuliX documentation presents Region as the primary live desktop abstraction: search, wait, click, hover, type, paste, drag/drop, OCR, and observe all hang directly off the region or screen.
Current Go behavior:
Region.Find, Region.Exists, Region.Wait, Region.FindAll, Region.ReadText, and Region.FindText all require a source *Image.Region has no direct desktop input methods.FindOnScreen, ExistsOnScreen, WaitOnScreen, and ClickOnScreen in packages/api/internal/grpcv1/server.go.Why this matters:
Region to be the live desktop handle.Region is closer to an image ROI helper, while live desktop interaction is a server concern.Relevant implementation:
packages/api/pkg/sikuli/types.gopackages/api/internal/grpcv1/server.gopackages/api/proto/sikuli/v1/sikuli.protoScreen is only a descriptor, not a live action surfaceSikuliX documentation describes Screen as a specialized region representing monitors, with monitor enumeration, monitor IDs, primary screen semantics, and capture helpers.
Current Go behavior:
pkg/sikuli defines:
type Screen struct { ID int; Bounds Rect }func NewScreen(id int, bounds Rect) ScreenScreen methods for capture, find, click, monitor enumeration, or selection.capture(...) and platform capture helpers.Why this matters:
Screen API.Relevant implementation:
packages/api/pkg/sikuli/types.gopackages/api/internal/grpcv1/server.goMatch is not Region-likeSikuliX documentation treats Match as a region-like result object that can be acted on directly.
Current Go behavior:
Match is a plain value type with geometry and score only.Why this matters:
InputController or the corresponding RPC.Relevant implementation:
packages/api/pkg/sikuli/match.goThe Region docs describe direct action methods such as:
clickdoubleClickrightClickhoverdragDroptypepastewheelmouseDown / mouseUpkeyDown / keyUpCurrent Go behavior:
MoveMouseClickTypeTextHotkeydoubleClick, rightClick as a convenience verb, hover as a verb, dragDrop, paste, wheel scrolling, or stateful key/mouse down/up operations.ClickOnScreen exists server-side, but only for image-find then click.Why this matters:
Relevant implementation:
packages/api/pkg/sikuli/input.gopackages/api/internal/grpcv1/server.gopackages/api/proto/sikuli/v1/sikuli.protoSikuliX Finder docs describe iterator-style behavior with findAll(), hasNext(), next(), and destroy().
Current Go behavior:
FindAll returns a full []Match.FindAllByRow and FindAllByColumn return reordered slices.LastMatches() exposes the last slice copy.destroy() lifecycle method.Why this matters:
Relevant implementation:
packages/api/pkg/sikuli/finder.goSikuliX docs describe:
find() throws FindFailed on miss.exists() returns null on miss.wait() throws on timeout.waitVanish() returns a boolean.setThrowException(false) changes miss behavior.Current Go behavior:
Find() returns ErrFindFailed.Exists() returns (Match{}, false, nil) on miss.Wait() returns ErrTimeout.WaitVanish() returns (bool, error).Region.ThrowException and global FindFailedThrows settings exist but are not consulted by the search methods.Why this matters:
ThrowException-style fields suggests parity, but the implementation does not currently honor them.Relevant implementation:
packages/api/pkg/sikuli/errors.gopackages/api/pkg/sikuli/types.gopackages/api/pkg/sikuli/settings.goThe Region docs describe helper families such as findAnyList, findBestList, and getAll-style multi-target workflows.
Current Go behavior:
Find, FindAll, Exists, Wait, and ordering helpers.pkg/sikuli or the gRPC surface.Why this matters:
Relevant implementation:
packages/api/pkg/sikuli/finder.gopackages/api/pkg/sikuli/types.gopackages/api/proto/sikuli/v1/sikuli.protoThe Text and OCR docs describe a broader helper vocabulary, including plain text extraction, search, and collection helpers such as collectLines() and collectWords().
Current Go behavior:
ReadText(params)FindText(query, params)Why this matters:
Relevant implementation:
packages/api/pkg/sikuli/ocr.gopackages/api/pkg/sikuli/finder.gopackages/api/internal/grpcv1/server.goThe App docs describe a richer app/window model around app instances, focused windows, and window-specific selection.
Current Go behavior:
OpenFocusCloseIsRunningListWindowsWindow only contains Title, Bounds, and Focused.focusedWindow() equivalent, and no documented per-window control layer.Why this matters:
Relevant implementation:
packages/api/pkg/sikuli/app.gopackages/api/proto/sikuli/v1/sikuli.protoThese are not gaps in the strict sense, but they are still behavior differences relative to the SikuliX docs:
template, orb, akaze, brisk, kaze, sift, hybrid), which is more explicit than the SikuliX docs.WithMask, WithMaskMatrix).Those differences are already covered at a higher level in behavioral-differences.md; this audit is focused on the public API behavior mismatches.
pkg/sikuli is intended to be a true SikuliX-shaped API or only a compatibility-oriented core for server/client wrappers.Screen and Region live-action methodsMatch as an action-capable region-like valueThrowException / FindFailedThrows into actual search behaviorjava-to-go-mapping.md and this audit aligned. The generated mapping currently overstates parity in a few places where the core Go surface still differs materially from the docs.