@sun-asterisk/sungen 2.4.2 → 2.4.3

package/src/orchestrator/templates/ai-instructions/claude-skill-test-design-techniques.md

@@ -0,0 +1,99 @@
+---
+name: sungen-test-design-techniques
+description: 'Test design techniques (EP, BVA, Decision Table, State Transition) for systematic scenario generation from spec constraints. Auto-loaded by create-test command.'
+user-invocable: false
+---
+
+## When to Apply
+
+| Technique | Apply when spec mentions |
+|---|---|
+| EP (Equivalence Partitioning) | Input types, categories, roles, valid/invalid ranges |
+| BVA (Boundary Value Analysis) | Numeric range, string length, date range, count limit |
+| Decision Table | 2+ mutually dependent conditions with different outcomes |
+| State Transition | Entity lifecycle, workflow states, status changes |
+
+**Rule:** These techniques determine **how many** and **which** scenarios to generate. `sungen-viewpoint` determines **which viewpoints** to cover.
+
+---
+
+## 1. Equivalence Partitioning (EP)
+
+**Goal:** One representative per input class. If one value in a partition passes, all values in that partition pass.
+
+**How to apply:**
+1. Extract partitions from `spec.md` constraints (e.g., field accepts 1-100)
+2. Valid class: 1 <= value <= 100
+3. Invalid class (below): value < 1
+4. Invalid class (above): value > 100
+5. Write **one** scenario per class
+
+**Anti-pattern:**
+```gherkin
+# BAD — 3 scenarios, same class, same result:
+Scenario: VP-VAL-001 Enter value 10
+Scenario: VP-VAL-002 Enter value 50
+Scenario: VP-VAL-003 Enter value 80
+```
+```gherkin
+# GOOD — one representative per class:
+Scenario: VP-VAL-001 Valid range value is accepted       # value = 50
+Scenario: VP-VAL-002 Below minimum is rejected           # value = 0
+Scenario: VP-VAL-003 Above maximum is rejected           # value = 101
+```
+
+---
+
+## 2. Boundary Value Analysis (BVA)
+
+**Goal:** Test exact edges where off-by-one errors occur (`>` vs `>=`, `<` vs `<=`).
+
+### Two modes
+
+| Mode | Values | Use when |
+|---|---|---|
+| **Compact (default)** | `min-1`, `min`, `max`, `max+1` | Most fields |
+| **Full 6-point** | `min-1`, `min`, `min+1`, `max-1`, `max`, `max+1` | Critical fields with `@critical`/`@high` priority |
+
+**How to apply** (example: "quantity must be 1-10"):
+- `min-1` = 0 -> invalid
+- `min` = 1 -> valid (lower boundary)
+- `max` = 10 -> valid (upper boundary)
+- `max+1` = 11 -> invalid
+- Midpoint (e.g., 5) already covered by EP valid class
+
+**BVA scenarios** (example: quantity 1-10):
+- `@high VP-VAL-010 Below minimum (0) is rejected`
+- `@high VP-VAL-011 Minimum boundary (1) is accepted`
+- `@high VP-VAL-012 Maximum boundary (10) is accepted`
+- `@high VP-VAL-013 Above maximum (11) is rejected`
+
+---
+
+## 3. Decision Table
+
+**Goal:** Cover all condition combinations when 2+ conditions constrain each other.
+
+**How to apply:** List conditions from `spec.md` → build combination→outcome table → one scenario per row.
+
+**Cap:** When >3 boolean conditions (>8 rows), prioritize rows with **distinct outcomes** and add `@manual` for exhaustive combos.
+
+**Example** — Submit requires valid form AND permission → 4 combos, 2 distinct outcomes:
+- `@normal` Form invalid + no permission → disabled
+- `@normal` Form valid + no permission → disabled
+- `@normal` Has permission + form invalid → disabled
+- `@critical` Form valid + has permission → succeeds
+
+---
+
+## 4. State Transition
+
+**Goal:** Verify every valid transition AND block invalid ones.
+
+**How to apply:** Extract state diagram from `spec.md` → one scenario per valid transition + key invalid transitions.
+
+**Example** — Order lifecycle (Draft→Pending→Approved→Completed):
+- `@high` Valid: Draft → Pending, Pending → Approved, Approved → Completed
+- `@normal` Invalid: Completed → Draft (blocked), Pending → Completed (skip approval)
+
+**test-data:** Use named state keys (`order_in_draft`, `order_in_pending`).

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

