@muggleai/works 4.9.2 → 4.10.1

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

@@ -5,6 +5,8 @@ description: "Make sure dev servers and sibling services are ready on the user's
 
 # Muggle Test Prepare
 
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-test-prepare"`.
+
 Make sure the local services a user needs for E2E acceptance testing are up and ready. Check what's already running, discover sibling service directories by folder name, and offer to start anything that's missing — always with the user in control.
 
 Some users start their own services (tmux scripts, docker-compose, a terminal per service). Others want help launching them. This skill handles both: it verifies readiness first, and only offers to start things when something is missing.
@@ -45,18 +47,30 @@ The `testing_scope` field records what the user is testing (from Step 1). The `e
 
 **On every invocation**, check this file first. If it exists with live PIDs (verify with `kill -0`), present the running services and ask:
 
-Use `AskQuestion`:
+Use `AskUserQuestion`:
 - Option 1: "Keep them running — skip to testing"
 - Option 2: "Tear down and start fresh"
 - Option 3: "Add more services to the running set"
 
 Prune any dead PIDs silently (the process crashed on its own — no point asking about it).
 
+## Preferences
+
+Gates run per [`preference-gates/README.md`](../muggle-preferences/preference-gates/README.md).
+
+| Preference | Step | Decision it gates |
+|------------|------|-------------------|
+| `autoRebase` | 0 | Rebase onto `origin/<default>` before starting dev servers (see [`_shared/rebase-before-e2e.md`](../_shared/rebase-before-e2e.md)) |
+
 ## Workflow
 
+### Step 0: Rebase check (gated by `autoRebase`)
+
+Fire per [`_shared/rebase-before-e2e.md`](../_shared/rebase-before-e2e.md) when `behind > 0`. Otherwise skip silently.
+
 ### Step 1: What Are You Testing?
 
-Before discovering services, understand the shape of the testing so you can scope correctly. Use `AskQuestion`:
+Before discovering services, understand the shape of the testing so you can scope correctly. Use `AskUserQuestion`:
 
 > "What are you testing locally?"
 
@@ -72,7 +86,7 @@ Some services can't run on a developer's machine by design — they need product
 
 **If the user already volunteered this information** in their initial message (e.g., "the payment-gateway can't run locally"), acknowledge it and skip the question — don't re-ask what they already answered.
 
-Otherwise, use `AskQuestion`:
+Otherwise, use `AskUserQuestion`:
 
 > "Are there any services in your stack that **can't** run locally? (e.g., needs production secrets, specific certificates, or cloud-only infra)"
 
@@ -98,7 +112,7 @@ Figure out which services need to be running. Start by listing folder names in t
 ls -d "$(dirname "$PWD")"/*/ | xargs -I{} basename {}
 ```
 
-Present folder names only (not contents) as candidates. Use `AskQuestion` with `multiSelect: true`:
+Present folder names only (not contents) as candidates. Use `AskUserQuestion` with `multiSelect: true`:
 
 > "Which of these need to be running for your tests?"
 
@@ -112,7 +126,7 @@ If the user provides manual paths, verify they exist before continuing. If a pat
 
 **Immediately after the user selects services**, ask how they want to handle startup. This avoids making someone who prefers their own scripts wait through command detection before they get to say "I'll handle it."
 
-Use `AskQuestion`:
+Use `AskUserQuestion`:
 
 > "How do you want to handle these?"
 
@@ -125,24 +139,53 @@ If the user picks **option 1**: proceed through Steps 4-7 as normal.
 
 ### Step 4: Check What's Already Running
 
