@sun-asterisk/sungen 2.6.11 → 2.6.14

package/dist/orchestrator/templates/ai-instructions/claude-skill-selector-keys.md

@@ -115,6 +115,44 @@ gửi lời cảm ơn--3:
   name: 'Gửi lời cảm ơn'
 ```
 
+## i18n: Template Variables in Selectors
+
+For multilingual sites without `data-testid`, use `{{variable}}` in `name` or `value` fields to reference locale-dependent text from `test-data.yaml`.
+
+```yaml
+# selectors — one file for all locales
+submit:
+  type: role
+  value: button
+  name: "{{lbl_submit}}"
+
+search:
+  type: placeholder
+  value: "{{lbl_search}}"
+
+logo:
+  type: testid
+  value: app-logo            # testid is locale-independent — no variable needed
+```
+
+```yaml
+# test-data/login.yaml (base — English)
+lbl_submit: "Sign in"
+lbl_search: "Search..."
+
+# test-data/login.vi.yaml (Vietnamese)
+lbl_submit: "Đăng nhập"
+lbl_search: "Tìm kiếm..."
+```
+
+Run: `SUNGEN_ENV=vi npx playwright test`
+
+**Rules:**
+1. Prefix i18n keys with `lbl_`, `msg_`, `txt_` to separate from test data
+2. Prefer `data-testid` — only use `{{variable}}` when no stable selector exists
+3. Feature file stays identical across locales
+4. Requires runtime data mode (default, not `--inline-data`)
+
 ## Lookup Priority
 
 Resolver searches in this order:

package/dist/orchestrator/templates/ai-instructions/claude-skill-tc-generation.md

@@ -352,6 +352,8 @@ Feature: <Screen> Screen
 
 **Environment-specific data**: create `<screen>.<env>.yaml` alongside the base file with only the keys that change. Users run `SUNGEN_ENV=staging npx playwright test` to merge overrides.
 
+**i18n / multilingual**: use the same `SUNGEN_ENV` overlay for locale variants — e.g., `login.vi.yaml`, `login.staging-ja.yaml`. Include `lbl_*` / `msg_*` keys for selector `{{variable}}` references (see `sungen-selector-keys` § i18n). One feature file + one selector file works across all locales.
+
 ## Flow Test Generation
 
 When generating tests for a **flow** (`qa/flows/<name>/`), adapt the strategy:

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

@@ -1,41 +1,59 @@
 ---
 name: sungen-add-screen
-description: 'Add a new Sungen screen — scaffolds directories, helps fill spec.md, and can auto-capture a live-page screenshot via Playwright MCP'
-argument-hint: '[screen-name] [url-path] [--figma <url>]'
+description: 'Add a new Sungen screen or a sub-feature to an existing one — scaffolds directories, helps fill spec.md, and can auto-capture a live-page screenshot via Playwright MCP'
+argument-hint: '[screen-name] [url-path] [--feature <name>] [--figma <url>]'
 agent: 'agent'
 tools: [vscode, execute, read, agent, edit, search, web, browser, todo, 'playwright/*']
 ---
 
 **Input**: Screen name and URL path (e.g., `/sungen-add-screen login /login`).
 Optionally include a Figma URL: `/sungen-add-screen login /login --figma https://www.figma.com/design/...`.
+To add a sub-feature file to an existing screen: `/sungen-add-screen awards --feature modal`.
 
-You are adding a new Sungen screen for test generation.
+You are adding a new Sungen screen for test generation, or extending an existing screen with an additional `.feature` file (sub-feature).
 
 ## Parameters
 
 - **screen** — ${input:screen:screen name (e.g., login, dashboard)}
-- **path** — ${input:path:URL path (e.g., /login, /dashboard)} — optional when --figma is provided
-- **--figma \<url\>** — Figma share URL (optional)
-- **--refresh** — bypass Figma cache and re-fetch (optional, use with --figma)
-- **--scale \<n\>** — PNG export scale factor, default 2 (optional)
-- **--hi-res** — export at 4× scale, shorthand for --scale 4 (optional)
+- **path** — ${input:path:URL path (e.g., /login, /dashboard)} — optional when --figma is provided or when adding a sub-feature
+- **`--feature <name>`** — sub-feature name to add to an existing screen (e.g., `modal`, `filter`, `create-flow`). Creates `<screen>-<feature>.feature` + matching `selectors/<screen>-<feature>.yaml` + `test-data/<screen>-<feature>.yaml` without touching the screen's other files. Use this when one screen has multiple `.feature` files.
+- **`--figma <url>`** — Figma share URL (optional)
+- **`--refresh`** — bypass Figma cache and re-fetch (optional, use with --figma)
+- **`--scale <n>`** — PNG export scale factor, default 2 (optional)
+- **`--hi-res`** — export at 4× scale, shorthand for --scale 4 (optional)
+
+**Mode detection** — before invoking the CLI, check whether `qa/screens/<screen>/` already exists:
+- Screen does NOT exist → fresh screen creation (need `--path` unless `--figma` provided)
+- Screen exists AND `--feature <name>` provided → sub-feature mode (skip spec.md, only generate the 3 new files)
+- Screen exists AND no `--feature` → ask the user whether they meant to add a sub-feature (offer `--feature <suggested-name>`) or refresh visuals only (with `--figma`)
 
 ## Steps
 