@@ -1,6 +1,6 @@
 ---
 name: sungen-viewpoint
-description: '7 UI patterns x 4 viewpoints — structured checklist for test case generation and review. Auto-loaded by make-tc and review commands.'
+description: '10 UI patterns x 4 viewpoints — structured checklist for test case generation and review. Auto-loaded by create-test and review commands.'
 user-invocable: false
 ---
 
@@ -13,148 +13,234 @@ user-invocable: false
 | **Logic** | Business rules, interactions, state changes | VP-LOGIC |
 | **Security** | Auth, injection, permissions | VP-SEC |
 
+## Shared Checks (apply across all patterns)
+
+These appear in multiple patterns — test once per screen, not per pattern:
+
+| Check | ER |
+|---|---|
+| **Loading State** | Spinner/skeleton shown, UI interaction locked during fetch |
+| **Empty State** | Clear message when no data, layout intact |
+| **XSS/Injection** | Malicious input sanitized to plain text, never executed |
+| **URL Manipulation** | Invalid URL params fallback to defaults, no server crash |
+
 ---
 
-## 1. Form & Inputs
+## GROUP 1: DATA ENTRY
+
+### 1. Form & Inputs
 
 **UI/UX**
-- Field States: disabled/readonly fields are dimmed and locked
-- Button States: Submit disabled when invalid, enabled when valid
-- Loading States: Spinner + block UI while waiting for server
-- Keyboard Navigation: Tab order correct, Enter submits form
+- Field States: disabled/readonly fields dimmed and locked, no interaction allowed
+- Button States: Submit disabled when form invalid, auto-enabled when valid
+- Keyboard Nav: Tab order correct, Enter submits form
 
 **Data & Validate**
-- Requirements: required field blank shows error, optional allowed blank
-- Boundaries & Types: min/max length, format (email, number) with error messages
-- Whitespace: trims excess whitespace or errors on spaces-only
-- Error Messaging: error at correct location, disappears on correction (Error Recovery)
+- Required/Optional: blank required field shows error; optional allows blank
+- Boundaries & Format: min/max length, format (email, number) with error messages
+- Whitespace: auto-trim or reject spaces-only input
+- Error Recovery: error at correct field, disappears immediately when user corrects data
 
 **Logic**
-- Dependencies: Field A value determines Field B status/data
-- Submission Control: prevent double submit (disable button after first click)
-- Success Flow: redirect / success toast / reset form
+- Field Dependencies: Field A value determines Field B status/options
+- Double Submit Prevention: button disabled after first click, only 1 request sent
+- Success Flow: redirect / success toast / form reset
 - Failure Flow: server error retains form data + shows system error
 
 **Security**
-- Injection Protection: XSS/SQL injection sanitized to plain text, never executed
+- → Shared: XSS/Injection
 
 ---
 
-## 2. Data Table
+## GROUP 2: DATA MANAGEMENT
+
+### 2. Data Table
 
 **UI/UX**
-- Empty State: clear message when no data, layout intact
-- Loading State: skeleton/spinner, table interaction locked during fetch
-- Layout & Truncation: long content truncated with tooltip, column width stable
+- → Shared: Empty State, Loading State
+- Truncation: long content shows `...` with tooltip on hover, column width stable
 - Sticky Elements: fixed header on vertical scroll, fixed action column on horizontal scroll
 
 **Data & Validate**
