@sun-asterisk/sungen 3.2.2 → 3.2.3-beta.3

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

@@ -1,93 +0,0 @@
----
-name: sungen-create-test
-description: 'Create or update test cases for a Sungen screen — generates feature + test-data files (tier-based: critical+high first, expand later). Uses sungen-gherkin-syntax and sungen-tc-generation skills.'
-argument-hint: '[screen-name]'
-agent: 'agent'
-tools: [vscode, execute, read, agent, edit, search, web, browser, todo, 'playwright/*']
----
-
-**Input**: Screen or flow name (e.g., `/sungen-create-test admin-users`).
-
-## Role
-
-You are a **Senior QA Engineer**. You structure test cases by viewpoint categories and translate UI into Gherkin test cases following the `sungen-gherkin-syntax` and `sungen-tc-generation` skills. **Tier 1 (critical+high) first** — expand coverage later. **Gherkin scenarios and test data only** — selectors are handled during `/sungen-run-test`.
-
-**Quality is built in.** After generating, run a **harness loop**: `sungen audit` measures the output and you **repair the findings** until critical viewpoints are covered — the user does not ask for this. Use the `sungen-harness-audit` skill. (`/sungen-design` is an **alias** of this command.)
-
-## Parameters
-
-- **name** — ${input:name:screen or flow name (e.g., login, award-submission)}
-
-**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>/`).
-
-## 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.
-
-## Steps
-
-1. **Flow**: Verify `qa/flows/${input:name}/` exists. If not → `/sungen-add-flow` first.
-   **Screen**: Verify `qa/screens/${input:name}/` exists. If not → `/sungen-add-screen` first.
-2. Check if `.feature` already has scenarios.
-   - If yes → summarize existing coverage and ask update mode (options depend on which tiers already exist — see `sungen-tc-generation` skill for details).
-   - If no → fresh creation. **Write the feature file incrementally** (successive writes/edits, ≈10-15 scenarios per call) — never emit the whole suite in one response, or it can exceed the model's output-token cap (`response exceeded the N output token maximum`). Ask generation scope:
-     - **1) Tier 1 — Critical & High priority** — ~10-15 scenarios/section: happy paths, core validation, security basics **(Recommended)**
-     - **2) Full coverage (incremental)** — Tier 1 + 2 + 3, written tier-by-tier in batches. Safe on any output-token budget.
-     - **3) Full coverage (single pass)** — everything in one go (~40-60 scenarios/section). Faster, but **only if you raised your output cap** (`CLAUDE_CODE_MAX_OUTPUT_TOKENS ≥ 64000`) — otherwise it errors mid-generation. For power users on a high-token model/config.
-3. **Read project context + screen requirements**
-
-   **Project context** — check `qa/context.md` (project root, not screen-specific):
-   - If exists → read it. Extract: roles, testing strategy directives, global business rules, error patterns.
-   - Summarize what you found in one line (e.g. `"Roles: admin/staff/user | Strategy: focus security, skip VP-UI T1 | 2 global rules"`).
-   - These are carried into the Coverage Map when invoking the `sungen-tc-generation` skill.
-   - If absent → continue without it, no action needed.
-
-   **Screen requirements** — check `<base>/${input:name}/requirements/`:
-   - If `spec.md` exists → read it as PRIMARY source (sections, fields, validation rules, business rules, states).
-   - If `test-viewpoint.md` exists → read it. If it only contains HTML comments (scaffold template), ask:
-     - **1) Fill test-viewpoint.md first** — identify edge cases, known issues, and design decisions before generating tests
-     - **2) Continue without it** — generate tests from spec and other sources only
-
-   **Auto-detect visual source** — do NOT ask the user to pick a source. Instead, check what already exists and use it:
-   1. If `spec_figma.md` exists → read it as Figma supplement (PAT flow already completed during `add-screen`). Do NOT call any `mcp__figma__*` tool.
-   2. If `ui/` has images (`.png`, `.jpg`, etc.) → read them for visual context (layout, element positions, states).
-   3. If neither exists → ask: *"No visual source found. Pick one:"* — then invoke the **`sungen-capture`** skill with the matching **mode** (read only that mode's file):
-      - **1) Figma PAT** — ask for URL, run `sungen add --screen ${input:name} --figma '<url>'`, then `sungen-capture` **mode figma-pat**
-      - **2) Figma MCP** — `sungen-capture` **mode figma-mcp**
-      - **3) Live page scan** — `sungen-capture` **mode live**
-      - **4) Skip** — generate from spec.md only
-
-   (When `spec_figma.md` exists, that is also `sungen-capture` **mode figma-pat**; when `ui/` images exist, that is **mode local**.)
-
-   **Cross-check**: if both `spec.md` and visual sources exist, flag any discrepancies (missing fields, different labels) before moving on. When `spec_figma.md` is present, follow the Figma supplement rules in `sungen-tc-generation` skill (reading order, Text Inventory, conflict handling).
-
-   Summarize what you found in requirements and present to the user.
-
-4. Follow the `sungen-tc-generation` skill for section identification, viewpoint generation, and output format. **For flows**, use the "Flow Test Generation" section in the skill. When requirements exist, use the "Requirements-Driven Generation" strategy. **For Tier 1**, apply the **Lightweight Guard** — verify required fields, validation rules, business rules, security checks, and key state transitions all have TCs after generation. **For Tier 2+**, **MUST** apply the full **Mapping Contract** — walk every `spec.md` section top-to-bottom and produce the indicated TCs per Table 1; handle `test-viewpoint.md` per Table 2. Do not silently skip sections. Present sections as a numbered list and let user pick.
-5. Generate or update `.feature` + `test-data.yaml` following `sungen-gherkin-syntax` and `sungen-tc-generation` skills. Generate **group-by-group** (one viewpoint group at a time, tier-by-tier `Write`/`Edit` batches) to stay under the output-token cap. **For flows**: use `[Screen:Element]` namespace format, namespace test-data by phase, add `@flow` tag.
-   > **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.
-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.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 trace.** Run `sungen trace --screen ${input:name}` and present: process map (phases + repair rounds), bottlenecks, **HUMAN-LOOP FOCUS** (@manual to verify), audit score + gate + residual gaps. Then offer next steps based on which tier was just generated:
-
-   > The harness gate + reviewer already ran above — `/sungen-review` is the independent checkpoint (hand/prompt-authored or pre-delivery), not a needed next step here.
-
-   **Optional — exploration mode (Loop 2).** The suite above is the deterministic official output. To push past "same output every time", offer the **challenge pass**: run `sungen challenge --screen ${input:name}` (deterministic structural critics), then apply the `sungen-challenge` criteria inline for semantic + novelty candidates. Advisory only — surfaces blind spots + ≤20% novelty candidates, never auto-merges. Record a confirmed recurring miss with `sungen blindspot add` so future runs don't repeat it.
-
-   **After Tier 1 generation:**
-   - **`/sungen-run-test ${input:name}`** — Generate selectors and run tests now (Recommended)
-   - **`/sungen-create-test ${input:name}`** — Expand coverage: add @normal + @low scenarios (Tier 2)
-   - **Done for now** — I'll come back later
-
-   **After Tier 2 generation:**
-   - **`/sungen-create-test ${input:name}`** — Deep coverage: add BVA combos, cross-field validation, negative inputs, race conditions (Tier 3) (Recommended)
-   - **`/sungen-run-test ${input:name}`** — Generate selectors and run tests now
-   - **Done for now** — I'll come back later
-
-   **After Tier 3 or Full generation:**
-   - **`/sungen-run-test ${input:name}`** — Generate selectors and run tests now (Recommended)
-   - **`/sungen-create-test ${input:name}`** — Add more sections if the screen changed
-   - **Done for now** — I'll come back later
-
-**No selectors.yaml** — selectors are generated during `/sungen-run-test`.

package/dist/orchestrator/templates/ai-instructions/copilot-cmd-dashboard.md

@@ -1,65 +0,0 @@
----
-name: sungen-dashboard
-description: 'Build a single-file HTML dashboard with test cases + pass/fail results, history trends, compare runs, and CSV/XLSX export.'
-argument-hint: "[screen-name...] (omit for all)"
-tools: [read, execute, edit, vscode/askQuestions]
----
-
-## Role
-
-You are a **QA Reporting Engineer**. Your job is to invoke the deterministic `sungen dashboard` CLI which builds a self-contained HTML report. The HTML is shareable as-is (open via `file://`, no server required).
-
-## Parameters
-
-Parse **screens** from `$ARGUMENTS`:
-- If empty → CLI will include **all** screens and flows.
-- If provided → pass them through.
-
-## Steps
-
-### 1. Invoke the CLI
-
-Prefer the local `./bin/sungen.js` when it exists (sungen monorepo dev). Fall back to `npx sungen` for downstream projects.
-
-```bash
-# Local-first dispatcher — works in both monorepo and consumer projects:
-[ -x ./bin/sungen.js ] && ./bin/sungen.js dashboard <screens> || npx sungen dashboard <screens>
-```
-
-- No args → all screens + flows.
-- With args → only those targets.
-- Add `--open` to auto-open the rendered HTML in the user's browser.
-
-The CLI handles:
-- Discovery of `qa/screens/*` and `qa/flows/*`.
-- Reuses the same parsers as `sungen delivery` (feature, spec.ts, test-data.yaml, results.json).
-- Builds `DashboardSnapshot` JSON.
-- Persists `qa/dashboard/history/<runId>.json` (max 10 retained, oldest pruned).
-- Renders `qa/dashboard/index.html` (~1MB, single file, fully self-contained).
-- Prints a summary table.
-
-### 2. Show the result + offer next steps
-
-Forward the CLI's summary verbatim, then ask the user what they want next:
-
-- **Open the dashboard** — Suggest `npx sungen dashboard --open` or open `qa/dashboard/index.html` manually.
-- **Re-run after a test run** — Run `/sungen:run-test <screen>` to refresh `test-results/results.json`, then re-invoke `/sungen:dashboard`.
-- **Build for a single screen** — Run `/sungen:dashboard <screen>` to scope the report.
-- **Share the file** — The HTML at `qa/dashboard/index.html` can be emailed / Slacked / committed; recipients open it directly without any server.
-- **Done** — Exit.
-
-## Important notes
-
-- **Do NOT parse files yourself** — the CLI is the source of truth.
-- **The HTML is stateless** — the snapshot is embedded in `<script id="__SUNGEN_DASHBOARD__" type="application/json">…</script>`. Re-running the CLI overwrites this file.
-- **History is retained in `qa/dashboard/history/`** — these JSON files power the Trends and Compare views. Keep them in git so collaborators see the same trend.
-- **CSV/XLSX export** in the dashboard runs entirely in the browser (SheetJS) and matches the `sungen delivery` format. Use it for quick exports without re-running the CLI.
-
-## CLI Reference
-
-```
-sungen dashboard [screens...]
-  [--no-history]            Do not persist this run under qa/dashboard/history/
-  [--max-history <n>]       Cap retained history files (default: 10)
-  [--open]                  Open the rendered HTML in the default browser
-```

