@muggleai/works 5.18.0-staging.120 → 5.18.0-staging.121

package/dist/plugin/skills/_shared/test-case-chain-readiness.md

@@ -11,8 +11,9 @@ This is the **graph the backend owns** — do not infer the chain from titles or
 Run once the target `testCaseId` is chosen and the local URL + services are confirmed (the generation calls below need `localUrl` and `cwd`).
 
 1. **Resolve the chain.** `muggle-remote-test-case-ancestors-get` with the target `testCaseId`. Response: `{ testCaseId, ancestors, orphan }`.
-   - `orphan: true` **or** empty `ancestors` → no prerequisites. Skip the rest; continue to Step 5.
-     One orphan is ordinary. **Every** case in a project reading `orphan: true` is not — it means the graph was never built, so nothing orders prerequisites and a bulk replay runs cases that destroy each other's fixtures (one empties a household another needs). Queue `muggle-remote-test-plan-graph-rebuild` for the project, then re-read the chain. It only queues the work, so the graph is not ready the moment it returns.
+   - `orphan: false` with empty `ancestors` → the graph places this case as a root: it has no prerequisites. Skip the rest; continue to Step 5.
+   - `orphan: true` → the graph holds no node for this case, so its prerequisites are **unknown, not absent**, and running it is a guess about what state already exists. Queue `muggle-remote-test-plan-graph-rebuild` for the project and re-read the chain once it has settled — the call only queues the work, so the graph is not ready the moment it returns.
+     One orphan is ordinary. **Every** case in a project reading `orphan: true` means the graph was never built, so nothing orders prerequisites and a bulk replay runs cases that destroy each other's fixtures (one empties a household another needs).
    - Otherwise `ancestors` is ordered **immediate-parent → root**. Reverse it to **root-first** so prerequisites are satisfied bottom-up.
 
 2. **For each ancestor, root-first:**
@@ -34,6 +35,12 @@ If an ancestor's generation does not reach `passed` (read it via `muggle-local-r
 
 Do not silently skip a failed ancestor and run the target.
 
+## Unattended callers
+
+A caller with no user to ask — an autonomous stage, an agent — resolves the same chain and takes the same actions, but never prompts. Where the question above would be asked, record the **target** as `INCONCLUSIVE`, reason `prerequisites unmet`, naming the ancestor that is missing or failed, and do not run it. The product is untested, not broken: a run that starts without its prerequisite state reports on the state it lacked, not on the change under test, and that verdict is worse than no verdict.
+
+The same applies to a target that still reads `orphan: true` after a rebuild has been queued for its project: its prerequisites are unknown, not absent, so it is `INCONCLUSIVE` for this cycle rather than a cold run. Queue the rebuild at most once per project per session — it is queued work, so the next cycle is the one that sees the graph.
+
 ## Notes
 
 - The target test case is **not** in its own `ancestors` list — only its prerequisites are.

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

@@ -98,6 +98,14 @@ Based on the changed files and the requirements goal, determine which test cases
 - Test cases that cover areas potentially affected by the changes
 - When in doubt, include the test case (better to over-test than miss a regression)
 
+### Step 3.5: Satisfy each target's prerequisite chain
+
+For every test case selected in Step 3, resolve its prerequisite chain from the backend's test-plan graph and make each ancestor ready before the target runs, per [`../_shared/test-case-chain-readiness.md`](../_shared/test-case-chain-readiness.md). This stage is unattended, so follow that file's unattended-caller rule: a target whose chain cannot be satisfied is reported `INCONCLUSIVE` with reason `prerequisites unmet` and is not run.
+
+A target that runs without its prerequisite state spends its step budget re-creating that state — signing in, seeding data — and reports on what it lacked rather than on the change under test. That verdict reads as a product failure and is worth less than no verdict.
+
+Ancestors generated here are prerequisites, not results: they belong in neither the Passed nor the Failed block of the report.
+
 ### Step 4: Run the dev loop, gather screenshots
 
 For each relevant test case, run the shared loop in [`../_shared/dev-loop/run.md`](../_shared/dev-loop/run.md): `muggle-remote-test-script-list` by `testCaseId` with `runEnvironmentType: "local"` (this stage runs against localhost) to pick [replay vs regen](../_shared/dev-loop/run.md), [execute with `timeoutMs`](../_shared/dev-loop/timeouts.md), [fetch the result](../_shared/dev-loop/failures.md) and [interpret failures](../_shared/dev-loop/failures.md), then read the studio-published [cloud refs and per-step screenshots](../_shared/dev-loop/publish.md) off the run result.