-- Consistency: total record count on UI matches server data
-- Row Limit: displayed rows never exceed page size/limit
-- Cell Integrity: cell data matches database, correct format (date, currency, status)
-- **Use `table match data:` with inline DataTable** for multi-row content verification (filter-based, resilient to data changes)
-- Use row scope (`row in [Table] table with {{v}}` + `column with {{v}}`) for single-row detail checks or when you need actions on a row
+- Record Count: "Total records" on UI matches server data exactly
+- Row Limit: displayed rows never exceed configured page size
+- Cell Integrity: cell data matches database, correct format (date, currency, status label)
 
 **Logic**
-- Sorting: column sort refreshes data with correct order, updates header icon
+- Sorting: column sort refreshes table with correct order, updates header icon
 - Row Actions: Edit/Delete/View buttons act on correct row ID
 
 **Security**
-- UI-level RBAC: hide sensitive columns or privileged buttons without authority
-- XSS Rendering: malicious code in database displayed as plain text
+- RBAC: hide sensitive columns or privileged action buttons without authority
+- → Shared: XSS/Injection (data from DB displayed safely)
+
+---
+
+### 3. Create / Add
+
+**UI/UX**
+- Blank Slate: all fields empty or BA-specified defaults, NO cache from previous operation
+- Required Indicator: required fields marked with visual cue (e.g., red *)
+- Unsaved Changes: navigate away with dirty form → browser/system warning popup
+
+**Data & Validate**
+- → Inherited: all Form & Inputs validation rules apply
+- Unique Constraint: duplicate unique field (e.g., Employee ID) → reject save, inline error
+- Data Dependency: selecting parent field loads correct child options
+
+**Logic**
+- Save & Close: toast notification, redirect to list, new record visible per sort rule
+- Save & Add Another: save to DB, form resets to blank for next entry
+- Double Submit Prevention: → same as Form & Inputs
+- Cancel: form closes, NO garbage record in DB, next open shows blank form
+
+**Security**
+- API Bypass / 403: unauthorized POST → system blocks (403 Forbidden), no record created
+- → Shared: XSS/Injection (persisted safely, not executed on display)
+
+---
+
+### 4. Update / Edit
+
+**UI/UX**
+- Pre-fill / Data Binding: all fields display exact current DB data (text, dropdown, radio, date...)
+- Readonly Fields: identity fields (ID, username, employee code) disabled, no interaction
+- Cancel: no data changed in DB; if dirty → unsaved changes warning
+
+**Data & Validate**
+- → Inherited: all Form & Inputs validation rules apply
+- Unique Self: saving without changing unique field → success, no self-duplicate error
+- Unique Conflict: changing unique field to existing value → duplicate error, block save
+- Unchanged Submit: Save disabled until dirty, or success without DB UPDATE
+
+**Logic**
+- Update Success: toast "Updated successfully", new data reflects on UI immediately without reload
+- Concurrent Edit: another user already edited → conflict warning, require reload
+
+**Security**
+- Authorization / 403: access edit without permission → 403 page
+- Not Found / 404: edit deleted object → 404
 
 ---
 
-## 3. Search
+### 5. Delete
 
 **UI/UX**
-- No Results: "No results found" message, list empty, Clear button visible
-- Loading State: spinner/skeleton, list dimmed, interaction locked
+- Confirmation: click Delete → MUST show confirmation dialog, delete button in warning color
+- Cancel: popup closes, record intact on UI and DB, no API called
+- Success Update: toast "Deleted successfully", record disappears immediately without reload
+- Pagination Fallback: delete only record on current page → auto-navigate to previous page
+
+**Data & Validate — Dependencies**
+- Independent: delete succeeds normally
+- Referenced (Restrict): delete parent with children → blocked, clear error "in use at [Module]"
+- Referenced (Cascade): warning first, then deletes parent AND all related children
+- Referenced (Set Null): parent deleted, child reference set to Unassigned/Empty
+
+**Logic — Storage**
+- Soft Delete: record hidden from UI, DB retains with status flag (is_deleted, deleted_at)
+- Hard Delete: record removed from UI AND permanently deleted from DB
+
+**Security**
+- Deleted Access / 404: soft or hard delete → direct URL/API returns 404
+- API Bypass: API delete on restricted object → backend rejects with business error, no 500
+
+---
+
+### 6. Search
+
+**UI/UX**
+- → Shared: Empty State ("No results found"), Loading State
 - Clear Action: search box empties, list reloads default data
 
 **Data & Validate**
