@muggleai/works 4.8.0 → 4.8.2

package/dist/plugin/skills/do/pre-flight.md

@@ -0,0 +1,104 @@
+# Pre-flight Agent (Stage 1/7)
+
+You are running the **only user-facing stage** of the muggle-do dev cycle. Your job is to consolidate every ambiguity — task scope, repos, validation strategy, environment, credentials, PR target — into a **single turn** so the rest of the cycle can run unattended.
+
+**Non-negotiable:** Never split pre-flight across multiple turns. Detect what you can silently, then ask every remaining question at once. If you find yourself asking a follow-up, you failed — fold the follow-up back into this file so the next run covers it.
+
+## Turn preamble
+
+Start the turn with:
+
+```
+**Stage 1/7 — Pre-flight** — consolidating everything the cycle needs before going silent.
+```
+
+## Input
+
+You receive:
+
+- The user's task description (from `$ARGUMENTS`).
+- The list of configured repos (names + paths) from the Muggle config.
+- Any session directory that already exists (resumption case).
+
+## Silent detection (do this first — no user prompts)
+
+Before asking anything, gather every fact you can resolve without the user:
+
+1. **Candidate repo(s).** Match keywords in the task description against configured repo names. If one repo is an obvious match, propose it as the default; if two or three are plausible, list them.
+2. **Current branch and default branch** for each candidate repo. Run `git -C <repo> symbolic-ref refs/remotes/origin/HEAD --short` and `git -C <repo> branch --show-current`. If the current branch is the default, the pre-flight must collect a new branch name.
+3. **Running dev server.** Scan common dev ports — `lsof -iTCP -sTCP:LISTEN -nP | grep -E ':(3000|3001|3999|4200|5173|8080)'` — and hit `/` with `curl -s -o /dev/null -w "%{http_code}"` to confirm 2xx.
+4. **Running backend.** If the repo's `.env.local` (or equivalent) declares a backend URL (e.g. `REACT_APP_BACKEND_BASE_URL=http://localhost:5050`), probe the health endpoint; note up/down.
+5. **Muggle MCP auth.** Call `muggle-remote-auth-status`. If expired, you will ask to re-auth in the questionnaire.
+6. **Candidate Muggle projects.** Call `muggle-remote-project-list` and rank by semantic match against the task description and the repo's dev URL.
+7. **Existing test-user secrets.** For each candidate Muggle project, call `muggle-remote-secret-list` and note whether `managed_profile_email` / `managed_profile_password` exist.
+8. **Auth0 tenant in use for local dev.** Grep the repo's env file for `*AUTH0_DOMAIN*`; record the tenant. This tells the user whether the staging-tenant test user will work or not.
+
+## The consolidated questionnaire
+
+Present **one `AskQuestion`** (or the platform's structured-selection equivalent) that collects every remaining decision. Use detected values as defaults whenever possible. Questions to include, in this order:
+
+1. **Task scope clarification** — only if the task description is genuinely ambiguous. Offer 2–3 interpretations as options plus "Other — type a clarification." If the task is unambiguous, omit.
+2. **Repo(s) to modify** — pre-selected with the best silent match. "Confirm <repo>" / "Change repo" / "Multi-repo (list them)".
+3. **Branch name** — default: `users/<user>/<slug>` derived from the task. "Use default" / "Use different name (type)".
+4. **Validation strategy** — the single most important question. Options:
+   - **Local E2E** (Muggle Electron against a running localhost) — default if a dev server was detected.
+   - **Staging replay** — for changes already deployed to a preview URL.
+   - **Unit tests only** — skip E2E, acceptable for pure refactors or backend-only changes.
+   - **Skip validation** — explicit opt-out; the PR title gets `[UNVERIFIED]`.
+5. **Local URL** — only if validation is Local E2E. Default: the detected port. "Confirm `<detected>`" / "Type a different URL".
+6. **Backend reachable?** — only if validation is Local E2E and a backend URL is declared. If the health probe failed, ask "Start the backend now and I'll re-probe" / "Proceed anyway" / "Skip to unit tests only".
+7. **Muggle project** — pre-selected with the best silent match. "Use <top match>" / "Use a different existing project (list)" / "Create new".
+8. **Test-user credentials** — only if validation is Local E2E AND the Auth0 tenant in the repo differs from the tenant the managed secrets were created under. Options: "Reuse existing secrets (may fail if tenant mismatch — will surface failure)" / "Create new secrets for this tenant (provide email + password)" / "Switch to staging replay".
+9. **PR target branch** — default: the repo's default branch. "Use default" / "Target a different branch".
+10. **Re-auth Muggle MCP?** — only if auth was missing/expired. "Log in now" / "Abort".
+
+If fewer than two of the above need the user, still gather them in a single turn — never open a second round.
+
+## Output
+
+After the user answers, write **`state.md`** with every resolved value, verbatim, in this format:
+
+```markdown
+# Session state
+
+**Slug:** <slug>
+**Current stage:** 1/7 (pre-flight complete)
+**Last update:** <ISO-8601 timestamp>
+
+## Pre-flight answers
+
+- Task: <one-line goal>
+- Repos: <repo1>, <repo2>
+- Branch: <branch-name>
+- Validation: <strategy>
+- Local URL: <url or N/A>
+- Backend status: <up | down | N/A>
+- Muggle project: <name> (<uuid>)
+- Test credentials: <existing | new | skip>
+- PR target: <branch>
+- Auth status: <ok | re-authed | N/A>
+
+## Blockers
+<none | bulleted list>
+```
+
+Also initialize `iterations/001.md` with a header:
+
+```markdown
+# Iteration 001 — <ISO-8601 timestamp>
+
+### Stage 1/7 — Pre-flight (<timestamp>)
+
+<verbatim copy of pre-flight answers>
+```
+
+## Handoff
+
+Return control to the muggle-do driver with a one-line summary: `pre-flight complete, proceeding silently through stages 2–7`. Do not print the pre-flight answers again — they are in `state.md` and the iteration log.
+
+## Non-negotiables
+
+- Exactly **one** user turn. Zero follow-up questions inside this stage.
+- Silent detection **must** run before the questionnaire — never ask for a value you can detect.
+- Every detected value is a default, not a lock — the user can always override via "Type a different …".
+- Missing `state.md` or `iterations/001.md` at the end of this stage is a stage failure.

package/dist/plugin/skills/do/requirements.md

@@ -1,7 +1,17 @@
-# Requirements Analysis Agent
+# Requirements Analysis Agent (Stage 2/7)
 
 You are analyzing a user's task description to extract structured requirements for an autonomous development cycle.
 
+## Turn preamble
+
+Start the turn with:
+
+```
+**Stage 2/7 — Requirements** — extracting structured goals from the pre-flight-clarified task.
+```
+
+Pre-flight already resolved ambiguity via the consolidated questionnaire. **Do not ask the user any questions here** — infer silently and record assumptions in Notes.
+
 ## Input
 
 You receive:

package/dist/plugin/skills/do/unit-tests.md

@@ -1,7 +1,15 @@
-# Unit Test Runner Agent
+# Unit Test Runner Agent (Stage 5/7)
 
 You are running unit tests for each repository that has changes in the dev cycle pipeline.
 
+## Turn preamble
+
+Start the turn with:
+
+```
+**Stage 5/7 — Unit tests** — running each repo's test suite.
+```
+
 ## Input
 
 You receive:

package/dist/plugin/skills/do/validate-code.md

@@ -1,7 +1,15 @@
-# Code Validation Agent
+# Code Validation Agent (Stage 4/7)
 
 You are validating that each repository's git state is ready for the dev cycle pipeline.
 
+## Turn preamble
+
+Start the turn with:
+
+```
+**Stage 4/7 — Validate code** — checking branch and commit state for each repo with changes.
+```
+
 ## Input
 
 You receive:

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

@@ -6,9 +6,9 @@ disable-model-invocation: true
 
 # Muggle Do
 
-Muggle Do is the command for the Muggle AI development workflow.
+Muggle Do runs a battle-tested autonomous dev cycle: **pre-flight → requirements → impact analysis → validate code → unit tests → E2E acceptance → open PR**.
 
-It runs a battle-tested autonomous dev cycle: requirements -> impact analysis -> validate code -> coding -> unit tests -> E2E acceptance tests -> open PRs.
+The design goal is **fire and review**: the user answers one consolidated pre-flight questionnaire, then walks away. Every subsequent stage runs unattended until completion or a genuine blocker.
 
 For maintenance tasks, use the dedicated skills:
 
@@ -20,34 +20,78 @@ For maintenance tasks, use the dedicated skills:
 
 Treat `$ARGUMENTS` as the user command:
 
-- Empty / `help` / `menu` / `?` -> show menu and session selector.
-- Anything else -> treat as a new task description and start/resume a dev-cycle session.
+- Empty / `help` / `menu` / `?` → show menu and session selector.
+- Anything else → treat as a new task description and start/resume a dev-cycle session.
+
+## The seven stages
+
+| # | Stage | File | User-facing? |
+| :- | :---- | :--- | :----------- |
+| 1 | Pre-flight | [../do/pre-flight.md](../do/pre-flight.md) | **Yes — single consolidated turn** |
+| 2 | Requirements | [../do/requirements.md](../do/requirements.md) | No |
+| 3 | Impact analysis | [../do/impact-analysis.md](../do/impact-analysis.md) | No |
+| 4 | Validate code | [../do/validate-code.md](../do/validate-code.md) | No |
+| 5 | Unit tests | [../do/unit-tests.md](../do/unit-tests.md) | No |
+| 6 | E2E acceptance | [../do/e2e-acceptance.md](../do/e2e-acceptance.md) | No |
+| 7 | Open PR | [../do/open-prs.md](../do/open-prs.md) | No |
+
+**Stage 1 (pre-flight) is the ONLY stage that talks to the user.** Stages 2–7 run silently to completion. If a later stage hits a genuine blocker that the pre-flight didn't cover, escalate with a single terminal message — do not open a second round of questions.
+
+## Front-loading (stage 1 non-negotiable)
+
+All ambiguity — task scope, repo selection, validation strategy, localhost URL, backend health, Muggle project, test-user credentials, branch name, PR target — is resolved in a **single** pre-flight turn. See `pre-flight.md` for the exact questionnaire.
+
+**Red-flag behaviors (do not do):**
+
+- Asking a clarifying question mid-cycle because "I didn't think of that at pre-flight."
+- Starting a dev server mid-cycle and discovering the port is wrong.
+- Reaching the E2E stage before knowing how the user wants it validated.
+- Asking the user to "pick one" across multiple turns instead of one turn.
+
+If any of these happen, the pre-flight was incomplete — treat it as a skill bug, not a user bug, and expand `pre-flight.md` to cover the missed case after the run.
 
 ## Session model
 
-Use `.muggle-do/sessions/<slug>/` with these files:
+Every run writes to `.muggle-do/sessions/<slug>/`:
 
-- `state.md`
-- `requirements.md`
-- `iterations/<NNN>.md`
-- `result.md`
+- `state.md` — one-screen live status: current stage (N/7), last update timestamp, pre-flight answers verbatim, any blockers.
+- `iterations/<NNN>.md` — append-only log of stage transitions for iteration NNN: what ran, what was decided, what artifacts were produced.
+- `requirements.md` — frozen output of stage 2.
+- `result.md` — final summary written by stage 7 (PR URLs, E2E outcome, open issues).
 
-On each stage transition, update `state.md` and append stage output to the active iteration file.
+**On every stage transition, you MUST:**
 
-## Dev cycle agents
+1. Append a dated entry to the active `iterations/<NNN>.md`: `### Stage N/7 — <name> (<timestamp>)` followed by the stage's output.
+2. Rewrite `state.md` to reflect the new current stage and any relevant counters.
 
-Use the supporting files in the `../do/` directory as stage-specific instructions:
+If these files don't exist, create them — missing session files means the user lost visibility into the cycle, which is the exact failure mode this skill exists to prevent.
 
-- [requirements.md](../do/requirements.md)
-- [impact-analysis.md](../do/impact-analysis.md)
-- [validate-code.md](../do/validate-code.md)
-- [unit-tests.md](../do/unit-tests.md)
-- [e2e-acceptance.md](../do/e2e-acceptance.md)
-- [open-prs.md](../do/open-prs.md)
+## Turn preamble
+
+Each stage turn MUST begin with one line in this form before any other output:
+
+```
+**Stage N/7 — <stage name>** — <one-line intent>
+```
+
+This is how the user can tell, at a glance, what phase the cycle is in without parsing a long response.
 
 ## Guardrails
 
-- Do not skip unit tests before E2E acceptance tests.
-- Do not skip E2E acceptance tests due to missing scripts; generate when needed.
-- If the same stage fails 3 times in a row, escalate with details.
-- If total iterations reach 3 and E2E acceptance tests still fail, continue to PR creation with `[E2E FAILING]`.
+- **No mid-cycle user questions.** Anything not covered by pre-flight is a skill bug; escalate once, do not loop.
+- **Do not skip unit tests before E2E acceptance tests.**
+- **Do not skip E2E acceptance tests due to missing scripts** — generate when needed.
+- **Do not hand-write the E2E block of the PR body.** The `open-prs.md` stage MUST invoke `muggle-pr-visual-walkthrough` Mode B to render the screenshots-and-steps section. Hand-writing it loses the dashboard links the user relies on for review.
+- **If the same stage fails 3 times in a row, escalate with details.**
+- **If total iterations reach 3 and E2E acceptance tests still fail**, continue to PR creation with `[E2E FAILING]` in the title; the visual walkthrough section makes the failures reviewable.
+
+## Completion contract
+
+When stage 7 finishes, the final message to the user contains at minimum:
+
+- PR URL(s)
+- E2E status (passing / `[E2E FAILING]`)
+- Link to the run dashboard for each test case (via the walkthrough skill output)
+- Path to `result.md` for full details
+
+No other content. The user already read the walkthrough in the PR body — do not re-summarize it here.

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

@@ -200,6 +200,17 @@ If nothing detected, ask as free text: "Your local app should be running. What's
 
 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).
 