package/dist/orchestrator/templates/ai-instructions/copilot-cmd-delivery.md

@@ -1,83 +0,0 @@
----
-name: sungen-delivery
-description: 'Export Gherkin scenarios + Playwright results to CSV test case file for QA delivery.'
-argument-hint: "[name...] [--env <locale>] (omit names for all targets; --env for locale-specific export)"
-tools: [read, execute, edit, vscode/askQuestions]
----
-
-## Role
-
-You are a **QA Test Delivery Engineer**. Your job is to invoke the deterministic `sungen delivery` CLI that performs all parsing and CSV export. Your role is minimal — just run the CLI and help the user if pre-flight checks fail.
-
-## Parameters
-
-Parse from `$ARGUMENTS`:
-- **names** — zero or more screen/flow names. Empty → CLI processes all targets in `qa/screens/` + `qa/flows/`.
-- **`--env <locale>`** — optional. Sets `SUNGEN_ENV=<locale>` for the run so the CLI merges `<name>.<locale>.yaml` over the base test-data and writes `<name>-testcases.<locale>.csv` / `.xlsx`. Accept `--locale <locale>` as an alias.
-
-If `--env` is passed but no value follows, ask the user which locale to use.
-
-## Steps
-
-### 1. Invoke the CLI
-
-Run via Bash (single command, no extra parsing):
-
-```bash
-# No env — local-first dispatcher:
-[ -x ./bin/sungen.js ] && ./bin/sungen.js delivery <names> || npx sungen delivery <names>
-
-# Locale-specific:
-[ -x ./bin/sungen.js ] && SUNGEN_ENV=<locale> ./bin/sungen.js delivery <names> || SUNGEN_ENV=<locale> npx sungen delivery <names>
-```
-
-- If no name args → omit `<names>` (CLI processes all targets).
-- If `--env <locale>` was provided → prepend `SUNGEN_ENV=<locale>` to the command. Do NOT pass `--env` to the CLI itself — it's not a CLI flag, only a slash-command convenience.
-
-The CLI handles:
-- Scope detection (all screens + flows vs specific names)
-- Auto-detect: `qa/flows/<name>/` → flow, `qa/screens/<name>/` → screen
-- Pre-flight source checks with colorful output
-- Parsing `.feature`, `.spec.ts`, `test-data.yaml` (+ `<name>.<env>.yaml` overlay when `SUNGEN_ENV` is set), and per-target `<name>-test-result[.<env>].json`
-- Generating CSV/XLSX at `qa/deliverables/<name>-testcases[.<env>].csv` / `.xlsx`
-- Printing summary table
-
-### 2. Handle pre-flight failures (if CLI exits non-zero)
-
-If the CLI exits with blocking issues, it will have already printed a clear table showing exactly what's missing per target.
-
-Use `AskUserQuestion` to offer next steps:
-
-**Options:**
-- **Fix missing sources** (Recommended) — Print the suggested commands from CLI output and stop. User will run those commands manually, then re-invoke `/sungen:delivery`.
-- **Continue with available targets** — Re-run as `npx sungen delivery <names> --continue-on-missing` to skip targets with blocking issues.
-- **Cancel** — Exit.
-
-### 3. Show summary + offer next steps (on success)
-
-Forward the CLI's summary table to the user verbatim. Then use `AskUserQuestion`:
-
-- **Open a specific CSV** — Help user inspect one of the exported files with Read tool.
-- **Run tests to refresh results** — Suggest `/sungen-run-test <name>` to update test results, then re-run delivery.
-- **Export another target** — User can run `/sungen-delivery <other-name>`.
-- **Done** — Exit.
-
-## Important notes
-
-- **Do NOT parse files yourself** — the CLI is the source of truth for parsing logic. Your job is orchestration + user interaction.
-- **Do NOT modify feature/spec.ts/test-data files** — the delivery is read-only.
-- **The CLI already respects `@manual` tags, skips `@steps:` base scenarios, groups by Category 2, and generates UTF-8 BOM CSV for Excel compatibility with Vietnamese.**
-- **Pre-flight check is built into the CLI** — use `--skip-preflight` only in CI/automated pipelines where checks are done externally.
-
-## CLI Reference
-
-```
-sungen delivery [names...]
-  [--skip-preflight]          Skip pre-flight checks (not recommended)
-  [--continue-on-missing]     Skip targets with blocking misses
-
-# Locale-aware export (env var, not a CLI flag):
-SUNGEN_ENV=<locale> sungen delivery [names...]
-  → reads <name>.<locale>.yaml overlay, picks <name>-test-result.<locale>.json,
-    writes <name>-testcases.<locale>.csv / .xlsx
-```