-- Cleanup: auto-trim whitespace, results match cleaned keyword
-- Input Limits: prevent input beyond max length or show error
-- Normalization: case-insensitive matching, handles Vietnamese accents
+- Whitespace: auto-trim, results match cleaned keyword
+- Input Limits: prevent beyond max length or show error
+- Normalization: case-insensitive, handles accented characters correctly
 
 **Logic**
-- Matching: partial/exact match returns correct results, no 500 errors
-- Multi-keyword: results based on AND/OR logic
-- Performance: debounce ~300ms before API call
+- Matching: partial/exact match returns correct results, no 500
+- Multi-keyword: results based on AND/OR logic per spec
+- Debounce: ~300ms delay before API call
 
 **Security**
-- Injection: XSS/SQL encoded as plain text, never executed
-- Wildcards: `%, _, *` treated as normal text (escaped)
+- → Shared: XSS/Injection
+- Wildcards: `%`, `_`, `*` treated as literal text (escaped), not DB commands
 
 ---
 
-## 4. Filter
+### 7. Filter
 
 **UI/UX**
 - Feedback: selected filters displayed as tags/badges
 - Persistence: collapse/expand retains selected values
-- Conflicts: conflicting conditions show "No data" message, header layout intact
+- Conflicts: conflicting conditions show "No data" message, layout intact
 
 **Data & Validate**
-- Range Validation: start > end or min > max shows field error, Apply button disabled
+- Range Validation: start > end or min > max → field error, Apply disabled
 - Dropdown Integrity: options match 100% of actual data, hide unauthorized values
 
 **Logic**
-- Logic AND/OR: results satisfy correct filter logic, Total Count updated
+- AND/OR Logic: results satisfy correct filter logic, total count updated
 - Dependent Filters: selecting Filter A updates Filter B options
-- Reset & Navigation: reset returns original data or preserves state depending on action
+- Reset & Navigation: reset returns original data or preserves state per spec
 
 **Security**
-- URL Manipulation: erroneous URL params ignored, defaults assigned, no 500 error
+- → Shared: URL Manipulation
 
 ---
 
-## 5. Pagination
+### 8. Pagination
 
 **UI/UX**
 - Boundary States: Previous/First disabled on page 1, Next/Last disabled on last page
-- Active & Loading: active page highlighted, loading effect during page transition
-- Hidden State: pagination bar hidden when data fits one page
+- Active Page: highlighted, loading effect during page transition
+- Hidden: pagination bar hidden when data fits one page
 
 **Data & Validate**
-- Label Consistency: "Viewing X of Y" matches actual data
+- Label Consistency: "Viewing X of Y" matches actual data exactly
 - Zero Records: pagination hidden, empty state displayed
 
 **Logic**
 - Navigation: loads correct dataset for page (page 2, limit 10 = records 11-20)
 - Change Page Size: shows correct quantity, resets to page 1
 - Interaction Resets: new search/filter resets to page 1
-- Delete Fallback: deleting all records on last page pushes to previous page
 
 **Security**
-- URL Manipulation: invalid page/size in URL fallbacks to defaults, no server crash
+- → Shared: URL Manipulation
 
 ---
 
