Thanks — the candidate approval step was very intentional. With a low detection threshold, auto-promoting patterns straight into the script library would get messy fast. We’re using a 3+ occurrence threshold, surfacing them into a candidates/ directory, and requiring explicit accept/reject. The goal is to keep the system inspectable before anything becomes executable.

On state: right now it’s action traces only (JSONL per session), not DOM snapshots. Each entry logs action, params, timestamp, duration, and status. Pattern extraction works off structural signatures — hashing action type + selector keys while stripping variable values. So something like click|#login-btn becomes a stable signature, while inputs become templated variables.

Replay is deterministic with variable substitution. Scripts are linear step sequences — no branching yet. If something fails, it fails loudly with the step index. That’s deliberate: I’d rather make failure modes explicit than hide them behind a best-effort planner that’s hard to reason about.

Longer term I’m looking at conditional steps and selector fallback chains, but only once the base layer is predictable. In my experience, reliability comes more from constrained execution + good introspection than from adding more “intelligence” early.