-### 1. Scaffold the screen
+### 1. Scaffold the screen (or sub-feature)
 
-**Standard path (no --figma):**
+**Standard path (no --figma, no --feature):**
 
 Run with #tool:terminal:
 ```bash
 sungen add --screen ${input:screen} --path ${input:path}
 ```
 
+**Sub-feature mode (`--feature <name>` provided):**
+
+Run with #tool:terminal:
+```bash
+sungen add --screen ${input:screen} --feature <name> [--path ${input:path}]
+# Generates qa/screens/${input:screen}/{features,selectors,test-data}/${input:screen}-<name>.{feature,yaml,yaml}
+# Existing screen files (spec.md, awards.feature, …) are untouched.
+# --path is optional — defaults to /${input:screen} when omitted.
+```
+
 **Figma branch (when --figma \<url\> is provided):**
 
 Run with #tool:terminal:
 ```bash
-sungen add --screen ${input:screen} --figma <figma-url> [--path ${input:path}] [--refresh] [--scale <n>]
+sungen add --screen ${input:screen} --figma <figma-url> [--path ${input:path}] [--feature <name>] [--refresh] [--scale <n>]
+# --feature can be combined with --figma when the new sub-feature has its own Figma frame.
 ```
 
 This CLI command automatically:
@@ -82,13 +100,32 @@ Each capture skill writes outputs into `qa/screens/${input:screen}/requirements/
 
 ### 3. Fill spec.md
 
-Ask: *"Fill `spec.md` now? (You can reference the captured visuals)"* — offer **1) Yes, fill now (Recommended)** / **2) Skip, fill later**.
+**Skip this step when `--feature` was used** — the screen's existing `spec.md` is reused for all sub-features; only suggest the user append a new section for the sub-feature if useful (e.g. `## Modal — Confirm Withdrawal`).
+
+For fresh screen creation, ask: *"Fill `spec.md` now? (You can reference the captured visuals)"* — offer **1) Yes, fill now (Recommended)** / **2) Skip, fill later**.
 
 If yes → open `qa/screens/${input:screen}/requirements/spec.md` and help the user fill sections, fields, validation rules, business rules, and states. Reference the captured visuals from Step 2 to suggest field names, form elements, and UI states. Especially prompt for the optional **Figma URL** and **Live URL** fields in Overview — those unlock auto-capture without re-asking next run.
 
 ### 4. Next steps
 
-Tell the user what was created and offer next steps:
+Tell the user what was created. When `--feature` was used, list the 3 new files explicitly (`features/${input:screen}-<name>.feature`, `selectors/${input:screen}-<name>.yaml`, `test-data/${input:screen}-<name>.yaml`) and remind that `/sungen-create-test` currently operates at the screen level — it will see both the parent feature and the new sub-feature and ask which one to update.
+
+Then offer next steps:
 
 - **`/sungen-create-test ${input:screen}`** — Create test cases from requirements/designs (Recommended)
 - **Done for now** — I'll come back later
+
+## CLI Reference
+
+```
+sungen add --screen <name>
+  [-p, --path <path>]            URL route (e.g., /awards). Required for capture; defaults to /<screen> when omitted.
+  [-f, --feature <name>]         Add a sub-feature .feature file to an existing screen.
+                                 Output filename = <screen>-<feature>.{feature,yaml,yaml}.
+  [-c, --capture]                Auto-capture a live screenshot to requirements/ui/ (needs --path).
+  [-d, --description <text>]     Screen description (used in spec.md stub).
+  [--figma <url>]                Figma share URL — generates spec_figma.md + ui/*.png.
+  [--refresh]                    Bypass Figma cache (use with --figma).
+  [--scale <n>]                  PNG export scale (default 2).
+  [--hi-res]                     Shorthand for --scale 4.
+```

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