-## 6. Modal / Dialog
+## GROUP 3: NAVIGATION & CONTAINERS
+
+### 9. Modal / Dialog
 
 **UI/UX**
-- Overlay & Backdrop: centered modal, backdrop blur, background scroll locked
+- Overlay: centered modal, backdrop blur, background scroll locked
 - Focus Trapping: Tab key cycles only within modal elements
 - Responsive: modal resizes, action buttons always visible or scrollable
 
 **Data & Validate**
-- Dismiss Actions: close via X, Cancel, Escape, backdrop click. Resets data on reopen
+- Dismiss Actions: close via X, Cancel, Escape, backdrop click → resets data to default on reopen
 
 **Logic**
-- Submissions: action button shows loading, modal closes on success, background data updated
-- Failure: modal stays open on API error, shows error message, retains entered data
+- Submit Success: action button shows loading, modal closes, background data updated
+- Submit Failure: modal stays open, shows error message, retains entered data
 - Stacked Modals: Modal B over A has higher z-index, closing B keeps A intact
 
 **Security**
-- Reload & Security: handles deep linking if present, removes HTML from DOM on close (protect sensitive data)
+- DOM Cleanup: remove HTML from DOM on close to protect sensitive data
+- Reload: handles deep linking if present
 
 ---
 
-## 7. List / Card
+## GROUP 4: DISPLAY PATTERNS
+
+### 10. List / Card
 
 **UI/UX**
-- Visual States: empty state when empty, skeleton when loading, hover effect (shadow/scale) on card
+- → Shared: Empty State, Loading State
+- Hover Effect: shadow/scale on card hover
 - Content: text truncation without breaking card height, placeholder image on broken image
 
 **Data & Validate**
@@ -164,25 +250,26 @@ user-invocable: false
 **Logic**
 - Navigation: clicking card navigates to correct detail page
 - Direct Actions: Like/Add to Cart updates immediately without reloading list
-- Loading Flows: Load More / Infinite Scroll appends records, maintains scroll position
+- Infinite Scroll / Load More: appends records, maintains scroll position
 - Layout Toggle: Grid/List view switch changes UI but preserves data
 
 **Security**
-- RBAC & Resilience: hide sensitive data/privileged buttons from DOM. Network loss shows error + "Try again" button
+- RBAC: hide sensitive data or privileged buttons from DOM
+- Network Resilience: error message + "Retry" button on connection loss
 
 ---
 
 ## Security Tag Rules
 
-For VP-SEC scenarios testing **unauthorized access** (no login, wrong role, direct URL access):
-- Use **`@no-auth`** tag — this runs the test without authentication, which is exactly what you want to verify.
-- Do NOT use `@manual` for these — they are automatable with `@no-auth`.
+For VP-SEC scenarios testing **unauthorized access** (no login, wrong role, direct URL):
+- Use **`@no-auth`** tag — runs without authentication to verify redirect/block.
+- Do NOT use `@manual` for these — they are automatable.
 
 ```gherkin
-@no-auth
+@critical @no-auth
 Scenario: VP-SEC-001 Unauthenticated user cannot access admin page
   Given User is on [Admin] page
   Then User see [Login] page
 ```
 
-Use `@manual` only when the environment truly cannot be set up automatically (e.g., third-party OAuth, physical device).
+Use `@manual` only when the environment truly cannot be set up automatically.

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

@@ -32,15 +32,10 @@ Ask the user: "Would you like to fill in `requirements/spec.md` now? This helps
 - If they have UI designs (screenshots, Figma exports, mockups) → suggest copying them to `requirements/ui/`.
 - If no → proceed to step 3.
 
-### 3. Create test cases
+### 3. Next steps
 
-Ask the user: "Would you like to create test cases now?"
+Tell the user what was created and offer next steps:
 
