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

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

@@ -1,446 +0,0 @@
----
-name: sungen-gherkin-syntax
-description: 'Sungen Gherkin patterns, selector types, and YAML key rules. Auto-loaded when writing .feature, selectors.yaml, or test-data.yaml.'
-user-invocable: false
----
-
-## Standard Syntax
-
-```
-[Keyword] User <Action> [Target Name] <Target Type> <in [Parent Name] <Parent Type>> <with {{Value}}> <is State>
-```
-
-- **Actor**: Always `User`, always active voice.
-- **Value**: `with {{snake_case}}` — never hardcode static data.
-- **State**: `is <keyword>` — never use `{{}}` for states.
-- **Parent scope**: `in [Parent] parentType` — optional, only when page has 2+ similar blocks needing disambiguation.
-
-## Keyword → Action Rules
-
-```
-GIVEN  →  is on
-WHEN   →  click · fill · select · press · clear · check · uncheck · hover
-         [⚠️ wait for — only for Spinner/Modal, minimize usage]
-THEN   →  see
-AND    →  inherits from preceding keyword
-```
-
-## Step Patterns (70 patterns)
-
-### Setup / Form / Interaction
-
-```
-User is on [T] page | page with {{v}} | dialog
-User fill [T] field | textarea | search | slider | date-picker with {{v}}
-User fill [T] uploader with {{f}}
-User clear [T] field
-User check [T] checkbox | toggle | radio
-User uncheck [T] checkbox | toggle
-User select [T] dropdown with {{v}}
-User click [T] button | tab | column | breadcrumb
-User click [T] row with {{v}}
-User double click [T] element
-User hover [T] icon | row
-User drag [T] to [T2]
-User expand | collapse [T] row
-```
-
-**click + with {{Value}} rule**: NO value for static (`button`, `link`, `icon`, `tab`). WITH value only for dynamic lists (`row`, `item`, `card`, `option`).
-
-### Alert / Keyboard / Wait / Scroll
-
-```
-User click [OK | Cancel] alert
-User fill [T] alert with {{v}}
-User see [message text] alert
-User press Escape key | Enter on [T] field
-User wait for N seconds | [T] dialog | [T] dialog is STATE | [T] page
-User scroll to [T] section
-User switch to [T] frame | [main] frame
-```
-
-> Alert steps must appear BEFORE the action that triggers the dialog.
-
-### Assertions (8 patterns → determines Playwright assertion)
-
-```
-# 1. Visibility: User see [T] type (NEVER add "is visible") | is hidden
-# 2. Text (toHaveText): User see [T] message | header | label with {{v}}
-# 3. Partial (toContainText): User see [T] text contains {{v}}
-# 4. Input (toHaveValue): User see [T] field | dropdown | date-picker | search | slider with {{v}}
-# 5. State: User see [T] button is disabled | checkbox is checked | dialog with {{v}} is hidden
-# 6. Attribute (toHaveAttribute): User see [T] image | link with {{v}}
-# 7. Count: User see [T] row with {{count}}
-# 8. Page: User see [T] page
-```
-
-### Collection / all-card (P5)
-
-```
-# Every element's TEXT matches a value (filter correctness, all items belong):
-User see all [Result Product Name] text contains {{category_term}}
-# Every CONTAINER holds a CHILD element (structural per-card proof — prove "each card has X"):
-User see all [Product Card] contain [Product Name]
-User see all [Product Card] contain [Add To Cart] button
-```
-
-Use the all-card form whenever a title claims *every / each* card/row exposes something — a single `User see [Add To Cart] button` does NOT prove "each card" and the harness Claim-Proof gate will flag it.
-
-### Table
-
-```
-User see [Col] column in [Table] table
-User see [Ref] row in [Table] table with {{v}}
-User see [Ref] row in [Table] table with {{v}} is hidden
-User see [Table] table with {{count}} | is empty
-User see [Col] column with {{v}}
-User click [Act] button in [Table] table with {{v}}
-User see [Table] table match data:
-    | Header1    | Header2    |
-    | {{value1}} | {{value2}} |
-```
-
-Row scope: `see [Ref] row in [Table] table with {{v}}` enters scope. Subsequent `see [Col] column with {{v}}` checks cell in that row. Use `table match data:` for multi-row verification.
-
-### Database verification (optional Data Driver)
-
-Read-only DB-state checks. **Prefer named queries** — SQL lives in `qa/screens/<screen>/database/queries.yaml` (reviewed once, parameterized). Invoke with the `@query:<name>` annotation; it binds the result rows to `{{name}}`, then assert with `expect`:
-
-```gherkin
-@query:active_user                 # precondition: run query, bind {{active_user}}
-@query:orders(buyer={{email}})     # …with explicit param override
-Scenario: ...
-  Then expect {{active_user.count}} is at least {{one}}   # ≥1 row
-  And  expect {{active_user.first.status}} is "active"     # first row's column
-  And  expect {{orders.count}} is {{expected}}             # exact count
-  And  User see [Total] text is {{orders.first.total}}     # UI ↔ DB
-```
-
-Path access on a bound result: `{{q.count}}`/`{{q.length}}`, `{{q.first.col}}`, `{{q.last.col}}`, `{{q[2].col}}`, `{{q.col}}` (= first row's col). `expect A is B` also supports `is at least` / `is at most` / `is not`. Tier-2 declarative (trivial inline, no catalog): `User see [<table>] row where [<col>] is {{v}} [has [<col2>] = "x"]`, `… no row where …`, `… count is {{n}}`. Full grammar + catalog/datasource/secret rules → **Advanced → Database** doc. Only emit DB steps when the project has a `database/` catalog / `datasources.yaml`.
-
-### States
-
-`hidden` `visible` `disabled` `enabled` `checked` `unchecked` `focused` `empty` `loading` `selected` `sorted ascending` `sorted descending`
-
-### Element Types
-
-| Group | Types |
-|---|---|
-| **Context** | `page` `dialog` `modal` `drawer` `tab` `alert` `overlay` `step` |
-| **Input** | `field` `textarea` `search` `dropdown` `option` `checkbox` `radio` `toggle` `uploader` `slider` `date-picker` |
-| **Trigger** | `button` `link` `icon` `menuitem` `tag` |
-| **Data** | `table` `row` `column` `cell` `list` `item` `card` `section` |
-| **Feedback** | `message` `header` `label` `text` `tooltip` `badge` `breadcrumb` `image` |
-| **System** | `key` `frame` `spinner` `progressbar` |
-
-### Auto-infer (no YAML entry needed)
-
-Most elements auto-infer from `[Label] type` → `getByRole(type, { name: 'Label' })`. Only add YAML when the accessible name differs, needs `nth`, or needs `testid`. Full auto-infer table → see `sungen-selector-keys` skill.
-
-**Types requiring YAML entry:** `date-picker`, `uploader`, `overlay`, `frame`, `step` - these have no standard ARIA role and need explicit selectors.
-
-## YAML Keys
-
-`[Reference]` → **lowercase, keep Unicode**: `[Search Content]` → `search content:`, `[Thời gian]` → `thời gian:`
-
-- Keys use **spaces** (not dots) as word separators
-- Same label, different element types → add `--type` suffix
-- Same label, nth occurrence → add `--N` suffix
-- Target Name > 30 chars → shorten to 1–3 meaningful words
-
-## Dynamic Variables (test-data YAML)
-
-Use `{{$var}}` in test-data YAML for values that must be unique per test run. Resolved at **runtime** by `TestDataLoader` — the compiler passes them through unchanged.
-
-| Variable | Example | Output |
-|---|---|---|
-| `{{$timestamp}}` | `"User-{{$timestamp}}"` | `"User-1714000000"` |
-| `{{$uuid}}` | `"{{$uuid}}"` | `"a1b2c3d4-..."` |
-| `{{$random:min:max}}` | `"{{$random:1:100}}"` | `"42"` |
-| `{{$date}}` | `"{{$date}}"` | `"2026-04-24"` |
-| `{{$datetime}}` | `"{{$datetime}}"` | `"2026-04-24T10:30:00.000Z"` |
-
-**Rules:**
-- `$timestamp` and `$uuid` → same value across all keys in one `load()` call (stable within a test file)
-- `$random` → unique per occurrence (each key gets a different random)
-- Resolved once at load time → every `get()` returns the same resolved value
-- Use for CRUD flows to avoid data collision between parallel runs
-
-```yaml
-# test-data/crud-award.yaml
-award:
-  name: "Award-{{$timestamp}}"
-  email: "test+{{$uuid}}@example.com"
-  score: "{{$random:1:100}}"
-```
-
-## Selectors (priority order)
-
-| type | value | name | use |
-|---|---|---|---|
-| `testid` | data-testid | — | when exists |
-| `role` | button/heading/link… | accessible name | interactive elements |
-| `placeholder` | placeholder text | — | inputs |
-| `label` | label text | — | labeled inputs |
-| `text` | — | — | static text |
-| `locator` | CSS selector | — | last resort |
-| `page` | relative URL | — | navigation |
-| `upload` | — | — | file inputs |
-| `frame` | iframe selector | — | iframes |
-
-Options: `nth` `exact` `scope` `match` `variant` `frame` `contenteditable` `columns`
-
-## Tags
-
-### Functional tags (affect code generation)
-
-| Tag | Effect |
-|---|---|
-| `@manual` | Skip in generation |
-| `@auth:role` | Use auth storage state for role |
-| `@no-auth` | Disable inherited auth |
-| `@steps:name` | Define reusable step block (base scenario) |
-| `@extend:name` | Prepend Given→When from @steps block (skip Then) |
-| `@cleanup:overlay` | Auto-cleanup: dismiss dialogs/overlays after each test (cleanupPage) |
-| `@cleanup:forms` | Auto-cleanup: clear form fields after each test (cleanupPage) |
-| `@cleanup:scroll` | Auto-cleanup: scroll to top after each test (cleanupPage) |
-| `@cleanup:storage` | Auto-cleanup: clear sessionStorage after each test (cleanupPage) |
-| `@screenshot:on-failure` | Auto-capture screenshot when test fails (base.ts fixture) |
-| `@parallel` | Opt-out: fresh page per test instead of serial default (for independent scenarios) |
-| `@beforeAll` | Hook: runs once before all tests → `test.beforeAll()` |
-| `@afterEach` | Hook: runs after each test → `test.afterEach()` (custom cleanup) |
-| `@afterAll` | Hook: runs once after all tests → `test.afterAll()` |
-| `@flow` | Mark feature as E2E flow (cross-screen testing) |
-| `@cases:dataset` | Data-driven: run the scenario once per row of the `dataset` LIST in test-data → one `test()` per row |
-| `@query:name` | Database: run the named query from `database/queries.yaml` (precondition) and bind its rows to `{{name}}`; assert with `expect {{name.count}} …` + path access. Override params `@query:name(p={{v}})`. Repeatable. (Optional Data Driver — see Database verification above) |
-| `@api:name` | API: run the named request from `api/apis.yaml` (precondition) and bind the response to `{{name}}`; assert with `expect {{name.status}} …` + path access (`{{name.body.<path>}}`). Override params `@api:name(p={{v}})`. Repeatable. (Optional API Driver) |
-| `@concurrent:N` | API idempotency: fire the bound `@api` request N times in parallel, then bind aggregates on the `@api` name — `{{name.ok_count}}` (2xx count) and `{{name.status_counts}}` (status→count map). Assert the exactly-once invariant (`expect {{name.ok_count}} is 1`); pair with `@query` as a DB oracle. Tag order = run order: `@api` (mutate) before `@query` (verify). (Optional API Driver) |
-| `@hybrid` | One unit, two capabilities: a signed-in browser session (UI) authorizes the `@api` call — the API request reuses the UI `storageState`. (Optional API + UI Drivers) |
-
-### Data-driven scenarios (`@cases`)
-
-For one test case × many inputs (email/format/boundary validation, decision tables), tag the
-scenario `@cases:<dataset>` and reference each row's columns as `{{col}}`. Put the rows as a LIST
-in test-data — NOT inline; data stays runtime + env-overlayable.
-
-```gherkin
-@high @cases:email_validation
-Scenario: VP-VAL-001 The email field rejects invalid formats
-  When User fill [Email] field with {{email}}
-  Then User see [Login Error] message with {{expected_error}}
-```
-```yaml
-# test-data/<screen>.yaml
-email_validation:
-  - { case: "no @",    email: "plainaddress", expected_error: "Invalid email" }
-  - { case: "valid",   email: "ok@x.com",     expected_error: "" }
-```
-An optional `case`/`name`/`label` column labels each run. Each row → its own pass/fail. Prefer
-`@cases` over duplicating a scenario per value. (Gherkin `Scenario Outline`/`Examples` is NOT
-supported — use `@cases`.)
-
-### Pass-through tags (filter at runtime via Playwright --grep)
-
-Any tag not listed above passes through to Playwright `{ tag: [...] }`. Feature-level tags inherit to all scenarios.
-
-| Tag | Purpose |
-|---|---|
-| `@smoke` | Quick sanity check — run after every deploy |
-| `@regression` | Full test suite — run nightly or before release |
-| `@high` | Priority: must pass — login, auth, core CRUD, primary business flow |
-| `@normal` | Priority: important — validation rules, secondary features, search/filter |
-| `@low` | Priority: minor/cosmetic — tooltips, hover states, element presence |
-| `@auto` | Standard scenario, ready for automation |
-| Any custom | e.g., `@sprint-42`, `@team-payment` — any tag works |
-
-**Assign priority by user impact** (canonical mapping — override only when context differs):
-
-| Scenario type | Tag |
-|---|---|
-| Auth redirect / unauthenticated access | `@high` |
-| CRUD happy path (create / update / delete — success) | `@high` |
-| Core business rule, state transition | `@high` |
-| XSS, SQL injection, permission blocked | `@high` |
-| Required field error, unique/duplicate constraint | `@high` |
-| Format validation (email, phone, date…) | `@normal` |
-| Boundary value — inclusive (`<=`, `>=`) → `@high`; standard range → `@normal` | `@normal` |
-| Secondary features (search, filter, sort, pagination) | `@normal` |
-| Element presence, label, placeholder, tooltip | `@low` |
-
-**Run filtered:**
-```bash
-npx playwright test --grep "@smoke"          # only smoke tests
-npx playwright test --grep "@high"           # only high priority
-npx playwright test --grep "@smoke|@high"    # smoke OR high
-```
-
-### Serial vs Parallel (test execution mode)
-
-**Default: serial** — `test.describe.serial()` with shared page. Background runs once in `beforeAll`. Fail → skip remaining.
-
-**`@parallel` opt-out** — `test.describe()` with fresh page per test. Background runs as `beforeEach`. Use when scenarios are truly independent (validation rules, permission tests).
-
-| Mode | Generated | Page | Background | On fail |
-|---|---|---|---|---|
-| Serial (default) | `test.describe.serial()` | Shared | `beforeAll` (1 goto) | Skip remaining |
-| `@parallel` | `test.describe()` | Fresh per test | `beforeEach` (N goto) | Continue |
-
-**`@parallel` is required** when a feature has multiple auth groups (e.g., `@auth:user` + `@no-auth` scenarios). Serial mode uses one shared browser context and cannot mix auth roles. The compiler will error if `@parallel` is missing in this case.
-
-### `@flow` tag (E2E cross-screen testing)
-
-`@flow` marks a feature as a **flow** — an E2E journey spanning multiple screens. Flows live in `qa/flows/<name>/` with their own selectors, test-data, and requirements.
-
-**Key differences from screen tests:**
-
-| Aspect | Screen (`qa/screens/`) | Flow (`qa/flows/`) |
-|---|---|---|
-| Scope | Single page | Multiple pages |
-| Selectors | `[Element]` → own YAML | `[Screen:Element]` → own YAML (namespaced) |
-| Test data | `{{variable}}` | `{{phase.variable}}` (namespaced by phase) |
-| Tag | `@auto` / `@smoke` etc. | `@flow` (required at feature level) |
-| Multi-domain | N/A | Absolute URL in selector `path:` skips baseURL |
-
-**Selector namespace format:** `[Screen:Element]` where colon separates screen prefix from element name. The YAML key is `"screen:element"` (quoted, lowercase).
-
-```gherkin
-# Feature file
-When User fill [Login:Email] field with {{login.email}}
-And User click [Login:Submit] button
-Then User see [Dashboard] page
-When User click [Dashboard:Awards] link
-```
-
-```yaml
-# selectors.yaml — keys are namespaced, quoted due to colon
-"login:email":
-  type: 'testid'
-  value: 'email-input'
-
-"login:submit":
-  type: 'role'
-  value: 'button'
-  name: 'Login'
-
-dashboard:
-  type: 'page'
-  value: '/dashboard'
-
-"dashboard:awards":
-  type: 'role'
-  value: 'link'
-  name: 'Awards'
-```
-
-**Flow structure:**
-- `Background:` — set starting page only (e.g., `Given User is on [Login] page`)
-- Each `Scenario:` — one phase/step of the flow (login, navigate, submit, etc.)
-- Page navigation between scenarios uses `[Screen] page` references
-
-**CLI:** `sungen add-flow --flow <name>`, `sungen generate --flow <name>`, `sungen generate --all` (includes flows)
-
-### @extend behavior
-
-- Tool executes **only Given→When** of `@steps` scenario (skips Then)
-- The `Given` in `@extend` scenario is the **entry assertion** (confirms state after base steps)
-- **Entry assertion MUST use `Given User is on [X] type`** — NEVER `Given User see [X] type`
-- `Given` keyword ONLY allows `is on` action. `see` = `Then` only.
-- If `@steps` scenario fails, `@extend` scenario is **skipped**
-- Name format: `snake_case` or `kebab-case` with module prefix: `@steps:kudos__open_modal`
-
-## Common Syntax Errors
-
-| Error | Wrong | Correct |
-|---|---|---|
-| Wrong keyword | `Given User click [T] button` | `When User click [T] button` |
-| `see` after Given | `Given User see [T] heading with {{v}}` | `Then User see [T] heading with {{v}}` (or `Given User is on [T] page` for entry assertion) |
-| Name ≠ step type | Scenario name says "modal" but step uses `dialog` | Use the **same element type** in both: "...dialog opens" + `[X] dialog` |
-| Wrong action for type | `When User click [T] checkbox` | `When User check [T] checkbox` |
-| press wrong target | `When User press [Submit] button` | `When User press Enter key` |
-| uncheck radio | `When User uncheck [Male] radio` | `When User check [Female] radio` |
-| Hardcode data | `with {{admin@mail.com}}` | `with {{invalid_email}}` |
-| Missing `is` for state | `with {{text}} hidden` | `with {{text}} is hidden` |
-| State as value | `with {{disabled}}` | `is disabled` |
-| Missing target type | `fill [email] with {{v}}` | `fill [email] field with {{v}}` |
-| Background with scope | `Background: ... And User is on [X] dialog` | Use `@steps` + `@extend` for scope-dependent flows |
-| `is on` after When | `When ... And User is on [X] dialog` | `And User see [X] dialog` or separate Given |
-| Literal URL navigate | `User navigate to "/dashboard"` | `User is on [Dashboard] page` (add page selector in `selectors.yaml`) |
-
-## Background vs @steps/@extend
-
-Both `Background` and `@steps`/`@extend` are valid — they serve different purposes.
-
-| Pattern | Use when | Generates |
-|---|---|---|
-| `Background` | Simple shared setup (navigate to page) | `test.beforeEach()` |
-| `@steps`/`@extend` | Complex reusable flows with scope (dialog, frame) | Inline merged steps in `test()` |
-
-**Use `Background` for simple navigation:**
-```gherkin
-Background:
-  Given User is on [Dashboard] page
-
-Scenario: View stats
-  Then User see [Revenue Chart] section
-```
-
-**Use `@steps`/`@extend` when scope matters (dialog, frame):**
-```gherkin
-@steps:open_modal
-Scenario: Open modal
-  Given User is on [Kudos] page
-  When User click [Open] button
-  Then User see [Modal] dialog
-
-@extend:open_modal
-Scenario: VP-UI-001 Title visible
-  Given User is on [Modal] dialog
-  Then User see [Title] heading
-```
-
-**Avoid `Background` with scope-dependent steps** — `When` + `And User is on [X] dialog` creates keyword mismatch (`is on` = Given, not When). Use `@steps`/`@extend` instead.
-
-## Hooks & Cleanup
-
-Two layers for test lifecycle management. Prefer `@cleanup:*` tags (Layer 1) — they work with base.ts automatically. Use hook scenarios (Layer 2) only for custom logic.
-
-### Layer 1: `@cleanup:*` tags (automatic via base.ts)
-
-Feature-level tags that activate cleanup fixtures in base.ts. No Gherkin steps needed.
-
-```gherkin
-@auth:admin
-@cleanup:overlay
-@cleanup:forms
-Feature: User Management
-  Path: /users
-
-  Background:
-    Given User is on [User Management] page
-
-  Scenario: Create user shows form
-    When User click [Add User] button
-    Then User see [Create User] dialog
-
-  Scenario: Search user by name
-    When User fill [Search] field with {{search_name}}
-    Then User see [User Row] row
-```
-
-| Tag | What base.ts does after each test |
-|---|---|
-| `@cleanup:overlay` | Press Escape, click body, dismiss fixed overlays |
-| `@cleanup:forms` | Clear all input/textarea fields, reset selects |
-| `@cleanup:scroll` | Scroll to top of page |
-| `@cleanup:storage` | Clear sessionStorage |
-
-### Layer 2: `@afterEach` scenario (custom cleanup)
-
-Only when `@cleanup:*` tags aren't enough — feature-specific logic.
-
-### Layer 3: `@beforeAll` / `@afterAll` (optional)
-
-For one-time setup/teardown.
-
-**Rendering order in `.spec.ts`:**
-`test.describe` → `test.use(storageState)` → `test.use(autoCleanup)` → `test.beforeAll` → `test.beforeEach` → `test.afterEach` → `test.afterAll` → `test()` blocks

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-harness-audit.md

@@ -1,85 +0,0 @@
----
-name: sungen-harness-audit
-description: 'How to read `sungen audit` output and repair test-design findings. Auto-loaded by the design orchestrator.'
-user-invocable: false
----
-
-## What `sungen audit` measures
-
-`sungen audit --screen <name>` runs deterministic sensors over `features/<name>.feature` + `requirements/test-viewpoint.md` and writes `.sungen/reports/<name>-audit.json`. It is the **gate** the orchestrator repairs against. Run with `--json` to parse it.
-
-### Report shape (key fields)
-```jsonc
-{
-  "score": { "overall": 3.9, "coverage": 0.4, "businessDepth": 0.18, "balance": 0.5, "traceability": 0.7 },
-  "gateStatus": "PASS" | "FAIL",
-  "gate": { "pageType": "ecommerce-list", "themesCovered": 2, "themesTotal": 5,
-            "gaps": [ { "theme": "cart-correctness", "keywords": [...] } ] },
-  "depth": { "businessCriticalShallow": 9, "businessCriticalTotal": 11,
-             "shallowBusinessCritical": [ { "name": "...", "category": "PRODUCT" } ] },
-  "balance": { "imbalanced": true, "coreCount": 11, "secondaryCount": 22, "byBucket": {...} },
-  "duplicates": { "clusters": [ { "sameDataLikely": false, "scenarios": [...] } ] },
-  "trace": { "mappedRatio": 0.4, "note": "..." },
-  "findings": [ "GATE: ...", "DEPTH: ...", "BALANCE: ...", "TRACE: ..." ]
-}
-```
-- **`overall` score is business-weighted** (coverage 0.4 + businessDepth 0.3 + balance 0.15 + traceability 0.15). It is intentionally strict on business value — a high count with shallow business coverage scores low. Don't optimize the count; optimize coverage + depth.
-- Exit code **2** when `gateStatus == FAIL` (usable in CI / loop).
-
-## Finding → repair mapping
-
-| Finding prefix | Meaning | Repair action |
-|---|---|---|
-| **GATE** | a critical theme for the page-type has no covering scenario | Generate scenarios for that theme. **If cross-screen** (cart-correctness, product-detail-consistency, filter-result-correctness, multi-item cart) → do NOT fake it on a single screen; plan a **flow** (`/sungen:add-flow`) and record the deferral. |
-| **DEPTH** | business-critical scenarios assert only visibility/navigation | Replace `Then User see [X] page/section` with **observable data assertions**: `Then User see [X] with {{value}}`, `Then User see [T] table match data:`. Capture real expected values into `test-data.yaml`. |
-| **BALANCE** | secondary viewpoints (UI/validation/security) outweigh business-core | **Stop expanding** secondary viewpoints; generate the missing business-core scenarios first. Do not add more subscription/UI variants while core is thin. |
-| **TRACE** | scenarios use ad-hoc `VP-<CAT>-NNN` codes not linked to the viewpoint-overview | Make each scenario map to a viewpoint-overview id (align category codes, or add a mapping comment). |
-| **UNIVERSAL** | a universal theme (error/empty-state, accessibility) is absent | Low priority — add if in scope; otherwise note as out-of-scope with reason. |
-
-## P5 steps for deep cross-screen / list coverage
-
-Use these when repairing GATE/DEPTH findings for the hard viewpoints (cart/detail/filter correctness). They need **runtime data mode** (the default).
-
-- **Capture a value to compare across screens** (product-detail-consistency, cart-correctness):
-  ```gherkin
-  When User remember [Product Name] text as {{selected_product_name}}
-  And User remember [Product Price] text as {{selected_product_price}}
-  And User click [View Product] link
-  Then User see [Detail Product Name] header with {{selected_product_name}}
-  And User see [Detail Product Price] text with {{selected_product_price}}
-  ```
-  `remember` stores the element's text/value at runtime; later `{{var}}` resolves to it. This proves the detail/cart shows the SAME product, not a random one.
-
-- **Assert every item in a result matches** (category/brand-filter-correctness):
-  ```gherkin
-  When User click [Women] link
-  And User click [Dress] link
-  Then User see all [Result Product Name] contain {{selected_category}}
-  ```
-  `see all [X] contain {{v}}` asserts EVERY matching element contains the value → "all displayed products belong to the selected category/brand", not just one.
-
-> Cross-screen flows (home → detail/cart): **automate the journey as a flow** (`/sungen:add-flow`) — it runs as one test, so it is automatable. Do **not** keep a full `@manual` duplicate of it on the screen (a non-running dead copy that `sungen audit` flags as `MANUAL-AUTOMATABLE` and that inflates nothing — deferred business-critical is reported as `DEPTH-DEFERRED`). The screen keeps its screen-contract; the flow owns the cross-screen depth. `@manual` is for genuine judgment / missing-capability only, tagged `@manual:Mx`.
-
-## Repair loop rules
-
-1. **Budget = 3 rounds.** Re-run `sungen audit` after each repair; track score delta.
-2. **Stop when** `gateStatus == PASS` AND `findings` empty — or budget exhausted.
-3. **Never fake a pass.** A shallow `see [Cart] page` does not satisfy `cart-correctness`. If a gap is genuinely cross-screen or needs capabilities the DSL lacks (e.g. capture an element value to compare elsewhere), **report it as a residual gap / flow item** instead of forcing a green gate.
-4. **EP/data families are OK.** A `duplicates` cluster with `sameDataLikely=false` is an intentional equivalence-partition family (e.g. many invalid-email cases) — keep it; only collapse `sameDataLikely=true` exact duplicates.
-5. **Advisory findings — surface, don't gate.** `MANUAL-REASON-MISMATCH` → fix the scenario's `@manual:Mx` code (so the planner recommends the right driver) during repair. `CAPABILITY-SUGGESTION` → **present it to the user as a next-step option** (e.g. "N @manual could be automated — `sungen capability add api db`?"), **recommend-only — never auto-install**. Neither fails the gate.
-
-## Discovery / fallback tree (when input is limited)
-
-```
-spec.md đủ tốt?      → YES: Spec-first
-  │ NO
-source code có?      → YES: Source-first (mine behavior từ code)
-  │ NO
-testcase cũ tương tự?→ YES: History-first
-  │ NO
-domain rủi ro+defect?→ YES: Defect-first
-  │ NO
-→ hỏi QA; QA chưa phản hồi → OUTPUT kèm ASSUMPTION LIST rõ ràng (không stall)
-```
-
-See `docs/orchestration-spec.md` for the full flow and `docs/spec/sungen_refactor_spec.md` for the design rationale.

package/src/orchestrator/templates/ai-instructions/github-skill-sungen-ingest-legacy.md

@@ -1,79 +0,0 @@
----
-name: sungen-ingest-legacy
-description: 'Import a legacy manual testcase suite from Google Sheets (multi-tab) or a local file into Sungen — fetch via MCP, then sungen ingest. Use when the user wants to convert/evaluate an existing manual testcase spreadsheet.'
-user-invocable: true
----
-
-# sungen-ingest-legacy
-
-Bring an existing **manual testcase workbook** into Sungen for evaluation + conversion. The
-fetch (Google login + pick file) is done here via MCP; the parsing/audit is deterministic
-(`sungen ingest`). **Security:** the workbook is the user's project data — read it on
-consent, keep the output in their project, never upload or commit the content.
-
-## Flow
-
-1. **Locate the source.**
-   - **Google Sheets (recommended):** use the Google Drive MCP. Authenticate if needed, then
-     `search_files` / list to find the workbook; confirm the file with the user.
-   - **Local:** if the user points to a `.xlsx`/`.csv`, skip to step 4.
-
-2. **List the tabs.** Read the workbook's sheet/tab names (Drive MCP file metadata or a values
-   read). A legacy workbook usually has **many** tabs — some are testcases, some are
-   viewpoint/UI matrices.
-
-3. **Assemble a JSON sheet-bundle.** For each tab, read its cell values (a 2-D array of
-   strings) and write a local bundle in the user project (e.g.
-   `qa/screens/<screen>/requirements/legacy/bundle.json`):
-   ```json
-   { "source": "<workbook name>", "sheets": [ { "name": "<tab>", "rows": [["TC ID","Page",…],["TC-01",…]] } ] }
-   ```
-   Record only the **source link** in `requirements/legacy/source.yaml` — never the content.
-
-4. **Classify the tabs.** Run:
-   ```bash
-   sungen ingest --legacy <bundle.json|file.xlsx|file.csv> --list-sheets
-   ```
-   It prints each tab + detected type (`testcase` / `viewpoint-matrix` / `ui-checklist`).
-
-5. **Confirm which tabs to ingest.** Use `AskUserQuestion` to let the user pick the
-   **testcase** tabs (matrix/UI tabs feed the viewpoint layer later, not the inventory).
-
-6. **Ingest + reconcile.**
-   ```bash
-   sungen ingest --legacy <source> --screen <screen> --sheets "<Tab A>,<Tab B>" --emit-gherkin
-   ```
-   Produces: `inventory.json` (+ baseline audit), `*.legacy-draft.feature` + `legacy-trace.json`
-   (parity: `@legacy:<id>` per scenario), and `test-viewpoint.draft.md` with **blind-spots**
-   (catalog-expected viewpoints the legacy suite lacks).
-
-7. **Hand off to quality.** Tell the user the next step is `/sungen:create-test <screen>` —
-   it discovers + refines the draft into real `[Reference]` steps and fills the blind-spots;
-   then `sungen audit <screen>` gates quality. A 1:1 convert is NOT the deliverable; the
-   harness raises the legacy floor to catalog quality.
-
-## Governance block (important)
-
-Many orgs mark confidential files as **"ineligible for generative AI contexts"** — the
-Google Drive MCP will then **refuse** to read the file (metadata + download both error).
-This is the org's DLP policy, not a bug, and it is the *expected* outcome for a
-confidential testcase suite. When you hit it, **do not retry** — fall back:
-
-> "This sheet is restricted by your org's data policy, so I can't read it through the
-> AI connector. Two ways to proceed, both running as **you**, not AI:
->  (1) `sungen ingest --gsheet <url>` — fetches under your own Google identity
->      (read-only; Viewer/Commenter is enough). It offers to install `googleapis`
->      and to open the Google login in your browser (pick your account), then
->      retries automatically. Needs the gcloud SDK for the browser login.
->  (2) Export it manually (**File → Download → Microsoft Excel `.xlsx`**) and I'll run
->      `sungen ingest --legacy <file>.xlsx`."
-
-The local-file path is deterministic and **never sends the content through AI** — the
-correct, governance-compliant channel for confidential data. The MCP auto-pick is only
-for files the org does *not* restrict.
-
-## Notes
-- Multiple local CSVs (one per tab) also work: `--legacy tab1.csv tab2.csv …`.
-- Re-run only re-fetches when the user asks; otherwise reuse the saved bundle.
-- Do not invent testcases. Only ingest what the workbook contains; the *augmentation*
-  (blind-spots) happens in `/sungen:create-test`, flagged for human review.