reticlehq/reticle

Problem reticle_session { action: "list" } returns nextAction.command as reticle open <url> (and reticle init in other branches). On an install where Reticle runs only through npx (the default MCP registration), there is no reticle on PATH, so the exact command fails with "command not found". The agent then has to guess the alternative. The CLI's own messages already say npx @reticlehq/server …. Repro Register Reticle only as an MCP server (no global install), connect an app, close its tab, call reticle_session { action: "list" }, and run nextAction.command in a shell. Where server/src/portal/session/no-session-next-action.ts (INIT_COMMAND, OPEN_COMMAND), plus the bare reticle open in session-info.ts and live-call-text.ts. Expected A command field is runnable as given. Use the same npx @reticlehq/server <cmd> spelling the CLI messages use, or detect the bin and choose. Related: #1421, where the same next action points at a URL that is no longer listening. Done when every command re

Problem After the 3.6.0 fix to stale-response-applied, reads with different key sets, different ids or a single-task fan-out no longer pair. Two reads of one PostgREST/Supabase table that have the SAME keys but ask for different columns (select=id,status and select=notes) still pair when they overlap and settle out of order. Both answers are wanted and neither overwrites the other's view, but the verdict comes back as a race. Repro In one action, fire two GETs to /rest/v1/items?select=a&parent=eq.1 and, 10 ms later, /rest/v1/items?select=b&parent=eq.1, with the first settling last. Make the page update after each. The act_and_wait result reports stale-response-applied. Where engine/src/disagreement/stale-response.ts, couldSupersede and the param sets beside it. Expected Projection params (select, fields, columns, include, expand) make two reads different shapes, the same way a differing key set already does. A real filter race (same select, different status=eq.x) still fires. Done when

Problem The minimize button inside the Reticle HUD chat panel closes the panel by setting aria-hidden="true" on it while that button still has focus. Chrome logs "Blocked aria-hidden on an element because its descendant retained focus", keyboard and screen-reader users are left focused inside a hidden region, and the app's console gains an accessibility warning the app didn't cause. Repro Open the HUD chat, click its minimize (caret) button, and check the console in Chrome. Where adapters/realm/browser/src/presenter/presenter-shell.ts:508 closeChat() sets aria-hidden="true" on the chat panel without moving focus out of it first. Expected If focus is inside the panel when it closes, move focus to the chat toggle before hiding it. Adding inert to the closed panel as well would stop focus re-entering it. Done when After closeChat() with focus in the panel, the active element (in the HUD's shadow root) is the chat toggle No aria-hidden focus warning when the panel is closed from inside

Problem reticle_act_and_wait { ref: "find:aria-label=Open menu" } fails with "that ref is stale: refs are invalidated whenever the DOM re-renders". That string was never a ref, so the explanation is wrong and the agent retries the same mistake. On dashboards that refetch, even genuine refs keep going stale, and the recovery says to re-query, while target: { role, name } or { text }, which resolves at action time, would have worked first try. Where adapters/realm/browser/src/dom/addressing/refs.ts:234: resolve returns null both for an unknown string and for a detached element, and both become the stale-ref refusal. core/src/verdict/predicate-tree.ts:152: core already has the minted shape, SESSION_REF = /^e\d+$/, but act refs aren't checked against it. server/src/surface/tools/error-recovery.ts:109 (STALE_REF): the recovery text. Refusing to silently re-resolve a stale ref is deliberate and stays. Expected A ref that doesn't match the minted shape is refused at the tool boundary: "fin

Problem With source mapping working (every control in nearMiss carries source), a failing reticle_assert { action: "now" } still lists an instrumentationGaps entry of kind no-source-mapping and advises installing the build plugin. The real problem was the locator. Agents go and reinstall a plugin that is already working. Repro On a Next or Vite app with source mapping on, without acting first: reticle_assert { action: "now", predicate: { kind: "element", query: { role: "button", name: "Wrong name" } } }. The response has nearMiss[].source and also no-source-mapping. Where server/src/surface/tools/assert/assert-verdict.ts:260 passes session.lastAct.source() to gapsForAction. With no prior act (or a prior act on an unstamped control) that is undefined, and the gap rule fires on any failure with no source. The same function computes the verdict's own source with assertSource({ predicate, evidence, pass, lastActSource }) a few lines later (:275). Expected Compute assertSource first and pas