-If yes → **tell the user to run `/sungen-create-test ${input:screen}` as a separate command.** Do NOT attempt to generate test cases yourself in this session — the `create-test` command auto-loads the `sungen-gherkin-syntax` and `sungen-tc-generation` skills which contain the full Gherkin syntax rules, pattern shapes, viewpoint checklists, and output format.
-
-### 4. Confirm
-
-If the user declined test case creation, tell them next steps:
-- Fill `requirements/spec.md` with screen specs (if not done)
-- Run `/sungen-create-test` to create test cases
-- Run `/sungen-run-test` to generate selectors, compile, and run tests
+- **`/sungen-create-test ${input:screen}`** — Create test cases from requirements/designs (Recommended)
+- **Fill `requirements/spec.md`** — Write screen specs first for better test quality
+- **Done for now** — I'll come back later

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

@@ -23,15 +23,22 @@ You are a **Senior QA Engineer**. You structure test cases by viewpoint categori
 3. **Read requirements** — check `qa/screens/${input:screen}/requirements/`:
    - If `spec.md` exists → read it as PRIMARY source (sections, fields, validation rules, business rules, states).
    - If `ui/` has images → read them for visual context (layout, element positions, states).
-   - If `notes.md` exists → read for edge cases and additional context.
+   - If `test-viewpoint.md` exists → read it. If it only contains HTML comments (scaffold template), ask:
+     - **1) Fill test-viewpoint.md first** — identify edge cases, known issues, and design decisions before generating tests
+     - **2) Continue without it** — generate tests from spec and other sources only
    - Summarize what you found in requirements and present to the user.
 4. **Screen input** (supplements requirements, or is primary source if no requirements):
    - Ask: "How should I get the screen design? **1) Figma design** (provide Figma URL — recommended), **2) UI images** (screenshots/mockups in `requirements/ui/`), or **3) Live page scan** (optional, via Playwright MCP)?"
    - Recommend Figma or UI images first. Live page scan is optional — useful to verify specs vs actual UI or capture real data.
-   - If live page, explore via #tool:playwright (see [copilot-instructions.md](../../copilot-instructions.md) for MCP rules). If auth needed, ask user to log in manually.
+   - If live page: `browser_navigate` → ONE `browser_snapshot`. If auth redirect → ask user to log in manually. Never use `browser_run_code` or `browser_evaluate` to inject cookies.
    - If exploring, verify and supplement requirements — flag any discrepancies found.
 5. Identify screen sections → ask user which to focus on (per `sungen-tc-generation` skill). When requirements exist, use the "Requirements-Driven Generation" strategy. Present sections as a numbered list and let user pick.
 6. Generate or update `.feature` + `test-data.yaml` following `sungen-gherkin-syntax` and `sungen-tc-generation` skills.
-7. Show summary → next: `/sungen-review ${input:screen}` or `/sungen-run-test ${input:screen}`
+7. Show summary and offer next steps:
+
+- **`/sungen-review ${input:screen}`** — Review syntax, coverage, viewpoint quality (Recommended)
+- **`/sungen-run-test ${input:screen}`** — Skip review, generate selectors and run tests now
+- **`/sungen-create-test ${input:screen}`** — Add more test cases for another section/viewpoint
+- **Done for now** — I'll come back later
 
 **No selectors.yaml** — selectors are generated during `/sungen-run-test`.

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

@@ -22,3 +22,8 @@ You are a **Senior QA Reviewer**. You evaluate Gherkin test cases using the `sun
 2. Follow the `sungen-tc-review` skill — score 3 dimensions: Syntax (30pts), Coverage (40pts), Viewpoint (30pts). Use `sungen-viewpoint` for pattern checklists.
 3. Output review report per `sungen-tc-review` format. **>= 60%**: PASS. **< 60%**: FAIL with recommendations.
 4. If FAIL and user confirms → update test cases following `sungen-gherkin-syntax` and `sungen-tc-generation` skills, then re-review.
+5. After PASS (or user decides to proceed), offer next steps:
+
+- **`/sungen-run-test ${input:screen}`** — Generate selectors, compile, and run tests (Recommended)
+- **`/sungen-create-test ${input:screen}`** — Add more test cases before running
+- **Done for now** — I'll come back later

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

@@ -16,20 +16,28 @@ You are a **Senior Developer**. Use `sungen-selector-fix`, `sungen-selector-keys
 
 - **screen** — ${input:screen:screen name (e.g., login, dashboard)}
 
