@sun-asterisk/sungen 2.6.11 → 2.6.14

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

@@ -1,7 +1,7 @@
 ---
 name: delivery
 description: 'Export Gherkin scenarios + Playwright results to CSV test case file for QA delivery.'
-argument-hint: "[screen-name...] (omit for all screens)"
+argument-hint: "[screen-name...] [--env <locale>] (omit screens for all; --env for locale-specific export)"
 allowed-tools: Bash, Read, AskUserQuestion
 ---
 
@@ -11,28 +11,34 @@ You are a **QA Test Delivery Engineer**. Your job is to invoke the deterministic
 
 ## Parameters
 
-Parse **screens** from `$ARGUMENTS`:
-- If empty → CLI will process **all** screens in `qa/screens/`
-- If provided → pass them through to the CLI
+Parse from `$ARGUMENTS`:
+- **screens** — 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):
+Run via Bash (single command, no extra parsing). Prefer the local `./bin/sungen.js` when it exists — the sungen monorepo ships local-only features the global npm package doesn't have yet (multi-sheet locale aggregation, `.<env>` filename suffix, locale-aware step rendering). Fall back to `npx sungen` in downstream projects.
 
 ```bash
-npx sungen delivery <screens>
+# No env — local-first dispatcher:
+[ -x ./bin/sungen.js ] && ./bin/sungen.js delivery <screens> || npx sungen delivery <screens>
+
+# Locale-specific:
+[ -x ./bin/sungen.js ] && SUNGEN_ENV=<locale> ./bin/sungen.js delivery <screens> || SUNGEN_ENV=<locale> npx sungen delivery <screens>
 ```
 
-- If no screen args → just run `npx sungen delivery`
-- If screen args → pass them as positional arguments
+- If no screen args → omit `<screens>` (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 vs specific)
+- Scope detection (all screens + flows vs specific)
 - Pre-flight source checks with colorful output
-- Parsing `.feature`, `.spec.ts`, `test-data.yaml`, `test-results/results.json`
-- Generating CSV at `qa/deliverables/<screen>-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)
@@ -68,4 +74,9 @@ Forward the CLI's summary table to the user verbatim. Then use `AskUserQuestion`
 sungen delivery [screens...]
   [--skip-preflight]          Skip pre-flight checks (not recommended)
   [--continue-on-missing]     Skip screens with blocking misses
+
+# Locale-aware export (env var, not a CLI flag):
+SUNGEN_ENV=<locale> sungen delivery [screens...]
+  → reads <name>.<locale>.yaml overlay, picks <name>-test-result.<locale>.json,
+    writes <name>-testcases.<locale>.csv / .xlsx
 ```

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

@@ -0,0 +1,71 @@
+---
+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]"
+allowed-tools: Read, Grep, Bash, Glob, Edit, Write, AskUserQuestion, mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_wait_for, mcp__playwright__browser_evaluate, mcp__playwright__browser_click, mcp__playwright__browser_storage_state, mcp__playwright__browser_set_storage_state
+---
+
+## 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`, `kudo-to-display-on-kudos`). If missing → AskUserQuestion.
+- **locale** — target locale code (e.g. `en`, `ja`, `en-US`, `staging-ja`). If missing → AskUserQuestion. This becomes the suffix in `test-data/<feature>.<locale>.yaml` and `SUNGEN_ENV=<locale>` at run time.
+- **`--base-locale <code>`** — optional. The locale of existing `test-data/<feature>.yaml`. Default `vi`. Used only for reporting/UX — files never get renamed.
+- **`--offline`** — force OFFLINE mode (skip Playwright capture). Useful when you know the live page can't be reached or when prepping a test-only template.
+
+Reject if name == locale (common typo).
+
+## 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 exists → 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, Phase 5 shows empty `target text` column for user to fill manually).
+- Else try `browser_navigate(baseURL)` — if it succeeds and page renders content → LIVE mode.
+- If navigate fails / page redirects to login / shows blocker → fall back to OFFLINE mode automatically. Announce the fallback clearly so the user knows what they got.
+
+## Enumerate features
+
+For multi-feature screens (e.g. `home` has `home.feature` + `home-modal.feature`), run Phases 1, 4, 6 once **per feature file**; run Phases 2 & 3 (live capture + mechanism detection) **once per screen** — the mechanism doesn't change between features in the same screen.
+
+Discover features the same way delivery does:
+
+```bash
+ls qa/screens/<name>/features/*.feature
+# or
+ls qa/flows/<name>/features/*.feature
+```
+
+## After Phase 7
+
+Use `AskUserQuestion` to offer next steps:
+
+- **`/sungen:run-test <name> --env <locale>`** — Run the tests against the new locale (Recommended)
+- **`/sungen:locale <name> <other-locale>`** — Bootstrap another locale (e.g. add `ja` after `en`)
+- **Open the overlay file** — Show `test-data/<feature>.<locale>.yaml` so user can review / edit before running
+- **Done** — Stop
+
+## Notes
+
+- Do NOT run tests yourself. `/sungen:run-test` is the executor. This command only PREPS files.
+- Do NOT modify `.feature` files. Localization happens entirely through `selectors/*.yaml` + `test-data/*.yaml`.
+- Auth blocker on SAA staging? Use `--offline`. See [[saa-auth-blocker]] memory.

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

