Stop letting your AI guess selectors.

Andrzej S. — Mon, 20 Jul 2026 20:02:37 +0000

Your AI writes E2E tests that look right and fail. I built a map so it stops guessing.

AI agents are surprisingly bad at writing end-to-end tests for real apps. Not demo apps - real ones. The kind with zero data-testid attributes, three i18n locales, forms that load their defaults asynchronously, and selectors that only make sense if you wrote the frontend yourself.

I watched agents do this at work: guess a selector, fail, guess again, loop, then finally produce a test that looks completely reasonable and fails on the first run. My favorite failure mode: the agent wrote getByRole('tab', ...) for tabs that are - of course - plain buttons with click handlers. The test was well-written. It was also fiction.

The root cause is simple: the agent has never seen your app. Runtime AI-navigation tools (browser-use, Stagehand, Playwright MCP) explore it live, but they have no persistent memory - every task starts from zero, and exploration burns tokens on every run.

So I built terra-incognita, an open-source "app knowledge compiler". The idea:

A human records navigation sessions in a real browser - you just click through your app once.
A deterministic distiller (no LLM, no API key) compiles those sessions into compact artifacts: an app map, an element dictionary with ranked selectors, a testability report, and a generated skill file.
The agent consumes the map when writing tests: prefer mapped selectors, never invent locators.

It is not a test recorder like codegen, not a runtime agent, not session replay. It compiles human ground truth into knowledge that any agent can read.

Does it help? Depends how big a mess your app is.

I benchmarked it with an A/B harness: same agent, same tasks, same turn budget - with and without the map. Beyond "does the test pass", I scored acceptance (how many acceptance criteria the test actually asserts) and strict (passes AND covers everything), because pass rates alone let narrow, under-asserting tests through.

On a realistically messy production SPA (zero test-ids, three locales, async forms):

A small model went from 0/8 to 7/8 strict with the map. Without it, its tests looked right and guessed wrong.
A mid-size model went from 29% to 54% strict; acceptance-criteria coverage rose from 43% to 78%.
The result I find most interesting: the small model with the map beat a ~7x more expensive model without it on every quality metric. A map instead of a bigger model.

And the honest flip side: on an app that is already well-testable - stable roles, test-ids everywhere - the map produced zero lift. There is nothing to fix. If that is your app, you do not need this tool. Maps are for wild territory.

(These are small pilots - 1-3 runs per task, tasks written by me. Directional evidence, not a published benchmark. A methodology write-up is coming.)

The part I did not expect: honesty needs a linter

The generated skill tells the agent: if a flow is not on the map, say so instead of inventing selectors. Some models follow that rule 100% of the time. Others ignore it routinely and fabricate plausible-looking locators anyway.

Prompt rules are advisory. So the tool ships a mechanical gate: terra lint checks every locator in your test files against the recorded element dictionary and fails the build on anything that is not traceable to a real, observed element. The model's discipline stops mattering; the gate does not care whether it felt like following instructions today.

Try it

The whole pipeline is deterministic and runs offline - record, distill, generate, lint. MIT licensed:

github.com/andrzej-stepien/terra-incognita

terra record http://localhost:3000 --name checkout-flow
terra distill
terra generate-skill --target claude-code
terra lint tests/**/*.spec.ts

If your app is a well-lit city grid, keep walking. If it is terra incognita - give your agent a map and tell me what breaks.

How to reset 20 Zustand stores correctly on logout

Andrzej S. — Mon, 20 Jul 2026 11:27:42 +0000

A user logs out, another logs in on the same device - and suddenly sees the previous user's cart or permissions. Whether you have 3 stores or 20, resetting state on logout is a critical task that often falls through the cracks.

Why the "Typical" Reset Fails

The most common approach is usually: reset: () => set(initialState). However, this fails in four specific ways:

Frozen dynamic values: If you have sessionId: crypto.randomUUID(), it was generated once at module load. Every "reset" restores that same ID. A real reset needs to re-run the initializer.
Merge instead of replace: Zustand's set merges by default. Leftover keys from previous states survive. You need set(fresh, true) to perform a full replacement.
Forgotten stores: A manual logout() function calling 20 different reset actions will eventually break the day someone adds store #21. You need a centralized registry.
Persist race conditions: Resetting memory while localStorage is still being read (rehydration) can cause the old data to overwrite your fresh state. If storage fails, Zustand might swallow the error, hanging your logout logic forever.

The Solution: zustand-reset-manager

I hit all of these walls in my own projects, so I built a small utility to handle it: zustand-reset-manager. It’s MIT-licensed, has zero runtime dependencies, and supports Zustand v4/v5.

1. Define a Resettable Store

The initializer keeps its exact Zustand signature, including middleware.

import { createResettableStore } from 'zustand-reset-manager';

export const useCart = createResettableStore<CartState>("cart")((set) => ({
  items: [],
  sessionId: crypto.randomUUID(), // This will be re-generated on every reset!
  add: (item) => set((s) => ({ items: [...s.items, item] })),
}));

Update (v0.4.0): the hooks promised in the comments are out, plus ordering - because with 20 stores the next question is always "but my session store must reset last".

One place to react to every reset - logging, analytics, cleanup:

const unsubscribe = addResetListener({
  beforeReset: ({ name, group, reason }) => console.log(`resetting ${name} (${reason})`),
  afterReset: ({ name }) => {},
});

Declare order instead of hand-sequencing 20 calls:

export const useSession = createResettableStore(
  { name: "session", dependsOn: ["cart", "user"] },
  (set) => ({ /* ... */ }),
);

await resetAllStores({ reason: "logout" });

dependsOn declares "reset me AFTER these" - bulk resets are topologically sorted (Kahn's algorithm), so cart and user reset before session, level by level; async resets are awaited per level, and independent stores within a level run in parallel. A cycle gets you a dev-mode warning and a safe fallback instead of a crash. reason is a free-form string that rides along to every hook, so "logout" vs "tenant-switch" vs "test" is one if away.

DEV Community: Andrzej S.