-## Phase 1: Compile & Run (no MCP)
+## Compile
 
 1. Verify `qa/screens/${input:screen}/` has `.feature` + `test-data.yaml`
 2. Ensure `selectors.yaml` has page selector. If missing, ask user for URL path
 3. `sungen generate --screen ${input:screen}`
-4. `npx playwright test specs/generated/${input:screen}/*.spec.ts --reporter=line`
-5. If all pass → done
-
-## Phase 2: Targeted Fix (only if failures)
-
-6. Parse failures → group by root cause
-7. Navigate to page ONCE via #tool:playwright → ONE `browser_snapshot`
-8. Fix broken selectors per `sungen-selector-fix` skill
-9. Recompile → re-run only failing tests
-10. Repeat up to 3 attempts
-11. Final full run for regression check
-12. Still failing → ask user
+
+## Run & Fix (phased — per `sungen-selector-fix` skill)
+
+4. **Phase 1 — Smoke Check**: Run first 5 `@critical`/`@high` scenarios only. If failures → diagnose, fix fundamentals (page selector, auth, base @steps), re-run. Max 2 attempts. If still broken → ask user.
+5. **Phase 2 — Priority Wave**: Run all `@critical` + `@high` scenarios. Fix only failures from this wave. Max 2 attempts. Shared selectors fixed here cascade to later phases.
+6. **Phase 3 — Full Run**: Run all tests. Fix only **new** failures (elements unique to `@normal`/`@low`). Max 1 attempt. Don't loop on low-priority failures.
+7. **Phase 4 — Regression**: One final full run. Report results. No more fix loops.
+
+## Next steps
+
+After showing results, offer next steps:
+
+If all tests **passed**:
+- **`/sungen-create-test ${input:screen}`** — Add more test cases (Recommended)
+- **Done** — All tests passed, I'm finished
+
+If tests **failed** (after retries):
+- **`/sungen-run-test ${input:screen}`** — Re-run after manual fixes
+- **`/sungen-create-test ${input:screen}`** — Revise test cases
+- **Done for now** — I'll fix manually later

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

@@ -10,8 +10,9 @@ You generate 3 files for sungen — a Gherkin compiler that produces Playwright
 | `sungen-gherkin-syntax` | All 70+ step patterns, selector types, YAML key rules, tags, element types |
 | `sungen-error-mapping` | Playwright & sungen error → fix mapping |
 | `sungen-tc-generation` | Test case generation strategy, output format |
+| `sungen-test-design-techniques` | EP, BVA, Decision Table, State Transition — systematic scenario generation |
 | `sungen-tc-review` | Review scoring, quality rules, checklist |
-| `sungen-viewpoint` | 7 UI patterns x 4 viewpoints — coverage checklists |
+| `sungen-viewpoint` | 10 UI patterns x 4 viewpoints — coverage checklists |
 | `sungen-selector-keys` | YAML key generation from `[Reference]` names, suffixes, lookup priority |
 | `sungen-selector-fix` | Selector generation from live page, auto-fix strategy |
 
@@ -26,6 +27,8 @@ You generate 3 files for sungen — a Gherkin compiler that produces Playwright
 
 **Order:** add-screen → create-test → review → run-test.
 
+After each command completes, present the next actions as selectable options. Never just print text — always give clickable choices so the user can continue the workflow seamlessly.
+
 ## File Structure
 
 ```
@@ -38,102 +41,6 @@ qa/screens/<screen-name>/
     └── ui/                        # Screenshots, mockups
 ```
 