+### Determine `freshSession` per test case
+
+Before executing each test case, inspect its content (title, goal, instructions, preconditions) for signals that it requires a **clean browser state** — no prior cookies, localStorage, or logged-in session. Set `freshSession: true` when the test case involves any of:
+
+- **Registration / sign-up** — creating a new account
+- **Login / authentication** — verifying the login flow itself (not a test that merely *uses* login as a prerequisite)
+- **Cookie consent / GDPR banners** — verifying first-visit consent prompts
+- **Onboarding flows** — first-time user experiences that only appear on a fresh session
+
+If none of the above apply, omit `freshSession` (defaults to `false`, preserving any existing session state). Evaluate this per test case — in a batch, some may need it and others may not.
+
 ### Run sequentially (Electron constraint)
 
 Execution itself **must** be sequential because there is only one local Electron browser. For each test case, in order:
@@ -208,6 +219,7 @@ Execution itself **must** be sequential because there is only one local Electron
    - `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`
+   - `freshSession`: `true` if the test case requires a clean browser state (see above), omit otherwise
 2. Store the returned `runId`
 
 If a generation fails, log it and continue to the next. Do not abort the batch.
@@ -231,7 +243,7 @@ Store every `viewUrl` — these are used in the next steps.
 ### Report summary
 
 ```
-Test Case                  Status    Duration   Steps   View on Muggle
+Test Case                  Status    Duration   Steps   View Steps on Muggle AI
 ─────────────────────────────────────────────────────────────────────────
 Login with valid creds     PASSED    12.3s      8       https://www.muggle-ai.com/...
 Login with invalid creds   PASSED    9.1s       6       https://www.muggle-ai.com/...

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

@@ -86,17 +86,28 @@ Remind them: local URL is only the execution target, not tied to cloud project c
 
 ### 5. Load data for the chosen path
 
+**Determine `freshSession`**
+
+Before calling either execution tool, inspect the test case content (title, goal, instructions, preconditions) for signals that the test requires a **clean browser state** — no prior cookies, localStorage, or logged-in session. Pass `freshSession: true` when the test case involves any of:
+
+- **Registration / sign-up** — creating a new account
+- **Login / authentication** — verifying the login flow itself (not a test that merely *uses* login as a prerequisite)
+- **Cookie consent / GDPR banners** — verifying first-visit consent prompts
+- **Onboarding flows** — first-time user experiences that only appear on a fresh session
+
+If none of the above apply, omit `freshSession` (defaults to `false`, preserving any existing session state).
+
 **Generate**
 
 1. `muggle-remote-test-case-get`
-2. `muggle-local-execute-test-generation` with that test case + `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`timeoutMs`** — see below)
+2. `muggle-local-execute-test-generation` with that test case + `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`freshSession`** — see above; **`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` with `testScript`, `actionScript`, `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`timeoutMs`** — see below)
+3. `muggle-local-execute-replay` with `testScript`, `actionScript`, `localUrl` (optional: `showUi: false` for headless — defaults to visible; **`freshSession`** — see above; **`timeoutMs`** — see below)
 
 ### Local execution timeout (`timeoutMs`)
 

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