@@ -19,8 +19,11 @@ Parse **screens** from `$ARGUMENTS`:
 
 ### 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
-npx sungen dashboard <screens>
+# 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.

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

@@ -1,7 +1,7 @@
 ---
 name: sungen-delivery
 description: 'Export Gherkin scenarios + Playwright results to CSV test case file for QA delivery.'
-argument-hint: "[name...] (omit for all screens and flows)"
+argument-hint: "[name...] [--env <locale>] (omit names for all targets; --env for locale-specific export)"
 tools: [read, execute, edit, vscode/askQuestions]
 ---
 
@@ -11,9 +11,11 @@ You are a **QA Test Delivery Engineer**. Your job is to invoke the deterministic
 
 ## Parameters
 
-Parse **names** from `$ARGUMENTS`:
-- If empty → CLI will process **all** screens in `qa/screens/` and flows in `qa/flows/`
-- If provided → pass them through to the CLI (auto-detects screen vs flow per name)
+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
 
@@ -22,18 +24,22 @@ Parse **names** from `$ARGUMENTS`:
 Run via Bash (single command, no extra parsing):
 
 ```bash
-npx sungen delivery <names>
+# 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 args → just run `npx sungen delivery` (exports all screens + flows)
-- If args → pass them as positional arguments (auto-detects screen vs flow)
+- 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`, `test-results/results.json`
-- Generating CSV at `qa/deliverables/<name>-testcases.csv`
+- 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)
@@ -69,4 +75,9 @@ Forward the CLI's summary table to the user verbatim. Then use `AskUserQuestion`
 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-locale.md

@@ -0,0 +1,70 @@
+---
+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

