@muggleai/works 5.16.0-staging.108 → 5.16.0-staging.110
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -1,31 +1,50 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: muggle-upgrade
|
|
3
3
|
model: haiku
|
|
4
|
-
description: Update Muggle AI to
|
|
4
|
+
description: Update Muggle AI to the newest version on its current release lane. Use when user types muggle upgrade or asks to update Muggle Test tools.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Muggle Test Upgrade
|
|
8
8
|
|
|
9
9
|
> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-upgrade"`.
|
|
10
10
|
|
|
11
|
-
Update all Muggle AI components to the
|
|
11
|
+
Update all Muggle AI components to the newest version **on the release lane the machine is already on**. This means **both** the `@muggleai/works` CLI on npm **and** the Electron runner the CLI manages.
|
|
12
|
+
|
|
13
|
+
## Release lanes
|
|
14
|
+
|
|
15
|
+
Two lanes ship on npm, each with its own dist-tag:
|
|
16
|
+
|
|
17
|
+
| Lane | dist-tag | Version shape |
|
|
18
|
+
| :--- | :------- | :------------ |
|
|
19
|
+
| stable | `latest` | `5.15.0` |
|
|
20
|
+
| staging | `staging` | `5.16.0-staging.109` |
|
|
21
|
+
|
|
22
|
+
**The lane is read off the installed build, never chosen by this skill.** A version carrying a prerelease identifier is on staging; a plain release is on stable. Stable is the default, and a machine that has never installed a prerelease stays there.
|
|
23
|
+
|
|
24
|
+
**Upgrade within the lane, and compare against that lane's tag.** Semver orders `5.15.0-staging.106` *below* `5.15.0`, so a staging build measured against `latest` looks out of date — that comparison silently moves a staging user onto stable and takes away the lane they were testing on. It is the specific bug this section exists to prevent.
|
|
25
|
+
|
|
26
|
+
**Switch lanes only when the user asks in this invocation** — "switch to stable", "go back to prod", "put me on staging", or naming an explicit version to install. A bare invocation always keeps the lane it found. When the user does name a version, install exactly that and say which lane it lands on.
|
|
12
27
|
|
|
13
28
|
## Steps
|
|
14
29
|
|
|
15
30
|
1. Run `/muggle:muggle-status` checks to capture current versions.
|
|
16
31
|
|
|
17
|
-
2. Capture CLI
|
|
32
|
+
2. Capture the installed CLI and resolve its lane:
|
|
18
33
|
- Installed CLI: `muggle --version`
|
|
19
|
-
-
|
|
34
|
+
- Published heads of both lanes: `npm view @muggleai/works dist-tags --json`
|
|
20
35
|
- Detect install location: `npm ls -g @muggleai/works --depth=0` (falls back to `pnpm ls -g @muggleai/works` if not found)
|
|
21
36
|
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
-
|
|
37
|
+
Read the lane off the installed version per the table above, then take that lane's tag as the upgrade target. Do not compare across lanes.
|
|
38
|
+
|
|
39
|
+
3. **If the installed CLI is behind its own lane's tag**, upgrade the CLI before touching Electron. Install the **tag**, not a version string, so the lane keeps resolving on later runs:
|
|
40
|
+
- stable, npm: `npm install -g @muggleai/works@latest` — pnpm: `pnpm add -g @muggleai/works@latest`
|
|
41
|
+
- staging, npm: `npm install -g @muggleai/works@staging` — pnpm: `pnpm add -g @muggleai/works@staging`
|
|
42
|
+
- Already at the lane's tag → report "already current" and continue to step 4.
|
|
43
|
+
- If neither package manager is detected, report the situation and ask the user how the CLI was installed before proceeding.
|
|
26
44
|
|
|
27
|
-
4. Run `muggle upgrade` to pull the Electron runner version
|
|
45
|
+
4. Run `muggle upgrade` to pull the Electron runner version the (now-current) CLI expects.
|
|
28
46
|
- Note: `muggle upgrade` only manages the Electron runner — it does NOT upgrade the CLI npm package. That is why step 3 must run first.
|
|
47
|
+
- The runner tracks published Studio releases only. When it reports "already on the latest version", that is the newest *released* runner — code merged to the Studio repo since that release is not in it, and no upgrade command can reach it until a new runner is published. Say so rather than implying the merge shipped.
|
|
29
48
|
|
|
30
49
|
5. **Reload plugins** — the npm install (step 3) triggers a postinstall script that updates the plugin cache at `~/.claude/plugins/cache/`, but Claude Code only picks up new skills/agents/hooks after a reload. Tell the user:
|
|
31
50
|
|
|
@@ -37,7 +56,7 @@ Update all Muggle AI components to the latest published version. This means **bo
|
|
|
37
56
|
|
|
38
57
|
## Output
|
|
39
58
|
|
|
40
|
-
Show a before/after table for **CLI**, **Electron runner**, **MCP server**, and **Auth
|
|
59
|
+
Show a before/after table for **CLI**, **Electron runner**, **MCP server**, and **Auth**, and name the lane beside the CLI version so it is visible that it did not move. Call out any version that did not change so the user understands what shipped vs what was already current.
|
|
41
60
|
|
|
42
61
|
If any component upgraded, always end with the `/reload-plugins` reminder — even if the user doesn't need new features right away, stale cached skills can cause confusing behavior.
|
|
43
62
|
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"release": "5.13.1",
|
|
3
|
-
"buildId": "run-
|
|
4
|
-
"commitSha": "
|
|
5
|
-
"buildTime": "2026-09-
|
|
3
|
+
"buildId": "run-110-1",
|
|
4
|
+
"commitSha": "da6b48486e8570320d840803c55ded923da268ac",
|
|
5
|
+
"buildTime": "2026-09-09T17:16:05Z",
|
|
6
6
|
"serviceName": "muggle-ai-works-mcp"
|
|
7
7
|
}
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@muggleai/works",
|
|
3
3
|
"mcpName": "io.github.multiplex-ai/muggle",
|
|
4
|
-
"version": "5.16.0-staging.
|
|
4
|
+
"version": "5.16.0-staging.110",
|
|
5
5
|
"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.",
|
|
6
6
|
"type": "module",
|
|
7
7
|
"main": "dist/index.js",
|
|
@@ -1,31 +1,50 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: muggle-upgrade
|
|
3
3
|
model: haiku
|
|
4
|
-
description: Update Muggle AI to
|
|
4
|
+
description: Update Muggle AI to the newest version on its current release lane. Use when user types muggle upgrade or asks to update Muggle Test tools.
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Muggle Test Upgrade
|
|
8
8
|
|
|
9
9
|
> Telemetry first step: see [`_shared/telemetry-emit.md`](../_shared/telemetry-emit.md). Use `skillName: "muggle-upgrade"`.
|
|
10
10
|
|
|
11
|
-
Update all Muggle AI components to the
|
|
11
|
+
Update all Muggle AI components to the newest version **on the release lane the machine is already on**. This means **both** the `@muggleai/works` CLI on npm **and** the Electron runner the CLI manages.
|
|
12
|
+
|
|
13
|
+
## Release lanes
|
|
14
|
+
|
|
15
|
+
Two lanes ship on npm, each with its own dist-tag:
|
|
16
|
+
|
|
17
|
+
| Lane | dist-tag | Version shape |
|
|
18
|
+
| :--- | :------- | :------------ |
|
|
19
|
+
| stable | `latest` | `5.15.0` |
|
|
20
|
+
| staging | `staging` | `5.16.0-staging.109` |
|
|
21
|
+
|
|
22
|
+
**The lane is read off the installed build, never chosen by this skill.** A version carrying a prerelease identifier is on staging; a plain release is on stable. Stable is the default, and a machine that has never installed a prerelease stays there.
|
|
23
|
+
|
|
24
|
+
**Upgrade within the lane, and compare against that lane's tag.** Semver orders `5.15.0-staging.106` *below* `5.15.0`, so a staging build measured against `latest` looks out of date — that comparison silently moves a staging user onto stable and takes away the lane they were testing on. It is the specific bug this section exists to prevent.
|
|
25
|
+
|
|
26
|
+
**Switch lanes only when the user asks in this invocation** — "switch to stable", "go back to prod", "put me on staging", or naming an explicit version to install. A bare invocation always keeps the lane it found. When the user does name a version, install exactly that and say which lane it lands on.
|
|
12
27
|
|
|
13
28
|
## Steps
|
|
14
29
|
|
|
15
30
|
1. Run `/muggle:muggle-status` checks to capture current versions.
|
|
16
31
|
|
|
17
|
-
2. Capture CLI
|
|
32
|
+
2. Capture the installed CLI and resolve its lane:
|
|
18
33
|
- Installed CLI: `muggle --version`
|
|
19
|
-
-
|
|
34
|
+
- Published heads of both lanes: `npm view @muggleai/works dist-tags --json`
|
|
20
35
|
- Detect install location: `npm ls -g @muggleai/works --depth=0` (falls back to `pnpm ls -g @muggleai/works` if not found)
|
|
21
36
|
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
-
|
|
37
|
+
Read the lane off the installed version per the table above, then take that lane's tag as the upgrade target. Do not compare across lanes.
|
|
38
|
+
|
|
39
|
+
3. **If the installed CLI is behind its own lane's tag**, upgrade the CLI before touching Electron. Install the **tag**, not a version string, so the lane keeps resolving on later runs:
|
|
40
|
+
- stable, npm: `npm install -g @muggleai/works@latest` — pnpm: `pnpm add -g @muggleai/works@latest`
|
|
41
|
+
- staging, npm: `npm install -g @muggleai/works@staging` — pnpm: `pnpm add -g @muggleai/works@staging`
|
|
42
|
+
- Already at the lane's tag → report "already current" and continue to step 4.
|
|
43
|
+
- If neither package manager is detected, report the situation and ask the user how the CLI was installed before proceeding.
|
|
26
44
|
|
|
27
|
-
4. Run `muggle upgrade` to pull the Electron runner version
|
|
45
|
+
4. Run `muggle upgrade` to pull the Electron runner version the (now-current) CLI expects.
|
|
28
46
|
- Note: `muggle upgrade` only manages the Electron runner — it does NOT upgrade the CLI npm package. That is why step 3 must run first.
|
|
47
|
+
- The runner tracks published Studio releases only. When it reports "already on the latest version", that is the newest *released* runner — code merged to the Studio repo since that release is not in it, and no upgrade command can reach it until a new runner is published. Say so rather than implying the merge shipped.
|
|
29
48
|
|
|
30
49
|
5. **Reload plugins** — the npm install (step 3) triggers a postinstall script that updates the plugin cache at `~/.claude/plugins/cache/`, but Claude Code only picks up new skills/agents/hooks after a reload. Tell the user:
|
|
31
50
|
|
|
@@ -37,7 +56,7 @@ Update all Muggle AI components to the latest published version. This means **bo
|
|
|
37
56
|
|
|
38
57
|
## Output
|
|
39
58
|
|
|
40
|
-
Show a before/after table for **CLI**, **Electron runner**, **MCP server**, and **Auth
|
|
59
|
+
Show a before/after table for **CLI**, **Electron runner**, **MCP server**, and **Auth**, and name the lane beside the CLI version so it is visible that it did not move. Call out any version that did not change so the user understands what shipped vs what was already current.
|
|
41
60
|
|
|
42
61
|
If any component upgraded, always end with the `/reload-plugins` reminder — even if the user doesn't need new features right away, stale cached skills can cause confusing behavior.
|
|
43
62
|
|