recall

Ask what Choto already remembers about an interface, as text — call this BEFORE observing or planning. A screenshot costs ~1400 tokens; this map costs a few hundred, so a window that has been visited before does not have to be looked at again to be planned against. The map is BY WINDOW and holds windows only: everything listed is inside one window, which is also where a plain target searches. Chrome — the menu bar, status items, open menus — is never remembered, so its absence here says nothing about the app; reach it with target.scope='chrome' in execute_plan, or see it as its own block in observe. All arguments are optional, and they widen the focus in three steps: with no arguments you get every application known, how many windows each has and when it was last seen; with app_name you get that app's windows plus the contents and outgoing transitions of the one it was last seen in; with app_name and window you get that one window — its text elements and its transitions, each reading 'click X -> window Y'. window is a piece of a window title (case-insensitive) or a node id such as '#5'; app_name matches exactly first, then as a substring ('settings' finds 'System Settings'). depth (default 1, max 3) unfolds that many levels of transitions; a branch leading back to a window already printed is marked '[shown above]' instead of being repeated, so cycles cost nothing. query= asks the other question — WHERE is this? — instead of walking the map yourself. It searches every element label, every named icon and every window title at once, with the same matcher a step's target uses, so a hit means a step aiming at that text would resolve to it. Each hit names the app, the window, what matched, how fresh it is, and the ROUTE to it. Add app_name to narrow the search. Routes read 'in #1 "Main" click "General" -> #2': that is the plan, in order, in the terms execute_plan takes. They start where the app was last seen — the window most recently read, which is where it still is unless something moved it since — unless you name from_window (a title or '#id'). When there is no route the reply names what is missing rather than saying no: which window cannot be reached, which recorded window leads into it (and whether that one was ever entered either), and what the starting window knows — how many windows it reaches, or that nothing has ever been clicked in it. That names the next thing to go and look at instead of leaving you to guess it. COVERAGE — read this before trusting an absence. Every reply carries what the map does NOT know: windows never clicked in, windows seen once, windows with no recorded way in, and 'N of M known control(s) ever clicked'. The denominator is what has been SEEN, never what the app has, so 'not found' means 'never seen here' and never 'does not exist' — the reply says so explicitly when a search comes back empty. A window that has never been clicked in is a photograph, not a map: what its buttons open is unknown, and the way to change that is to go and look. Reading the dates: the reply opens with the server's current time, and every window and transition carries when it was last seen, absolutely (UTC, '07-25 17:29Z', the year omitted while it is the current one) and relatively ('3h ago'). Nothing is hidden for being old, because only you can weigh it: minutes or hours old is normally safe to plan against; days old, or a window marked STALE, means the app may have been updated or rearranged since — either verify with one cheap step (a short plan that just navigates there, whose reply lists the windows it saw) or observe before acting. Element text is what you target in execute_plan; coordinates are deliberately absent, since the executor resolves text to pixels itself. The reply is size-capped and names what it cut ('elements (24 of 40)').