Never guess credentials — ask the user, or read them from knowledge

[DavertMik]

What happened

A page that redirected to a login form was treated as a form to fill. The model invented an email and a password, submitted them, and spent the rest of its attempts on a login that was never going to succeed:

AI Navigator resolving state at /users/sign_in?info=You+must+be+logged+in...
  > I.fillField({"role":"textbox","text":"name@email.com"}, "Enrique.Schinner@gmail.com")
  > I.fillField({"role":"textbox","text":"********"}, "RV6kXHNcheHiUIz")
  > I.click({"role":"button","text":"Sign In"})
URL verification failed: expected /projects/Testomat/defects, got /users/sign_in

The system prompt already said to ask the user for credentials — but resolveState exposed only stop. The instruction had no mechanism behind it, so guessing was the only move on the table.

Changes

Credentials have two sources, and neither is invention. The <credentials> block in the Navigator prompt rules out made-up values for anything that identifies an account. A scenario that explicitly creates something, such as registering a new user, still makes up the values it needs.

The Navigator can ask. askUser is now among the tools in resolveState, so credentials are requested at the moment they are needed and the run carries on with the answer. Where nobody can answer, it stops and names what is missing — the failure path already points at explorbot learn "<path>" for recording them once.

The loop survives an ask-only turn. A turn that called a tool and returned no code used to end the loop, so the user's answer arrived after the Navigator had given up and was discarded (src/ai/navigator.ts, one line).

An answer can become knowledge. askUser takes persistent: a lasting fact about the page is appended to that page's knowledge file, and later runs read it instead of asking again. It is filed under the page path with the query string dropped — normalizeUrl only trims, and matchesUrl keeps a query in the compared path whenever the pattern has one, so filing under /users/sign_in?info=You+must+be+logged+in... would have written a file no later visit could match.

The tool is offered only where somebody can answer it. The Pilot's inline copy became the shared createAskUserTool, and both call sites gate on isInteractive() rather than handing the model a tool whose only possible reply was "user input not available".

Tests

Two paths that could silently not work are covered: the ask → fill round trip in navigator-resolve-state.test.ts (verified to fail without the loop fix — the first version of it passed for the wrong reason, via the end-of-loop fallback), and persistence in tools.test.ts, where the fake state carries a query string so the path stripping stays locked in.

Unit 1026 pass / 3 fail, integration 80 pass / 0 fail. The 3 failures are pre-existing and untracked on main — navigator-user-redirect.test.ts and execution-controller-resume.test.ts test a <user_redirect> feature that does not exist in navigator.ts; confirmed by stashing this branch's changes.

Known, not fixed

• Answering the same persistent question in a later run appends a second block under a --- separator. addKnowledge has always appended rather than deduped.
• askUser answers are not passed to registerSecret, so a password typed at the prompt is written verbatim into the experience file when the successful login flow is recorded.
• LearnCommand passes state.url to addKnowledge unstripped and has the same query-string issue; left alone as out of scope.

🤖 Generated with Claude Code

[DenysKuchma]

This could silently save login credentials to knowledge/*.md. The model decides whether persistent is true, while the user isn’t told that their answer will be written to a file. I’d either ask for explicit permission before saving it or avoid automatically persisting credential-related answers

[DavertMik]

Agreed, we already have --session so we can avoid persistent storage

[DenysKuchma]

Credentials are still persisted, just in experience now. Prompt answers aren't registered as secrets, so redactSecrets() won't hide passwords. Credential answers should stay session-only or be redacted before writeFlow()