🤖 fix: allow ask_user_question back navigation

[ThomasK33]

Fix ask_user_question back-navigation for single-select answers.

• Removed effect-based auto-advance that re-triggered when navigating back to an answered question.
• Auto-advance now happens only on the user’s selection event (single-select, selecting, non-Other).
• Added Storybook play test covering: select → advances; click back → stays; change answer → advances.

Also includes small test-suite stabilizations uncovered while running make test-unit:

• Gate web_fetch internet tests behind TEST_INTEGRATION=1.
• Reduce timing-based flakiness in background process output tests.
• Guard telemetry client for window-less test environments.
• Skip URL-hash sync in Storybook preview (avoids test-runner navigation retries).

---

📋 Implementation Plan

Fix: ask_user_question can’t navigate back after answering (single‑select)

Diagnosis (why it happens)

In src/browser/components/tools/AskUserQuestionToolCall.tsx, there’s a useEffect that auto-advances whenever the current question is single-select and has exactly one non-Other selection.

Because this effect runs any time activeIndex / currentQuestion changes, when you click a previous “section” (the header buttons like Approach, Platforms) you briefly land on that question and then the effect immediately pushes you forward again. Result: you can’t stay on a previously-answered single-select question to edit it.

Recommended fix (keep auto-advance, but only on the user action)

Net LoC (product code): ~-10 to -25 (remove effect + ref; add a small in-handler advance).

1. Remove the useEffect-based auto-advance and the hasUserInteracted ref.
2. Move auto-advance into the option toggle() handler for single-select questions:
   • Only advance when the user is selecting (not de-selecting) an option.
   • Only advance for non-Other selections.
   • Advance to activeIndex + 1 (which will naturally hit “Summary” after the last question).

This preserves the “fast path” UX for single-select while allowing users to click back to previous sections and change answers.

Suggested implementation sketch

• In toggle():
  • detect const isSelecting = !checked;
  • after calling setDraftAnswers(...), if !currentQuestion.multiSelect && isSelecting && opt.label !== OTHER_VALUE, call setActiveIndex((i) => i + 1).
• Delete the auto-advance useEffect entirely.

Tests (prevent regression)

Storybook interaction test (preferred for UI)

1. Add a play function to the existing AskUserQuestionPending story (or create a new focused story, e.g. AskUserQuestionBackNavigation).
2. Steps in play:
   • Click an option in the first single-select question → verify the UI advances to the next question.
   • Click the previous section button (Approach) → verify the first question remains visible (i.e., it does not auto-jump forward again).
   • Optionally: change the selection and confirm it advances again.

This will run in CI via the existing “Test / Storybook” GitHub Actions job.

(Optional) unit test if we want belt + suspenders

If you’d like a unit test that runs in bun test src too, extract the “should auto-advance” logic into a small pure helper (e.g. shouldAutoAdvanceSingleSelect(...)) and test:

• navigating back to an already-answered question does not auto-advance
• selecting a new non-Other option does

(But the Storybook interaction test should be sufficient and closer to the real bug.)

Validation checklist

• Repro the original issue locally (answer single-select → attempt to click back).
• After fix: you can click back to Approach and stay there.
• Run:
  • make test-unit
  • make storybook-build && make test-storybook

Alternatives considered

1. Keep the useEffect but add guards (track “last auto-advanced question+answer” in a ref).
   • Works, but is more stateful and easier to re-break.
2. Disable auto-advance entirely.
   • Simplest, but changes UX (users must always click Next).

The in-handler auto-advance is the smallest change that preserves existing intent.

---

Generated with mux • Model: openai:gpt-5.2 • Thinking: xhigh