@sun-asterisk/sungen 3.2.2-beta.13 → 3.2.2-beta.17

package/src/harness/quality-gates.ts

@@ -42,6 +42,26 @@ export function isolationRisk(featureText: string, stateful: boolean): boolean {
   return !/@cleanup:cart\b|@isolate\b|empty cart|fresh (?:browser )?context|new context/i.test(featureText);
 }
 
+/**
+ * #414 — the complement of isolationRisk. Per-scenario isolation is the DEFAULT now, so untagged
+ * suites can't cascade. `@serial` opts INTO a shared-page `test.describe.serial` suite, whose
+ * Playwright semantics SKIP every test after the first failure. That is correct ONLY for a genuinely
+ * stateful ordered sequence; for INDEPENDENT scenarios — each re-establishing its own start state via
+ * a navigating Background — `@serial` buys no correctness, only a cascade that *masks* failures (one
+ * early red turns the rest into greens-by-omission). Returns the scenario count when `@serial` should
+ * be dropped (the default isolation is safer), else 0.
+ *
+ * Conservative on purpose — only fires on `@serial` suites whose every scenario provably restarts (a
+ * `Background` that navigates `on [..] page`), so a real stateful sequence keeps its `@serial`.
+ */
+export function serialCascadeRisk(featureText: string, scenarioCount: number): number {
+  if (!/@serial\b/i.test(featureText)) return 0;        // isolated by default → no cascade
+  if (scenarioCount < 8) return 0;                      // small blast radius — not worth the churn
+  const navBackground = /Background:[\s\S]*?\bon \[[^\]]+\] page\b/i.test(featureText);
+  if (!navBackground) return 0;                         // no per-scenario reset → genuinely stateful; @serial is right
+  return scenarioCount;
+}
+
 export function downstreamScope(specText: string, scenarios: ScenarioInfo[]): DownstreamResult {
   const routes = downstreamRoutes(specText);
   const underCovered: { route: string; slug: string }[] = [];

package/src/orchestrator/templates/ai-instructions/claude-agent-reviewer.md

@@ -26,6 +26,18 @@ You are an **independent Senior QA Reviewer**. You did **not** write these tests
    - **Idempotency uses the DB oracle.** A "no double-charge / exactly once" claim is proven by `@concurrent` + a `@query` count, not HTTP status alone (status can lie under a race).
    - **Auth negatives** exist for protected mutations (401/403), not just the happy path.
 
+## Lens mode (parallel review — #410)
+
+If the invoking prompt contains a line `LENS: <name>`, review **only that lens** and go *deeper* on it — ignore the other lenses' items (a sibling agent owns each). Diversity beats one blurred pass: each lens is a distinct failure mode, and a focused reviewer catches what a do-everything pass skims. The lenses map to the checks above:
+
+- `LENS: correctness` → items **1** (title ↔ steps proof; negative / "does-not-happen" contrast) + **2** (observable, non-tautological `Then`).
+- `LENS: depth` → item **3** (business-critical scenarios assert DATA, not visibility/nav).
+- `LENS: manual` → item **4** (`@manual` genuinely unautomatable; flag `MANUAL-AUTOMATABLE` / cross-screen-should-be-a-flow).
+- `LENS: traceability` → item **5** (meaning-level duplicates, missing criticals, `VP-` ids aligned to the viewpoint-overview).
+- `LENS: api` → item **6** (API-only units: prove-the-effect, error matrix, self-clean flows, idempotency via DB oracle, auth negatives).
+
+With **no** `LENS:` line, review **all** lenses in one pass (the single-agent / Copilot fallback). The output format is identical either way; the orchestrator dedupes the merged issues by `[scenario id]` + problem.
+
 ## Output (do NOT edit any file)
 Return a concise verdict:
 

package/src/orchestrator/templates/ai-instructions/claude-cmd-create-test.md

@@ -32,6 +32,17 @@ Parse **name** from `$ARGUMENTS`. If missing, ask the user.
 
 **Auto-detect context**: check if `qa/api/<name>/` or `qa/api/flows/<name>/` exists → **API unit mode** (below). Else if `qa/flows/<name>/` → flow mode. Else `qa/screens/<name>/` → screen mode. This determines paths, generation strategy, and CLI commands.
 
+## Multi-unit fan-out (`--all` or several names)
+
+If `$ARGUMENTS` is `--all` (or lists several units), generate them **concurrently** — generation parallelises across independent units, but **human review stays serial** (you can't judge N boards at once).
+
+1. **Discover + dedup.** List units with `sungen journey --all` (screens + flows + api). Skip units already `✅ signed off`; target the rest.
+2. **Budget the fan-out.** `N = clamp(unit_count, 1, min(16, cores-2))`, and scale per-unit depth to context budget (S4): on a tight (~200k) budget run fewer at once / Tier-1 only. The orchestrator holds only the **roll-up summary**, never each unit's full sources.
+3. **Fan out — one sub-agent per unit.** Spawn the **`sungen-generator`**-style flow per unit via the Task tool (`subagent_type: sungen-discovery` for reading, then generate), each running the **full per-unit loop in isolation** (steps 1-6 below: discover → generate → depth-lint → audit → gate). Each agent sees only its unit's slice and returns a one-line status (unit · gate · score · review-queue count). **Copilot has no sub-agents → do the units sequentially**, same output.
+4. **Roll up + review serially.** Run `sungen journey --all` and present the table. Then walk the user through the units **one at a time** in the board's order (open-obligations first), presenting each unit's own `sungen journey --screen <unit>` review queue, until each is signed off. Never batch sign-offs.
+
+(For a single unit, ignore this section and follow the steps below.)
+
 ## API unit mode (driver-api)
 
 If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the design loop differs — **no visual capture, no selectors**; the contract is the named-endpoint catalog. **Follow the `sungen-api-design` skill end-to-end** instead of the screen/flow steps below: `sungen context --area <name>` (discover) → API viewpoint overview → generate `@api`/`@cases`/flow/`@concurrent`/`@query` scenarios → **`sungen audit --area <name>` gate + the `sungen-reviewer` sub-agent + repair loop to businessDepth ≥ 0.7** → record + trace. Then jump to the "Converge" next-step options (recommend `/sungen:run-test <name>`). The capture / viewpoint-group / selector steps do **not** apply.
@@ -104,7 +115,7 @@ If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the d
 
 5.5. **Quality gate & repair (harness — always run, do NOT skip).** Follow the `sungen-harness-audit` skill:
    - Run `sungen audit --screen <name>` (Bash) and read `gateStatus` + `findings` (deterministic, structural).
-   - **Independent semantic review.** **Claude Code:** spawn the **`sungen-reviewer`** sub-agent (Task tool, `subagent_type: sungen-reviewer`) — it judges what the gate can't (does each scenario's steps PROVE its title/viewpoint, observable Thens, business-critical assertion depth) and returns `VERDICT` + `ISSUES` with concrete fixes. **Merge its NEEDS-REPAIR issues with the audit findings.** (Copilot / no sub-agents: run the same review inline using the `sungen-reviewer` criteria.)
+   - **Independent semantic review — multi-lens (#410).** **Claude Code:** fan out the `sungen-reviewer` sub-agent **once per lens, in parallel** (Task tool, `subagent_type: sungen-reviewer`), passing a `LENS: <name>` line in each prompt — `correctness`, `depth`, `traceability`, `manual` (+ `api` for an API unit). Each lens reviews only its failure mode and goes deeper than one blurred pass would. **Merge all lenses' NEEDS-REPAIR issues, dedupe by `[scenario id]` + problem, then merge with the audit findings.** (Copilot / no sub-agents: run the lenses **sequentially** with the same criteria — still more thorough than one pass; same merge. A single all-lens pass is the fallback when budget is tight.)
    - Repair **both** the audit findings and the reviewer issues (budget 3 rounds), then re-audit:
    - **Repair runs single-agent by default** (it edits the one `.feature` — concurrent edits to the same file conflict, and BALANCE/dedup needs whole-suite context). **Exception:** a finding that is purely **additive new coverage** (GATE missing-theme → generate scenarios for an uncovered theme) is just more shards — fan it out as `sungen-generator` sub-agent(s) (new disjoint `VP-` prefix) and merge, exactly like Step 5b. Findings that **edit existing** scenarios (DEPTH/BALANCE/TRACE) stay serial.
    - If the gate FAILs or there are findings, **repair** (budget 3 rounds), then re-audit:

package/src/orchestrator/templates/ai-instructions/claude-cmd-review.md

@@ -29,7 +29,7 @@ You are an **independent QA Reviewer** running in a **fresh context** — you di
 1. **Enumerate feature files** — glob `<base>/<name>/features/*.feature` (main + any sub-features). If none → `/sungen:create-test` first.
 2. **Run the harness (source of truth) — do NOT re-score with a separate rubric:**
    - `sungen audit --screen <name>` (Bash) → gate status, business-weighted score, findings, gaps (coverage / assertion-depth / balance / duplicate / traceability).
-   - **`sungen-reviewer`** sub-agent (Task tool, `subagent_type: sungen-reviewer`) → semantic verdict the gate can't see (do steps prove the title, observable Then, @manual justified). Copilot/no-sub-agents: apply the `sungen-reviewer` criteria inline.
+   - **`sungen-reviewer`** sub-agent (Task tool, `subagent_type: sungen-reviewer`) → semantic verdict the gate can't see (do steps prove the title, observable Then, @manual justified). **Multi-lens (#410):** fan it out in parallel one per lens — `correctness`, `depth`, `traceability`, `manual` (+ `api`) — via a `LENS: <name>` line, and merge + dedupe the verdicts. Copilot/no-sub-agents: walk the lenses inline (sequential), same merge.
    - `sungen script-check --screen <name>` (Bash) → is the generated spec a 1:1 of the Gherkin (only if a spec exists; flags hand-edit / stale drift).
 3. **Unified scorecard** — present ONE report per feature, anchored on the harness signals (the `sungen-tc-review` 7 dimensions are a *presentation layer* over these, not a competing score):
 

package/src/orchestrator/templates/ai-instructions/claude-cmd-run-test.md

@@ -135,6 +135,7 @@ If the unit is **api-first**, skip every selector/capture phase (an API test has
 6. **Phase 2 — Priority Wave**: Run all `@high` scenarios. Fix only failures from this wave. Max 2 attempts. Shared selectors fixed here cascade to later phases.
 7. **Phase 3 — Full Run**: Run all tests. Fix only **new** failures (elements unique to `@normal`/`@low`). Max 1 attempt. Don't loop on low-priority failures.
 8. **Phase 4 — Regression**: One final full run. Report results. No more fix loops.
+   - **⚠️ Read SKIPPED as MASKED, not passed (#414).** Suites are **per-scenario isolated by default** (`test.describe` + a fresh page each scenario, run sequentially via `workers: 1`) — a failure isolates, every scenario runs. **But an `@serial` suite** (`test.describe.serial`, shared page) **skips every test after the first failure** — so "5 passed, 1 failed, 51 skipped" means **51 never ran**, not 51 OK. If you see that, the feature is `@serial`: unless it's a genuinely stateful ordered sequence, **remove `@serial`, regenerate, and re-run** (the default isolation runs them all). `sungen audit` flags this as **SERIAL-CASCADE-RISK**. Never report an `@serial` run with many skips as green.
 9. **Integrity check & trace (always run after the final run).**
    - `sungen script-check --screen <name>` — verify the generated spec is a **1:1** of the Gherkin (every non-@manual scenario ↔ one `test()`, no drift). If it reports **DRIFT** (spec hand-edited or stale), re-run `sungen generate --screen <name>` so the spec matches the feature, then re-run — **never hand-edit the generated spec** (auto-fix must edit `selectors.yaml`, not the `.spec.ts`).
    - `sungen ledger record --screen <name> --step run --ms <elapsed>` (record this run), then **present the journey board** — `sungen journey --screen <name>` — as the human-facing close-out: **📍 you-are-here**, the **obligation checklist** (now including automation), and **especially the 🔎 Review queue** with its per-item anchors 〔`VP-id · file:line`〕 (*review what / where*) plus any **candidate bugs left FAILING by the source-of-truth rule** (#387). Then `sungen trace --screen <name>` for the process map + bottlenecks. The board's **→ Next** tells the user whether they can sign off & deliver.

package/src/orchestrator/templates/ai-instructions/claude-skill-error-mapping.md

@@ -26,9 +26,12 @@ Then choose the fix from the patterns below.
 `.feature` + `test-data.yaml` + `spec.md` are the **oracle**. The **live page is NOT** — it may be the thing that's broken. A failing test is not automatically a test to "make pass". Classify first:
 
 - **Selector-resolution failure** (element not found / wrong locator / strict-mode / wrong element type) → the test looked in the wrong place. **Fix the locator in `selectors.yaml`** (re-snapshot, copy the exact accessible name). Legit auto-fix.
-- **Assertion-value failure** (element FOUND, but observed value ≠ expected) → STOP and ask: *is the TEST wrong, or is the APP wrong?*
-  - Expected value/rule is wrong **relative to `spec.md`** (typo, stale test-data) → fix `test-data.yaml`/`.feature` so it matches the **spec** — never the live page.
-  - App behaviour contradicts `spec.md` (spec says X, app shows Y) → **CANDIDATE BUG**. **Report it** (let the test FAIL / surface to the QA in the run summary). **NEVER** change the expected value, loosen the rule, weaken the assertion (`toHaveText`→`toContainText` to dodge a mismatch), edit `.feature`, or edit the generated `.spec.ts` to make it pass.
+- **Assertion-value failure** (element FOUND, but observed value ≠ expected) → STOP and ask the decisive question: ***does `spec.md` PIN this exact value?***
+  - **Spec PINS the value and live contradicts it** (spec mandates X, app shows Y) → **CANDIDATE BUG**. **Report it** (let the test FAIL / surface it in the run summary). **NEVER** change the expected, loosen the rule, weaken the assertion (`toHaveText`→`toContainText`), shrink a boundary (`>8`→`>=6`), or edit `.feature`/`.spec.ts` to pass.
+  - **Spec does NOT pin the exact string, and your expected was your own transcription/guess** (whitespace, casing, punctuation, or a label the spec only *describes* narratively) while the live value is the legitimate, spec-consistent truth → **accuracy fix (allowed):** set `test-data.yaml`/`.feature` to the **real** value. This is *not* weakening — the claim is unchanged. (test-11 example: the hero `<h1>` renders `AutomationExercise`; the spec says "the Automation Exercise logo" but pins no exact string → fix `hero_title` to `"AutomationExercise"`, don't leave it failing.)
+  - Expected is wrong **relative to a value `spec.md` DOES state** (a typo vs the spec) → fix to the **spec** value, never the live page.
+
+> **Accuracy fix vs weakening — the line:** an *accuracy fix* makes the expected match a spec-consistent reality the spec didn't pin (cosmetic: whitespace/casing/label), meaning preserved. *Weakening* changes the **oracle** to dodge a real discrepancy (loosen the matcher, shrink a boundary, substring-hide a wrong value, or match a value that contradicts the spec). **If the spec pins it, or you're unsure → treat as a bug and leave it failing.** Don't launder a real defect as an "accuracy fix".
 
 > **Cardinal sin (do NOT do this):** a `password > 8 chars` rule fails on a 6-char input → "fix" it to `>= 6` so the test passes. The logic is now meaningless. A failing assertion is a **finding**, not a chore.
 

package/src/orchestrator/templates/ai-instructions/claude-skill-gherkin-syntax.md

@@ -206,7 +206,8 @@ Options: `nth` `exact` `scope` `match` `variant` `frame` `contenteditable` `colu
 | `@cleanup:scroll` | Auto-cleanup: scroll to top after each test (cleanupPage) |
 | `@cleanup:storage` | Auto-cleanup: clear sessionStorage after each test (cleanupPage) |
 | `@screenshot:on-failure` | Auto-capture screenshot when test fails (base.ts fixture) |
-| `@parallel` | Opt-out: fresh page per test instead of serial default (for independent scenarios) |
+| `@serial` | Opt-IN to a shared-page serial suite (`test.describe.serial`) for a genuinely STATEFUL ordered sequence (scenario N depends on N-1). Default is per-scenario isolation. ⚠️ a failure skips the rest. |
+| `@parallel` | Isolation (same as default) + a hint that the suite is safe to run with multiple workers / `fullyParallel`. |
 | `@beforeAll` | Hook: runs once before all tests → `test.beforeAll()` |
 | `@afterEach` | Hook: runs after each test → `test.afterEach()` (custom cleanup) |
 | `@afterAll` | Hook: runs once after all tests → `test.afterAll()` |
@@ -274,18 +275,21 @@ npx playwright test --grep "@high"           # only high priority
 npx playwright test --grep "@smoke|@high"    # smoke OR high
 ```
 
-### Serial vs Parallel (test execution mode)
+### Isolation vs Serial (test execution mode)
 
-**Default: serial** — `test.describe.serial()` with shared page. Background runs once in `beforeAll`. Fail → skip remaining.
+**Default: per-scenario isolation** — `test.describe()` with a **fresh page per scenario** (Background runs as `beforeEach`). A failure **isolates** — every scenario still runs (no skip-cascade). The scaffolded `playwright.config.ts` runs `workers: 1` (sequential), so an isolated suite has no cross-test contention on a live site. This is right for the vast majority of screens (independent checks that each re-navigate).
 
-**`@parallel` opt-out** — `test.describe()` with fresh page per test. Background runs as `beforeEach`. Use when scenarios are truly independent (validation rules, permission tests).
+**`@serial` opt-in** — `test.describe.serial()` with a **shared page** (Background runs once in `beforeAll`). Use ONLY for a genuinely **stateful ordered sequence** where scenario N depends on N-1's state. ⚠️ A failure **skips every remaining scenario** (Playwright can't trust the shared page after a failure) — so one early red MASKS the rest. `sungen audit` emits **SERIAL-CASCADE-RISK** if an `@serial` suite's scenarios are actually independent.
+
+**`@parallel`** — isolation (same as the default) plus a signal that the suite is safe to run with multiple workers; raise `workers` / set `fullyParallel: true` in `playwright.config.ts` for speed once your target tolerates concurrency.
 
 | Mode | Generated | Page | Background | On fail |
 |---|---|---|---|---|
-| Serial (default) | `test.describe.serial()` | Shared | `beforeAll` (1 goto) | Skip remaining |
-| `@parallel` | `test.describe()` | Fresh per test | `beforeEach` (N goto) | Continue |
+| **Isolated (default)** | `test.describe()` | Fresh per scenario | `beforeEach` (N goto) | **Continue (isolated)** |
+| `@serial` (stateful opt-in) | `test.describe.serial()` | Shared | `beforeAll` (1 goto) | Skip remaining ⚠️ |
+| `@parallel` | `test.describe()` | Fresh per scenario | `beforeEach` | Continue (+ may multi-worker) |
 
-**`@parallel` is required** when a feature has multiple auth groups (e.g., `@auth:user` + `@no-auth` scenarios). Serial mode uses one shared browser context and cannot mix auth roles. The compiler will error if `@parallel` is missing in this case.
+Multiple auth groups (e.g. `@auth:user` + `@no-auth`) work under the default isolation (each group sets its own `storageState`). Only `@serial` shares one context and cannot mix auth roles.
 
 ### `@flow` tag (E2E cross-screen testing)
 

package/src/orchestrator/templates/ai-instructions/copilot-cmd-create-test.md

@@ -27,6 +27,8 @@ You are a **Senior QA Engineer**. You structure test cases by viewpoint categori
 
 **Auto-detect context**: check if `qa/api/<name>/` or `qa/api/flows/<name>/` exists → **API unit mode** (below). Else if `qa/flows/<name>/` → flow mode (base path: `qa/flows/<name>/`). Else `qa/screens/<name>/` → screen mode (base path: `qa/screens/<name>/`).
 
+**Multi-unit (`--all` or several names):** Copilot has no sub-agents, so process units **sequentially** — `sungen journey --all` to list + skip already-signed-off units, then run the full per-unit loop for each. After all are generated, present the `sungen journey --all` roll-up and review **one unit at a time** (open-obligations first; each unit's own `sungen journey --screen <unit>` queue) until signed off. Same output as the Claude fan-out, no speedup.
+
 ## API unit mode (driver-api)
 
 If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the design loop differs — **no visual capture, no selectors**; the contract is the named-endpoint catalog. **Follow the `sungen-api-design` skill end-to-end** instead of the screen/flow steps: `sungen context --area <name>` (discover) → API viewpoint overview → generate `@api`/`@cases`/flow/`@concurrent`/`@query` scenarios → **`sungen audit --area <name>` gate + reviewer + repair loop to businessDepth ≥ 0.7** → record + trace. Then recommend `/sungen-run-test <name>`. The capture / viewpoint-group / selector steps do **not** apply.
@@ -75,7 +77,7 @@ If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the d
    > **No parallel fan-out here.** Copilot has no sub-agents, so generation is sequential (the Claude Code variant fans out one `sungen-generator` per viewpoint group and merges). Same output, no speedup.
    > **Load lazily (budget, S4).** Per group, load **only** the one matching `sungen-viewpoint` group file + the relevant `spec.md` section(s) — never all five groups or the whole spec. On a tight (~200k) budget, write smaller tier-by-tier batches and keep prior batches on disk; this is what keeps generation inside a non-1M context.
 5.4. **Depth self-check (deterministic — BEFORE the audit).** Run `sungen depth-lint --screen ${input:name}`. It splits every shallow business-critical scenario into **DEEPEN IN PLACE** (add a real value assertion — the printed `template` is a theme-keyed hint, apply judgment to the actual claim; never fake one onto a visibility/behavior scenario) and **CROSS-SCREEN** (route to a flow / tag `@manual:Mx` + reason — removes it from the depth denominator honestly). Act on both, re-run until `deepen` is empty (or only honest over-counts remain), THEN gate. Lifts first-pass `businessDepth` mechanically instead of via 2–3 repair rounds.
-5.5. **Quality gate & repair (harness — always run).** Per `sungen-harness-audit`: run `sungen audit --screen ${input:name}` (structural), THEN do an **independent semantic review inline** using the `sungen-reviewer` criteria (does each scenario's steps PROVE its title/viewpoint? observable Thens? business-critical assertion depth?). Merge both sets of issues; if gate FAILs / findings exist, repair (budget 3) and re-audit — GATE missing theme → generate it (cross-screen → **automate it in the flow** via `/sungen:add-flow`, NOT a full `@manual` screen duplicate — `sungen audit` flags an automatable `@manual` as `MANUAL-AUTOMATABLE`; reserve `@manual:Mx` for true judgment/missing-capability); DEPTH → add data assertions; BALANCE → add business-core first; TRACE → align VP ids. Never fake a pass.
+5.5. **Quality gate & repair (harness — always run).** Per `sungen-harness-audit`: run `sungen audit --screen ${input:name}` (structural), THEN do an **independent semantic review inline** using the `sungen-reviewer` criteria. Copilot has no sub-agents, so walk the **lenses sequentially** (#410) — `correctness` (steps PROVE the title? observable, non-tautological Thens? negative-claim contrast?), `depth` (business-critical scenarios assert DATA, not visibility), `traceability` (meaning-level dups, missing criticals, VP-ids aligned), `manual` (each `@manual` genuinely unautomatable, not a cross-screen cop-out), `api` (API units only) — going deeper per lens than one blurred pass. Merge all lenses' issues (dedupe by `[scenario id]` + problem) with the audit findings; if gate FAILs / findings exist, repair (budget 3) and re-audit — GATE missing theme → generate it (cross-screen → **automate it in the flow** via `/sungen:add-flow`, NOT a full `@manual` screen duplicate — `sungen audit` flags an automatable `@manual` as `MANUAL-AUTOMATABLE`; reserve `@manual:Mx` for true judgment/missing-capability); DEPTH → add data assertions; BALANCE → add business-core first; TRACE → align VP ids. Never fake a pass.
 5.5b. **Phase gate (boundary — do NOT skip).** Run `sungen gate --screen ${input:name} --phase create` (exit 2 = HALT): every required obligation (spec · coverage · depth · trace) must be **satisfied or explicitly waived**. On **HALT**, keep repairing within budget; a genuinely-accepted gap → `sungen journey --screen ${input:name} --waive <OB> --reason "..."` (reason mandatory). Do **not** converge (step 6) past a HALT without a fix or a reasoned waiver.
 5.6. **Record.** `sungen manifest --screen ${input:name}`. Ledger **each phase** (not just repair) — pick one `runId` at the start and pass it so `trace`/`ledger report` show THIS run, not a mix: `sungen ledger record --screen ${input:name} --run <runId> --step <discovery|viewpoint|gherkin|audit|repair:N> --ms <elapsed>`. On re-run, start with `sungen manifest --screen ${input:name} --diff` and only regenerate changed sections.
 6. **Converge — show the journey board first, then the trace.** First run `sungen journey --screen ${input:name}` and present the board: **📍 you-are-here**, the **obligation checklist** (what must still be true), and **especially the 🔎 Review queue** — each item carries an IDE-jumpable anchor 〔`VP-id · file:line`〕 that tells the user *what to review and where*. End with the board's **→ Next**. Then run `sungen trace --screen ${input:name}` for the process map (phases + repair rounds), bottlenecks, audit score + gate + residual gaps. Then offer next steps based on which tier was just generated:

package/src/orchestrator/templates/ai-instructions/copilot-cmd-review.md

@@ -32,7 +32,7 @@ You are an **independent QA Reviewer** — you did not author these tests. You d
 1. **Enumerate** `<base>/${input:name}/features/*.feature`. If none → `/sungen-create-test` first.
 2. **Run the harness (source of truth) — no separate rubric:**
    - `sungen audit --screen ${input:name}` → gate, business-weighted score, findings, gaps.
-   - Apply the **`sungen-reviewer` criteria inline** → semantic verdict (do steps prove the title? observable Then? business-critical depth? @manual justified?).
+   - Apply the **`sungen-reviewer` criteria inline** → semantic verdict (do steps prove the title? observable Then? business-critical depth? @manual justified?). Walk the **lenses sequentially** (#410) — `correctness`, `depth`, `traceability`, `manual` (+ `api`) — deeper per lens than one pass, then merge + dedupe by `[scenario id]` + problem.
    - `sungen script-check --screen ${input:name}` → spec is 1:1 with the Gherkin (flags hand-edit / stale drift; only if a spec exists).
 3. **Unified scorecard** per feature, anchored on harness signals (the `sungen-tc-review` 7 dimensions are a presentation layer, not a competing score):
    ```

package/src/orchestrator/templates/ai-instructions/copilot-cmd-run-test.md

@@ -128,6 +128,7 @@ If the unit is **api-first**, skip every selector/capture phase (an API test has
 6. **Phase 2 — Priority Wave**: Run all `@high` scenarios. Fix only failures from this wave. Max 2 attempts. Shared selectors fixed here cascade to later phases.
 7. **Phase 3 — Full Run**: Run all tests. Fix only **new** failures (elements unique to `@normal`/`@low`). Max 1 attempt. Don't loop on low-priority failures.
 8. **Phase 4 — Regression**: One final full run. Report results. No more fix loops.
+   - **⚠️ SKIPPED ≠ passed (#414).** Suites are **per-scenario isolated by default** (failures isolate, all run). An **`@serial`** suite (`test.describe.serial`, shared page) **skips every test after the first failure** — "5 passed / 1 failed / 51 skipped" = 51 never ran. If you see that and the suite isn't a genuinely stateful sequence, **remove `@serial`, regenerate, re-run**. `sungen audit` flags it as **SERIAL-CASCADE-RISK**. Don't report an `@serial` run with many skips as green.
 9. **Integrity & trace (always run after the final run).** `sungen script-check --screen <name>` — verify the spec is a **1:1** of the Gherkin; if **DRIFT**, re-run `sungen generate --screen <name>` (never hand-edit the `.spec.ts` — auto-fix edits `selectors.yaml`). Then `sungen ledger record --screen <name> --step run --ms <elapsed>` and **present the journey board** — `sungen journey --screen <name>` — as the human-facing close-out: **📍 you-are-here**, the **obligation checklist**, and **especially the 🔎 Review queue** with per-item anchors 〔`VP-id · file:line`〕 (*review what / where*) plus any candidate bugs left FAILING by the source-of-truth rule (#387). Then `sungen trace --screen <name>` for the process map + bottlenecks; the board's **→ Next** says whether to sign off & deliver.
 9b. **Phase gate (boundary — do NOT skip).** `sungen gate --screen <name> --phase run` (exit 2 = HALT): run-boundary obligations (incl. automation) must be **satisfied or explicitly waived**. On HALT, classify per `sungen-error-mapping` § Source of truth (#387): selector-resolution failure → fix `selectors.yaml` + re-run; assertion-vs-spec failure → **report as a candidate bug / leave it FAIL** (never weaken to pass); accepted gap → `sungen journey --screen <name> --waive <OB> --reason "..."`. Don't declare "done" past a HALT without a fix, a reported bug, or a reasoned waiver.
 10. **Capability-pending offer (consent-gated).** If `sungen audit` reports `AUTOMATION-READY-PENDING` (or `@requires:<cap>` tests are skipped "requires …"), offer: *"N scenario(s) are automation-ready — enable `<cap>` to run them? (`sungen capability add <cap>`)"*. Only on the user's yes, run `sungen capability add <cap>` + re-run; on no, leave skipped (not failures, not manual). **Never auto-install.**

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-error-mapping.md

@@ -26,9 +26,12 @@ Then choose the fix from the patterns below.
 `.feature` + `test-data.yaml` + `spec.md` are the **oracle**. The **live page is NOT** — it may be the thing that's broken. A failing test is not automatically a test to "make pass". Classify first:
 
 - **Selector-resolution failure** (element not found / wrong locator / strict-mode / wrong element type) → the test looked in the wrong place. **Fix the locator in `selectors.yaml`** (re-snapshot, copy the exact accessible name). Legit auto-fix.
-- **Assertion-value failure** (element FOUND, but observed value ≠ expected) → STOP and ask: *is the TEST wrong, or is the APP wrong?*
-  - Expected value/rule is wrong **relative to `spec.md`** (typo, stale test-data) → fix `test-data.yaml`/`.feature` so it matches the **spec** — never the live page.
-  - App behaviour contradicts `spec.md` (spec says X, app shows Y) → **CANDIDATE BUG**. **Report it** (let the test FAIL / surface to the QA in the run summary). **NEVER** change the expected value, loosen the rule, weaken the assertion (`toHaveText`→`toContainText` to dodge a mismatch), edit `.feature`, or edit the generated `.spec.ts` to make it pass.
+- **Assertion-value failure** (element FOUND, but observed value ≠ expected) → STOP and ask the decisive question: ***does `spec.md` PIN this exact value?***
+  - **Spec PINS the value and live contradicts it** (spec mandates X, app shows Y) → **CANDIDATE BUG**. **Report it** (let the test FAIL). **NEVER** change the expected, loosen the rule, weaken the assertion (`toHaveText`→`toContainText`), shrink a boundary (`>8`→`>=6`), or edit `.feature`/`.spec.ts` to pass.
+  - **Spec does NOT pin the exact string, and your expected was your own transcription/guess** (whitespace, casing, punctuation, or a label the spec only *describes* narratively) while the live value is the legitimate, spec-consistent truth → **accuracy fix (allowed):** set `test-data.yaml`/`.feature` to the **real** value — *not* weakening, the claim is unchanged. (e.g. hero `<h1>` renders `AutomationExercise`; spec says "the Automation Exercise logo" but pins no string → fix `hero_title` to `"AutomationExercise"`, don't leave it failing.)
+  - Expected is wrong **relative to a value `spec.md` DOES state** (typo vs the spec) → fix to the **spec** value, never the live page.
+
+> **Accuracy fix vs weakening — the line:** an *accuracy fix* matches a spec-consistent reality the spec didn't pin (cosmetic, meaning preserved). *Weakening* changes the **oracle** to dodge a real discrepancy. **If the spec pins it, or you're unsure → treat as a bug and leave it failing.**
 
 > **Cardinal sin (do NOT do this):** a `password > 8 chars` rule fails on a 6-char input → "fix" it to `>= 6` so the test passes. The logic is now meaningless. A failing assertion is a **finding**, not a chore.
 

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-gherkin-syntax.md

@@ -206,7 +206,8 @@ Options: `nth` `exact` `scope` `match` `variant` `frame` `contenteditable` `colu
 | `@cleanup:scroll` | Auto-cleanup: scroll to top after each test (cleanupPage) |
 | `@cleanup:storage` | Auto-cleanup: clear sessionStorage after each test (cleanupPage) |
 | `@screenshot:on-failure` | Auto-capture screenshot when test fails (base.ts fixture) |
-| `@parallel` | Opt-out: fresh page per test instead of serial default (for independent scenarios) |
+| `@serial` | Opt-IN to a shared-page serial suite (`test.describe.serial`) for a genuinely STATEFUL ordered sequence (scenario N depends on N-1). Default is per-scenario isolation. ⚠️ a failure skips the rest. |
+| `@parallel` | Isolation (same as default) + a hint that the suite is safe to run with multiple workers / `fullyParallel`. |
 | `@beforeAll` | Hook: runs once before all tests → `test.beforeAll()` |
 | `@afterEach` | Hook: runs after each test → `test.afterEach()` (custom cleanup) |
 | `@afterAll` | Hook: runs once after all tests → `test.afterAll()` |
@@ -274,18 +275,21 @@ npx playwright test --grep "@high"           # only high priority
 npx playwright test --grep "@smoke|@high"    # smoke OR high
 ```
 
-### Serial vs Parallel (test execution mode)
+### Isolation vs Serial (test execution mode)
 
-**Default: serial** — `test.describe.serial()` with shared page. Background runs once in `beforeAll`. Fail → skip remaining.
+**Default: per-scenario isolation** — `test.describe()` with a **fresh page per scenario** (Background runs as `beforeEach`). A failure **isolates** — every scenario still runs (no skip-cascade). The scaffolded `playwright.config.ts` runs `workers: 1` (sequential) → no cross-test contention on a live site. Right for the vast majority of screens.
 
-**`@parallel` opt-out** — `test.describe()` with fresh page per test. Background runs as `beforeEach`. Use when scenarios are truly independent (validation rules, permission tests).
+**`@serial` opt-in** — `test.describe.serial()` with a **shared page** (Background once in `beforeAll`). Use ONLY for a genuinely **stateful ordered sequence** (scenario N depends on N-1). ⚠️ a failure **skips every remaining scenario** → one early red MASKS the rest. `sungen audit` emits **SERIAL-CASCADE-RISK** if an `@serial` suite is actually independent.
+
+**`@parallel`** — isolation (same as default) + a signal it's safe to run with multiple workers; raise `workers` / `fullyParallel` for speed once the target tolerates concurrency.
 
 | Mode | Generated | Page | Background | On fail |
 |---|---|---|---|---|
-| Serial (default) | `test.describe.serial()` | Shared | `beforeAll` (1 goto) | Skip remaining |
-| `@parallel` | `test.describe()` | Fresh per test | `beforeEach` (N goto) | Continue |
+| **Isolated (default)** | `test.describe()` | Fresh per scenario | `beforeEach` (N goto) | **Continue (isolated)** |
+| `@serial` (stateful opt-in) | `test.describe.serial()` | Shared | `beforeAll` (1 goto) | Skip remaining ⚠️ |
+| `@parallel` | `test.describe()` | Fresh per scenario | `beforeEach` | Continue (+ may multi-worker) |
 
-**`@parallel` is required** when a feature has multiple auth groups (e.g., `@auth:user` + `@no-auth` scenarios). Serial mode uses one shared browser context and cannot mix auth roles. The compiler will error if `@parallel` is missing in this case.
+Multiple auth groups (`@auth:user` + `@no-auth`) work under the default isolation (each sets its own `storageState`). Only `@serial` shares one context and cannot mix auth roles.
 
 ### `@flow` tag (E2E cross-screen testing)
 

package/src/orchestrator/templates/playwright.config.ts

@@ -37,14 +37,17 @@ export default defineConfig({
   testDir: './specs/generated',
   /* Output directory for test artifacts (screenshots, videos, traces). */
   outputDir: './test-results',
-  /* Run tests in files in parallel */
-  fullyParallel: true,
+  /* Sequential by default. Scenarios are per-scenario ISOLATED (each test gets a fresh page), so a
+     failure never cascades — but we run one-at-a-time (workers: 1) so a heavy live site isn't hit by
+     concurrent workers (which causes flaky timeouts / ad-consent races). Once your suite is stable
+     and your target tolerates concurrency, raise `workers` (and set `fullyParallel: true`) for speed. */
+  fullyParallel: false,
   /* Fail the build on CI if you accidentally left test.only in the source code. */
   forbidOnly: !!process.env.CI,
   /* Retry on CI only */
   retries: process.env.CI ? 2 : 0,
-  /* Opt out of parallel tests on CI. */
-  workers: process.env.CI ? 1 : 2,
+  /* One worker → sequential execution, no cross-test contention on the target site. */
+  workers: 1,
   /* Global timeout per test */
   timeout: 15_000,
   /* Reporter to use. See https://playwright.dev/docs/test-reporters */