-## Complete Example
-
-Given a login page, here are the 3 files you generate:
-
-**qa/screens/login/features/login.feature**
-```gherkin
-@no-auth
-Feature: Login Screen
-
-  Scenario: VP-LOGIC-001 Successful login
-    Given User is on [login] page
-    When User fill [Email] field with {{email}}
-    And User fill [Password] field with {{password}}
-    And User click [Submit] button
-    Then User see [Welcome] heading with {{welcome_text}}
-    And User see [Dashboard] link
-```
-
-**qa/screens/login/selectors/login.yaml**
-```yaml
-login:
-  type: 'page'
-  value: '/login'
-
-email:
-  type: 'placeholder'
-  value: 'Enter your email'
-
-password:
-  type: 'placeholder'
-  value: 'Enter your password'
-
-submit:
-  type: 'role'
-  value: 'button'
-  name: 'Submit'
-
-welcome:
-  type: 'role'
-  value: 'heading'
-  name: 'Welcome'
-
-dashboard:
-  type: 'role'
-  value: 'link'
-  name: 'Dashboard'
-```
-
-**qa/screens/login/test-data/login.yaml**
-```yaml
-email: 'admin@example.com'
-password: 'password123'
-welcome_text: 'Welcome back'
-```
-
-## Critical Gherkin Rules (quick reference)
-
-1. **NEVER write `is visible`** — `User see [T] type` already asserts visibility. Only use `is hidden` to assert absence.
-2. **Use `@no-auth` for pre-login pages** (login, register, forgot-password). Use `@auth:role` for authenticated pages.
-3. **Scenario names use VP prefix** — `VP-UI-001`, `VP-VAL-001`, `VP-LOGIC-001`, `VP-SEC-001`.
-4. **Values use `{{snake_case}}`** — never hardcode data in `.feature`. All values go in `test-data.yaml`.
-5. **Selectors are deferred** — `selectors.yaml` is generated during `/sungen-run-test` from the live page, NOT during `/sungen-create-test`.
-6. **Every `{{variable}}` must exist in `test-data.yaml`** — missing variables cause compile failures.
-7. **Assertion type is determined by element type** — input types (`field`, `textarea`, `search`, `dropdown`, `slider`, `date-picker`) → `toHaveValue()`. Everything else → `toHaveText()`. Wrong type = wrong assertion = test failure.
-
-## Using Playwright MCP to explore pages
-
-When exploring a page to generate test files:
-1. Read `playwright.config.ts` for `baseURL`
-2. Use `browser_navigate` to open `baseURL + /path`
-3. Use `browser_snapshot` to see all elements
-4. Generate the 3 files from the snapshot
-
-### Allowed MCP tools
-
-| Tool | Use for |
-|---|---|
-| `browser_navigate` | Open pages |
-| `browser_snapshot` | Capture all accessible elements |
-| `browser_click` | Interact with elements (open dialogs, dropdowns) |
-| `browser_fill_form` | Fill form fields |
-| `browser_evaluate` | **Read-only DOM queries only** (e.g., detect `data-testid` attributes) |
-
-**NEVER use `browser_run_code`** — fails with `require is not defined`.
-
-### Authentication via MCP
-
-1. `browser_navigate` to `baseURL`
-2. If redirected to login, ask the user to log in manually:
-   > "This page requires login. Please log in using the browser. Confirm when you're done."
-3. Once confirmed, `browser_navigate` to the target page and take `browser_snapshot`
-
-**Never use `sungen makeauth`.** Always let the user log in manually via the MCP browser.
-**NEVER use `browser_evaluate` to inject cookies or localStorage** — causes size limit issues and server 500 errors. Use `browser_evaluate` ONLY for read-only DOM queries.
-**Minimize navigations** — take one snapshot per page, do not navigate repeatedly.
-
 ## CLI Commands
 
 ```bash