@@ -17,13 +17,28 @@ Parse **name** from `$ARGUMENTS`. If missing, ask the user.
 
 ## 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), use `AskUserQuestion` to offer next steps:
-
-- **`/sungen:run-test <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), use `AskUserQuestion` to offer next steps:
+
+- **`/sungen:run-test <name>`** — Generate selectors, compile, and run tests for **every feature** in this screen (Recommended)
 - **`/sungen:create-test <name>`** — Add more test cases before running
 - **Done for now** — I'll come back later

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

@@ -1,7 +1,7 @@
 ---
 name: run-test
 description: 'Generate selectors + auth state via Playwright MCP, compile, and run Playwright tests — auto-fixes selectors on failure'
-argument-hint: [screen-name]
+argument-hint: "[screen-name] [--env <locale>]"
 allowed-tools: Read, Grep, Bash, Glob, Edit, Write, AskUserQuestion, mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_wait_for, mcp__playwright__browser_evaluate, mcp__playwright__browser_run_code, mcp__playwright__browser_storage_state, mcp__playwright__browser_set_storage_state
 ---
 
@@ -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 values — the run will execute but won't actually exercise the locale. Before kicking off Phase 0.5, check:
+
+```bash
+ls qa/<screens|flows>/<name>/test-data/*.<locale>.yaml 2>/dev/null | wc -l
+```
+
+If the count is 0 → use `AskUserQuestion` to offer:
+- **Run `/sungen:locale <name> <locale>` first** (Recommended) — bootstrap the overlay before running tests
+- **Continue anyway** — run with empty overlay (tests will assert base-locale text, will likely fail on a real locale page)
+- **Cancel**
+
+Skip this pre-flight when `--env` matches the base locale (no overlay needed in that case).
 
 **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,31 @@ 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
+# → writes <basename>-test-result.vi.json for each feature
+
 # ✅ 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 +127,7 @@ npx playwright test specs/generated/<screen>/<screen>.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/claude-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

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

@@ -0,0 +1,316 @@
+---
+name: sungen-locale
+description: 'Bootstrap i18n for a screen/flow — audit hardcoded selector text, detect locale-switch mechanism via live Playwright, generate test-data overlay file. Auto-loaded by /sungen:locale command.'
+user-invocable: false
+---
+
+## Goal
+
+Take a screen/flow whose `selectors/*.yaml` and `.feature` files were authored against the default locale (usually Vietnamese) and prepare it to run against a second locale. Output:
+
+1. `selectors/<feature>.yaml` — hardcoded `name`/`value` replaced with `{{var}}`
+2. `test-data/<feature>.yaml` — base locale, complete with all new keys
+3. `test-data/<feature>.<locale>.yaml` — overlay with only the keys that change
+4. (Optional) `selectors/<feature>.yaml` Pages block updated when locale uses URL prefix or query param
+
+After this skill finishes, `sungen run-test <name> --env <locale>` Just Works.
+
+## Run mode — Live (preferred) vs Offline (fallback)
+
+Pick mode **once at start**, based on whether MCP Playwright can reach the page.
+
+```
+Try: browser_navigate(baseURL)
+  → succeeds + page renders content → LIVE MODE (all 6 phases)
+  → fails (auth blocked, network down, app broken) → OFFLINE MODE
+    (audit + scaffold template + ask user to fill, skip detection phases)
+```
+
+**Live mode is the value-add** — it auto-detects locale switch mechanism and auto-fills translations. Offline mode just makes the file structure right; user fills in text manually.
+
+Announce which mode is being used before Phase 1.
+
+## Phase 1 — Audit selectors (always, no MCP)
+
+For each `.feature` file under the screen, read the matching `selectors/<feature>.yaml`. List every entry whose `name` or `value` field contains literal text WITHOUT `{{…}}` AND is not a CSS/href selector.
+
+Classify each candidate:
+- **`name` field of `role`-type selector** → very likely locale-dependent
+- **`value` field of `text`-type selector** → very likely locale-dependent
+- **`value` of `locator`-type selector** that contains `:has-text("…")` → check if the text is in target language
+- **`value` of `page`-type selector** → URL — handled separately in Phase 3
+- **CSS / href / attribute selectors** (e.g. `a[href="/awards"]`) → skip, locale-invariant
+
+Print the candidate list as a table:
+
+```
+selector key       | field | hardcoded value           | classification
+-------------------+-------+---------------------------+------------------
+nav about          | name  | Giới thiệu SAA 2025       | locale-dependent
+nav awards         | name  | Thông tin giải thưởng     | locale-dependent
+event date         | name  | 26/12/2025                | maybe (date format)
+nav kudos          | name  | Sun* Kudos                | brand — skip
+```
+
+If there are zero candidates and no `{{var}}` either, the screen has no localizable text → tell user and stop.
+
+## Phase 2 — Capture base locale (LIVE only)
+
+1. Read `playwright.config.ts` for `baseURL`. Read `Path:` from `.feature` for the entry-point path.
+2. If the screen has `@auth:<role>` tags, load `specs/.auth/<role>.json` via `browser_set_storage_state` first.
+3. `browser_navigate(baseURL + entryPath)` then `browser_wait_for` something stable.
+4. Capture:
+   - `browser_snapshot()` — DOM accessibility tree
+   - `browser_evaluate(() => location.href)` — full URL
+   - `browser_evaluate(() => ({ localStorage: {...localStorage}, cookies: document.cookie }))` — storage state hash
+5. For each candidate from Phase 1: verify the hardcoded text actually appears on the page (string contains check against snapshot text). Drop candidates that don't appear (probably stale selectors or false positives).
+
+Save state to memory as `baseLocale = { url, snapshot, storage }`.
+
+If page redirects to `/login` (auth blocker) → stop. Print: *"Auth blocked — cannot capture live page. Fall back to OFFLINE mode by re-running once auth works, or pick `Offline-only` next time."*
+
+## Phase 3 — Switch locale (LIVE only) — detect mechanism + storage delta
+
+Goal: identify (a) HOW to switch the app to the target locale, and (b) WHAT app-side storage state ends up holding the locale preference so a fresh BrowserContext can be primed identically without driving the UI.
+
+Before triggering the switch, capture full storage baseline:
+
+```js
+const before = await browser_evaluate(() => ({
+  sessionStorage: { ...sessionStorage },
+  localStorage:   { ...localStorage },
+  cookies:        document.cookie,
+  url:            location.href,
+}));
+```
+
+Then try mechanisms in order. First one that produces visibly different text wins. For EACH attempt, capture `after` state and diff against `before`.
+
+**3a. URL prefix**
+- `browser_navigate(baseURL + '/' + locale + entryPath)` (e.g. `https://saa-2025.../en/`)
+- Wait, snapshot
+- Compare text content with baseLocale snapshot for a known-changed element
+- If text differs and page didn't 404 → **URL prefix mechanism**. Save `localePrefix = '/' + locale`.
+
+**3b. Query param** (only if 3a failed)
+- `browser_navigate(baseURL + entryPath + '?lang=' + locale)` (also try `?locale=`, `?lng=`, `?l=`, `?language=`)
+- Same diff check
+- If text differs → **Query param mechanism**. Save `localeQuery = '?lang=' + locale` (or whichever variant worked).
+
+**3c. Language switcher UI** (only if 3a + 3b failed)
+- Look in base-locale snapshot for buttons/links matching: `'Select language'`, `'Language'`, `'言語'`, `'Ngôn ngữ'`, role=combobox
+- If found, ask user: *"Detected possible language switcher: [X]. Click it and proceed?"*
+- On confirm: `browser_click` the switcher, then `browser_click` the locale option
+- Verify text changed
+- If yes → **UI switcher mechanism**. Save selector + option details.
+
+**3d. None detected**
+- AskUserQuestion: *"Couldn't auto-detect locale switching. Either (a) demo it for me in browser then I'll snapshot, (b) provide locale URL manually, (c) skip — assume URL prefix `/<locale>`."*
+
+### Phase 3.5 — Storage diff (always run after Phase 3 succeeds)
+
+After locale text confirmed switched, capture `after` state and diff:
+
+```js
+const after = await browser_evaluate(() => ({
+  sessionStorage: { ...sessionStorage },
+  localStorage:   { ...localStorage },
+  cookies:        document.cookie,
+  url:            location.href,
+}));
+
+// Diff each storage area:
+const sessionDiff = diffEntries(before.sessionStorage, after.sessionStorage);
+const localDiff   = diffEntries(before.localStorage,   after.localStorage);
+const cookieDiff  = diffCookies(before.cookies, after.cookies);
+```
+
+**Filter noise** — only keep entries where:
+- Key name contains `lang|locale|language|i18n|intl` (case-insensitive), OR
+- Value matches a locale code pattern: `^[a-z]{2}(-[A-Z]{2})?$` or matches the target locale code exactly
+
+Drop known noise:
+- Auth tokens: `sb-*`, `*-token`, `*-jwt`, `*-session-id`
+- Analytics: `_ga*`, `_gid`, `_fbp`
+- App state: `csrf*`, `last-*`, `visit-*`
+
+**Auto-confidence scoring** per remaining entry:
+- High confidence: key name contains locale-related word AND value is a locale code matching target → KEEP, no user prompt
+- Medium: only one signal matches → present to user for confirmation
+- Low: neither matches but key changed → present to user, default to skip
+
+### Phase 3.6 — Verification (always run after Phase 3.5)
+
+For each high/medium-confidence storage entry, verify by replaying in a FRESH context:
+
+```js
+// 1. Capture current page state (have JWT in memory) — note: can't replay JWT separately
+// 2. Open new browser_navigate to baseURL but pre-set the detected key via addInitScript
+// 3. Snapshot new page and confirm a known target-locale string appears
+
+// Pseudo-code — real impl uses Playwright MCP `browser_evaluate` with init pattern
+```
+
+Actually since MCP browser sessions don't expose `addInitScript` directly, use a softer verification:
+- Manually set the candidate key via `browser_evaluate(() => sessionStorage.setItem('key', 'value'))`
+- Hard reload the page: `browser_navigate(baseURL)` to force re-init
+- Snapshot, look for known target-locale text
+- Caveat: hard reload kills any in-memory JWT — auth blocker amplifies failure surface. Skip verification if the screen has `@auth:*` tags and the staging app has known JWT-persistence issues.
+
+If verification fails / can't run → drop confidence by one tier, ask user.
+
+Save mechanism + verified storage delta to memory for use in Phase 6.
+
+## Phase 4 — Diff base ↔ target (LIVE only)
+
+For each candidate from Phase 1 that survived Phase 2:
+- Find the SAME element in the target-locale snapshot (match by `role`+position, by `aria-label` if available, by neighbor structure)
+- Extract its text → `targetText`
+- Pair: `(selectorKey, hardcoded baseText, observed targetText)`
+
+If matching fails for a candidate → mark as "needs manual" — flag for user input rather than skip.
+
+Result: list of triples `{ selectorKey, baseText, targetText, confidence }`.
+
+## Phase 5 — Confirm + edit (always)
+
+Present the proposal table:
+
+```
+selector key       | base text                | target text          | proposed var     | apply?
+-------------------+--------------------------+----------------------+------------------+-------
+nav about          | Giới thiệu SAA 2025      | About SAA 2025       | nav_about        | [✓]
+nav awards         | Thông tin giải thưởng    | Awards Info          | nav_awards       | [✓]
+event location     | Au Co Arts Centre, Hanoi | Au Co Arts Centre…   | event_location   | (already has {{}})
+nav kudos          | Sun* Kudos               | Sun* Kudos           | —                | [skip — same]
+event date         | 26/12/2025               | 26/12/2025           | —                | [skip — same]
+```
+
+Propose **var names** by snake_casing the selector key. Avoid collisions with existing test-data keys.
+
+Auto-skip rows where `baseText === targetText` (brand names, dates that don't change between locales).
+
+Ask user via AskUserQuestion: *"Review the table above. Confirm to apply / edit individual rows / re-run capture / cancel."*
+
+If user wants to edit a row → fall through to a per-row prompt asking for `var name` or `targetText` correction.
+
+In OFFLINE mode this phase is the same table but `target text` column is blank — user fills via subsequent prompts or by editing the overlay file after the skill finishes.
+
+## Phase 6 — Apply changes (always, after confirmation)
+
+For each confirmed row:
+
+**6a. Update `selectors/<feature>.yaml`**
+
+Replace `name: '<baseText>'` with `name: '{{<varName>}}'`. Preserve quoting style.
+
+**6b. Update `test-data/<feature>.yaml`** (base locale, complete dictionary)
+
+Append new keys at the end, grouped under a `# === i18n: <screen> ===` comment. Example:
+
+```yaml
+# === i18n: home ===
+nav_about: 'Giới thiệu SAA 2025'
+nav_awards: 'Thông tin giải thưởng'
+```
+
+**6c. Create `test-data/<feature>.<locale>.yaml`** (overlay, only diffs)
+
+```yaml
+# home — <locale> overlay. Only keys that change vs base.
+# Run with: SUNGEN_ENV=<locale> npx playwright test ...
+
+nav_about: 'About SAA 2025'
+nav_awards: 'Awards Info'
+```
+
+**6d. (URL/query mechanism only) Update Pages selectors**
+
+If Phase 3 detected URL prefix:
+
+```yaml
+# selectors/<feature>.yaml — Pages block becomes locale-aware
+home:
+  type: 'page'
+  value: '{{base_path}}/'
+awards:
+  type: 'page'
+  value: '{{base_path}}/awards'
+```
+
+And add to test-data:
+```yaml
+# test-data/<feature>.yaml (base)
+base_path: ''
+
+# test-data/<feature>.<locale>.yaml (overlay)
+base_path: '/en'
+```
+
+If Phase 3 detected query param: similar but with `query_suffix: ''` / `query_suffix: '?lang=en'` appended to each page value.
+
+If Phase 3 detected UI switcher: do NOT modify Pages. Instead, write the storage delta from Phase 3.5 into `specs/generated/locale-config.json` (sibling of `specs/generated/base.ts` + `specs/generated/locale-fixture.ts`) (see 6f below).
+
+**6f. Storage injection config — `specs/generated/locale-config.json` (sibling of `specs/generated/base.ts` + `specs/generated/locale-fixture.ts`)**
+
+Always write `specs/generated/locale-config.json` (sibling of `specs/generated/base.ts` + `specs/generated/locale-fixture.ts`) with the verified storage delta from Phase 3.5/3.6. This file is consumed by `specs/locale-fixture.ts` (auto-generated alongside `specs/base.ts`) — the fixture wraps Playwright's context, calls `addInitScript` to seed sessionStorage / localStorage, and `addCookies` for any cookies, BEFORE the first page navigation. Without this file, `SUNGEN_ENV=<locale>` only swaps test-data overlay — the browser would still boot in base locale.
+
+Schema (only include areas that actually changed):
+
+```json
+{
+  "$schema": "sungen-locale-config-v1",
+  "sessionStorage": {
+    "saa-language-preference": "${SUNGEN_ENV}"
+  },
+  "localStorage": {},
+  "cookies": [],
+  "notes": "Detected by /sungen:locale on YYYY-MM-DD. App persists locale in sessionStorage; initial trigger uses ?language=<code> query param."
+}
+```
+
+Notes on the schema:
+- Use the literal placeholder `"${SUNGEN_ENV}"` (or `"{{SUNGEN_ENV}}"`) when the stored value equals the locale code itself. The fixture substitutes `process.env.SUNGEN_ENV` at runtime, so the same file works for `en`, `ja`, etc.
+- Use a hardcoded literal (e.g. `"en_US"`) when the stored value is fixed regardless of which locale runs.
+- `cookies[]` entries need either `domain` or `url`. Other fields (`path`, `httpOnly`, `secure`, `sameSite`) are optional and pass through to `context.addCookies()`.
+- Do not commit auth tokens / session IDs into this file even if they showed up in the Phase 3.5 diff — they are noise. The skill's Phase 3.5 filter must drop them; if one slipped through, edit it out before applying.
+- `notes` is free-form, informational; the fixture ignores it.
+
+Multi-locale projects: the same `locale-config.json` works for every locale because the value templating uses `${SUNGEN_ENV}`. No per-locale file needed.
+
+The file lives at `specs/generated/locale-config.json` (sibling of `specs/generated/base.ts` + `specs/generated/locale-fixture.ts`) (sibling of `specs/base.ts`). If a different output directory is used, mirror the existing `specs/base.ts` location.
+
+**6e. Compile**
+
+Run `sungen generate --screen <name>` (or `--flow`) and report any compile errors back to the user. The selectors changed so compile must succeed before run-test.
+
+## Phase 7 — Hand off
+
+Print summary:
+- N selectors converted to `{{var}}`
+- M base keys added to `test-data/<feature>.yaml`
+- K overlay keys written to `test-data/<feature>.<locale>.yaml`
+- Pages selectors updated: yes/no
+- Locale-switching mechanism: URL prefix `/en` / query `?lang=en` / UI switcher / manual
+
+Suggest:
+
+```
+/sungen:run-test <name> --env <locale>
+```
+
+## Multi-feature screens
+
+If the screen has multiple `.feature` files (e.g. `home.feature` + `home-modal.feature`), repeat Phase 1 → Phase 6 for each feature file with its own selectors + test-data pair. Phase 2 + 3 (live capture + locale switch detection) run **once per screen** — the mechanism is the same. Phase 4 (text diff) runs per feature because each has its own scope of UI.
+
+## What NOT to do
+
+- Do not edit `.feature` files. The i18n shape is already correct there (`{{var}}` was the convention from the start). Only selectors + test-data need surgery.
+- Do not write a separate selectors file per locale (`home.en.yaml`). One selectors file with `{{var}}` works across all locales — that's the whole point.
+- Do not delete keys from the base `test-data/<feature>.yaml`. Always append. Existing tests rely on base values being complete.
+- Do not run tests in this skill. Hand off to `/sungen:run-test` for execution.
+- Do not commit. Hand off to user.
+
+## Memory link
+
+Related: [[saa-auth-blocker]] — Live mode will not work on SAA staging while the upstream Supabase `persistSession: false` issue is open. Default to Offline mode on SAA until that ships.

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

@@ -61,6 +61,7 @@ When running Phase 0 for a **flow** (`qa/flows/<name>/`), check existing screen
    - Selector priority: follow the table in **Diagnosis & Fix § Step 3** (`testid` > `role`+name > `placeholder` > `label` > `locator` > `text`).
    - Copy names **character-for-character** from the snapshot. Never infer from the Gherkin label.
    - If an element is auto-inferable per `sungen-selector-keys` § Auto-Infer, **omit it** from YAML — keep the file minimal.
+   - **i18n sites**: if the site supports multiple languages, use `{{variable}}` in `name`/`value` fields instead of hardcoded text. Add corresponding `lbl_*` keys to `test-data.yaml` + locale overlay files (see `sungen-selector-keys` § i18n).
 7. **Substring ambiguity check**: for each `role` + `name` selector, check if any other element in the snapshot has a name that **contains** this name as a substring (e.g., `"Đăng ký"` vs `"Đăng ký bằng Google"`). If yes → add `exact: true` to prevent strict mode violation at runtime.
 8. **Merge, don't overwrite**: preserve the page selector and any user-authored entries in `selectors.yaml`. Only add missing keys.
 9. **Show summary + confirm**: list the keys that will be added, ask the user to approve, then write the file.