package/dist/orchestrator/templates/ai-instructions/copilot-cmd-design.md

@@ -1,13 +0,0 @@
----
-name: sungen-design
-description: 'Alias of create-test. Generates test cases AND runs the quality harness (gate + repair). Kept for discoverability; create-test now does this by default.'
-argument-hint: '[screen-name]'
-agent: 'agent'
-tools: [vscode, execute, read, agent, edit, search, web, browser, todo, 'playwright/*']
----
-
-## `/sungen-design` is an alias of `/sungen-create-test`
-
-As of v3.0 the quality harness (discovery → viewpoint overview → generate → **`sungen audit` gate → repair loop** → manifest/ledger) is built into **`/sungen-create-test`** by default — no second command needed for quality.
-
-**Do exactly what `/sungen-create-test <name>` does** — follow that command verbatim, including the mandatory harness gate & repair step and the `sungen-harness-audit` skill. This entry exists only to keep the `design` name discoverable.

package/dist/orchestrator/templates/ai-instructions/copilot-cmd-feedback.md

@@ -1,24 +0,0 @@
----
-name: sungen-feedback
-description: 'Record QA feedback locally (test-design knowledge or product telemetry). Auto-attaches context and stores to .sungen/feedback/.'
-argument-hint: '[message]'
-agent: 'agent'
-tools: [vscode, execute, read, search]
----
-
-## Role
-Capture QA feedback and store it **locally** (no server) via `sungen feedback record`. Closes the learning loop inside the project; the harness can reuse it later.
-
-## Steps
-1. Read message from arguments (ask if empty).
-2. **Classify**: `test-design` (viewpoint/scenario wrong/missing/duplicate/add), `product` (Sungen itself misbehaved), or `other`. Infer; confirm only if ambiguous.
-3. **Auto-attach context** (don't make the user repeat): `--screen <name>` (current focus), `--target <ref>` (VP id / scenario / command / artifact), `--decision <accept|reject|edit|add|none>`, `--reason <text>`.
-4. Run:
-   ```bash
-   sungen feedback record --type <type> --screen <name> --target "<ref>" --decision <d> --message "<msg>" --reason "<why>"
-   ```
-5. Confirm what/where (`.sungen/feedback/feedback.jsonl`). It is **local**; cross-project sync is opt-in later.
-6. If feedback implies an action (missing critical viewpoint), offer `sungen-design <name>` (regenerate with gate) or `sungen-add-flow` (cross-screen gap).
-
-## Notes
-- Never send anywhere — local file only. Keep `product` vs `test-design` distinct. View: `sungen feedback list`.

package/dist/orchestrator/templates/ai-instructions/copilot-cmd-locale.md

@@ -1,70 +0,0 @@
----
-name: sungen-locale
-description: 'Bootstrap i18n for a screen/flow — audit selectors, detect locale switch mechanism via Playwright, generate test-data overlay so `sungen:run-test --env <locale>` works.'
-argument-hint: "<name> <locale> [--base-locale <code>] [--offline]"
-tools: [read, execute, edit, vscode/askQuestions, playwright/*]
----
-
-## Role
-
-You are a **Senior QA Localization Engineer**. Use the `sungen-locale` skill — it contains the full phased strategy. Your job in this command is parameter parsing, context detection, and final hand-off.
-
-## Parameters
-
-Parse from `$ARGUMENTS`:
-- **name** — screen or flow name (e.g. `home`, `awards`). If missing, ask the user.
-- **locale** — target locale code (e.g. `en`, `ja`, `en-US`, `staging-ja`). If missing, ask. This becomes the suffix in `test-data/<feature>.<locale>.yaml` and `SUNGEN_ENV=<locale>` at run time.
-- **`--base-locale <code>`** — optional. Locale of the existing `test-data/<feature>.yaml`. Default `vi`. Reporting only — files are never renamed.
-- **`--offline`** — force OFFLINE mode (skip Playwright capture). Useful when you know the live page can't be reached.
-
-Reject if name == locale.
-
-## Auto-detect context
-
-Same as `/sungen:run-test`:
-- `qa/flows/<name>/` exists → flow mode (base path: `qa/flows/<name>/`)
-- Else `qa/screens/<name>/` exists → screen mode (base path: `qa/screens/<name>/`)
-- Neither → tell user and stop
-
-## Steps
-
-The `sungen-locale` skill defines 7 phases. Execute them in order:
-
-1. **Phase 1 — Selector audit** (always, no MCP)
-2. **Phase 2 — Capture base locale** (Live mode only)
-3. **Phase 3 — Switch locale + detect mechanism** (Live mode only)
-4. **Phase 4 — Diff base ↔ target** (Live mode only)
-5. **Phase 5 — Confirm proposal** (always)
-6. **Phase 6 — Apply files** (always, after confirmation)
-7. **Phase 7 — Hand off** (always)
-
-**Mode selection** happens at the start of Phase 2:
-
-- If `--offline` flag → OFFLINE mode (skip Phases 2-4).
-- Else try `browser_navigate(baseURL)` — succeeds + page renders content → LIVE mode.
-- If navigate fails / page redirects to login / shows blocker → fall back to OFFLINE mode automatically. Announce the fallback clearly.
-
-## Enumerate features
-
-Multi-feature screens (e.g. `home` has `home.feature` + `home-modal.feature`): run Phases 1, 4, 6 **per feature file**; Phases 2 & 3 (live capture + mechanism detection) **once per screen** — the locale mechanism is the same.
-
-```bash
-ls qa/screens/<name>/features/*.feature
-# or
-ls qa/flows/<name>/features/*.feature
-```
-
-## After Phase 7
-
-Offer the user:
-
-- **`/sungen:run-test <name> --env <locale>`** — Run tests against the new locale (Recommended)
-- **`/sungen:locale <name> <other-locale>`** — Bootstrap another locale
-- **Open the overlay file** for review/edit
-- **Done**
-
-## Notes
-
-- Do NOT run tests yourself. `/sungen:run-test` is the executor; this command only PREPS files.
-- Do NOT modify `.feature` files. Localization lives in `selectors/*.yaml` + `test-data/*.yaml` only.
-- Auth blocked? Use `--offline`.

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

@@ -1,38 +0,0 @@
----
-name: sungen-review
-description: 'Independent quality checkpoint for test cases — runs the harness (audit gate + reviewer criteria + script-check) and presents one unified scorecard. Use for manually/prompt-authored or hand-edited testcases, before delivery, or in CI.'
-argument-hint: '[screen-name]'
-agent: 'agent'
-tools: [vscode, execute, read, edit, search, todo]
----
-
-**Input**: Screen or flow name (e.g., `/sungen-review admin-users`).
-
-## Role
-
-You are an **independent QA Reviewer** — you did not author these tests. You do **not** invent a parallel score; you run the **harness** and present its signals as a human scorecard. Skills: `sungen-tc-review` (presentation rubric), `sungen-viewpoint`, `sungen-gherkin-syntax`.
-
-## When this matters
-
-`/sungen-create-test` already runs the harness gate while generating, so you don't need to review right after it. Run `/sungen-review` when the harness did **not** run or you need an independent sign-off: hand/prompt-authored testcases, a hand-edited `.feature`, **before `/sungen-delivery`**, or in **CI**.
-
-## Parameters
-- **name** — ${input:name:screen or flow name}
-**Auto-detect context**: `qa/flows/<name>/` → flow, else `qa/screens/<name>/` → screen.
-
-## Steps
-
-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?).
-   - `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):
-   ```
-   Feature        Gate   Score   Reviewer        Spec 1:1   Verdict
-   home.feature   PASS   8.4/10  2 minor issues  in-sync    PASS
-   ```
-   PASS = gate PASS + reviewer clean + spec in-sync. Else CONDITIONAL/FAIL with findings + fixes. Score = audit score adjusted by unresolved reviewer issues — never contradicting the gate.
-4. **Repair (on confirm)** — apply audit findings + reviewer fixes (use `remember`/`see all` per `sungen-harness-audit`), re-run step 2 on the affected file. On drift → `sungen generate` to resync (never hand-edit the spec).
-5. **Trace + next** — `sungen trace --screen ${input:name}` (human-loop focus), then offer:
-   - **`/sungen-run-test ${input:name}`** (Recommended) · **`/sungen-delivery ${input:name}`** · **`/sungen-create-test ${input:name}`** · Done.

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

@@ -1,155 +0,0 @@
----
-name: sungen-run-test
-description: 'Generate selectors + auth state via Playwright MCP, compile, and run Playwright tests — auto-fixes selectors on failure'
-argument-hint: "[name] [--env <locale>]"
-tools: [read, execute, edit, vscode/askQuestions, playwright/*]
----
-
-## Role
-
-You are a **Senior Developer**. Use `sungen-selector-fix`, `sungen-selector-keys`, and `sungen-error-mapping` skills.
-
-## Parameters
-
-Parse from `$ARGUMENTS`:
-- **name** — screen or flow name. If missing, ask the user.
-- **`--env <locale>`** — optional. Sets `SUNGEN_ENV=<locale>` for the test run so the runtime test-data resolver merges `<name>.<locale>.yaml` over the base, and `playwright.config.ts` writes results to `<name>-test-result.<locale>.json`. Accept `--locale <locale>` as an alias.
-
-If `--env` is passed but no value follows, ask the user which locale to use.
-
-**`--env <locale>` pre-flight**: when `--env` is passed AND the matching overlay file doesn't exist yet (`test-data/<feature>.<locale>.yaml` missing), tests will silently fall back to base locale — the run will execute but won't actually exercise the locale. Before Phase 0.5, check:
-
-```bash
-ls qa/<screens|flows>/<name>/test-data/*.<locale>.yaml 2>/dev/null | wc -l
-```
-
-Count 0 → offer the user:
-- **Run `/sungen-locale <name> <locale>` first** (Recommended) — bootstrap the overlay
-- **Continue anyway** — tests will likely fail on a real locale page
-- **Cancel**
-
-Skip when `--env` matches the base locale.
-
-**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>/`).
-
-## API unit mode (driver-api) — no selectors
-
-If the unit is **api-first**, skip every selector/capture phase (an API test has no DOM):
-1. **Resolve the datasource** — `base_url` + auth wired in `qa/datasources.yaml` + `.env.qa` (`${X_URL}` from `sungen api init`); a `production` datasource is refused unless `SUNGEN_ALLOW_PROD=1`.
-2. **Compile**: `npx sungen generate --area <name>` → `specs/generated/api/<name>/`.
-3. **Run**: `npx playwright test specs/generated/api/<name>/<name>.spec.ts`.
-4. **Auto-fix** (use `sungen-error-mapping`): 401/403 → `@hybrid`+`@auth` or `Bearer :token` header (`sungen makeauth`); base_url unresolved → set `${X_URL}`; missing param → trace `{{var}}` to test-data/a prior `@api` response; `expect.status` mismatch → reconcile against `apis.yaml` (re-`generate --area`, never hand-edit the spec); **400 "parameter missing" / body ignored → set `encoding: form` (or `multipart`) on the catalog entry, don't mark @manual**; flaky → self-clean + `@concurrent` caps.
-5. **Integrity + trace** — `sungen script-check --area <name>` (1:1; on DRIFT re-`generate --area`, never hand-edit the spec) + `sungen trace --area <name>` (process map + HUMAN-LOOP FOCUS). Report + offer next steps.
-
-## Pre-run (phased — per `sungen-selector-fix` skill)
-
-1. Verify `<base>/<name>/` has `.feature` + `test-data.yaml`.
-2. **Phase 0 — Selector Pre-gen**: if `selectors.yaml` is missing/empty or doesn't cover the feature file's `[Reference]`s, apply the following decision tree before running Phase 0 from `sungen-selector-fix`:
-
-   ```
-   Phase 0 — Selector Generation decision tree
-
-   Live page reachable? (URL provided and loads without error)
-     YES → existing flow: browser_navigate → wait for page to fully load (no spinner/skeleton/empty table) →
-            one browser_snapshot → cross-verify every [Reference] label vs snapshot name →
-            generate selectors.yaml (verified entries; explicit YAML for any label≠DOM-name mismatch)
-     NO  → spec_figma.md exists in requirements/?
-             YES → provisional flow (sungen-capture mode figma-pat + sungen-selector-fix skills):
-                   1. Read filtered Figma node data from spec_figma.md (## Components + ## Text Inventory)
-                   2. Apply selector priority from sungen-selector-fix § Step 3 (testid > role+name > label > placeholder > text > locator CSS last)
-                   3. Write selectors.yaml — every provisional entry gets this comment on the line above:
-                          # @needs-live-verify source=figma node_id=<id>
-                   4. Compile: Screen: sungen generate --screen <name>. Flow: sungen generate --flow <name> — must succeed
-                   5. Phase 1 smoke check runs; tests using unverified selectors may fail
-                      → auto-fix triggers on next run-test invocation when a live page is available
-             NO  → hard stop: print the following message and stop:
-                   "Cannot generate selectors: no live page URL and no spec_figma.md found.
-                    Options:
-                    • Provide the live URL so Playwright MCP can snapshot the page, OR
-                    • Run: sungen add --screen <name> --figma <figma-url>  to generate spec_figma.md first"
-   ```
-
-   **Auto-fix on subsequent runs**: when `run-test` is invoked again with a reachable live page, Phase 0 compares the DOM snapshot against existing `selectors.yaml` entries. Entries tagged `# @needs-live-verify` are treated as candidates — if the actual selector differs, the entry is replaced and the comment removed (entry becomes verified). Entries that already match are also promoted to verified (comment removed).
-
-   **`@needs-live-verify` comment format** (one comment line, directly above the YAML key):
-   ```yaml
-   # @needs-live-verify source=figma node_id=<figma-node-id>
-   submit-button:
-     type: role
-     value: button
-     name: "Submit"
-   ```
-3. **Phase 0.5 — Auth Persistence**: if the feature has `@auth:<role>` tags and `specs/.auth/<role>.json` is missing/expired, run Phase 0.5 from `sungen-selector-fix` — user logs in manually in MCP browser → `browser_storage_state` → `specs/.auth/<role>.json`. Offer `sungen makeauth <role>` as CLI fallback only if `browser_storage_state` isn't available in this MCP version.
-4. Compile via local-first dispatcher so the sungen monorepo's unpublished selector-resolver features (i18n `{{var}}` interpolation, namespaced selector lookup) are picked up:
-   - **Screen**: `[ -x ./bin/sungen.js ] && ./bin/sungen.js generate --screen <name> || npx sungen generate --screen <name>`
-   - **Flow**: `[ -x ./bin/sungen.js ] && ./bin/sungen.js generate --flow <name> || npx sungen generate --flow <name>`
-
-   Default: runtime data loading from YAML. Use `--inline-data` only if user requests compile-time hardcoded values.
-
-## Run & Fix (phased — per `sungen-selector-fix` skill)
-
-5. **Phase 1 — Smoke Check**: Run first 5 `@high` scenarios only. If failures → diagnose, fix fundamentals (page selector, auth, base @steps), re-run. Max 2 attempts. If still broken → ask user.
-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.
-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 `sungen trace --screen <name>` to show the process map + bottlenecks + **HUMAN-LOOP FOCUS**.
-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.**
-
-## Playwright command guidelines
-
-**Multi-feature screens** — `sungen generate --screen <name>` produces one `<basename>.spec.ts` per `.feature` file (e.g. `home.spec.ts` + `home-modal.spec.ts`). You must **invoke playwright once per spec file** so each gets its own JSON result that `sungen delivery` can pick up. Do NOT run a single command with the directory as the test argument — that bundles everything into one results file that delivery can't disambiguate.
-
-**Per-spec JSON results** — each invocation writes its JSON report to a path matching the spec basename. When `--env <locale>` was parsed from `$ARGUMENTS`, prepend `SUNGEN_ENV=<locale>` — `playwright.config.ts` auto-inserts `.<locale>` before `.json` in the output path:
-
-```bash
-# ✅ Screen with 1 feature
-PLAYWRIGHT_JSON_OUTPUT_NAME=specs/generated/<name>/<name>-test-result.json \
-  npx playwright test specs/generated/<name>/<name>.spec.ts
-
-# ✅ Screen with multiple features — loop in shell:
-for spec in specs/generated/<name>/*.spec.ts; do
-  base=$(basename "$spec" .spec.ts)
-  PLAYWRIGHT_JSON_OUTPUT_NAME="specs/generated/<name>/${base}-test-result.json" \
-    npx playwright test "$spec"
-done
-
-# ✅ Locale 'vi' — same loop, just prepend SUNGEN_ENV=vi
-for spec in specs/generated/<name>/*.spec.ts; do
-  base=$(basename "$spec" .spec.ts)
-  SUNGEN_ENV=vi \
-  PLAYWRIGHT_JSON_OUTPUT_NAME="specs/generated/<name>/${base}-test-result.json" \
-    npx playwright test "$spec"
-done
-
-# ✅ Flow
-PLAYWRIGHT_JSON_OUTPUT_NAME=specs/generated/flows/<name>/<name>-test-result.json \
-  npx playwright test specs/generated/flows/<name>/<name>.spec.ts
-```
-
-**DO NOT** pass `--reporter=...` flag — it overrides the reporters from `playwright.config.ts` and disables the JSON reporter that `sungen delivery` depends on.
-
-```bash
-# ❌ Wrong — --reporter flag disables the config's JSON reporter
-npx playwright test specs/generated/<name>/<name>.spec.ts --reporter=list
-
-# ❌ Wrong — no env var → writes to default test-results/results.json
-# (overwritten on every screen run, loses per-screen tracking)
-npx playwright test specs/generated/<name>/<name>.spec.ts
-```
-
-If you want to filter scenarios, use `-g "<pattern>"` instead of a reporter override.
-
-`sungen delivery` reads per-feature `<basename>-test-result[.env].json` files (one per feature in the screen) and writes one CSV/XLSX per feature (e.g. `home-testcases.csv` + `home-modal-testcases.csv`). When `--env <locale>` was used here, run delivery with the same locale (`/sungen-delivery <name> --env <locale>`) so it picks the matching `*-test-result.<locale>.json` files and produces `*-testcases.<locale>.csv` / `.xlsx`.
-
-## Next steps
-
-After showing results, use `AskUserQuestion` to offer next steps:
-
-If all tests **passed**:
-- **`/sungen-create-test <name>`** — Add more test cases (Recommended)
-- **Done** — All tests passed, I'm finished
-
-If tests **failed** (after retries):
-- **`/sungen-run-test <name>`** — Re-run after manual fixes
-- **`/sungen-create-test <name>`** — Revise test cases
-- **Done for now** — I'll fix manually later