An optimistic update is a promise the server can break

Updating the UI before the server answers makes an app feel fast. It also means the UI claims something the server has not agreed to yet. The failure path, where the request fails and the UI has to take the claim back, is the one nobody clicks through, because on a working backend it never happens.

Reticle can make it happen in the running app. Not installed? RETICLE_INSTALL_SOURCE=npx_skill npx @reticlehq/server@latest init, then the install-and-verify skill.

Read this before you start: failing a request needs a browser Reticle owns

reticle_network_mock works in a leased tab (reticle_run({ tool: "reticle_lease", args: { action: "acquire", url } })) or a driven one, and not through the always-on SDK, which answers { ok: false, reason: "no-cdp-provider" }. Without one, do step 4 (the success path) and report the rollback as unknown. Driving the happy path and reporting that rollback works is the one thing you may not do.

Confirm the session can observe first: reticle_session({ action: "list" }). A hidden or throttled tab can accept a click and render nothing.

1. Make the save fail, slowly

reticle_run({ tool: "reticle_network_mock", sessionId, args: {
  mocks: [{ urlContains: "/api/todos", method: "PATCH", status: 500, delayMs: 1500 }],
}})