@@ -1,6 +1,6 @@
 ---
 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 remote test script generation for each one in parallel 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 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
@@ -116,27 +116,22 @@ After selection, call `AskQuestion` once more for a final confirmation:
 
 Only proceed after the user picks "Yes".
 
-### Step 6 — Dispatch Remote Generations
+### Step 6 — Dispatch Remote Generations (Bulk)
 
-For each selected test case, in order:
+Send a single bulk request instead of dispatching one workflow per test case:
 
-1. Call `muggle-remote-test-case-get` with `testCaseId` to fetch the full record (the list endpoint returns a slim shape; generation needs `goal`, `precondition`, `instructions`, `expectedResult`, `url`).
-2. Call `muggle-remote-workflow-start-test-script-generation` with:
+1. Call `muggle-remote-workflow-start-test-script-generation-bulk` with:
    - `projectId` — from Step 2
-   - `useCaseId` — from the test case
-   - `testCaseId` — the test case being regenerated
-   - `name` — `"muggle-test-regenerate-missing: {test case title}"` (so it's easy to find this batch later in the dashboard)
-   - `url` — prefer the test case's own `url` if set, else the project URL from Step 2
-   - `goal`, `precondition`, `instructions`, `expectedResult` — straight from the test case. If `precondition` is empty, pass `"None"` (the schema requires a non-empty string).
-3. Capture the returned workflow runtime ID and store it alongside the test case.
+   - `name` — `"muggle-test-regenerate-missing: bulk ({count} test cases)"` where `{count}` is the number of selected test cases
+   - `testCaseIds` — array of all selected test case IDs from Step 5
+2. The backend handles looking up full test case details (goal, precondition, instructions, expectedResult, url), so there is no need to call `muggle-remote-test-case-get` per test case.
+3. Parse the response to get the `items` array with per-test-case status. Each item contains the test case ID, dispatch status, and (when successful) the workflow runtime ID.
 
-**Failure handling:** if a single dispatch fails (validation error, server error, missing field), log it inline, mark the test case as `dispatch_failed`, and continue to the next one. Do not abort the whole batch — partial progress is more useful than nothing.
-
-**Pacing:** Muggle's cloud handles parallelism on its side, so you don't need to throttle. Just dispatch sequentially as fast as the API will accept them.
+**Failure handling:** the bulk API returns per-item status in the response `items` array. Individual test cases may fail (validation error, missing field, etc.) while others succeed. Surface failures in the Step 7 report — partial progress beats no progress.
 
 ### Step 7 — Report
 
-After all dispatches are done, print a summary table:
+After the bulk dispatch returns, build a summary table from the response `items` array. Each item contains a test case ID, dispatch status, and (when successful) a workflow runtime ID. Cross-reference with the test case list from Step 3 to fill in titles and use case names:
 
 ```
 Test Case                          Use Case             Prev Status       Dispatch       Runtime
@@ -149,7 +144,7 @@ Apply expired coupon               Checkout Flow        GENERATION_PEND.  ❌ fa
 Total: 17 dispatched | 16 started | 1 failed
 ```
 
-For failures: include a one-line error excerpt 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").
+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").
 
 ### Step 8 — Open the Dashboard
 
@@ -183,8 +178,7 @@ Add item to cart         rt-ghi789   COMPLETED   12
 | Auth | `muggle-remote-auth-status`, `muggle-remote-auth-login`, `muggle-remote-auth-poll` |
 | Project | `muggle-remote-project-list`, `muggle-remote-project-create` |
 | Scan | `muggle-remote-test-case-list` (paginated) |
-| Detail | `muggle-remote-test-case-get` |
-| Dispatch | `muggle-remote-workflow-start-test-script-generation` |
+| Dispatch | `muggle-remote-workflow-start-test-script-generation-bulk` |
 | Status (optional) | `muggle-remote-wf-get-ts-gen-latest-run`, `muggle-remote-wf-get-latest-ts-gen-by-tc` |
 | Browser | `open` (shell command) |
 
@@ -193,9 +187,8 @@ Add item to cart         rt-ghi789   COMPLETED   12
 - **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.
 - **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 `muggle-remote-test-case-get` before each dispatch** — the list endpoint returns a slim shape and generation needs the full payload.
-- **Failures don't abort the batch** — log and continue, then surface them at the end. Partial progress beats no progress.
-- **Never throttle artificially** — dispatch sequentially as fast as the API accepts. Muggle's cloud handles parallelism.
+- **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.
 - **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-upgrade/SKILL.md

@@ -10,7 +10,7 @@ Update all Muggle AI components to the latest published version.
 ## Steps
 
 1. Run `/muggle:muggle-status` checks to capture current versions.
-2. Run `muggle setup --force` to download the latest Electron browser test runner.
+2. Run `muggle upgrade` to check GitHub releases for the latest electron-app version and download it.
 3. Report the upgrade results:
    - Previous version vs new version for each component.
    - Whether the upgrade succeeded or failed.

package/dist/release-manifest.json

@@ -1,7 +1,7 @@
 {
-  "release": "4.8.0",
-  "buildId": "run-19-1",
-  "commitSha": "970c730d39e45df17c9f9498ddcad410beafb8fb",
-  "buildTime": "2026-04-12T05:58:39Z",
+  "release": "4.8.2",
+  "buildId": "run-21-1",
+  "commitSha": "a654d42a8f3fccd94a876740a4d564807e16cd9a",
+  "buildTime": "2026-04-14T22:44:16Z",
   "serviceName": "muggle-ai-works-mcp"
 }

package/dist/{src-2IDMKEJ5.js → src-ZRUONWKV.js}

@@ -1 +1 @@
-export { buildElectronAppChecksumsUrl, buildElectronAppReleaseAssetUrl, buildElectronAppReleaseTag, calculateFileChecksum, createApiKeyWithToken, createChildLogger, deleteApiKeyData, deleteCredentials, e2e_exports as e2e, getApiKey, getApiKeyFilePath, getAuthService, getBundledElectronAppVersion, getCallerCredentials, getCallerCredentialsAsync, getChecksumForPlatform, getConfig, getCredentialsFilePath, getDataDir, getDownloadBaseUrl, getElectronAppChecksums, getElectronAppDir, getElectronAppVersion, getElectronAppVersionSource, getLocalQaTools, getLogger, getPlatformKey, getQaTools, getValidApiKeyData, getValidCredentials, hasApiKey, isElectronAppInstalled, loadApiKeyData, loadCredentials, local_exports as localQa, mcp_exports as mcp, openBrowserUrl, performLogin, performLogout, pollDeviceCode, e2e_exports as qa, resetConfig, resetLogger, saveApiKey, saveApiKeyData, saveCredentials, startDeviceCodeFlow, toolRequiresAuth, verifyFileChecksum } from './chunk-OUI734ME.js';
+export { buildElectronAppChecksumsUrl, buildElectronAppReleaseAssetUrl, buildElectronAppReleaseTag, calculateFileChecksum, createApiKeyWithToken, createChildLogger, deleteApiKeyData, deleteCredentials, e2e_exports as e2e, getApiKey, getApiKeyFilePath, getAuthService, getBundledElectronAppVersion, getCallerCredentials, getCallerCredentialsAsync, getChecksumForPlatform, getConfig, getCredentialsFilePath, getDataDir, getDownloadBaseUrl, getElectronAppChecksums, getElectronAppDir, getElectronAppVersion, getElectronAppVersionSource, getLocalQaTools, getLogger, getPlatformKey, getQaTools, getValidApiKeyData, getValidCredentials, hasApiKey, isElectronAppInstalled, loadApiKeyData, loadCredentials, local_exports as localQa, mcp_exports as mcp, openBrowserUrl, performLogin, performLogout, pollDeviceCode, e2e_exports as qa, resetConfig, resetLogger, saveApiKey, saveApiKeyData, saveCredentials, startDeviceCodeFlow, toolRequiresAuth, verifyFileChecksum } from './chunk-44I5ROCB.js';

package/package.json

@@ -1,7 +1,7 @@
 {
     "name": "@muggleai/works",
     "mcpName": "io.github.multiplex-ai/muggle",
-    "version": "4.8.0",
+    "version": "4.8.2",
     "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.55",
+        "electronAppVersion": "1.0.60",
         "downloadBaseUrl": "https://github.com/multiplex-ai/muggle-ai-works/releases/download",
         "runtimeTargetDefault": "production",
         "checksums": {
-            "darwin-arm64": "b489ecb3273d8c15727ab80430468099a41e58417ef0f853de435f13aff0d903",
-            "darwin-x64": "38a34f45a23a9b53e3383c1f016363a294a28c3abdc454da35a34f1b03ddc191",
-            "win32-x64": "795495f9ddaab676e60f0140651c04f8d375adbadd3258a387bc7c82581c6d76",
-            "linux-x64": "2005101c8b23bce055c2d059e0a123f2b795779fd88df3658fdd1b74f4684599"
+            "darwin-arm64": "a1e084b32ebc28fa823bcc9161959bd3618f0c5e45f41f946b5efa9192b8b15b",
+            "darwin-x64": "0605176a152b12149015b500b5d04dfaec06a5f3ed4d615d5442437cbaa2ba3a",
+            "win32-x64": "f6c9a243894720420229d37ff8915827e56c5aa2f21dd887a0f476d952698ad8",
+            "linux-x64": "4404163f56b664c1d8c040435ef981d1ff6583e2ba2e4b38ea4375afecd1c204"
         }
     },
     "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.8.0",
+  "version": "4.8.2",
   "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.8.0",
+  "version": "4.8.2",
   "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 and syncs `muggle-*` skills into `~/.cursor/skills/` for Cursor. 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 into `~/.cursor/skills/`. Claude slash commands remain plugin-managed, so use `/plugin update muggleai@muggle-works` to refresh them.
 
 ## Skills
 

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

@@ -1,7 +1,15 @@
-# E2E / acceptance agent
+# E2E / acceptance agent (Stage 6/7)
 
 You are running **end-to-end (E2E) acceptance** test cases against code changes using Muggle AI's local testing infrastructure. These tests simulate real users in a browser — they are not unit tests.
 
+## Turn preamble
+
+Start the turn with:
+
+```
+**Stage 6/7 — E2E acceptance** — running browser tests against the validation target from pre-flight.
+```
+
 ## Design
 
 E2E acceptance testing runs **locally** using the `test-feature-local` approach:
@@ -15,32 +23,35 @@ This guarantees E2E acceptance tests always run — no dependency on cloud repla
 
 ## Input
 
-You receive:
-- The Muggle project ID
+You receive everything from `state.md` already — pre-flight resolved it:
+
+- `localUrl` — the locally running dev server URL
+- `projectId` — the chosen Muggle project
+- The validation strategy (`local-e2e`, `staging-replay`, `unit-only`, `skip`)
+- Test-user credential status (existing / new / skip)
 - The list of changed repos, files, and a summary of changes
 - The requirements goal
-- `localUrl` per repo (from `muggle-repos.json`) — the locally running dev server URL
 
 ## Your Job
 
-### Step 0: Resolve Local URL
+### Step 0: Consume pre-flight (no user questions)
+
+Read `state.md`. If the validation strategy is `unit-only` or `skip`, **do not run this stage** — skip to stage 7 and record the skip reason. Otherwise use `localUrl` directly; **do not ask the user** for it.
+
+If `localUrl` or `projectId` is missing from `state.md`, that is a pre-flight bug. **Do not paper over it by asking the user** — escalate once with the session path and halt. The fix is to expand `pre-flight.md`, not to grow a new question here.
 
-Read `localUrl` for each repo from the context. If it is not provided, ask the user:
-> "E2E acceptance testing requires a running local server. What URL is the `<repo>` app running on? (e.g. `http://localhost:3000`)"
+### Step 0.5: Pre-flight verification probes
 
-**Do not skip E2E acceptance tests.** Wait for the user to provide the URL before proceeding.
+Before launching Electron, run these live checks and fail loudly if any fails:
 
-### Step 1: Check Authentication
+1. `curl -s -o /dev/null -w "%{http_code}" <localUrl>` — expect 2xx or 3xx. If the dev server isn't up, halt with the exact command the user needs to start it.
+2. If a backend URL is recorded, probe its health endpoint. A 5xx or unreachable backend means the dashboard will render in an error state and test results will be meaningless — halt.
+3. `muggle-remote-auth-status` — must be `authenticated`. If not, the pre-flight missed this; escalate.
+4. If test credentials were marked `existing`, confirm the Auth0 tenant in the repo's env matches the tenant the secrets were created under (recorded in `state.md`). Tenant mismatch → halt with "existing secrets target tenant X, local dev targets tenant Y — update pre-flight to collect new credentials."
 
-- `muggle-remote-auth-status`
-- 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`
+### Step 1: Authentication already verified
 
-Do not skip or assume auth.
+Pre-flight handled auth. If `muggle-remote-auth-status` somehow shows expired here (session clock skew, etc.), re-auth silently via `muggle-remote-auth-login` + `muggle-remote-auth-poll` — but do not ask the user "continue with this account?" again.
 
 ### Step 2: Get Test Cases
 

package/plugin/skills/do/impact-analysis.md

@@ -1,7 +1,15 @@
-# Impact Analysis Agent
+# Impact Analysis Agent (Stage 3/7)
 
 You are analyzing git repositories to determine which ones have actual code changes that need to go through the dev cycle pipeline.
 
+## Turn preamble
+
+Start the turn with:
+
+```
+**Stage 3/7 — Impact analysis** — diffing each affected repo against its default branch.
+```
+
 ## Input
 
 You receive: