@muggleai/works 4.5.0 → 4.6.0

package/dist/{chunk-MNCBJEPQ.js → chunk-TP4T4T2Z.js}

@@ -723,8 +723,9 @@ var AuthService = class {
   }
   /**
    * Start the device code flow.
+   * @param options.forceNewSession - Clear existing Auth0 browser session before login to allow account switching.
    */
-  async startDeviceCodeFlow() {
+  async startDeviceCodeFlow(options) {
     const logger14 = getLogger();
     const config = getConfig();
     const { domain, clientId, audience, scopes } = config.localQa.auth0;
@@ -761,15 +762,25 @@ var AuthService = class {
       userCode: data.user_code,
       expiresAt: new Date(Date.now() + data.expires_in * 1e3).toISOString()
     });
+    let browserUrl = data.verification_uri_complete;
+    if (options?.forceNewSession) {
+      const logoutUrl = new URL(`https://${domain}/v2/logout`);
+      logoutUrl.searchParams.set("client_id", clientId);
+      logoutUrl.searchParams.set("returnTo", data.verification_uri_complete);
+      browserUrl = logoutUrl.toString();
+      logger14.info("Force new session: opening logout-redirect URL", {
+        logoutUrl: browserUrl
+      });
+    }
     const browserOpenResult = await openBrowserUrl({
-      url: data.verification_uri_complete
+      url: browserUrl
     });
     if (browserOpenResult.opened) {
       logger14.info("Browser opened for device code login");
     } else {
       logger14.warn("Failed to open browser for device code login", {
         error: browserOpenResult.error,
-        verificationUriComplete: data.verification_uri_complete
+        url: browserUrl
       });
     }
     return {
@@ -2556,7 +2567,7 @@ var getCredentialsFilePath = getApiKeyFilePath;
 
 // packages/mcps/src/shared/auth.ts
 var logger4 = getLogger();
-async function startDeviceCodeFlow(config) {
+async function startDeviceCodeFlow(config, options) {
   const deviceCodeUrl = `https://${config.domain}/oauth/device/code`;
   try {
     logger4.info("[Auth] Starting device code flow", {
@@ -2581,8 +2592,16 @@ async function startDeviceCodeFlow(config) {
       userCode: data.user_code,
       expiresIn: data.expires_in
     });
+    let browserUrl = data.verification_uri_complete;
+    if (options?.forceNewSession) {
+      const logoutUrl = new URL(`https://${config.domain}/v2/logout`);
+      logoutUrl.searchParams.set("client_id", config.clientId);
+      logoutUrl.searchParams.set("returnTo", data.verification_uri_complete);
+      browserUrl = logoutUrl.toString();
+      logger4.info("[Auth] Force new session: opening logout-redirect URL");
+    }
     const browserOpenResult = await openBrowserUrl({
-      url: data.verification_uri_complete
+      url: browserUrl
     });
     if (browserOpenResult.opened) {
       logger4.info("[Auth] Browser opened for device code login");
@@ -3251,7 +3270,8 @@ var ApiKeyRevokeInputSchema = z.object({
 });
 var AuthLoginInputSchema = z.object({
   waitForCompletion: z.boolean().optional().describe("Whether to wait for browser login completion before returning. Default: true"),
-  timeoutMs: z.number().int().positive().min(1e3).max(9e5).optional().describe("Maximum time to wait for login completion in milliseconds. Default: 120000")
+  timeoutMs: z.number().int().positive().min(1e3).max(9e5).optional().describe("Maximum time to wait for login completion in milliseconds. Default: 120000"),
+  forceNewSession: z.boolean().optional().describe("Force a fresh login by clearing any existing Auth0 browser session before redirecting to the device activation page. Use this to switch accounts. Default: false")
 });
 var AuthPollInputSchema = z.object({
   deviceCode: z.string().optional().describe("Device code from the login response. Optional if a login was recently started.")
@@ -4880,7 +4900,9 @@ var authTools = [
     localHandler: async (input) => {
       const data = input;
       const authService = getAuthService();
-      const deviceCodeResponse = await authService.startDeviceCodeFlow();
+      const deviceCodeResponse = await authService.startDeviceCodeFlow({
+        forceNewSession: data.forceNewSession
+      });
       const waitForCompletion = data.waitForCompletion ?? true;
       if (!waitForCompletion) {
         return {
@@ -5173,12 +5195,10 @@ var ExecuteTestGenerationInputSchema = z.object({
   testCase: TestCaseDetailsSchema.describe("Test case details obtained from muggle-remote-test-case-get"),
   /** Local URL to test against. */
   localUrl: z.string().url().describe("Local URL to test against (e.g., http://localhost:3000)"),
-  /** Explicit approval to launch electron-app. */
-  approveElectronAppLaunch: z.boolean().describe("Set to true after the user explicitly approves launching electron-app"),
   /** Optional timeout. */
   timeoutMs: z.number().int().positive().optional().describe("Timeout in milliseconds (default: 300000 = 5 min)"),
-  /** Show the electron-app UI during execution. Ask the user before approving; true = visible window, false or omit = headless. */
-  showUi: z.boolean().optional().describe("Show the electron-app UI during generation. Ask the user: true to watch the window, false or omit for headless.")
+  /** Show the electron-app UI during execution. Default: visible window. Pass false to run headless. */
+  showUi: z.boolean().optional().describe("Show the electron-app UI during generation. Defaults to visible; pass false to run headless.")
 });
 var ExecuteReplayInputSchema = z.object({
   /** Test script metadata from muggle-remote-test-script-get. */
@@ -5187,12 +5207,10 @@ var ExecuteReplayInputSchema = z.object({
   actionScript: z.array(z.unknown()).describe("Action script steps from muggle-remote-action-script-get"),
   /** Local URL to test against. */
   localUrl: z.string().url().describe("Local URL to test against (e.g., http://localhost:3000)"),
-  /** Explicit approval to launch electron-app. */
-  approveElectronAppLaunch: z.boolean().describe("Set to true after the user explicitly approves launching electron-app"),
   /** Optional timeout. */
   timeoutMs: z.number().int().positive().optional().describe("Timeout in milliseconds (default: 180000 = 3 min)"),
-  /** Show the electron-app UI during execution. Ask the user before approving; true = visible window, false or omit = headless. */
-  showUi: z.boolean().optional().describe("Show the electron-app UI during replay. Ask the user: true to watch the window, false or omit for headless.")
+  /** Show the electron-app UI during execution. Default: visible window. Pass false to run headless. */
+  showUi: z.boolean().optional().describe("Show the electron-app UI during replay. Defaults to visible; pass false to run headless.")
 });
 var CancelExecutionInputSchema = z.object({
   runId: MuggleEntityIdSchema.describe("Run ID (UUID) to cancel")
@@ -5432,38 +5450,13 @@ var testScriptGetTool = {
 };
 var executeTestGenerationTool = {
   name: "muggle-local-execute-test-generation",
-  description: "Generate an end-to-end (E2E) acceptance test script by launching a real browser against your web app. The browser navigates your app, executes the test case steps (like signing up, filling forms, clicking through flows), and produces a replayable test script with screenshots. Use this to create new browser tests for any user flow. Requires a test case (from muggle-remote-test-case-get) and a localhost URL. Launches an Electron browser \u2014 requires explicit approval via approveElectronAppLaunch. Before approving, ask the user whether they want a visible GUI; pass showUi: true to watch the window or showUi: false for headless (default when omitted).",
+  description: "Generate an end-to-end (E2E) acceptance test script by launching a real browser against your web app. The browser navigates your app, executes the test case steps (like signing up, filling forms, clicking through flows), and produces a replayable test script with screenshots. Use this to create new browser tests for any user flow. Requires a test case (from muggle-remote-test-case-get) and a localhost URL. Launches an Electron browser \u2014 defaults to a visible window; pass showUi: false to run headless.",
   inputSchema: ExecuteTestGenerationInputSchema,
   execute: async (ctx) => {
     const logger14 = createChildLogger2(ctx.correlationId);
     logger14.info("Executing muggle-local-execute-test-generation");
     const input = ExecuteTestGenerationInputSchema.parse(ctx.input);
-    if (!input.approveElectronAppLaunch) {
-      const showUiExplicit = input.showUi !== void 0;
-      const uiMode = input.showUi === true ? "visible GUI (showUi: true)" : "headless (showUi: false or omitted)";
-      return {
-        content: [
-          "## Electron App Launch Required",
-          "",
-          "This tool will launch the electron-app to generate a test script.",
-          "Please set `approveElectronAppLaunch: true` to proceed.",
-          "",
-          "**Visible GUI:** Ask the user whether they want to watch the Electron window during generation.",
-          "- If **yes** \u2192 when approving, pass `showUi: true`.",
-          "- If **no** \u2192 when approving, pass `showUi: false` (or omit `showUi`; generation runs headless).",
-          "",
-          showUiExplicit ? `**Current choice:** ${uiMode}` : "**Current choice:** not set \u2014 default on approval is headless unless you pass `showUi: true`.",
-          "",
-          `**Test Case:** ${input.testCase.title}`,
-          `**Local URL:** ${input.localUrl}`,
-          "",
-          "**Note:** The electron-app will navigate your test URL and record steps."
-        ].join("\n"),
-        isError: false,
-        data: { requiresApproval: true }
-      };
-    }
-    const showUi = input.showUi === true;
+    const showUi = input.showUi !== false;
     try {
       const result = await executeTestGeneration({
         testCase: input.testCase,
@@ -5495,39 +5488,13 @@ var executeTestGenerationTool = {
 };
 var executeReplayTool = {
   name: "muggle-local-execute-replay",
-  description: "Replay an existing E2E acceptance test script in a real browser to verify your app still works correctly \u2014 use this for regression testing after code changes. The browser executes each saved step and captures screenshots so you can see what happened. Requires: (1) test script metadata from muggle-remote-test-script-get, (2) actionScript content from muggle-remote-action-script-get using the testScript.actionScriptId, and (3) a localhost URL. Launches an Electron browser \u2014 requires explicit approval via approveElectronAppLaunch. Before approving, ask the user whether they want a visible GUI; pass showUi: true to watch the window or showUi: false for headless (default when omitted).",
+  description: "Replay an existing E2E acceptance test script in a real browser to verify your app still works correctly \u2014 use this for regression testing after code changes. The browser executes each saved step and captures screenshots so you can see what happened. Requires: (1) test script metadata from muggle-remote-test-script-get, (2) actionScript content from muggle-remote-action-script-get using the testScript.actionScriptId, and (3) a localhost URL. Launches an Electron browser \u2014 defaults to a visible window; pass showUi: false to run headless.",
   inputSchema: ExecuteReplayInputSchema,
   execute: async (ctx) => {
     const logger14 = createChildLogger2(ctx.correlationId);
     logger14.info("Executing muggle-local-execute-replay");
     const input = ExecuteReplayInputSchema.parse(ctx.input);
-    if (!input.approveElectronAppLaunch) {
-      const showUiExplicit = input.showUi !== void 0;
-      const uiMode = input.showUi === true ? "visible GUI (showUi: true)" : "headless (showUi: false or omitted)";
-      return {
-        content: [
-          "## Electron App Launch Required",
-          "",
-          "This tool will launch the electron-app to replay a test script.",
-          "Please set `approveElectronAppLaunch: true` to proceed.",
-          "",
-          "**Visible GUI:** Ask the user whether they want to watch the Electron window during replay.",
-          "- If **yes** \u2192 when approving, pass `showUi: true`.",
-          "- If **no** \u2192 when approving, pass `showUi: false` (or omit `showUi`; replay runs headless).",
-          "",
-          showUiExplicit ? `**Current choice:** ${uiMode}` : "**Current choice:** not set \u2014 default on approval is headless unless you pass `showUi: true`.",
-          "",
-          `**Test Script:** ${input.testScript.name}`,
-          `**Local URL:** ${input.localUrl}`,
-          `**Steps:** ${input.actionScript.length}`,
-          "",
-          "**Note:** The electron-app will execute the test steps against your local URL."
-        ].join("\n"),
-        isError: false,
-        data: { requiresApproval: true }
-      };
-    }
-    const showUi = input.showUi === true;
+    const showUi = input.showUi !== false;
     try {
       const result = await executeReplay({
         testScript: input.testScript,

package/dist/cli.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { runCli } from './chunk-MNCBJEPQ.js';
+import { runCli } from './chunk-TP4T4T2Z.js';
 
 // src/cli/main.ts
 runCli().catch((error) => {

package/dist/index.js

@@ -1 +1 @@
-export { src_exports2 as commands, createChildLogger, createUnifiedMcpServer, e2e_exports as e2e, getConfig, getLocalQaTools, getLogger, getQaTools, local_exports as localQa, mcp_exports as mcp, e2e_exports as qa, server_exports as server, src_exports as shared } from './chunk-MNCBJEPQ.js';
+export { src_exports2 as commands, createChildLogger, createUnifiedMcpServer, e2e_exports as e2e, getConfig, getLocalQaTools, getLogger, getQaTools, local_exports as localQa, mcp_exports as mcp, e2e_exports as qa, server_exports as server, src_exports as shared } from './chunk-TP4T4T2Z.js';

package/dist/plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "muggle",
   "description": "Run real-browser end-to-end (E2E) acceptance tests on your web app from any AI coding agent. Generate test scripts from plain English, replay them on localhost, capture screenshots, and validate user flows like signup, checkout, and dashboards. Works across Claude Code, Cursor, Codex, and Windsurf.",
-  "version": "4.5.0",
+  "version": "4.6.0",
   "author": {
     "name": "Muggle AI",
     "email": "support@muggle-ai.com"

package/dist/plugin/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "muggle",
   "displayName": "Muggle AI",
   "description": "Ship quality products with AI-powered end-to-end (E2E) acceptance testing that validates your web app like a real user — from Claude Code and Cursor to PR.",
-  "version": "4.5.0",
+  "version": "4.6.0",
   "author": {
     "name": "Muggle AI",
     "email": "support@muggle-ai.com"

package/dist/plugin/skills/do/e2e-acceptance.md

@@ -33,7 +33,12 @@ Read `localUrl` for each repo from the context. If it is not provided, ask the u
 ### Step 1: Check Authentication
 
 - `muggle-remote-auth-status`
-- If not signed in: `muggle-remote-auth-login` then `muggle-remote-auth-poll`
+- If **authenticated**: print the logged-in email and ask via `AskQuestion`:
+  > "You're logged in as **{email}**. Continue with this account?"
+  - Option 1: "Yes, continue"
+  - Option 2: "No, switch account"
+  If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true` then `muggle-remote-auth-poll`.
+- If **not signed in or expired**: `muggle-remote-auth-login` then `muggle-remote-auth-poll`
 
 Do not skip or assume auth.
 
@@ -62,7 +67,6 @@ For each relevant test case:
      - `testScript`: the full script object
      - `actionScript`: the full action script object (from `muggle-remote-action-script-get`)
      - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true` *(pipeline context — user starting `muggle-do` is implicit approval)*
      - `timeoutMs`: `600000` (10 min) or `900000` (15 min) for complex flows
 
 3. **If no script exists** (generation path):
@@ -70,7 +74,6 @@ For each relevant test case:
    - `muggle-local-execute-test-generation` with:
      - `testCase`: the full test case object
      - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true`
      - `timeoutMs`: `600000` (10 min) or `900000` (15 min) for complex flows
 
 4. When execution completes, call `muggle-local-run-result-get` with the `runId` returned by the execute call.

package/dist/plugin/skills/muggle-test/SKILL.md

@@ -15,6 +15,22 @@ A router skill that detects code changes, resolves impacted test cases, executes
 - **Multi-select** (use cases, test cases): Use `AskQuestion` with `allow_multiple: true`.
 - **Free-text inputs** (URLs, descriptions): Only use plain text prompts when there is no finite set of options. Even then, offer a detected/default value when possible.
 - **Batch related questions**: If two questions are independent, present them together in a single `AskQuestion` call rather than asking sequentially.
+- **Parallelize job-creation calls**: Whenever you're kicking off N independent cloud jobs — creating multiple use cases, generating/creating multiple test cases, fetching details for multiple test cases, starting multiple remote workflows, publishing multiple local runs, or fetching per-step screenshots for multiple runs — issue all N tool calls in a single message so they run in parallel. Never loop them sequentially unless there is a real ordering constraint (e.g. a single local Electron browser that can only run one test at a time).
+
+## Test Case Design: One Atomic Behavior Per Test Case
+
+Every test case verifies exactly **one** user-observable behavior. Never bundle multiple concerns, sequential flows, or bootstrap/setup into a single test case — even if you think it would be "cleaner" or "more efficient."
+
+**Ordering, dependencies, and bootstrap are Muggle's service responsibility, not yours.** Muggle's cloud handles test case dependencies, prerequisite state, and execution ordering. Your job is to describe the *atomic behavior to verify* — never the flow that gets there.
+
+- ❌ Wrong: one test case that "signs up, logs in, navigates to the detail modal, verifies icon stacking, verifies tab order, verifies history format, and verifies reference layout."
+- ✅ Right: four separate test cases — one per verifiable behavior — each with instruction text like "Verify the detail modal shows stacked pair of icons per card" with **no** signup / login / navigation / setup language.
+
+**Never bake bootstrap into a test case description.** Signup, login, seed data, prerequisite navigation, tear-down — none of these belong inside the test case body. Write only the verification itself. The service will prepend whatever setup is needed based on its own dependency graph.
+
+**Never consolidate the generator's output.** When `muggle-remote-test-case-generate-from-prompt` returns N micro-tests from a single prompt, that decomposition is the authoritative one. Do not "merge them into 1 for simplicity," do not "rewrite them to share bootstrap," do not "collapse them to match a 4 UC / 4 TC plan." Accept what the generator gave you.
+
+**Never skip the generate→review cycle.** Even when you are 100% confident about the right shape, always present the generated test cases to the user before calling `muggle-remote-test-case-create`. "I'll skip the generate→review cycle and create directly" is a sign you're about to get it wrong.
 
 ## Step 1: Confirm Scope of Work (Always First)
 
@@ -41,8 +57,8 @@ If the user's intent is clear, state back what you understood and use `AskQuesti
 - Option 2: "Switch to [the other mode]"
 
 If ambiguous, use `AskQuestion` to let the user choose:
-- Option 1: "Local — launch browser on your machine against localhost"
-- Option 2: "Remote — Muggle cloud tests against a preview/staging URL"
+- Option 1: "On my computer — test your localhost dev server in a browser on your machine"
+- Option 2: "In the cloud — test remotely targeting your deployed preview/staging URL"
 
 Only proceed after the user selects an option.
 
@@ -66,8 +82,12 @@ If no changes detected (clean tree), tell the user and ask what they want to tes
 ## Step 3: Authenticate
 
 1. Call `muggle-remote-auth-status`
-2. If authenticated and not expired → proceed
-3. If not authenticated or expired → call `muggle-remote-auth-login`
+2. If **authenticated and not expired** → print the logged-in email and ask via `AskQuestion`:
+   > "You're logged in as **{email}**. Continue with this account?"
+   - Option 1: "Yes, continue"
+   - Option 2: "No, switch account"
+   If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true`, then `muggle-remote-auth-poll`.
+3. If **not authenticated or expired** → call `muggle-remote-auth-login`
 4. If login pending → call `muggle-remote-auth-poll`
 
 If auth fails repeatedly, suggest: `muggle logout && muggle login` from terminal.
@@ -93,56 +113,68 @@ A **project** is where all your test results, use cases, and test scripts are gr
 
 Store the `projectId` only after user confirms.
 
-## Step 5: Select Use Case (User Must Choose)
+## Step 5: Select Use Case (Best-Effort Shortlist)
 
 ### 5a: List existing use cases
 Call `muggle-remote-use-case-list` with the project ID.
 
-### 5b: Present ALL use cases for user selection
+### 5b: Best-effort match against the change summary
+
+Using the change summary from Step 2, pick the use cases whose title/description most plausibly relate to the impacted areas. Produce a **short shortlist** (typically 1–5) — don't try to be exhaustive, and don't dump the full project list on the user. A confident best-effort match is the goal.
+
+If nothing looks like a confident match, fall back to asking the user which use case(s) they have in mind.
 
-Use `AskQuestion` with `allow_multiple: true` to present all use cases as clickable options. Always include a "Create new use case" option at the end.
+### 5c: Present the shortlist for confirmation
 
-Prompt: "Which use case(s) do you want to test?"
+Use `AskQuestion` with `allow_multiple: true`:
 
-### 5c: Wait for explicit user selection
+Prompt: "These use cases look most relevant to your changes — confirm which to test:"
 
-**CRITICAL: Do NOT auto-select use cases** based on:
-- Git changes analysis
-- Use case title/description matching
-- Any heuristic or inference
+- Pre-check the shortlisted items so the user can accept with one click
+- Include "Pick a different use case" to reveal the full project list
+- Include "Create new use case" at the end
 
-The user MUST explicitly tell you which use case(s) to use.
+### 5d: If user picks "Pick a different use case"
+Re-present the full list from 5a via `AskQuestion` with `allow_multiple: true`, then continue.
 
-### 5d: If user chooses "Create new use case"
-1. Ask the user to describe the use case in plain English
-2. Call `muggle-remote-use-case-create-from-prompts`:
+### 5e: If user chooses "Create new use case"
+1. Ask the user to describe the use case(s) in plain English — they may want more than one
+2. Call `muggle-remote-use-case-create-from-prompts` **once** with **all** descriptions batched into the `instructions` array (this endpoint natively fans out the jobs server-side — do NOT make one call per use case):
    - `projectId`: The project ID
-   - `instructions`: A plain array of strings, one per use case — e.g. `["<user's description>"]`
-3. Present the created use case and confirm it's correct
+   - `instructions`: A plain array of strings, one per use case — e.g. `["<description 1>", "<description 2>", ...]`
+3. Present the created use cases and confirm they're correct
 
-## Step 6: Select Test Case (User Must Choose)
+## Step 6: Select Test Case (Best-Effort Shortlist)
 
 For the selected use case(s):
 
 ### 6a: List existing test cases
 Call `muggle-remote-test-case-list-by-use-case` with each use case ID.
 
-### 6b: Present ALL test cases for user selection
+### 6b: Best-effort match against the change summary
 
-Use `AskQuestion` with `allow_multiple: true` to present all test cases as clickable options. Always include a "Generate new test case" option at the end.
+Using the change summary from Step 2, pick the test cases that look most relevant to the impacted areas. Keep the shortlist small and confident — don't enumerate every test case attached to the use case(s).
 
-Prompt: "Which test case(s) do you want to run?"
+If nothing looks like a confident match, fall back to offering to run all test cases for the selected use case(s), or ask the user what they had in mind.
 
-### 6c: Wait for explicit user selection
+### 6c: Present the shortlist for confirmation
 
-**CRITICAL: Do NOT auto-select test cases** — the user MUST explicitly choose which test case(s) to execute.
+Use `AskQuestion` with `allow_multiple: true`:
+
+Prompt: "These test cases look most relevant — confirm which to run:"
+
+- Pre-check the shortlisted items so the user can accept with one click
+- Include "Show all test cases" to reveal the full list
+- Include "Generate new test case" at the end
 
 ### 6d: If user chooses "Generate new test case"
-1. Ask the user to describe what they want to test in plain English
-2. Call `muggle-remote-test-case-generate-from-prompt`:
-   - `projectId`, `useCaseId`, `instruction` (the user's description)
-3. Present the generated test case(s) for review
-4. Call `muggle-remote-test-case-create` to save the ones the user approves
+1. Ask the user to describe what they want to test in plain English — they may want more than one test case
+2. For N descriptions, issue N `muggle-remote-test-case-generate-from-prompt` calls **in parallel** (single message, multiple tool calls — never loop sequentially):
+   - `projectId`, `useCaseId`, `instruction` (one description per call)
+   - Each `instruction` must describe **exactly one atomic behavior to verify**. No signup, no login, no "first navigate to X, then click Y, then verify Z" chains, no seed data, no cleanup. Just the verification. See **Test Case Design** above.
+3. **Accept the generator's decomposition as-is.** If the generator returns 4 micro-tests from a single prompt, that's 4 correct test cases — never merge, consolidate, or rewrite them to bundle bootstrap.
+4. Present the generated test case(s) for user review — **always do this review cycle**, even when you think you already know the right shape. Skipping straight to creation is the anti-pattern this skill most frequently gets wrong.
+5. For the ones the user approves, issue `muggle-remote-test-case-create` calls **in parallel**
 
 ### 6e: Confirm final selection
 
@@ -154,9 +186,7 @@ Wait for user confirmation before moving to execution.
 
 ## Step 7A: Execute — Local Mode
 
-### Pre-flight questions (batch where possible)
-
-**Question 1 — Local URL:**
+### Pre-flight question — Local URL
 
 Try to auto-detect the dev server URL by checking running terminals or common ports (e.g., `lsof -iTCP -sTCP:LISTEN -nP | grep -E ':(3000|3001|4200|5173|8080)'`). If a likely URL is found, present it as a clickable default via `AskQuestion`:
 - Option 1: "http://localhost:3000" (or whatever was detected)
@@ -164,38 +194,31 @@ Try to auto-detect the dev server URL by checking running terminals or common po
 
 If nothing detected, ask as free text: "Your local app should be running. What's the URL? (e.g., http://localhost:3000)"
 
-**Question 2 — Electron launch + window visibility (ask together):**
-
-After getting the URL, use a single `AskQuestion` call with two questions:
+**No separate approval or visibility question.** The user picking Local mode in Step 1 *is* the approval — do not ask "ready to launch Electron?" before every run. The Electron browser defaults to visible; if the user wants headless, they will say so, otherwise let it run visible.
 
-1. "Ready to launch the Muggle Electron browser for [N] test case(s)?"
-   - "Yes, launch it (visible — I want to watch)"
-   - "Yes, launch it (headless — run in background)"
-   - "No, cancel"
+### Fetch test case details (in parallel)
 
-If user cancels, stop and ask what they want to do instead.
+Before execution, fetch full test case details for all selected test cases by issuing **all** `muggle-remote-test-case-get` calls in parallel (single message, multiple tool calls).
 
-### Run sequentially
+### Run sequentially (Electron constraint)
 
-For each test case:
+Execution itself **must** be sequential because there is only one local Electron browser. For each test case, in order:
 
-1. Call `muggle-remote-test-case-get` to fetch full details
-2. Call `muggle-local-execute-test-generation`:
-   - `testCase`: Full test case object from step 1
-   - `localUrl`: User's local URL (from Question 1)
-   - `approveElectronAppLaunch`: `true` (only if user approved in Question 2)
-   - `showUi`: `true` if user chose "visible", `false` if "headless" (from Question 2)
-3. Store the returned `runId`
+1. Call `muggle-local-execute-test-generation`:
+   - `testCase`: Full test case object from the parallel fetch above
+   - `localUrl`: User's local URL from the pre-flight question
+   - `showUi`: omit (default visible) unless the user explicitly asked for headless, then pass `false`
+2. Store the returned `runId`
 
 If a generation fails, log it and continue to the next. Do not abort the batch.
 
-### Collect results
+### Collect results (in parallel)
 
-For each `runId`, call `muggle-local-run-result-get`. Extract: status, duration, step count, `artifactsDir`.
+For every `runId`, issue all `muggle-local-run-result-get` calls in parallel. Extract: status, duration, step count, `artifactsDir`.
 
-### Publish each run to cloud
+### Publish each run to cloud (in parallel)
 
-For each completed run, call `muggle-local-publish-test-script`:
+For every completed run, issue all `muggle-local-publish-test-script` calls in parallel (single message, multiple tool calls):
 - `runId`: The local run ID
 - `cloudTestCaseId`: The cloud test case ID
 
@@ -225,26 +248,29 @@ For failures: show which step failed, the local screenshot path, and a suggestio
 
 > "What's the preview/staging URL to test against?"
 
-### Trigger remote workflows
+### Fetch test case details (in parallel)
 
-For each test case:
+Issue all `muggle-remote-test-case-get` calls in parallel (single message, multiple tool calls) to hydrate the test case bodies.
 
-1. Call `muggle-remote-test-case-get` to fetch full details
-2. Call `muggle-remote-workflow-start-test-script-generation`:
-   - `projectId`: The project ID
-   - `useCaseId`: The use case ID
-   - `testCaseId`: The test case ID
-   - `name`: `"muggle-test: {test case title}"`
-   - `url`: The preview/staging URL
-   - `goal`: From the test case
-   - `precondition`: From the test case (use `"None"` if empty)
-   - `instructions`: From the test case
-   - `expectedResult`: From the test case
-3. Store the returned workflow runtime ID
+### Trigger remote workflows (in parallel)
+
+Once details are in hand, issue all `muggle-remote-workflow-start-test-script-generation` calls in parallel — never loop them sequentially. For each test case:
+
+- `projectId`: The project ID
+- `useCaseId`: The use case ID
+- `testCaseId`: The test case ID
+- `name`: `"muggle-test: {test case title}"`
+- `url`: The preview/staging URL
+- `goal`: From the test case
+- `precondition`: From the test case (use `"None"` if empty)
+- `instructions`: From the test case
+- `expectedResult`: From the test case
+
+Store each returned workflow runtime ID.
 
-### Monitor and report
+### Monitor and report (in parallel)
 
-For each workflow, call `muggle-remote-wf-get-ts-gen-latest-run` with the runtime ID.
+Issue all `muggle-remote-wf-get-ts-gen-latest-run` calls in parallel, one per runtime ID.
 
 ```
 Test Case                  Workflow Status   Runtime ID
@@ -287,12 +313,11 @@ After reporting results, ask the user if they want to attach a **visual walkthro
 
 The shared skill takes an **`E2eReport` JSON** that includes per-step screenshot URLs. You already have `projectId`, `testCaseId`, `runId`, `viewUrl`, and `status` from earlier steps — you still need the step-level data.
 
-For each published run from Step 7A:
+For the published runs from Step 7A, issue **all** `muggle-remote-test-script-get` calls in parallel (single message, multiple tool calls) — one per `testScriptId` returned by `muggle-local-publish-test-script`. Then, for each response:
 
-1. Call `muggle-remote-test-script-get` with the `testScriptId` returned by `muggle-local-publish-test-script`.
-2. Extract from the response: `steps[].operation.action` (description) and `steps[].operation.screenshotUrl` (cloud URL).
-3. Build a `steps` array: `[{ stepIndex: 0, action: "...", screenshotUrl: "..." }, ...]`.
-4. If the run failed, also capture `failureStepIndex`, `error`, and the local `artifactsDir` from `muggle-local-run-result-get`.
+1. Extract `steps[].operation.action` (description) and `steps[].operation.screenshotUrl` (cloud URL).
+2. Build a `steps` array: `[{ stepIndex: 0, action: "...", screenshotUrl: "..." }, ...]`.
+3. If the run failed, also capture `failureStepIndex`, `error`, and the local `artifactsDir` from `muggle-local-run-result-get`.
 
 Assemble the report:
 
@@ -364,11 +389,15 @@ This skill always uses **Mode A** (post to an existing PR); `muggle-do` is the o
 
 - **Always confirm intent first** — never assume local vs remote without asking
 - **User MUST select project** — present clickable options via `AskQuestion`, wait for explicit choice, never auto-select
-- **User MUST select use case(s)** — present clickable options via `AskQuestion`, wait for explicit choice, never auto-select based on git changes or heuristics
-- **User MUST select test case(s)** — present clickable options via `AskQuestion`, wait for explicit choice, never auto-select
+- **Best-effort shortlist use cases** — use the change summary to narrow the list to the most relevant 1–5 use cases and pre-check them; never dump every use case in the project on the user. Always leave an escape hatch to reveal the full list.
+- **Best-effort shortlist test cases** — same idea: pre-check the test cases most relevant to the change summary; never enumerate every test case attached to a use case. Always leave an escape hatch to reveal the full list.
 - **Use `AskQuestion` for every selection** — never ask the user to type a number; always present clickable options
-- **Batch related questions** — combine Electron approval + visibility into one question; auto-detect localhost URL when possible
-- **Never launch Electron without explicit user approval** (`approveElectronAppLaunch`)
+- **Auto-detect localhost URL when possible**; only fall back to free-text when nothing is listening on a common port
+- **Parallelize independent cloud jobs** — when creating N use cases, generating/creating N test cases, fetching N test case details, starting N remote workflows, polling N workflow runtimes, publishing N local runs, or fetching N per-step test scripts, issue all N calls in a single message so they fan out in parallel. The only tolerated sequential loop is local Electron execution (one browser, one test at a time). For use case creation specifically, use the native batch form of `muggle-remote-use-case-create-from-prompts` (all descriptions in one `instructions` array) instead of parallel calls.
+- **One atomic behavior per test case** — every test case verifies exactly one user-observable behavior. Never bundle signup/login/navigation/bootstrap/teardown into a test case body. Ordering and dependencies are Muggle's service responsibility, not the skill's.
+- **Never consolidate the generator's output** — if `muggle-remote-test-case-generate-from-prompt` returns N micro-tests, accept all N; never merge them into fewer test cases, even if "the plan" says 4 UC / 4 TC.
+- **Never skip the generate→review cycle** — always present generated test cases to the user before calling `muggle-remote-test-case-create`, even when you're confident. "I'll skip the review and create directly" is always wrong.
+- **Never ask for Electron launch approval before each run** — the user picking Local mode is the approval. Don't prompt "Ready to launch Electron?" before execution; just run.
 - **Never silently drop test cases** — log failures and continue, then report them
 - **Never guess the URL** — always ask the user for localhost or preview URL
 - **Always publish before opening browser** — the dashboard needs the published data to show results

package/dist/plugin/skills/muggle-test-feature-local/SKILL.md

@@ -19,7 +19,7 @@ The local URL only changes where the browser opens; it does not change the remot
 
 **Every selection-based question MUST use the `AskQuestion` tool** (or the platform's equivalent structured selection tool). Never ask the user to "reply with a number" in a plain text message — always present clickable options.
 
-- **Selections** (project, use case, test case, script, approval): Use `AskQuestion` with labeled options the user can click.
+- **Selections** (project, use case, test case, script): Use `AskQuestion` with labeled options the user can click.
 - **Free-text inputs** (URLs, descriptions): Only use plain text prompts when there is no finite set of options. Even then, offer a detected/default value when possible.
 
 ## Workflow
@@ -27,7 +27,12 @@ The local URL only changes where the browser opens; it does not change the remot
 ### 1. Auth
 
 - `muggle-remote-auth-status`
-- If not signed in: `muggle-remote-auth-login` then `muggle-remote-auth-poll`
+- If **authenticated**: print the logged-in email and ask via `AskQuestion`:
+  > "You're logged in as **{email}**. Continue with this account?"
+  - Option 1: "Yes, continue"
+  - Option 2: "No, switch account"
+  If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true` then `muggle-remote-auth-poll`.
+- If **not signed in or expired**: call `muggle-remote-auth-login` then `muggle-remote-auth-poll`.
   Do not skip or assume auth.
 
 ### 2. Targets (user must confirm)
@@ -84,21 +89,21 @@ Remind them: local URL is only the execution target, not tied to cloud project c
 **Generate**
 
 1. `muggle-remote-test-case-get`
-2. `muggle-local-execute-test-generation` (after approval in step 6) with that test case + `localUrl` + `approveElectronAppLaunch: true` (optional: `showUi: true`, **`timeoutMs`** — see below)
+2. `muggle-local-execute-test-generation` with that test case + `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`timeoutMs`** — see below)
 
 **Replay**
 
 1. `muggle-remote-test-script-get` — note `actionScriptId`
 2. `muggle-remote-action-script-get` with that id — full `actionScript`
    **Use the API response as-is.** Do not edit, shorten, or rebuild `actionScript`; replay needs full `label` paths for element lookup.
-3. `muggle-local-execute-replay` (after approval in step 6) with `testScript`, `actionScript`, `localUrl`, `approveElectronAppLaunch: true` (optional: `showUi: true`, **`timeoutMs`** — see below)
+3. `muggle-local-execute-replay` with `testScript`, `actionScript`, `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`timeoutMs`** — see below)
 
 ### Local execution timeout (`timeoutMs`)
 
 The MCP client often uses a **default wait of 300000 ms (5 minutes)** for `muggle-local-execute-test-generation` and `muggle-local-execute-replay`. **Exploratory script generation** (Auth0 login, dashboards, multi-step wizards, many LLM iterations) routinely **runs longer than 5 minutes** while Electron is still healthy.
 
 - **Always pass `timeoutMs`** for flows that may be long — for example **`600000` (10 min)** or **`900000` (15 min)** — unless the user explicitly wants a short cap.
-- If the tool reports **`Electron execution timed out after 300000ms`** (or similar) **but** Electron logs show the run still progressing (steps, screenshots, LLM calls), treat it as **orchestration timeout**, not an Electron app defect: **increase `timeoutMs` and retry** (after user re-approves if your policy requires it).
+- If the tool reports **`Electron execution timed out after 300000ms`** (or similar) **but** Electron logs show the run still progressing (steps, screenshots, LLM calls), treat it as **orchestration timeout**, not an Electron app defect: **increase `timeoutMs` and retry**.
 - **Test case design:** Preconditions like "a test run has already completed" on an **empty account** can force many steps (sign-up, new project, crawl). Prefer an account/project that **already has** the needed state, or narrow the test goal so generation does not try to create a full project from scratch unless that is intentional.
 
 ### Interpreting `failed` / non-zero Electron exit
@@ -106,15 +111,9 @@ The MCP client often uses a **default wait of 300000 ms (5 minutes)** for `muggl
 - **`Electron execution timed out after 300000ms`:** Orchestration wait too short — see **`timeoutMs`** above.
 - **Exit code 26** (and messages like **LLM failed to generate / replay action script**): Often corresponds to a completed exploration whose **outcome was goal not achievable** (`goal_not_achievable`, summary with `halt`) — e.g. verifying "view script after a successful run" when **no run or script exists yet** in the UI. Use `muggle-local-run-result-get` and read the **summary / structured summary**; do not assume an Electron crash. **Fix:** choose a **project that already has** completed runs and scripts, or **change the test case** so preconditions match what localhost can satisfy (e.g. include steps to create and run a test first, or assert only empty-state UI when no runs exist).
 
-### 6. Approval before any local execution
+### 6. Execute (no approval prompt)
 
-Use `AskQuestion` to get explicit approval before launching Electron. State: replay vs generation, test case name, URL.
-
-- "Yes, launch Electron (visible — I want to watch)"
-- "Yes, launch Electron (headless — run in background)"
-- "No, cancel"
-
-Only call local execute tools with `approveElectronAppLaunch: true` after the user selects a "Yes" option. Map visible to `showUi: true`, headless to `showUi: false`.
+Call `muggle-local-execute-test-generation` or `muggle-local-execute-replay` directly. **Do not** ask the user to re-approve the Electron launch — the user choosing this skill in the first place is the approval. The browser defaults to visible; only pass `showUi: false` if the user explicitly asked for headless.
 
 ### 7. After successful generation only
 
@@ -177,10 +176,11 @@ Always use **Mode A** (post to existing PR) from this skill. Never hand-write th
 
 ## Non-negotiables
 
-- No silent auth skip; no launching Electron without approval via `AskQuestion`.
+- No silent auth skip.
+- **Never prompt for Electron launch approval** before execution — invoking this skill is the approval. Just run.
 - If replayable scripts exist, do not default to generation without user choice.
 - No hiding failures: surface errors and artifact paths.
 - Replay: never hand-built or simplified `actionScript` — only from `muggle-remote-action-script-get`.
-- Use `AskQuestion` for every selection — project, use case, test case, script, and approval. Never ask the user to type a number.
+- Use `AskQuestion` for every selection — project, use case, test case, script. Never ask the user to type a number.
 - Project, use case, and test case selection lists must always include "Create new ...". Include "Show full list" whenever the API returned at least one row for that step; omit "Show full list" when the list is empty (offer "Create new ..." only). For creates, use preview tools (`muggle-remote-use-case-prompt-preview`, `muggle-remote-test-case-generate-from-prompt`) before persisting.
 - PR posting is always optional and always delegated to the `muggle-pr-visual-walkthrough` skill — never inline the walkthrough markdown or call `gh pr comment` directly from this skill.

package/dist/plugin/skills/muggle-test-import/SKILL.md

@@ -130,9 +130,12 @@ If the user wants changes, incorporate feedback, then ask again. Only proceed af
 
 Call `muggle-remote-auth-status` first.
 
-If already authenticated → skip to Step 5.
+If **already authenticated** → print the logged-in email and ask via `AskQuestion`:
+> "You're logged in as **{email}**. Continue with this account?"
+- Option 1: "Yes, continue" → skip to Step 5.
+- Option 2: "No, switch account" → call `muggle-remote-auth-login` with `forceNewSession: true`, then `muggle-remote-auth-poll`.
 
-If not authenticated:
+If **not authenticated**:
 1. Tell the user a browser window is about to open.
 2. Call `muggle-remote-auth-login` (opens browser automatically).
 3. Tell the user to complete login in the browser.

package/dist/plugin/skills/muggle-test-regenerate-missing/SKILL.md

@@ -40,8 +40,13 @@ Treat this filter as a default, not a law. If the user explicitly says "include
 ### Step 1 — Authenticate
 
 1. Call `muggle-remote-auth-status`.
-2. If not authenticated or expired → call `muggle-remote-auth-login`, then poll with `muggle-remote-auth-poll`.
-3. Do not skip auth and do not assume a stale token still works.
+2. If **authenticated and not expired** → print the logged-in email and ask via `AskQuestion`:
+   > "You're logged in as **{email}**. Continue with this account?"
+   - Option 1: "Yes, continue"
+   - Option 2: "No, switch account"
+   If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true`, then poll with `muggle-remote-auth-poll`.
+3. If **not authenticated or expired** → call `muggle-remote-auth-login`, then poll with `muggle-remote-auth-poll`.
+4. Do not skip auth and do not assume a stale token still works.
 
 If auth keeps failing, suggest the user run `muggle logout && muggle login` from a terminal.
 

package/dist/release-manifest.json

@@ -1,7 +1,7 @@
 {
-  "release": "4.5.0",
-  "buildId": "run-13-1",
-  "commitSha": "bff100bb7229ea757db7154a9ef0c289da0124ef",
-  "buildTime": "2026-04-09T22:06:42Z",
+  "release": "4.6.0",
+  "buildId": "run-14-1",
+  "commitSha": "6bb3f01991815677a37182923c26ba71d623a2b0",
+  "buildTime": "2026-04-10T20:31:08Z",
   "serviceName": "muggle-ai-works-mcp"
 }

package/package.json

@@ -1,7 +1,7 @@
 {
     "name": "@muggleai/works",
     "mcpName": "io.github.multiplex-ai/muggle",
-    "version": "4.5.0",
+    "version": "4.6.0",
     "description": "Ship quality products with AI-powered E2E acceptance testing that validates your web app like a real user — from Claude Code and Cursor to PR.",
     "type": "module",
     "main": "dist/index.js",
@@ -41,14 +41,14 @@
         "test:watch": "vitest"
     },
     "muggleConfig": {
-        "electronAppVersion": "1.0.47",
+        "electronAppVersion": "1.0.49",
         "downloadBaseUrl": "https://github.com/multiplex-ai/muggle-ai-works/releases/download",
         "runtimeTargetDefault": "production",
         "checksums": {
-            "darwin-arm64": "f80b943ea5f05e7113d603ee8104c07be101a26092c4fa50ed6fcb37a0cbebff",
-            "darwin-x64": "3189a5c07087f9ba2ef03f99e3735055c00a752b2421ae9cffc113f04933da61",
-            "win32-x64": "d8e102fce024776262f856dfea0b12429e853689d29d03e27e54dbeffbe59725",
-            "linux-x64": "d7218dddcbab47f78c64fe438cf5bd129740f20f6ad160b615a648415f8faffc"
+            "darwin-arm64": "0a93aa97ace4c2afbb8dd7e49c91673e352eefbc6df6bebb0ea0e7142ee5d63c",
+            "darwin-x64": "98e37f7ddf4b86fef15bfe6ab8275072d04857690de776b89611a1a4d83d4691",
+            "win32-x64": "5d72b318388ae45f8aad0a9f6363dd680f870effc69991ea8ab244786a6f9d31",
+            "linux-x64": "5275c5c8fca3435ac0294d3ded00d68ecf5cd7d602a4f58b6de8fef3568559ee"
         }
     },
     "dependencies": {

package/plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "muggle",
   "description": "Run real-browser end-to-end (E2E) acceptance tests on your web app from any AI coding agent. Generate test scripts from plain English, replay them on localhost, capture screenshots, and validate user flows like signup, checkout, and dashboards. Works across Claude Code, Cursor, Codex, and Windsurf.",
-  "version": "4.5.0",
+  "version": "4.6.0",
   "author": {
     "name": "Muggle AI",
     "email": "support@muggle-ai.com"

package/plugin/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "muggle",
   "displayName": "Muggle AI",
   "description": "Ship quality products with AI-powered end-to-end (E2E) acceptance testing that validates your web app like a real user — from Claude Code and Cursor to PR.",
-  "version": "4.5.0",
+  "version": "4.6.0",
   "author": {
     "name": "Muggle AI",
     "email": "support@muggle-ai.com"

package/plugin/skills/do/e2e-acceptance.md

@@ -33,7 +33,12 @@ Read `localUrl` for each repo from the context. If it is not provided, ask the u
 ### Step 1: Check Authentication
 
 - `muggle-remote-auth-status`
-- If not signed in: `muggle-remote-auth-login` then `muggle-remote-auth-poll`
+- If **authenticated**: print the logged-in email and ask via `AskQuestion`:
+  > "You're logged in as **{email}**. Continue with this account?"
+  - Option 1: "Yes, continue"
+  - Option 2: "No, switch account"
+  If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true` then `muggle-remote-auth-poll`.
+- If **not signed in or expired**: `muggle-remote-auth-login` then `muggle-remote-auth-poll`
 
 Do not skip or assume auth.
 
@@ -62,7 +67,6 @@ For each relevant test case:
      - `testScript`: the full script object
      - `actionScript`: the full action script object (from `muggle-remote-action-script-get`)
      - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true` *(pipeline context — user starting `muggle-do` is implicit approval)*
      - `timeoutMs`: `600000` (10 min) or `900000` (15 min) for complex flows
 
 3. **If no script exists** (generation path):
@@ -70,7 +74,6 @@ For each relevant test case:
    - `muggle-local-execute-test-generation` with:
      - `testCase`: the full test case object
      - `localUrl`: the resolved local URL
-     - `approveElectronAppLaunch`: `true`
      - `timeoutMs`: `600000` (10 min) or `900000` (15 min) for complex flows
 
 4. When execution completes, call `muggle-local-run-result-get` with the `runId` returned by the execute call.

package/plugin/skills/muggle-test/SKILL.md

@@ -15,6 +15,22 @@ A router skill that detects code changes, resolves impacted test cases, executes
 - **Multi-select** (use cases, test cases): Use `AskQuestion` with `allow_multiple: true`.
 - **Free-text inputs** (URLs, descriptions): Only use plain text prompts when there is no finite set of options. Even then, offer a detected/default value when possible.
 - **Batch related questions**: If two questions are independent, present them together in a single `AskQuestion` call rather than asking sequentially.
+- **Parallelize job-creation calls**: Whenever you're kicking off N independent cloud jobs — creating multiple use cases, generating/creating multiple test cases, fetching details for multiple test cases, starting multiple remote workflows, publishing multiple local runs, or fetching per-step screenshots for multiple runs — issue all N tool calls in a single message so they run in parallel. Never loop them sequentially unless there is a real ordering constraint (e.g. a single local Electron browser that can only run one test at a time).
+
+## Test Case Design: One Atomic Behavior Per Test Case
+
+Every test case verifies exactly **one** user-observable behavior. Never bundle multiple concerns, sequential flows, or bootstrap/setup into a single test case — even if you think it would be "cleaner" or "more efficient."
+
+**Ordering, dependencies, and bootstrap are Muggle's service responsibility, not yours.** Muggle's cloud handles test case dependencies, prerequisite state, and execution ordering. Your job is to describe the *atomic behavior to verify* — never the flow that gets there.
+
+- ❌ Wrong: one test case that "signs up, logs in, navigates to the detail modal, verifies icon stacking, verifies tab order, verifies history format, and verifies reference layout."
+- ✅ Right: four separate test cases — one per verifiable behavior — each with instruction text like "Verify the detail modal shows stacked pair of icons per card" with **no** signup / login / navigation / setup language.
+
+**Never bake bootstrap into a test case description.** Signup, login, seed data, prerequisite navigation, tear-down — none of these belong inside the test case body. Write only the verification itself. The service will prepend whatever setup is needed based on its own dependency graph.
+
+**Never consolidate the generator's output.** When `muggle-remote-test-case-generate-from-prompt` returns N micro-tests from a single prompt, that decomposition is the authoritative one. Do not "merge them into 1 for simplicity," do not "rewrite them to share bootstrap," do not "collapse them to match a 4 UC / 4 TC plan." Accept what the generator gave you.
+
+**Never skip the generate→review cycle.** Even when you are 100% confident about the right shape, always present the generated test cases to the user before calling `muggle-remote-test-case-create`. "I'll skip the generate→review cycle and create directly" is a sign you're about to get it wrong.
 
 ## Step 1: Confirm Scope of Work (Always First)
 
@@ -41,8 +57,8 @@ If the user's intent is clear, state back what you understood and use `AskQuesti
 - Option 2: "Switch to [the other mode]"
 
 If ambiguous, use `AskQuestion` to let the user choose:
-- Option 1: "Local — launch browser on your machine against localhost"
-- Option 2: "Remote — Muggle cloud tests against a preview/staging URL"
+- Option 1: "On my computer — test your localhost dev server in a browser on your machine"
+- Option 2: "In the cloud — test remotely targeting your deployed preview/staging URL"
 
 Only proceed after the user selects an option.
 
@@ -66,8 +82,12 @@ If no changes detected (clean tree), tell the user and ask what they want to tes
 ## Step 3: Authenticate
 
 1. Call `muggle-remote-auth-status`
-2. If authenticated and not expired → proceed
-3. If not authenticated or expired → call `muggle-remote-auth-login`
+2. If **authenticated and not expired** → print the logged-in email and ask via `AskQuestion`:
+   > "You're logged in as **{email}**. Continue with this account?"
+   - Option 1: "Yes, continue"
+   - Option 2: "No, switch account"
+   If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true`, then `muggle-remote-auth-poll`.
+3. If **not authenticated or expired** → call `muggle-remote-auth-login`
 4. If login pending → call `muggle-remote-auth-poll`
 
 If auth fails repeatedly, suggest: `muggle logout && muggle login` from terminal.
@@ -93,56 +113,68 @@ A **project** is where all your test results, use cases, and test scripts are gr
 
 Store the `projectId` only after user confirms.
 
-## Step 5: Select Use Case (User Must Choose)
+## Step 5: Select Use Case (Best-Effort Shortlist)
 
 ### 5a: List existing use cases
 Call `muggle-remote-use-case-list` with the project ID.
 
-### 5b: Present ALL use cases for user selection
+### 5b: Best-effort match against the change summary
+
+Using the change summary from Step 2, pick the use cases whose title/description most plausibly relate to the impacted areas. Produce a **short shortlist** (typically 1–5) — don't try to be exhaustive, and don't dump the full project list on the user. A confident best-effort match is the goal.
+
+If nothing looks like a confident match, fall back to asking the user which use case(s) they have in mind.
 
-Use `AskQuestion` with `allow_multiple: true` to present all use cases as clickable options. Always include a "Create new use case" option at the end.
+### 5c: Present the shortlist for confirmation
 
-Prompt: "Which use case(s) do you want to test?"
+Use `AskQuestion` with `allow_multiple: true`:
 
-### 5c: Wait for explicit user selection
+Prompt: "These use cases look most relevant to your changes — confirm which to test:"
 
-**CRITICAL: Do NOT auto-select use cases** based on:
-- Git changes analysis
-- Use case title/description matching
-- Any heuristic or inference
+- Pre-check the shortlisted items so the user can accept with one click
+- Include "Pick a different use case" to reveal the full project list
+- Include "Create new use case" at the end
 
-The user MUST explicitly tell you which use case(s) to use.
+### 5d: If user picks "Pick a different use case"
+Re-present the full list from 5a via `AskQuestion` with `allow_multiple: true`, then continue.
 
-### 5d: If user chooses "Create new use case"
-1. Ask the user to describe the use case in plain English
-2. Call `muggle-remote-use-case-create-from-prompts`:
+### 5e: If user chooses "Create new use case"
+1. Ask the user to describe the use case(s) in plain English — they may want more than one
+2. Call `muggle-remote-use-case-create-from-prompts` **once** with **all** descriptions batched into the `instructions` array (this endpoint natively fans out the jobs server-side — do NOT make one call per use case):
    - `projectId`: The project ID
-   - `instructions`: A plain array of strings, one per use case — e.g. `["<user's description>"]`
-3. Present the created use case and confirm it's correct
+   - `instructions`: A plain array of strings, one per use case — e.g. `["<description 1>", "<description 2>", ...]`
+3. Present the created use cases and confirm they're correct
 
-## Step 6: Select Test Case (User Must Choose)
+## Step 6: Select Test Case (Best-Effort Shortlist)
 
 For the selected use case(s):
 
 ### 6a: List existing test cases
 Call `muggle-remote-test-case-list-by-use-case` with each use case ID.
 
-### 6b: Present ALL test cases for user selection
+### 6b: Best-effort match against the change summary
 
-Use `AskQuestion` with `allow_multiple: true` to present all test cases as clickable options. Always include a "Generate new test case" option at the end.
+Using the change summary from Step 2, pick the test cases that look most relevant to the impacted areas. Keep the shortlist small and confident — don't enumerate every test case attached to the use case(s).
 
-Prompt: "Which test case(s) do you want to run?"
+If nothing looks like a confident match, fall back to offering to run all test cases for the selected use case(s), or ask the user what they had in mind.
 
-### 6c: Wait for explicit user selection
+### 6c: Present the shortlist for confirmation
 
-**CRITICAL: Do NOT auto-select test cases** — the user MUST explicitly choose which test case(s) to execute.
+Use `AskQuestion` with `allow_multiple: true`:
+
+Prompt: "These test cases look most relevant — confirm which to run:"
+
+- Pre-check the shortlisted items so the user can accept with one click
+- Include "Show all test cases" to reveal the full list
+- Include "Generate new test case" at the end
 
 ### 6d: If user chooses "Generate new test case"
-1. Ask the user to describe what they want to test in plain English
-2. Call `muggle-remote-test-case-generate-from-prompt`:
-   - `projectId`, `useCaseId`, `instruction` (the user's description)
-3. Present the generated test case(s) for review
-4. Call `muggle-remote-test-case-create` to save the ones the user approves
+1. Ask the user to describe what they want to test in plain English — they may want more than one test case
+2. For N descriptions, issue N `muggle-remote-test-case-generate-from-prompt` calls **in parallel** (single message, multiple tool calls — never loop sequentially):
+   - `projectId`, `useCaseId`, `instruction` (one description per call)
+   - Each `instruction` must describe **exactly one atomic behavior to verify**. No signup, no login, no "first navigate to X, then click Y, then verify Z" chains, no seed data, no cleanup. Just the verification. See **Test Case Design** above.
+3. **Accept the generator's decomposition as-is.** If the generator returns 4 micro-tests from a single prompt, that's 4 correct test cases — never merge, consolidate, or rewrite them to bundle bootstrap.
+4. Present the generated test case(s) for user review — **always do this review cycle**, even when you think you already know the right shape. Skipping straight to creation is the anti-pattern this skill most frequently gets wrong.
+5. For the ones the user approves, issue `muggle-remote-test-case-create` calls **in parallel**
 
 ### 6e: Confirm final selection
 
@@ -154,9 +186,7 @@ Wait for user confirmation before moving to execution.
 
 ## Step 7A: Execute — Local Mode
 
-### Pre-flight questions (batch where possible)
-
-**Question 1 — Local URL:**
+### Pre-flight question — Local URL
 
 Try to auto-detect the dev server URL by checking running terminals or common ports (e.g., `lsof -iTCP -sTCP:LISTEN -nP | grep -E ':(3000|3001|4200|5173|8080)'`). If a likely URL is found, present it as a clickable default via `AskQuestion`:
 - Option 1: "http://localhost:3000" (or whatever was detected)
@@ -164,38 +194,31 @@ Try to auto-detect the dev server URL by checking running terminals or common po
 
 If nothing detected, ask as free text: "Your local app should be running. What's the URL? (e.g., http://localhost:3000)"
 
-**Question 2 — Electron launch + window visibility (ask together):**
-
-After getting the URL, use a single `AskQuestion` call with two questions:
+**No separate approval or visibility question.** The user picking Local mode in Step 1 *is* the approval — do not ask "ready to launch Electron?" before every run. The Electron browser defaults to visible; if the user wants headless, they will say so, otherwise let it run visible.
 
-1. "Ready to launch the Muggle Electron browser for [N] test case(s)?"
-   - "Yes, launch it (visible — I want to watch)"
-   - "Yes, launch it (headless — run in background)"
-   - "No, cancel"
+### Fetch test case details (in parallel)
 
-If user cancels, stop and ask what they want to do instead.
+Before execution, fetch full test case details for all selected test cases by issuing **all** `muggle-remote-test-case-get` calls in parallel (single message, multiple tool calls).
 
-### Run sequentially
+### Run sequentially (Electron constraint)
 
-For each test case:
+Execution itself **must** be sequential because there is only one local Electron browser. For each test case, in order:
 
-1. Call `muggle-remote-test-case-get` to fetch full details
-2. Call `muggle-local-execute-test-generation`:
-   - `testCase`: Full test case object from step 1
-   - `localUrl`: User's local URL (from Question 1)
-   - `approveElectronAppLaunch`: `true` (only if user approved in Question 2)
-   - `showUi`: `true` if user chose "visible", `false` if "headless" (from Question 2)
-3. Store the returned `runId`
+1. Call `muggle-local-execute-test-generation`:
+   - `testCase`: Full test case object from the parallel fetch above
+   - `localUrl`: User's local URL from the pre-flight question
+   - `showUi`: omit (default visible) unless the user explicitly asked for headless, then pass `false`
+2. Store the returned `runId`
 
 If a generation fails, log it and continue to the next. Do not abort the batch.
 
-### Collect results
+### Collect results (in parallel)
 
-For each `runId`, call `muggle-local-run-result-get`. Extract: status, duration, step count, `artifactsDir`.
+For every `runId`, issue all `muggle-local-run-result-get` calls in parallel. Extract: status, duration, step count, `artifactsDir`.
 
-### Publish each run to cloud
+### Publish each run to cloud (in parallel)
 
-For each completed run, call `muggle-local-publish-test-script`:
+For every completed run, issue all `muggle-local-publish-test-script` calls in parallel (single message, multiple tool calls):
 - `runId`: The local run ID
 - `cloudTestCaseId`: The cloud test case ID
 
@@ -225,26 +248,29 @@ For failures: show which step failed, the local screenshot path, and a suggestio
 
 > "What's the preview/staging URL to test against?"
 
-### Trigger remote workflows
+### Fetch test case details (in parallel)
 
-For each test case:
+Issue all `muggle-remote-test-case-get` calls in parallel (single message, multiple tool calls) to hydrate the test case bodies.
 
-1. Call `muggle-remote-test-case-get` to fetch full details
-2. Call `muggle-remote-workflow-start-test-script-generation`:
-   - `projectId`: The project ID
-   - `useCaseId`: The use case ID
-   - `testCaseId`: The test case ID
-   - `name`: `"muggle-test: {test case title}"`
-   - `url`: The preview/staging URL
-   - `goal`: From the test case
-   - `precondition`: From the test case (use `"None"` if empty)
-   - `instructions`: From the test case
-   - `expectedResult`: From the test case
-3. Store the returned workflow runtime ID
+### Trigger remote workflows (in parallel)
+
+Once details are in hand, issue all `muggle-remote-workflow-start-test-script-generation` calls in parallel — never loop them sequentially. For each test case:
+
+- `projectId`: The project ID
+- `useCaseId`: The use case ID
+- `testCaseId`: The test case ID
+- `name`: `"muggle-test: {test case title}"`
+- `url`: The preview/staging URL
+- `goal`: From the test case
+- `precondition`: From the test case (use `"None"` if empty)
+- `instructions`: From the test case
+- `expectedResult`: From the test case
+
+Store each returned workflow runtime ID.
 
-### Monitor and report
+### Monitor and report (in parallel)
 
-For each workflow, call `muggle-remote-wf-get-ts-gen-latest-run` with the runtime ID.
+Issue all `muggle-remote-wf-get-ts-gen-latest-run` calls in parallel, one per runtime ID.
 
 ```
 Test Case                  Workflow Status   Runtime ID
@@ -287,12 +313,11 @@ After reporting results, ask the user if they want to attach a **visual walkthro
 
 The shared skill takes an **`E2eReport` JSON** that includes per-step screenshot URLs. You already have `projectId`, `testCaseId`, `runId`, `viewUrl`, and `status` from earlier steps — you still need the step-level data.
 
-For each published run from Step 7A:
+For the published runs from Step 7A, issue **all** `muggle-remote-test-script-get` calls in parallel (single message, multiple tool calls) — one per `testScriptId` returned by `muggle-local-publish-test-script`. Then, for each response:
 
-1. Call `muggle-remote-test-script-get` with the `testScriptId` returned by `muggle-local-publish-test-script`.
-2. Extract from the response: `steps[].operation.action` (description) and `steps[].operation.screenshotUrl` (cloud URL).
-3. Build a `steps` array: `[{ stepIndex: 0, action: "...", screenshotUrl: "..." }, ...]`.
-4. If the run failed, also capture `failureStepIndex`, `error`, and the local `artifactsDir` from `muggle-local-run-result-get`.
+1. Extract `steps[].operation.action` (description) and `steps[].operation.screenshotUrl` (cloud URL).
+2. Build a `steps` array: `[{ stepIndex: 0, action: "...", screenshotUrl: "..." }, ...]`.
+3. If the run failed, also capture `failureStepIndex`, `error`, and the local `artifactsDir` from `muggle-local-run-result-get`.
 
 Assemble the report:
 
@@ -364,11 +389,15 @@ This skill always uses **Mode A** (post to an existing PR); `muggle-do` is the o
 
 - **Always confirm intent first** — never assume local vs remote without asking
 - **User MUST select project** — present clickable options via `AskQuestion`, wait for explicit choice, never auto-select
-- **User MUST select use case(s)** — present clickable options via `AskQuestion`, wait for explicit choice, never auto-select based on git changes or heuristics
-- **User MUST select test case(s)** — present clickable options via `AskQuestion`, wait for explicit choice, never auto-select
+- **Best-effort shortlist use cases** — use the change summary to narrow the list to the most relevant 1–5 use cases and pre-check them; never dump every use case in the project on the user. Always leave an escape hatch to reveal the full list.
+- **Best-effort shortlist test cases** — same idea: pre-check the test cases most relevant to the change summary; never enumerate every test case attached to a use case. Always leave an escape hatch to reveal the full list.
 - **Use `AskQuestion` for every selection** — never ask the user to type a number; always present clickable options
-- **Batch related questions** — combine Electron approval + visibility into one question; auto-detect localhost URL when possible
-- **Never launch Electron without explicit user approval** (`approveElectronAppLaunch`)
+- **Auto-detect localhost URL when possible**; only fall back to free-text when nothing is listening on a common port
+- **Parallelize independent cloud jobs** — when creating N use cases, generating/creating N test cases, fetching N test case details, starting N remote workflows, polling N workflow runtimes, publishing N local runs, or fetching N per-step test scripts, issue all N calls in a single message so they fan out in parallel. The only tolerated sequential loop is local Electron execution (one browser, one test at a time). For use case creation specifically, use the native batch form of `muggle-remote-use-case-create-from-prompts` (all descriptions in one `instructions` array) instead of parallel calls.
+- **One atomic behavior per test case** — every test case verifies exactly one user-observable behavior. Never bundle signup/login/navigation/bootstrap/teardown into a test case body. Ordering and dependencies are Muggle's service responsibility, not the skill's.
+- **Never consolidate the generator's output** — if `muggle-remote-test-case-generate-from-prompt` returns N micro-tests, accept all N; never merge them into fewer test cases, even if "the plan" says 4 UC / 4 TC.
+- **Never skip the generate→review cycle** — always present generated test cases to the user before calling `muggle-remote-test-case-create`, even when you're confident. "I'll skip the review and create directly" is always wrong.
+- **Never ask for Electron launch approval before each run** — the user picking Local mode is the approval. Don't prompt "Ready to launch Electron?" before execution; just run.
 - **Never silently drop test cases** — log failures and continue, then report them
 - **Never guess the URL** — always ask the user for localhost or preview URL
 - **Always publish before opening browser** — the dashboard needs the published data to show results

package/plugin/skills/muggle-test-feature-local/SKILL.md

@@ -19,7 +19,7 @@ The local URL only changes where the browser opens; it does not change the remot
 
 **Every selection-based question MUST use the `AskQuestion` tool** (or the platform's equivalent structured selection tool). Never ask the user to "reply with a number" in a plain text message — always present clickable options.
 
-- **Selections** (project, use case, test case, script, approval): Use `AskQuestion` with labeled options the user can click.
+- **Selections** (project, use case, test case, script): Use `AskQuestion` with labeled options the user can click.
 - **Free-text inputs** (URLs, descriptions): Only use plain text prompts when there is no finite set of options. Even then, offer a detected/default value when possible.
 
 ## Workflow
@@ -27,7 +27,12 @@ The local URL only changes where the browser opens; it does not change the remot
 ### 1. Auth
 
 - `muggle-remote-auth-status`
-- If not signed in: `muggle-remote-auth-login` then `muggle-remote-auth-poll`
+- If **authenticated**: print the logged-in email and ask via `AskQuestion`:
+  > "You're logged in as **{email}**. Continue with this account?"
+  - Option 1: "Yes, continue"
+  - Option 2: "No, switch account"
+  If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true` then `muggle-remote-auth-poll`.
+- If **not signed in or expired**: call `muggle-remote-auth-login` then `muggle-remote-auth-poll`.
   Do not skip or assume auth.
 
 ### 2. Targets (user must confirm)
@@ -84,21 +89,21 @@ Remind them: local URL is only the execution target, not tied to cloud project c
 **Generate**
 
 1. `muggle-remote-test-case-get`
-2. `muggle-local-execute-test-generation` (after approval in step 6) with that test case + `localUrl` + `approveElectronAppLaunch: true` (optional: `showUi: true`, **`timeoutMs`** — see below)
+2. `muggle-local-execute-test-generation` with that test case + `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`timeoutMs`** — see below)
 
 **Replay**
 
 1. `muggle-remote-test-script-get` — note `actionScriptId`
 2. `muggle-remote-action-script-get` with that id — full `actionScript`
    **Use the API response as-is.** Do not edit, shorten, or rebuild `actionScript`; replay needs full `label` paths for element lookup.
-3. `muggle-local-execute-replay` (after approval in step 6) with `testScript`, `actionScript`, `localUrl`, `approveElectronAppLaunch: true` (optional: `showUi: true`, **`timeoutMs`** — see below)
+3. `muggle-local-execute-replay` with `testScript`, `actionScript`, `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`timeoutMs`** — see below)
 
 ### Local execution timeout (`timeoutMs`)
 
 The MCP client often uses a **default wait of 300000 ms (5 minutes)** for `muggle-local-execute-test-generation` and `muggle-local-execute-replay`. **Exploratory script generation** (Auth0 login, dashboards, multi-step wizards, many LLM iterations) routinely **runs longer than 5 minutes** while Electron is still healthy.
 
 - **Always pass `timeoutMs`** for flows that may be long — for example **`600000` (10 min)** or **`900000` (15 min)** — unless the user explicitly wants a short cap.
-- If the tool reports **`Electron execution timed out after 300000ms`** (or similar) **but** Electron logs show the run still progressing (steps, screenshots, LLM calls), treat it as **orchestration timeout**, not an Electron app defect: **increase `timeoutMs` and retry** (after user re-approves if your policy requires it).
+- If the tool reports **`Electron execution timed out after 300000ms`** (or similar) **but** Electron logs show the run still progressing (steps, screenshots, LLM calls), treat it as **orchestration timeout**, not an Electron app defect: **increase `timeoutMs` and retry**.
 - **Test case design:** Preconditions like "a test run has already completed" on an **empty account** can force many steps (sign-up, new project, crawl). Prefer an account/project that **already has** the needed state, or narrow the test goal so generation does not try to create a full project from scratch unless that is intentional.
 
 ### Interpreting `failed` / non-zero Electron exit
@@ -106,15 +111,9 @@ The MCP client often uses a **default wait of 300000 ms (5 minutes)** for `muggl
 - **`Electron execution timed out after 300000ms`:** Orchestration wait too short — see **`timeoutMs`** above.
 - **Exit code 26** (and messages like **LLM failed to generate / replay action script**): Often corresponds to a completed exploration whose **outcome was goal not achievable** (`goal_not_achievable`, summary with `halt`) — e.g. verifying "view script after a successful run" when **no run or script exists yet** in the UI. Use `muggle-local-run-result-get` and read the **summary / structured summary**; do not assume an Electron crash. **Fix:** choose a **project that already has** completed runs and scripts, or **change the test case** so preconditions match what localhost can satisfy (e.g. include steps to create and run a test first, or assert only empty-state UI when no runs exist).
 
-### 6. Approval before any local execution
+### 6. Execute (no approval prompt)
 
-Use `AskQuestion` to get explicit approval before launching Electron. State: replay vs generation, test case name, URL.
-
-- "Yes, launch Electron (visible — I want to watch)"
-- "Yes, launch Electron (headless — run in background)"
-- "No, cancel"
-
-Only call local execute tools with `approveElectronAppLaunch: true` after the user selects a "Yes" option. Map visible to `showUi: true`, headless to `showUi: false`.
+Call `muggle-local-execute-test-generation` or `muggle-local-execute-replay` directly. **Do not** ask the user to re-approve the Electron launch — the user choosing this skill in the first place is the approval. The browser defaults to visible; only pass `showUi: false` if the user explicitly asked for headless.
 
 ### 7. After successful generation only
 
@@ -177,10 +176,11 @@ Always use **Mode A** (post to existing PR) from this skill. Never hand-write th
 
 ## Non-negotiables
 
-- No silent auth skip; no launching Electron without approval via `AskQuestion`.
+- No silent auth skip.
+- **Never prompt for Electron launch approval** before execution — invoking this skill is the approval. Just run.
 - If replayable scripts exist, do not default to generation without user choice.
 - No hiding failures: surface errors and artifact paths.
 - Replay: never hand-built or simplified `actionScript` — only from `muggle-remote-action-script-get`.
-- Use `AskQuestion` for every selection — project, use case, test case, script, and approval. Never ask the user to type a number.
+- Use `AskQuestion` for every selection — project, use case, test case, script. Never ask the user to type a number.
 - Project, use case, and test case selection lists must always include "Create new ...". Include "Show full list" whenever the API returned at least one row for that step; omit "Show full list" when the list is empty (offer "Create new ..." only). For creates, use preview tools (`muggle-remote-use-case-prompt-preview`, `muggle-remote-test-case-generate-from-prompt`) before persisting.
 - PR posting is always optional and always delegated to the `muggle-pr-visual-walkthrough` skill — never inline the walkthrough markdown or call `gh pr comment` directly from this skill.

package/plugin/skills/muggle-test-import/SKILL.md

@@ -130,9 +130,12 @@ If the user wants changes, incorporate feedback, then ask again. Only proceed af
 
 Call `muggle-remote-auth-status` first.
 
-If already authenticated → skip to Step 5.
+If **already authenticated** → print the logged-in email and ask via `AskQuestion`:
+> "You're logged in as **{email}**. Continue with this account?"
+- Option 1: "Yes, continue" → skip to Step 5.
+- Option 2: "No, switch account" → call `muggle-remote-auth-login` with `forceNewSession: true`, then `muggle-remote-auth-poll`.
 
-If not authenticated:
+If **not authenticated**:
 1. Tell the user a browser window is about to open.
 2. Call `muggle-remote-auth-login` (opens browser automatically).
 3. Tell the user to complete login in the browser.

package/plugin/skills/muggle-test-regenerate-missing/SKILL.md

@@ -40,8 +40,13 @@ Treat this filter as a default, not a law. If the user explicitly says "include
 ### Step 1 — Authenticate
 
 1. Call `muggle-remote-auth-status`.
-2. If not authenticated or expired → call `muggle-remote-auth-login`, then poll with `muggle-remote-auth-poll`.
-3. Do not skip auth and do not assume a stale token still works.
+2. If **authenticated and not expired** → print the logged-in email and ask via `AskQuestion`:
+   > "You're logged in as **{email}**. Continue with this account?"
+   - Option 1: "Yes, continue"
+   - Option 2: "No, switch account"
+   If the user picks "switch account", call `muggle-remote-auth-login` with `forceNewSession: true`, then poll with `muggle-remote-auth-poll`.
+3. If **not authenticated or expired** → call `muggle-remote-auth-login`, then poll with `muggle-remote-auth-poll`.
+4. Do not skip auth and do not assume a stale token still works.
 
 If auth keeps failing, suggest the user run `muggle logout && muggle login` from a terminal.