@@ -134,7 +142,7 @@ For each test case:
   - steps: `[{ stepIndex, action, screenshotUrl }, ...]`
   - artifactsDir: `<path>` (for local debugging)
 
-**Inconclusive:** (count) — use for runs that couldn't yield a pass/fail signal: no replayable script, environment precondition unmet, infra error, agent stalled on auth/cookie banner before reaching the assertion, missing secrets. The product is **not** implicated — that's `failed`, not `inconclusive`.
+**Inconclusive:** (count) — use for runs that couldn't yield a pass/fail signal: no replayable script, environment precondition unmet, prerequisites unmet (Step 3.5), infra error, agent stalled on auth/cookie banner before reaching the assertion, missing secrets. The product is **not** implicated — that's `failed`, not `inconclusive`.
 - (test case name):
   - testCaseId: `<id>`
   - runId: `<id>` (synthesize a UUID if no run started)

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

@@ -47,6 +47,8 @@ Map each bucket to exactly one disposition. Buckets are defined in [`../_shared/
 
 A `repair` disposition requires a named defect: the failing step, expected-versus-actual, and the code path it implicates. Without one it is `ask`, whatever the bucket said.
 
+An Inconclusive entry Stage 6 recorded as `prerequisites unmet` never executed. It carries no bucket and none may be derived from it — there is no run to read. Its disposition is `ask`, and the question names the missing prerequisite: what failed is the project's test-plan chain, not the diff.
+
 ## Step 3: Act
 
 Process dispositions in order — `retry`, then `regenerate`, then `repair` — so cheap self-healing runs before any code change.

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

@@ -41,12 +41,12 @@ Reach for these when the user is weighing Muggle Test against hand-written specs
 
 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 Test's service responsibility, not yours.** Muggle Test'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.
+**Ordering and dependencies belong to the test-plan graph, not to the test case body.** The backend records which case depends on which; the run path reads that chain and runs the prerequisites first ([`_shared/test-case-chain-readiness.md`](../_shared/test-case-chain-readiness.md)). 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 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. Setup arrives as its own prerequisite case: the chain runs ahead of the target, and the session it leaves behind is what the target starts from. Nothing is spliced into the case body.
 
 **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.
 

package/dist/plugin/skills/muggle-test/execute-local.md

@@ -30,6 +30,10 @@ Gate `showElectronBrowser` (per `preference-gates/README.md`). Resolve once; app
 - `never` → pass `showUi: false`.
 - `ask` → run Picker 1 from `preference-gates/showElectronBrowser.md` via `AskUserQuestion`; map the answer back to one of the actions above.
 
+## Prerequisite chain
+
+Before the first run, resolve each selected test case's prerequisite chain and make every ancestor ready, per [`../_shared/test-case-chain-readiness.md`](../_shared/test-case-chain-readiness.md). Ancestors are generated, never replayed, root-first; the session an ancestor leaves behind is what the target starts from, so ordering here is what makes `freshSession: false` mean anything below.
+
 ## Run the dev loop
 
 Execute each test case via the shared loop in [`../_shared/dev-loop/run.md`](../_shared/dev-loop/run.md): [sequential replay/regen](../_shared/dev-loop/run.md), [`actionScript` as-is](../_shared/dev-loop/action-script.md), [`freshSession`](../_shared/dev-loop/fresh-session.md), and [`timeoutMs`](../_shared/dev-loop/timeouts.md).

package/dist/release-manifest.json

@@ -1,7 +1,7 @@
 {
   "release": "5.18.0",
-  "buildId": "run-120-1",
-  "commitSha": "6d7859fc743b237f7178b4ac633a31ca6bc26419",
-  "buildTime": "2026-09-18T16:35:22Z",
+  "buildId": "run-121-1",
+  "commitSha": "1810276d941825cc77603d1deae4613cb9d05d30",
+  "buildTime": "2026-09-19T07:54:36Z",
   "serviceName": "muggle-ai-works-mcp"
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@muggleai/works",
   "mcpName": "io.github.multiplex-ai/muggle",
-  "version": "5.18.0-staging.120",
+  "version": "5.18.0-staging.121",
   "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",

package/plugin/skills/_shared/test-case-chain-readiness.md

@@ -11,8 +11,9 @@ This is the **graph the backend owns** — do not infer the chain from titles or
 Run once the target `testCaseId` is chosen and the local URL + services are confirmed (the generation calls below need `localUrl` and `cwd`).
 
 1. **Resolve the chain.** `muggle-remote-test-case-ancestors-get` with the target `testCaseId`. Response: `{ testCaseId, ancestors, orphan }`.
-   - `orphan: true` **or** empty `ancestors` → no prerequisites. Skip the rest; continue to Step 5.
-     One orphan is ordinary. **Every** case in a project reading `orphan: true` is not — it means the graph was never built, so nothing orders prerequisites and a bulk replay runs cases that destroy each other's fixtures (one empties a household another needs). Queue `muggle-remote-test-plan-graph-rebuild` for the project, then re-read the chain. It only queues the work, so the graph is not ready the moment it returns.
+   - `orphan: false` with empty `ancestors` → the graph places this case as a root: it has no prerequisites. Skip the rest; continue to Step 5.
+   - `orphan: true` → the graph holds no node for this case, so its prerequisites are **unknown, not absent**, and running it is a guess about what state already exists. Queue `muggle-remote-test-plan-graph-rebuild` for the project and re-read the chain once it has settled — the call only queues the work, so the graph is not ready the moment it returns.
+     One orphan is ordinary. **Every** case in a project reading `orphan: true` means the graph was never built, so nothing orders prerequisites and a bulk replay runs cases that destroy each other's fixtures (one empties a household another needs).
    - Otherwise `ancestors` is ordered **immediate-parent → root**. Reverse it to **root-first** so prerequisites are satisfied bottom-up.
 
 2. **For each ancestor, root-first:**
@@ -34,6 +35,12 @@ If an ancestor's generation does not reach `passed` (read it via `muggle-local-r
 
 Do not silently skip a failed ancestor and run the target.
 
+## Unattended callers
+
+A caller with no user to ask — an autonomous stage, an agent — resolves the same chain and takes the same actions, but never prompts. Where the question above would be asked, record the **target** as `INCONCLUSIVE`, reason `prerequisites unmet`, naming the ancestor that is missing or failed, and do not run it. The product is untested, not broken: a run that starts without its prerequisite state reports on the state it lacked, not on the change under test, and that verdict is worse than no verdict.
+
+The same applies to a target that still reads `orphan: true` after a rebuild has been queued for its project: its prerequisites are unknown, not absent, so it is `INCONCLUSIVE` for this cycle rather than a cold run. Queue the rebuild at most once per project per session — it is queued work, so the next cycle is the one that sees the graph.
+
 ## Notes
 
 - The target test case is **not** in its own `ancestors` list — only its prerequisites are.

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

@@ -98,6 +98,14 @@ Based on the changed files and the requirements goal, determine which test cases
 - Test cases that cover areas potentially affected by the changes
 - When in doubt, include the test case (better to over-test than miss a regression)
 
+### Step 3.5: Satisfy each target's prerequisite chain
+
+For every test case selected in Step 3, resolve its prerequisite chain from the backend's test-plan graph and make each ancestor ready before the target runs, per [`../_shared/test-case-chain-readiness.md`](../_shared/test-case-chain-readiness.md). This stage is unattended, so follow that file's unattended-caller rule: a target whose chain cannot be satisfied is reported `INCONCLUSIVE` with reason `prerequisites unmet` and is not run.
+
+A target that runs without its prerequisite state spends its step budget re-creating that state — signing in, seeding data — and reports on what it lacked rather than on the change under test. That verdict reads as a product failure and is worth less than no verdict.
+
+Ancestors generated here are prerequisites, not results: they belong in neither the Passed nor the Failed block of the report.
+
 ### Step 4: Run the dev loop, gather screenshots
 
 For each relevant test case, run the shared loop in [`../_shared/dev-loop/run.md`](../_shared/dev-loop/run.md): `muggle-remote-test-script-list` by `testCaseId` with `runEnvironmentType: "local"` (this stage runs against localhost) to pick [replay vs regen](../_shared/dev-loop/run.md), [execute with `timeoutMs`](../_shared/dev-loop/timeouts.md), [fetch the result](../_shared/dev-loop/failures.md) and [interpret failures](../_shared/dev-loop/failures.md), then read the studio-published [cloud refs and per-step screenshots](../_shared/dev-loop/publish.md) off the run result.
@@ -134,7 +142,7 @@ For each test case:
   - steps: `[{ stepIndex, action, screenshotUrl }, ...]`
   - artifactsDir: `<path>` (for local debugging)
 
-**Inconclusive:** (count) — use for runs that couldn't yield a pass/fail signal: no replayable script, environment precondition unmet, infra error, agent stalled on auth/cookie banner before reaching the assertion, missing secrets. The product is **not** implicated — that's `failed`, not `inconclusive`.
+**Inconclusive:** (count) — use for runs that couldn't yield a pass/fail signal: no replayable script, environment precondition unmet, prerequisites unmet (Step 3.5), infra error, agent stalled on auth/cookie banner before reaching the assertion, missing secrets. The product is **not** implicated — that's `failed`, not `inconclusive`.
 - (test case name):
   - testCaseId: `<id>`
   - runId: `<id>` (synthesize a UUID if no run started)

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

@@ -47,6 +47,8 @@ Map each bucket to exactly one disposition. Buckets are defined in [`../_shared/
 
 A `repair` disposition requires a named defect: the failing step, expected-versus-actual, and the code path it implicates. Without one it is `ask`, whatever the bucket said.
 
+An Inconclusive entry Stage 6 recorded as `prerequisites unmet` never executed. It carries no bucket and none may be derived from it — there is no run to read. Its disposition is `ask`, and the question names the missing prerequisite: what failed is the project's test-plan chain, not the diff.
+
 ## Step 3: Act
 
 Process dispositions in order — `retry`, then `regenerate`, then `repair` — so cheap self-healing runs before any code change.

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

@@ -41,12 +41,12 @@ Reach for these when the user is weighing Muggle Test against hand-written specs
 
 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 Test's service responsibility, not yours.** Muggle Test'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.
+**Ordering and dependencies belong to the test-plan graph, not to the test case body.** The backend records which case depends on which; the run path reads that chain and runs the prerequisites first ([`_shared/test-case-chain-readiness.md`](../_shared/test-case-chain-readiness.md)). 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 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. Setup arrives as its own prerequisite case: the chain runs ahead of the target, and the session it leaves behind is what the target starts from. Nothing is spliced into the case body.
 
 **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.
 

package/plugin/skills/muggle-test/execute-local.md

@@ -30,6 +30,10 @@ Gate `showElectronBrowser` (per `preference-gates/README.md`). Resolve once; app
 - `never` → pass `showUi: false`.
 - `ask` → run Picker 1 from `preference-gates/showElectronBrowser.md` via `AskUserQuestion`; map the answer back to one of the actions above.
 
+## Prerequisite chain
+
+Before the first run, resolve each selected test case's prerequisite chain and make every ancestor ready, per [`../_shared/test-case-chain-readiness.md`](../_shared/test-case-chain-readiness.md). Ancestors are generated, never replayed, root-first; the session an ancestor leaves behind is what the target starts from, so ordering here is what makes `freshSession: false` mean anything below.
+
 ## Run the dev loop
 
 Execute each test case via the shared loop in [`../_shared/dev-loop/run.md`](../_shared/dev-loop/run.md): [sequential replay/regen](../_shared/dev-loop/run.md), [`actionScript` as-is](../_shared/dev-loop/action-script.md), [`freshSession`](../_shared/dev-loop/fresh-session.md), and [`timeoutMs`](../_shared/dev-loop/timeouts.md).