@@ -20,13 +20,28 @@ You are a **Senior QA Reviewer**. You evaluate Gherkin test cases using the `sun
 
 ## Steps
 
-1. Read `<base>/<name>/features/<name>.feature` and `<base>/<name>/test-data/<name>.yaml`. If missing → `/sungen-create-test` first.
-2. Follow the `sungen-tc-review` skill — score 3 dimensions: Syntax (30pts), Coverage (40pts), Viewpoint (30pts). **For flows**, also apply the "Flow Review Additions" section. Use `sungen-viewpoint` for pattern checklists.
-3. **Unverified Selectors check** — if `<base>/<name>/selectors/<name>.yaml` exists, count lines matching `@needs-live-verify`. Include in the review report as a non-scoring metric. Does NOT affect the 60% threshold.
-4. Output review report per `sungen-tc-review` format. **>= 60%**: PASS. **< 60%**: FAIL with recommendations.
-5. If FAIL and user confirms → update test cases following `sungen-gherkin-syntax` and `sungen-tc-generation` skills, then re-review.
-6. After PASS (or user decides to proceed), offer next steps:
-
-- **`/sungen-run-test ${input:name}`** — Generate selectors, compile, and run tests (Recommended)
+1. **Enumerate feature files** — glob `<base>/<name>/features/*.feature`. A screen may have one main file (`<name>.feature`) plus sub-features (`<name>-<sub>.feature` like `awards-modal.feature`); a flow has a single `<name>.feature`. If zero `.feature` files found → `/sungen-create-test` first.
+2. **Review every feature file** — for each `<basename>.feature` discovered in step 1:
+   - Read `<basename>.feature` and the matching `test-data/<basename>.yaml`.
+   - Apply the `sungen-tc-review` skill — score 3 dimensions: Syntax (30pts), Coverage (40pts), Viewpoint (30pts). **For flows**, also apply the "Flow Review Additions" section. Use `sungen-viewpoint` for pattern checklists.
+   - Apply the **Unverified Selectors check** — if `<base>/<name>/selectors/<basename>.yaml` exists, count lines matching `@needs-live-verify`. Include in the per-file report as a non-scoring metric. Does NOT affect the 60% threshold.
+3. **Aggregated output** — present scores in a per-feature table, then a screen-level rollup:
+
+   ```
+   Feature              Syntax  Coverage  Viewpoint  Total  Verdict
+   ──────────────────────────────────────────────────────────────────
+   home.feature           28/30    36/40      27/30   91%   PASS
+   home-modal.feature     26/30    24/40      22/30   72%   PASS
+   ──────────────────────────────────────────────────────────────────
+   Screen rollup (mean)   27/30    30/40      24.5/30 81.5% PASS
+   ```
+
+   - **>= 60% per file**: PASS that file.
+   - **< 60% per file**: FAIL that file with recommendations.
+   - Show the full per-file report (recommendations, top issues) **only for files that fail**, or when the user asks for the deep report.
+4. If any file is FAIL and user confirms → update that file's test cases following `sungen-gherkin-syntax` and `sungen-tc-generation` skills, then re-review **only the failing files** (skip already-passing ones to save time).
+5. After all files PASS (or user decides to proceed), offer next steps:
+
+- **`/sungen-run-test ${input:name}`** — Generate selectors, compile, and run tests for **every feature** in this screen (Recommended)
 - **`/sungen-create-test ${input:name}`** — Add more test cases before running
 - **Done for now** — I'll come back later

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

@@ -1,7 +1,7 @@
 ---
 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]'
+argument-hint: "[name] [--env <locale>]"
 tools: [read, execute, edit, vscode/askQuestions, playwright/*]
 ---
 
@@ -11,7 +11,24 @@ You are a **Senior Developer**. Use `sungen-selector-fix`, `sungen-selector-keys
 
 ## Parameters
 
-Parse **name** from `$ARGUMENTS`. If missing, ask the user.
+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/flows/<name>/` exists → flow mode (base path: `qa/flows/<name>/`). Else check `qa/screens/<name>/` → screen mode (base path: `qa/screens/<name>/`).
 
@@ -52,7 +69,11 @@ Parse **name** from `$ARGUMENTS`. If missing, ask the user.
      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: **Screen**: `sungen generate --screen <name>`. **Flow**: `sungen generate --flow <name>`. Default: runtime data loading from YAML. Use `--inline-data` only if user requests compile-time hardcoded values.
+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)
 
@@ -63,13 +84,30 @@ Parse **name** from `$ARGUMENTS`. If missing, ask the user.
 
 ## Playwright command guidelines
 
-**Per-screen/flow JSON results** — each run must write its JSON report to a dedicated path co-located with the `.spec.ts`, so `sungen delivery` can read the correct results:
+**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
+# ✅ 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
@@ -88,7 +126,7 @@ 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 the per-screen file first, falls back to the global `test-results/results.json` if missing.
+`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
 

package/dist/orchestrator/templates/ai-instructions/copilot-config.md

@@ -20,8 +20,9 @@ You generate 3 files for sungen — a Gherkin compiler that produces Playwright
 | `sungen-capture-local` | Load existing UI assets (screenshots, mockups, Figma exports) from `requirements/ui/` |
 | `sungen-capture-live` | Capture a live running page via Playwright MCP (snapshot + screenshot) |
 | `sungen-figma-source` | Figma URL → spec_figma.md + ui/*.png + provisional selectors |
+| `sungen-locale` | Bootstrap i18n — audit selectors, detect locale switch mechanism, generate test-data overlay |
 
-## Workflow (6 AI commands)
+## Workflow (7 AI commands)
 
 | Command | What it does |
 |---|---|
@@ -31,9 +32,11 @@ You generate 3 files for sungen — a Gherkin compiler that produces Playwright
 | `/sungen-review <name>` | Score syntax, coverage, viewpoint quality (auto-detects screen or flow) |
 | `/sungen-run-test <name>` | Generate `selectors.yaml`, compile, run, auto-fix (auto-detects screen or flow) |
 | `/sungen-delivery [name...]` | Export test cases → CSV for QA delivery (all screens if no arg) |
+| `/sungen-locale <name> <locale>` | Bootstrap i18n for a screen — audit selectors, detect locale switch, generate overlay (run before `/sungen-run-test --env <locale>`) |
 
 **Screen path:** add-screen → create-test → review → run-test → delivery.
 **Flow path:** add-flow → create-test → review → run-test → delivery.
+**i18n path:** (after run-test passes for base locale) → locale → run-test --env <locale> → delivery --env <locale>.
 
 `create-test`, `review`, and `run-test` auto-detect context: if `qa/flows/<name>/` exists → flow mode, else `qa/screens/<name>/` → screen mode.
 
@@ -82,6 +85,8 @@ qa/deliverables/<name>-testcases.xlsx  # Styled workbook for client hand-off
 
 **Environment overrides**: `SUNGEN_ENV=staging npx playwright test` merges `<screen>.staging.yaml` on top of `<screen>.yaml`. Create `<screen>.<env>.yaml` for environment-specific values (different credentials, URLs, test users).
 
+**i18n support**: for multilingual sites, use `{{variable}}` in selector `name`/`value` fields to reference locale-dependent text from test-data. Create locale overlay files (e.g., `<screen>.vi.yaml`, `<screen>.staging-ja.yaml`) and run with `SUNGEN_ENV=vi`. One feature file + one selector file works across all locales. See `sungen-selector-keys` skill for details.
+
 ## CLI Commands
 
 ```bash