-Before offering to start anything, check what's already listening on common dev ports:
-
-```bash
-lsof -iTCP -sTCP:LISTEN -nP 2>/dev/null | grep -E ':(3000|3001|3002|4200|5173|5174|8080|8081|8000|8888|4000|9000)'
-```
-
-Cross-reference against the selected service directories. If a selected service appears to already be running (match by port or by the process's working directory), report it as ready:
+Run port detection and (when the app declares a backend URL) backend-health probe per [`_shared/dev-server-readiness.md`](../_shared/dev-server-readiness.md). Cross-reference hits against the selected service directories. If a selected service appears to already be running (match by port or by the process's working directory), report it as ready:
 
 > "**backend-api** is already listening on port 3001 (PID 54321) — looks good."
 
 If **all** required services are already running, report readiness and skip straight to Step 7. No need to go through Steps 5-6.
 
-If some are running and some aren't, acknowledge the running ones and continue to Step 5 only for the missing services. Use `AskQuestion` for any already-running service the user might want restarted:
+If some are running and some aren't, acknowledge the running ones and continue to Step 5 only for the missing services. Use `AskUserQuestion` for any already-running service the user might want restarted:
 - Option 1: "It's fine, keep it"
 - Option 2: "Restart it"
 
 For services that are already running and the user wants to keep, add them to the PID tracking file so cleanup can find them later, but mark them as `external: true` so cleanup knows not to kill them (the user started them independently).
 
+**Port already held** — when the user wants a port that is currently held by a process they did **not** select (typically a stale dev server from a sibling worktree). Surface the conflict via `AskUserQuestion`:
+
+> "Port 3999 is held by PID 87421 (you didn't select this process). How do you want to proceed?"
+
+- Option 1: "Use the next available port" (recommended — non-destructive)
+- Option 2: "Force-kill PID 87421 and claim port 3999"
+- Option 3: "Abort"
+
+**Option 1 — next available port:** probe `3999 + N` for `N = 1, 2, 3, ...` until `Test-NetConnection`/`lsof -i :<port>` returns nothing listening. Record the new port (and the env file edit, if `PORT=` is set in `.env.local` etc.) so downstream steps use it. The dev server may need a restart to pick up the new value.
+
+**Option 2 — force-kill (destructive):**
+- **Windows PowerShell:** `Get-NetTCPConnection -LocalPort <port> -ErrorAction SilentlyContinue | ForEach-Object { try { Stop-Process -Id $_.OwningProcess -Force -ErrorAction SilentlyContinue } catch { } }`
+- **POSIX:** `lsof -ti:<port> 2>/dev/null | xargs -r kill -9`
+
+Re-verify the port is free before continuing.
+
+### Step 4.5: Environment File Sanity
+
+The env file is **per-repo** — don't hardcode `.env.local`. Detect it: scan `package.json` `scripts/*` for `.env*` literals and known port vars (`PORT=`, `VITE_PORT=`); check framework config (`next.config.*`, `vite.config.*`).
+
+When a dependency on an env file exists:
+
+1. Check whether `<cwd>/<envfile>` exists. If yes, no-op.
+2. If absent, `git worktree list --porcelain` and check each sibling for the same filename.
+3. If found, surface via `AskUserQuestion`:
+
+   > "`<envfile>` is missing in this worktree but exists at `<sibling>/<envfile>`. Copy it before starting services?"
+
+   - Option 1: "Yes — copy from `<sibling>`"
+   - Option 2: "No — I'll provide it another way"
+
+4. If not found anywhere, report and ask how to proceed.
+
+Skip silently when no env file is referenced. The point is to catch the common worktree-bootstrap miss, not to mandate any specific file.
+
 ### Step 5: Determine Start Commands
 
 For each required service that isn't already running, figure out how to start it. Propose the command so there's a shared understanding.
@@ -174,12 +217,33 @@ frontend             ~/Github/frontend                  npm run dev
 ────────────────────────────────────────────────────────────────
 ```
 
-Use `AskQuestion`:
+Use `AskUserQuestion`:
 - Option 1: "Looks good, start them"
 - Option 2: "I need to edit some commands"
 
 If the user needs edits, collect corrections and re-present.
 
+### Step 5.5: Fresh-Worktree Install Probe
+
+Before launching `npm run dev` (or equivalent) in a Node service, check whether `node_modules/` is present and current. Stale or missing `node_modules/` causes silent runtime failures that look like the service is broken when actually the install is just missing.
+
+For each Node service the user selected:
+
+1. If `<service-dir>/node_modules/` is missing entirely → install is required.
+2. If `<service-dir>/package-lock.json` is newer than `<service-dir>/node_modules/.package-lock.json` → install is stale.
+3. Otherwise → install is current, no action needed.
+
+When install is required or stale, propose via `AskUserQuestion`:
+
+> "`<service-name>` needs a fresh `npm install` before starting (node_modules is missing/stale). Run `npm install --prefer-offline --no-audit --no-fund` now?"
+
+- Option 1: "Yes — install now"
+- Option 2: "No — skip; I know it's fine"
+
+**Never symlink `node_modules/` from a sibling worktree.** webpack's `resolve.symlinks: true` default rewrites paths to the shared real location; asset-identity tracking fails with `Can't handle conflicting asset info for sourceFilename`. Run a real per-worktree install.
+
+For non-Node services (Go, Rust, Python), skip this probe — their build systems handle dependency caching differently.
+
 ### Step 6: Start Services
 
 For each service, launch in the background:
@@ -191,10 +255,7 @@ echo $!
 
 Capture the PID. Write all service entries to `/tmp/muggle-test-prepare.json`.
 
-**Startup verification** — after a short pause (~3-5 seconds per service), check:
-
-1. PID is alive: `kill -0 <pid> 2>/dev/null`
-2. Port is listening (if known): `lsof -iTCP:<port> -sTCP:LISTEN -nP 2>/dev/null`
+**Startup verification** — first confirm the PID is alive (`kill -0 <pid> 2>/dev/null`), then run the two-stage readiness probe per [`_shared/dev-server-readiness.md`](../_shared/dev-server-readiness.md) against `/tmp/muggle-prepare-<service-name>.log`. Cap log-tail at 60s. Halt on whatever it surfaces; do not re-implement the ready-signal patterns here.
 
 If a service's PID dies immediately, read the last 20 lines of its log and show the user:
 

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

@@ -1,35 +1,28 @@
 ---
 name: muggle-test-regenerate-missing
-description: "Bulk-regenerate test scripts for every test case in a Muggle AI project that doesn't currently have an active script. Scans the project, finds test cases stuck in DRAFT or GENERATION_PENDING (no usable script attached), shows the user the list, and on approval kicks off bulk remote test script generation via the Muggle cloud. Use this skill whenever the user asks to 'regenerate missing scripts', 'fill in missing test scripts', 'generate scripts for test cases without one', 'regen all the test cases that don't have scripts', 'rebuild scripts for stale test cases', 'fix test cases with no script', 'bulk regenerate', or any phrasing that means 'kick off script generation across a project for the cases that need it'. Triggers on: 'regenerate missing test scripts', 'generate scripts for all empty test cases', 'fill the gaps in my test scripts', 'bulk test script regen', 'all my test cases without active scripts'. This is the go-to skill for project-wide script catch-up — it handles discovery, filtering, confirmation, and remote workflow dispatch end-to-end."
+description: "Bulk-regenerate test scripts for every test case in a Muggle AI project that doesn't currently have an active script. Scans the project, finds test cases stuck in DRAFT or GENERATION_PENDING (no usable script attached), shows the user the list, and on approval kicks off bulk remote test script generation via the Muggle Test cloud. Use this skill whenever the user asks to 'regenerate missing scripts', 'fill in missing test scripts', 'generate scripts for test cases without one', 'regen all the test cases that don't have scripts', 'rebuild scripts for stale test cases', 'fix test cases with no script', 'bulk regenerate', or any phrasing that means 'kick off script generation across a project for the cases that need it'. Triggers on: 'regenerate missing test scripts', 'generate scripts for all empty test cases', 'fill the gaps in my test scripts', 'bulk test script regen', 'all my test cases without active scripts'. This is the go-to skill for project-wide script catch-up — it handles discovery, filtering, confirmation, and remote workflow dispatch end-to-end."
 ---
 
 # Muggle Test — Regenerate Missing Test Scripts
 
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-test-regenerate-missing"`.
+
 A bulk maintenance skill for Muggle AI projects. It finds every test case in a project that does **not** currently have an active (ready-to-run) test script, shows the list to the user, and on approval triggers a remote test script generation workflow for each one. Useful after creating a batch of new test cases or when cleaning up a project that has drifted.
 
-Execution is **remote only** — Muggle's cloud generates the scripts in parallel against the project URL. The user's machine is not involved beyond making API calls.
+Execution is **remote only** — Muggle Test's cloud generates the scripts in parallel against the project URL. The user's machine is not involved beyond making API calls.
 
 ## Preferences
 
-User preferences are available in the session context (injected at session start). Look for the line starting with `Muggle Preferences` — it contains key=value pairs like `autoLogin=ask showElectronBrowser=always ...`.
-
-If no preferences line is present, treat all preferences as `"ask"`.
-
-When you reach a decision gated by a preference:
-- **`always`** → proceed without asking the user
-- **`never`** → skip without asking the user  
-- **`ask`** → ask the user, then offer: "Want me to remember this choice for future sessions?" If yes, call `muggle-local-preferences-set` with the key, their chosen value, and scope `global`.
+Gates run per `preference-gates/README.md`.
 
-This skill uses these preferences:
-
-| Preference | Decision it gates |
-|------------|------------------|
-| `autoLogin` | Reuse saved credentials when auth is required |
-| `autoSelectProject` | Reuse last-used Muggle project for this repo |
+| Preference | Step | Decision it gates |
+|------------|------|-------------------|
+| `autoLogin` | 1 | Reuse saved credentials when auth is required |
+| `autoSelectProject` | 2 | Reuse last-used Muggle Test project for this repo |
 
 ## Concept: what counts as "no active script"
 
-In the Muggle data model, a test case carries a status that reflects whether it has a usable script attached:
+In the Muggle Test data model, a test case carries a status that reflects whether it has a usable script attached:
 
 | Status | Meaning | Regenerate? |
 |:-------|:--------|:-----------:|
@@ -47,33 +40,41 @@ Treat this filter as a default, not a law. If the user explicitly says "include
 
 ## UX Guidelines — Minimize Typing
 
-**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" — always present clickable options.
+**Every selection-based question MUST use the `AskUserQuestion` tool** (or the platform's equivalent structured selection tool). Never ask the user to "reply with a number" — always present clickable options.
 
-- **Selections** (project, which test cases to include): Use `AskQuestion`, with `allow_multiple: true` for the test case picker.
+- **Selections** (project, which test cases to include): Use `AskUserQuestion`, with `allow_multiple: true` for the test case picker.
 - **Free-text inputs** (project URL when creating, override filters): Only ask as plain text when the option set isn't finite.
 - **Batch related questions** when independent. Don't ask sequentially what could be one screen.
 
 ## Workflow
 
-### Step 1 — Authenticate
+### Step 1 — Authenticate (gated by `autoLogin`)
 
 1. Call `muggle-remote-auth-status`.
-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`.
+2. If **authenticated and not expired** → gate `autoLogin` (per `preference-gates/README.md`):
+   - `always` → proceed with saved session.
+   - `never` → `muggle-remote-auth-login` with `forceNewSession: true`, then `muggle-remote-auth-poll`.
+   - `ask` → run Picker 1 from `preference-gates/autoLogin.md` via `AskUserQuestion`; map the answer back to one of the actions above.
 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.
 
-### Step 2 — Select Project (user must choose)
+### Step 2 — Select Project (gated by `autoSelectProject`)
 
 A **project** is the unit on the Muggle AI dashboard that groups test cases, scripts, and runs. The user must pick the one to scan — never auto-select from repo name, branch, or URL heuristics.
 
-1. Call `muggle-remote-project-list`.
-2. Use `AskQuestion` to present projects as clickable options. Include the project URL in each label so the user can disambiguate. Always include "Create new project" as the last option.
+The per-repo project cache lives at `<cwd>/.muggle-ai/last-project.json` (via the `muggle-local-last-project-get` / `muggle-local-last-project-set` MCP tools). Look for `Muggle Test Last Project: id=… url=… name="…"` in session context.
+
+Gate `autoSelectProject` (per `preference-gates/README.md`). Cache: `Muggle Test Last Project` session line.
+- `always` + cache → use cached `projectId`, proceed to Step 3. No cache → fall through to `ask`.
+- `never` → full project list; skip Picker 2.
+- `ask` → project list picker (see gate file for spec + Picker 2 override). Skip Picker 2 if "Create new project".
+
+### Logic
+
+1. Call `muggle-remote-project-list` (only when not satisfied by the `always` cache).
+2. Use `AskUserQuestion` to present projects as clickable options. Include the project URL in each label so the user can disambiguate. Always include "Create new project" as the last option.
 3. Wait for explicit selection.
 4. If the user picks "Create new project": collect `projectName`, `description`, and `url`, then call `muggle-remote-project-create`.
 
@@ -109,7 +110,7 @@ If after filtering the list is empty, congratulate the user — every test case
 
 ### Step 5 — Present and Confirm Selection
 
-Use `AskQuestion` with `allow_multiple: true` to present every candidate test case as a clickable option. The user must explicitly approve which ones to regenerate.
+Use `AskUserQuestion` with `allow_multiple: true` to present every candidate test case as a clickable option. The user must explicitly approve which ones to regenerate.
 
 For each option label, show enough context for the user to make a real decision:
 
@@ -122,12 +123,12 @@ For example:
 - `[GENERATION_PENDING] Add item to cart — use case: Checkout Flow`
 
 Default behavior:
-- If there are **≤ 25** candidates, present all of them in a single `AskQuestion` with everything pre-checked and let the user deselect anything they want to skip.
+- If there are **≤ 25** candidates, present all of them in a single `AskUserQuestion` with everything pre-checked and let the user deselect anything they want to skip.
 - If there are **> 25** candidates, show the first 25 ranked by status priority (`DRAFT` → `GENERATION_PENDING`), plus a tail option **"Include all N — don't make me click each one"**. The user can also pick "Show next batch" to see more.
 
-After selection, call `AskQuestion` once more for a final confirmation:
+After selection, call `AskUserQuestion` once more for a final confirmation:
 
-> "About to start remote test script generation for **N** test cases against `<projectUrl>`. This will consume Muggle workflow budget. Proceed?"
+> "About to start remote test script generation for **N** test cases against `<projectUrl>`. This will consume Muggle Test workflow budget. Proceed?"
 >
 > - "Yes, start all N"
 > - "No, cancel"
@@ -164,6 +165,19 @@ Total: 17 dispatched | 16 started | 1 failed
 
 For failures: include a one-line error excerpt from the item's error field and (where possible) a hint at the cause (e.g., "missing instructions field — edit the test case in the dashboard, then re-run this skill").
 
+### Per-item failure routing (regen)
+
+For every item with a non-success dispatch status, follow [`_shared/failure-mode-handling.md`](../_shared/failure-mode-handling.md) section C (regen failure buckets: `transient` / `infra` / `agent-course` / `product-uxux`).
+
+Because this skill is bulk-dispatch (no live user attention per item), batch the routing — don't ask the user per item:
+
+1. Group failed items by AI-classified bucket using the signal heuristics in the shared doc (most failures here will be `transient` or `infra` since dispatch failures rarely surface product-uxux signals).
+2. Emit one `regen-failure-classified` event per failed item via `muggle-local-telemetry-event-emit`.
+3. Present the buckets to the user via a single `AskUserQuestion` summarizing counts: e.g., "12 transient (recommend retry), 3 infra (recommend report-bug). What do you want to do?" Options: "Retry transient items", "Report all to Muggle AI", "muggle-feedback for selected items", "Skip — leave them as-is".
+4. Emit one `regen-failure-resolved` event per item with the user's batch decision applied.
+
+Bulk regen does not run replays, so the section B (replay) router does not apply here.
+
 ### Step 8 — Open the Dashboard
 
 Open the Muggle AI dashboard so the user can watch progress visually:
@@ -202,11 +216,11 @@ Add item to cart         rt-ghi789   COMPLETED   12
 
 ## Non-negotiables
 
-- **The user MUST select the project** — present projects via `AskQuestion`, never infer from cwd, repo name, or URL guesses.
-- **The user MUST approve which test cases to regenerate** — show the candidates via `AskQuestion`, let them deselect, then confirm again before any dispatch. Bulk-regenerating without approval can waste meaningful workflow budget.
+- **The user MUST select the project** — present projects via `AskUserQuestion`, never infer from cwd, repo name, or URL guesses.
+- **The user MUST approve which test cases to regenerate** — show the candidates via `AskUserQuestion`, let them deselect, then confirm again before any dispatch. Bulk-regenerating without approval can waste meaningful workflow budget.
 - **Default filter is `DRAFT` + `GENERATION_PENDING`** — never include `GENERATING`, `ACTIVE`, `DEPRECATED`, `ARCHIVED`, `REPLAYING`, or `REPLAY_PENDING` unless the user explicitly says so. `GENERATING` already has a workflow in flight and dispatching another races against it. `ACTIVE` test cases already have working scripts. The rest reflect deliberate user decisions or in-flight replays the skill should not interfere with.
 - **Use the bulk endpoint for dispatch** — call `muggle-remote-workflow-start-test-script-generation-bulk` once with all selected test case IDs rather than dispatching one-by-one. The backend resolves full test case details internally.
 - **Failures don't abort the batch** — the bulk API returns per-item status. Surface failures in the report. Partial progress beats no progress.
 - **Open the dashboard, don't poll by default** — the runs page is the canonical view of progress. Only poll if the user explicitly asks.
-- **Use `AskQuestion` for every selection** — never ask the user to type a number.
+- **Use `AskUserQuestion` for every selection** — never ask the user to type a number.
 - **Can be invoked at any state** — if the user already has a project chosen in conversation context, skip Step 2 and go straight to scanning.

package/dist/plugin/skills/muggle-test-regenerate-missing/evals/evals.json

@@ -1,6 +1,6 @@
 {
   "skill_name": "muggle-test-regenerate-missing",
-  "notes": "These evals test the PLAN behavior. Because Muggle MCP tools require live auth and a real project, the subagents can't actually execute the workflow — each prompt tells them to write a step-by-step plan instead. The assertions check whether the plan reflects the skill's non-negotiables (correct filter, AskQuestion-based selection, no auto-select, dispatch via the remote workflow tool, batch-failure tolerance, dashboard open-at-end).",
+  "notes": "These evals test the PLAN behavior. Because Muggle MCP tools require live auth and a real project, the subagents can't actually execute the workflow — each prompt tells them to write a step-by-step plan instead. The assertions check whether the plan reflects the skill's non-negotiables (correct filter, AskUserQuestion-based selection, no auto-select, dispatch via the remote workflow tool, batch-failure tolerance, dashboard open-at-end).",
   "evals": [
     {
       "id": 0,
@@ -9,13 +9,13 @@
       "files": [],
       "assertions": [
         { "name": "calls_auth_status_first", "text": "Plan starts by calling muggle-remote-auth-status (and login/poll if needed) before any other Muggle tool." },
-        { "name": "project_selection_via_AskQuestion", "text": "Plan calls muggle-remote-project-list and presents projects via AskQuestion rather than auto-selecting 'Acme Checkout QA' by name match." },
+        { "name": "project_selection_via_AskQuestion", "text": "Plan calls muggle-remote-project-list and presents projects via AskUserQuestion rather than auto-selecting 'Acme Checkout QA' by name match." },
         { "name": "default_filter_is_draft_and_generation_pending", "text": "Plan states that the status filter is DRAFT + GENERATION_PENDING and explicitly excludes GENERATING, ACTIVE, DEPRECATED, ARCHIVED, REPLAYING, and REPLAY_PENDING." },
         { "name": "uses_test_case_list_paginated", "text": "Plan calls muggle-remote-test-case-list with pagination (or equivalent full-enumeration) for the project scan step." },
         { "name": "test_case_get_before_dispatch", "text": "Plan calls muggle-remote-test-case-get for each candidate before dispatching generation, to obtain the full payload (goal, precondition, instructions, expectedResult, url)." },
         { "name": "dispatch_via_remote_workflow_tool", "text": "Plan dispatches each regeneration via muggle-remote-workflow-start-test-script-generation (not a local Electron tool)." },
-        { "name": "candidate_list_via_AskQuestion_multi_select", "text": "Plan presents the candidate test cases via AskQuestion with multi-select (allow_multiple: true) so the user can deselect individuals." },
-        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no confirmation AskQuestion before any dispatch, showing the count of test cases about to be regenerated." },
+        { "name": "candidate_list_via_AskQuestion_multi_select", "text": "Plan presents the candidate test cases via AskUserQuestion with multi-select (allow_multiple: true) so the user can deselect individuals." },
+        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no confirmation AskUserQuestion before any dispatch, showing the count of test cases about to be regenerated." },
         { "name": "batch_failure_tolerance", "text": "Plan explicitly states that a single dispatch failure does not abort the batch — failures are logged and the loop continues." },
         { "name": "opens_dashboard_runs_page_at_end", "text": "Plan ends by opening the Muggle dashboard project runs page for the user to watch progress." }
       ]
@@ -27,12 +27,12 @@
       "files": [],
       "assertions": [
         { "name": "calls_auth_status_first", "text": "Plan starts by calling muggle-remote-auth-status before any other Muggle tool." },
-        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskQuestion to let the user confirm project choice; does not auto-select 'Tanka Staging' by name match alone." },
+        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskUserQuestion to let the user confirm project choice; does not auto-select 'Tanka Staging' by name match alone." },
         { "name": "honors_override_to_include_generating", "text": "Plan explicitly honors the user's override and includes GENERATING in the filter for this run, noting that this is a deliberate override of the default filter." },
         { "name": "still_excludes_active_deprecated_archived", "text": "Even with the override, the plan still excludes ACTIVE, DEPRECATED, ARCHIVED, REPLAY_PENDING, and REPLAYING — it only widens the filter to include GENERATING, not everything." },
         { "name": "handles_large_candidate_list", "text": "Plan acknowledges that with ~200 test cases the candidate list may exceed 25 and describes paging or bulk-include handling (e.g., 'Include all N' tail option)." },
         { "name": "dispatch_via_remote_workflow_tool", "text": "Plan dispatches each regeneration via muggle-remote-workflow-start-test-script-generation." },
-        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskQuestion confirmation before any dispatch, showing the total count." },
+        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskUserQuestion confirmation before any dispatch, showing the total count." },
         { "name": "batch_failure_tolerance", "text": "Plan states that a single dispatch failure does not abort the batch." },
         { "name": "opens_dashboard_runs_page_at_end", "text": "Plan ends by opening the Muggle dashboard project runs page." }
       ]
@@ -44,12 +44,12 @@
       "files": [],
       "assertions": [
         { "name": "calls_auth_status_first", "text": "Plan starts by calling muggle-remote-auth-status before any other Muggle tool." },
-        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskQuestion to let the user pick the project — does not infer it." },
+        { "name": "project_selection_via_AskQuestion", "text": "Plan uses AskUserQuestion to let the user pick the project — does not infer it." },
         { "name": "default_filter_is_draft_and_generation_pending", "text": "Plan states that the status filter is DRAFT + GENERATION_PENDING by default." },
-        { "name": "small_list_all_preselected", "text": "Plan describes presenting all candidates in a single AskQuestion with everything pre-checked (since the candidate list is ≤ 25)." },
+        { "name": "small_list_all_preselected", "text": "Plan describes presenting all candidates in a single AskUserQuestion with everything pre-checked (since the candidate list is ≤ 25)." },
         { "name": "test_case_get_before_dispatch", "text": "Plan calls muggle-remote-test-case-get for each candidate before dispatching generation." },
         { "name": "dispatch_via_remote_workflow_tool", "text": "Plan dispatches each regeneration via muggle-remote-workflow-start-test-script-generation." },
-        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskQuestion confirmation before any dispatch." },
+        { "name": "final_confirmation_step", "text": "Plan includes a final yes/no AskUserQuestion confirmation before any dispatch." },
         { "name": "batch_failure_tolerance", "text": "Plan states that a single dispatch failure does not abort the batch." },
         { "name": "opens_dashboard_runs_page_at_end", "text": "Plan ends by opening the Muggle dashboard project runs page." }
       ]

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

@@ -1,9 +1,11 @@
 ---
 name: muggle-upgrade
-description: Update Muggle AI to latest version. Use when user types muggle upgrade or asks to update Muggle tools.
+description: Update Muggle AI to latest version. Use when user types muggle upgrade or asks to update Muggle Test tools.
 ---
 
-# Muggle Upgrade
+# Muggle Test Upgrade
+
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-upgrade"`.
 
 Update all Muggle AI components to the latest published version. This means **both** the `@muggleai/works` CLI on npm **and** the Electron runner the CLI manages.
 

package/dist/plugin/skills/muggle-works-npm-release/SKILL.md

@@ -1,13 +1,15 @@
 ---
 name: muggle-works-npm-release
 description: >-
-  Cut @muggleai/works release: AskQuestion (major/minor/patch), sync master, stop if
+  Cut @muggleai/works release: AskUserQuestion (major/minor/patch), sync master, stop if
   nothing ships, semver baseline + Electron from GitHub, confirm plan, bump
   package.json + sync:versions, full local verify, chore(release) PR, merge via gh,
   dispatch publish-works-to-npm.yml—no local npm publish.
 ---
 
-# Muggle Works — npm release (single playbook)
+# Muggle Test Works — npm release (single playbook)
+
+> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-works-npm-release"`.
 
 Repo: **`multiplex-ai/muggle-ai-works`**. Workflow: **`.github/workflows/publish-works-to-npm.yml`** (“Publish Works to npm”). **Never** run local **`npm publish`** (OIDC trusted publishing in CI).
 
@@ -17,7 +19,7 @@ Repo: **`multiplex-ai/muggle-ai-works`**. Workflow: **`.github/workflows/publish
 
 **Stop until the user answers.**
 
-**Prefer `AskQuestion`** with exactly these three options: **major**, **minor**, **patch** (fix). If the environment has no structured question tool, ask the same in plain text:
+**Prefer `AskUserQuestion`** with exactly these three options: **major**, **minor**, **patch** (fix). If the environment has no structured question tool, ask the same in plain text:
 
 > Is this release a **major**, **minor**, or **patch** (fix)?
 
@@ -185,7 +187,7 @@ Give the user the **Actions run URL**. If npm lags, wait ~60s and retry.
 ## Rules
 
 - **No local `npm publish`.**
-- **Phase 1:** use **`AskQuestion`** for major / minor / patch when available (see Phase 1).
+- **Phase 1:** use **`AskUserQuestion`** for major / minor / patch when available (see Phase 1).
 - Phases 1–3: keep chat concise; Phase 4–5 can be terse status lines.
 - If the user cancels after Phase 3, **do not** merge or dispatch CI.
 - **Tag vs npm:** **`v*`** tags are for the **npm** package; **`electron-app-v*`** is separate — **`electronAppVersion`** can move independently of **`version`**.

package/dist/plugin/skills/mupgrade/SKILL.md

@@ -0,0 +1,8 @@
+---
+name: mupgrade
+description: Explicit short alias for the `muggle-upgrade` skill. ONLY invoke when the user explicitly types `mupgrade` or `/mupgrade` — never auto-trigger from any other phrasing.
+---
+
+# mupgrade — alias for muggle-upgrade
+
+Invoke the `muggle-upgrade` skill via the Skill tool. Forward any user-provided arguments unchanged.

package/dist/release-manifest.json

@@ -1,7 +1,7 @@
 {
-  "release": "4.9.2",
-  "buildId": "run-27-1",
-  "commitSha": "d8e6156d74d5da6c7d5442ddfa365ec1c8f8f9d0",
-  "buildTime": "2026-04-21T18:36:08Z",
+  "release": "4.10.1",
+  "buildId": "run-32-1",
+  "commitSha": "8be7ac283bd1924e1d2e2df90f214a40d85a3038",
+  "buildTime": "2026-05-13T18:34:37Z",
   "serviceName": "muggle-ai-works-mcp"
 }

package/dist/src-2G7ENRGI.js

@@ -0,0 +1 @@
+export { DEFAULT_PREFERENCES, PREFERENCES_FILE_NAME, PREFERENCES_PROJECT_DIR_NAME, PREFERENCES_SCHEMA, PREFERENCES_VERSION, PREFERENCE_ALLOWED_VALUES, PreferenceKey, PreferenceValue, buildElectronAppChecksumsUrl, buildElectronAppReleaseAssetUrl, buildElectronAppReleaseTag, calculateFileChecksum, createApiKeyWithToken, createChildLogger, deleteApiKeyData, deleteCredentials, e2e_exports as e2e, formatPreferencesOneLiner, getApiKey, getApiKeyFilePath, getAuthService, getBundledElectronAppVersion, getCallerCredentials, getCallerCredentialsAsync, getChecksumForPlatform, getConfig, getCredentialsFilePath, getDataDir, getDownloadBaseUrl, getElectronAppChecksums, getElectronAppDir, getElectronAppVersion, getElectronAppVersionSource, getLocalQaTools, getLogger, getPlatformKey, getQaTools, getValidApiKeyData, getValidCredentials, hasApiKey, isElectronAppInstalled, isFirstRun, loadApiKeyData, loadCredentials, local_exports as localQa, mcp_exports as mcp, openBrowserUrl, performLogin, performLogout, pollDeviceCode, e2e_exports as qa, readGlobalPreferences, readProjectPreferences, resetConfig, resetLogger, resetPreference, resolveElectronAppPathOrNull, resolvePreferences, saveApiKey, saveApiKeyData, saveCredentials, startDeviceCodeFlow, toolRequiresAuth, validatePreference, verifyFileChecksum, writePreferences } from './chunk-ZKRHFTIC.js';

package/package.json

@@ -1,7 +1,7 @@
 {
     "name": "@muggleai/works",
     "mcpName": "io.github.multiplex-ai/muggle",
-    "version": "4.9.2",
+    "version": "4.10.1",
     "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",
@@ -16,7 +16,7 @@
     ],
     "scripts": {
         "clean": "rimraf dist",
-        "build": "tsup && node scripts/write-release-manifest.mjs && node scripts/sync-versions.mjs && node scripts/build-plugin.mjs",
+        "build": "tsup && node scripts/strip-telemetry-comments.mjs && node scripts/write-release-manifest.mjs && node scripts/sync-versions.mjs && node scripts/build-plugin.mjs",
         "build:plugin": "node scripts/build-plugin.mjs",
         "sync:versions": "node scripts/sync-versions.mjs",
         "build:release": "npm run build",
@@ -41,29 +41,31 @@
         "test:watch": "vitest"
     },
     "muggleConfig": {
-        "electronAppVersion": "1.0.61",
+        "electronAppVersion": "1.0.82",
         "downloadBaseUrl": "https://github.com/multiplex-ai/muggle-ai-works/releases/download",
         "runtimeTargetDefault": "production",
         "checksums": {
-            "darwin-arm64": "987d2957052adb3b1db9deef4febcf4e0c7649ee17aa5cf2822a048c29c28ee8",
-            "darwin-x64": "a713179a51c149a97958fa1c3411789161780c2267b083c0b974e59a8159d82a",
-            "win32-x64": "bc4ddf090239a77f34a34bc42c4849ae1e0a0e797052affe4346b0733e8ea216",
-            "linux-x64": "f64357e258a28eb080df65dd84439fcc72a840c3de5de8f51cba92184dcacdad"
+            "darwin-arm64": "ceab8a6ea1982cff9385896d392519ef2b5545d3f99e1409eec247e888334b02",
+            "darwin-x64": "423b23d98a2858c7e4d203133aab586bbc5014b7cd50a4aa7125803ccaf7deed",
+            "win32-x64": "c231ae9ae512ab97d3ee7980309a807c31b9d8033daab47c50bc1d6f4c112e4f",
+            "linux-x64": "0dd15add46ca7bed5ad8e4d4cb751c63506b9dbb2eec294d9039426baeba8c32"
         }
     },
     "dependencies": {
         "@modelcontextprotocol/sdk": "^1.25.3",
         "@muggleai/mcp": "file:packages/mcps",
         "@muggleai/workflows": "file:packages/workflows",
+        "applicationinsights": "^3.14.0",
         "axios": "^1.7.9",
         "commander": "^14.0.3",
         "open": "^11.0.0",
         "ulid": "^3.0.2",
-        "uuid": "^13.0.0",
+        "uuid": "^14.0.0",
         "winston": "^3.17.0",
         "zod": "^4.3.6"
     },
     "devDependencies": {
+        "@anthropic-ai/claude-agent-sdk": "^0.2.133",
         "@eslint/js": "^10.0.1",
         "@types/node": "^25.5.2",
         "@types/uuid": "^11.0.0",

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.9.2",
+  "version": "4.10.1",
   "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.9.2",
+  "version": "4.10.1",
   "author": {
     "name": "Muggle AI",
     "email": "support@muggle-ai.com"

package/plugin/README.md

@@ -15,7 +15,7 @@ For npm installs:
 npm install -g @muggleai/works
 ```
 
-This updates the CLI, configures Cursor MCP (`~/.cursor/mcp.json`), and syncs `muggle-*` skills into `~/.cursor/skills/`. Claude slash commands remain plugin-managed, so use `/plugin update muggleai@muggle-works` to refresh them.
+This updates the CLI, configures Cursor MCP (`~/.cursor/mcp.json`), and syncs `muggle-*` skills (plus their short `m*` aliases) into `~/.cursor/skills/`. Claude slash commands remain plugin-managed, so use `/plugin update muggleai@muggle-works` to refresh them.
 
 ## Skills
 
@@ -23,7 +23,7 @@ Type `muggle` to discover the full command family.
 
 | Skill | What it does |
 |:---|:---|
-| `/muggle:muggle` | Router and menu for all Muggle commands. |
+| `/muggle:muggle` | Router and menu for all Muggle Test commands. |
 | `/muggle:muggle-do` | Autonomous dev pipeline: requirements, code, unit tests, E2E acceptance tests, PR. |
 | `/muggle:muggle-test` | Change-driven E2E acceptance router: detects code changes, maps to use cases, runs test generation locally or remotely, publishes to dashboard, opens in browser, posts E2E acceptance results to PR. |
 | `/muggle:muggle-test-feature-local` | Test a feature on localhost with AI-driven browser automation. Offers publish to cloud after each run. |
@@ -33,6 +33,8 @@ Type `muggle` to discover the full command family.
 | `/muggle:muggle-repair` | Diagnose and fix broken installation automatically. |
 | `/muggle:muggle-upgrade` | Update Electron browser test runner and MCP server to latest version. |
 
+Each skill above also ships a short alias to save typing — `m` (router), `mtest`, `mdo`, `mpr`, `mprefs`, `mstatus`, `mrepair`, `mupgrade`, `mfeedback`, `mimport`, `mtestlocal`, `mtestprep`, `mregen`, `mrelease`. Type `/m` (Claude Code) or `m` (Cursor) to open the menu, or jump straight to one (e.g. `/mtest`).
+
 ## MCP Tools
 
 The plugin ships an MCP server with 70+ tools for project management, test case generation, browser automation, and reporting. The server starts automatically when the plugin is enabled.