@sun-asterisk/sungen 2.3.1 → 2.4.1

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

@@ -1,212 +1,72 @@
 ---
 name: sungen-tc-generation
-description: 'Exhaustive test case generation strategy — section-focused, 20+ scenarios per viewpoint per section, Gherkin + test-data only, no selectors. Auto-loaded by make-tc command.'
+description: 'Test case generation strategy — section-focused, viewpoint-driven, Gherkin + test-data only. Auto-loaded by create-test command.'
 user-invocable: false
 ---
 
-## Test Case Generation Strategy
+## Goal
 
-### Goal
+Generate **focused test cases per screen section** with **20+ scenarios per viewpoint**. Output `.feature` + `test-data.yaml` only — selectors are deferred to `/sungen:run-test`.
 
-Generate **focused, high-quality test cases per screen section** with **at least 20 scenarios per viewpoint category**. Output only `.feature` and `test-data.yaml` — selectors are deferred to `/sungen:make-test`.
+## Update Mode
 
-### Update Mode (existing test cases)
+When `.feature` already has scenarios, summarize and ask:
+1. **Add new sections** — append, continue numbering
+2. **Add viewpoints** — add to existing sections
+3. **Replace all** — overwrite
 
-When the `.feature` file already has scenarios, read it first and summarize what exists:
+For append: read highest `VP-<CAT>-<NNN>`, continue from next number. Never modify existing scenarios.
 
-> This screen already has **57 scenarios**:
-> - Section: Filters & Search — 22 scenarios (UI: 7, VAL: 8, LOGIC: 5, SEC: 2)
-> - Section: User Table — 23 scenarios (UI: 13, LOGIC: 11, SEC: 3)
-> - Section: Pagination — 12 scenarios (UI: 4, LOGIC: 6, SEC: 2)
->
-> What would you like to do?
-> 1. **Add new sections** — keep existing, add tests for uncovered sections
-> 2. **Add viewpoints to existing sections** — e.g., more edge cases, more security tests
-> 3. **Replace all** — start fresh
+## Requirements-Driven Generation
 
-For options 1 and 2:
-- Read the existing scenarios to understand current coverage and the highest `VP-<CAT>-<NNN>` number
-- Continue numbering from the next available number (e.g., if last is `VP-UI-024`, start at `VP-UI-025`)
-- **Append** new scenarios to the end of the relevant section — never modify or delete existing scenarios
-- Merge new test-data variables into `test-data.yaml` without overwriting existing ones
+When `qa/screens/<screen>/requirements/` exists:
+- **`spec.md`** — primary: sections, field constraints, validation messages, business rules, states
+- **`ui/`** — supplementary: screenshots for layout/visual context
+- **`notes.md`** — supplementary: edge cases, known issues
 
-For option 3:
-- Overwrite both `.feature` and `test-data.yaml` completely
+Requirements improve every viewpoint: exact error messages for VAL, business rules for LOGIC, role permissions for SEC.
 
-### Requirements-Driven Generation
+If also exploring live page: verify spec vs actual, flag mismatches, capture exact text.
 
-When `qa/screens/<screen>/requirements/` exists, use it as the **primary source** for test case generation. This produces higher quality tests because requirements contain exact validation messages, field constraints, business rules, and states.
+## Screen Input Sources
 
-#### Reading Requirements
+**Recommended** (in priority order):
+1. **Figma designs** — use Figma MCP to read design context, screenshots, and component metadata
+2. **UI images** — screenshots or mockups in `qa/screens/<screen>/requirements/ui/`
+3. **`spec.md`** — written specification with sections, fields, validation rules
 
-1. **`spec.md`** (primary) — structured screen specification:
-   - **Sections** → map directly to test case sections
-   - **Fields table** → generate boundary value tests (min/max constraints), required field tests, format tests
-   - **Validation Rules table** → generate exact assertion tests using the error messages as `{{test_data}}` values
-   - **Actions table** → generate interaction tests (click, submit, navigate)
-   - **States table** → generate state transition tests (loading, error, success, disabled)
-   - **Business Rules** → generate logic tests (limits, permissions, conditional behavior)
-   - **Accessibility** → generate tab-order and aria tests
+**Optional**: **Live page scan** via Playwright MCP — useful to verify specs vs actual UI, capture real data (error messages, labels). If auth needed → ask user to log in manually via MCP browser.
 
-2. **`ui/`** (supplementary) — screenshots, mockups, design images:
-   - Read images to understand layout, element positions, visual states
-   - Cross-reference with spec.md — identify elements visible in UI but missing from spec
-   - Use for UI/UX viewpoint tests (element visibility, placement, responsive)
+**Single screen focus**: one URL = one screen. Don't explore sibling paths. Modals on same page = part of this screen.
 
-3. **`notes.md`** (supplementary) — free-form edge cases, decisions, known issues:
-   - Extract edge cases → add to test coverage
-   - Flag known issues → add TODO scenarios
+### Capture Real Data
 
-#### How Requirements Improve Each Viewpoint
+When exploring live page or reading Figma designs, actively collect to hardcode in `test-data.yaml`:
+- User names, option labels, card content, error messages, counter keywords
+- **Hardcode first, @manual last** — stale data that fails fast > @manual that never runs
 
-| Viewpoint | Without Requirements | With Requirements |
-|-----------|---------------------|-------------------|
-| **UI/UX** | "see [Field] is visible" (generic) | "see [Field] field" + verify label, placeholder, default from spec |
-| **Validation** | "submit empty → see error" (vague) | "submit empty email → see {{email_required_error}}" with exact message from spec |
-| **Logic** | Based on observed page behavior | Business rules drive specific tests (lockout after N attempts, session expiry) |
-| **Security** | Generic injection tests | Role-based tests from auth requirements, permission-specific scenarios |
+## Section Identification
 
-#### Merging Requirements + Live Page
+Identify sections from page patterns. Use `sungen-viewpoint` skill for the 7 pattern types (Form, Table, Search, Filter, Pagination, Modal, List/Card). Present sections and ask user which to focus on.
 
-If the user also explores the live page:
-- **Verify** spec.md against actual page — flag mismatches (e.g., field in spec but not on page)
-- **Supplement** — discover elements on page not in spec (e.g., footer links, tooltips)
-- **Exact text** — capture actual placeholder text, button labels, error messages from live page and update test-data accordingly
+## Viewpoint & Coverage
 
-### Page Exploration & Auth
+Use `sungen-viewpoint` skill for per-pattern checklists across 4 viewpoints: UI/UX, Data & Validate, Logic, Security.
 
-Use Playwright MCP to explore the live page. If the page requires authentication:
-1. `browser_navigate` to `baseURL` (from `playwright.config.ts`)
-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`
+Generate **20+ scenarios per applicable viewpoint**. Skip viewpoints truly N/A.
 
-**Never use `sungen makeauth`.** Always let the user log in manually via the MCP browser.
+**Validation rule**: capture actual error messages from live page or spec.md. Use `User see {{error_var}}` — never assert just "is visible".
 
-### Single Screen Focus
-
-**One screen = one URL path.** Only generate test cases for elements visible on the target page.
-
-- Navigate to the target screen path — do NOT explore sibling paths (e.g., testing `/admin/users` should not scan `/admin/review`)
-- Take ONE snapshot of the target page — do not click links to navigate away
-- If a link goes to a different path, test only that the link is visible and clickable — the destination page is a SEPARATE screen
-- If a modal/dialog opens on the same page, that IS part of this screen
-- Each screen gets its own `qa/screens/<name>/` directory — never mix screens
-
-#### Detail screens with dynamic IDs
-
-For screens like `/admin/users/:id` or `/products/:slug`, write Gherkin normally (`User is on [User Detail] page`). The real ID will be resolved during `/sungen:make-test` when selectors are generated from the live page. See `sungen-selector-fix` skill for details.
-
-### Section-Focused Approach
-
-After exploring the page, identify distinct **sections** based on common UI patterns. Present them as a numbered list and ask the user which to focus on.
-
-#### Common Section Patterns
-
-Identify which patterns exist on the screen:
-
-| Pattern | Elements to look for |
-|---|---|
-| **Header / Navigation** | Logo, nav links, breadcrumbs, user menu, notifications, language selector |
-| **Form** | Input fields, dropdowns, checkboxes, radio buttons, date pickers, file uploads, submit/cancel buttons |
-| **Data Table** | Column headers, sortable columns, row data, row actions, bulk actions, column filters |
-| **Search & Filters** | Search input, filter dropdowns, clear/reset, active filter tags |
-| **Card Grid / List** | Cards with title/image/description, load more, infinite scroll |
-| **Pagination** | Previous/next buttons, page numbers, page size selector, total count |
-| **Tabs / Accordion** | Tab headers, tab panels, expand/collapse |
-| **Modal / Dialog** | Open trigger, close button, form inside modal, confirmation dialog |
-| **Sidebar** | Stats, quick actions, related links, mini widgets |
-| **File Upload** | Drop zone, file picker, progress bar, file list, delete |
-| **Rich Text Editor** | Toolbar, content area, formatting buttons, preview |
-| **Carousel / Slider** | Prev/next arrows, dots/indicators, auto-play, swipe |
-
-Example output:
-
-> This screen has the following sections:
-> 1. Header (logo, navigation tabs, user menu)
-> 2. Create Form (name, email, role dropdown, department, submit)
-> 3. User Table (columns: name, email, status, actions; sortable, filterable)
-> 4. Pagination (previous/next, page indicator)
->
-> Which sections do you want to create test cases for? (e.g., "2, 3" or "all")
-
-For each selected section, generate **20+ scenarios per applicable viewpoint**. Skip viewpoint categories that don't apply.
-
-Present a test plan summary and wait for user confirmation before generating files.
-
-### Assertion & Review Quality
-
-For assertion quality rules, action-result coherence rules, and the 9-point quality review checklist, see the `sungen-gherkin-review` skill. That skill is auto-loaded during the self-review step.
-
-### Viewpoint Categories
-
-| VP Category | Description |
-|---|---|
-| **UI/UX** | Default appearance, default values/text, default states. Group related elements per scenario. |
-| **Validation** | Input validation, error messages, edge cases. **Assert exact error messages via `User see [T] with {{error_var}}`** — store texts in test-data.yaml. |
-| **Logic** | Business logic, interactions, state changes |
-| **Security** | Auth guards, injection, permission checks |
-
-### Coverage Checklist per Section Pattern
-
-#### Form sections
-- **UI/UX**: All fields + labels + default values in 1-2 grouped scenarios. Default states (button enabled/disabled, checkbox unchecked). Placeholder text via `with {{placeholder}}`.
-- **Validation**: Empty submit → verify all error messages. Each required field empty individually → verify specific error. Invalid formats → verify specific error. Boundary values (min/max length). Special chars, unicode, XSS, SQL injection.
-- **Logic**: Successful submit → verify success state/redirect. Edit existing → verify pre-filled values. Cancel → verify form resets. Field dependencies (show/hide).
-- **Security**: Unauthorized submit, role-based field visibility, input sanitization
-
-#### Data Table sections
-- **UI/UX**: All column headers in one scenario. Row data displays with correct values. Empty state message. Action buttons per row.
-- **Logic**: Sort ascending/descending. Filter by column. Search. Row actions (edit/delete/view). Bulk select + action.
-- **Security**: Action permissions per role
-
-#### Search & Filter sections
-- **UI/UX**: Search field + filter buttons + clear button states in one scenario
-- **Validation**: Empty search, special chars, injection, long text, unicode
-- **Logic**: Apply/clear single filter, combine filters, no results state with message
-- **Security**: Injection via search/filter params
-
-#### Pagination sections
-- **UI/UX**: Page indicator + button states (previous disabled on page 1, next enabled)
-- **Logic**: Navigate pages, boundary behavior, indicator updates
-
-#### Modal / Dialog sections
-- **UI/UX**: Modal content + all fields + close button in one scenario
-- **Validation**: Field validation inside modal with exact errors
-- **Logic**: Open/close methods (X, Escape, overlay), submit success/error behavior
-
-#### Tabs / Accordion sections
-- **UI/UX**: All tab labels + active tab highlighted + default tab content
-- **Logic**: Switch tabs → verify content changes, accordion expand/collapse
-
-### General Coverage Dimensions (aim for 20+ total per viewpoint)
-
-**Happy paths (3-5):** Standard flow with full assertion of result state
-**Edge cases (5-8):** Empty, max length, special chars, unicode, whitespace, boundary values
-**Negative cases (3-5):** Invalid format, missing required, wrong type, exact error messages
-**State transitions (2-4):** Before/after action, verify both old and new state
-**Combinatorial (2-4):** Multiple invalid fields, valid+invalid combos
-
-### SPA Wait-For Steps
-
-If the page is an SPA (Next.js, Nuxt, React Router, etc.), add a `wait for` step after navigation:
+## SPA Wait-For Steps
 
 ```gherkin
 Given User is on [Screen] page
 And User wait for [Page Title] heading is visible
 ```
 
-For scenarios needing dynamic data, add a second wait:
-
-```gherkin
-And User wait for [Data Element] button is visible
-```
-
-### Output Files
+## Output Format
 
-**1. Feature file** — `qa/screens/<screen>/features/<screen>.feature`
-
-Group by section, then by viewpoint within each section:
+**Feature file** — `qa/screens/<screen>/features/<screen>.feature`
 
 ```gherkin
 @auth:role
@@ -220,20 +80,15 @@ Feature: <Screen> Screen
 
   Scenario: VP-UI-001 Form displays all fields with correct defaults
     Given User is on [Create User] page
-    Then User see [Create User] heading with {{form_title}}
-    And User see [Name] field
+    Then User see [Name] field
     And User see [Email] field
-    And User see [Role] dropdown with {{default_role}}
     And User see [Submit] button is disabled
-    And User see [Cancel] button is enabled
 
   # --- Validation ---
 
   Scenario: VP-VAL-001 Submit with all empty fields shows errors
-    Given User is on [Create User] page
     When User click [Submit] button
     Then User see [Name error] message with {{name_required_error}}
-    And User see [Email error] message with {{email_required_error}}
 
   # ============================================================
   # Section: User Table
@@ -242,36 +97,33 @@ Feature: <Screen> Screen
   # --- UI/UX ---
 
   Scenario: VP-UI-010 Table displays all columns
-    Given User is on [Users] page
     Then User see [Name] column in [Users] table
     And User see [Email] column in [Users] table
     And User see [Status] column in [Users] table
-    And User see [Actions] column in [Users] table
-```
 
-**Naming convention:** `VP-<CATEGORY>-<NNN>` prefix in Scenario name.
+  # --- Data & Validate ---
 
-**2. Test data file** — `qa/screens/<screen>/test-data/<screen>.yaml`
+  Scenario: VP-VAL-010 Table displays correct data
+    Then User see [Users] table match data:
+      | Name         | Email          | Status       |
+      | {{name_1}}   | {{email_1}}    | {{status_1}} |
+      | {{name_2}}   | {{email_2}}    | {{status_2}} |
 
-Group variables by section:
+  Scenario: VP-VAL-011 Edit button targets correct row
+    Given User see [Target] row in [Users] table with {{name_1}}
+    When User click [Edit] button in [Users] table with {{name_1}}
+    Then User see [Name] field with {{name_1}}
+```
 
-```yaml
-# ============================================================
-# Create User Form
-# ============================================================
-valid_name: 'John Doe'
-valid_email: 'john@example.com'
-empty_input: ''
-special_chars: '!@#$%^&*()'
+### When to use DataTable vs Row Scope
 
-# ============================================================
-# User Table
-# ============================================================
-sort_column: 'Name'
-search_term: 'John'
-```
+| Pattern | Use when |
+|---|---|
+| `table match data:` + DataTable | Verifying **multiple rows** exist with expected values |
+| `row in [Table] table with {{v}}` + `column with {{v}}` | Checking **single row** details or **acting** on a row (click, edit) |
+
+**Naming**: `VP-<CATEGORY>-<NNN>` prefix.
 
-### Do NOT Generate
+**Test data** — `qa/screens/<screen>/test-data/<screen>.yaml`, grouped by section.
 
-- `selectors.yaml` — this is created during `/sungen:make-test`
-- Playwright code — sungen compiles Gherkin to Playwright
+**Do NOT generate**: `selectors.yaml` (created during run-test), Playwright code (sungen compiles).

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

@@ -0,0 +1,104 @@
+---
+name: sungen-tc-review
+description: 'Test case review — scoring rubric, quality rules, checklist. Auto-loaded by review command.'
+user-invocable: false
+---
+
+## Scoring (3 dimensions, 100 points total)
+
+**>= 60%**: PASS | **< 60%**: FAIL — guide improvements
+
+### Syntax (30 pts)
+
+| Check | Pts |
+|---|---|
+| Steps match `sungen-gherkin-syntax` patterns | 10 |
+| Correct `[Ref] type with {{value}}` structure | 5 |
+| Given = setup, When = action, Then = assertion | 5 |
+| All `{{variables}}` exist in test-data.yaml | 5 |
+| Valid tags, no duplicate scenarios | 5 |
+
+### Coverage (40 pts)
+
+| Dimension | Pts | Min scenarios |
+|---|---|---|
+| Happy paths | 8 | 3-5 |
+| Negative cases | 8 | 3-5 |
+| Edge cases | 8 | 5-8 |
+| Boundary values | 6 | 3-5 |
+| State transitions | 5 | 2-4 |
+| Combinatorial | 5 | 2-4 |
+
+Score: `(dimensions_covered / 6) * 40`. Per-pattern checklists → `sungen-viewpoint` skill.
+
+### Viewpoint (30 pts)
+
+| Check | Pts |
+|---|---|
+| All applicable VP present (UI/VAL/LOGIC/SEC) | 10 |
+| Correct classification | 8 |
+| `VP-<CAT>-<NNN>` naming + section grouping | 8 |
+| Assertion quality (see rules below) | 4 |
+
+**Classification**: UI = static/always-same appearance. VAL = input validation/errors. LOGIC = behavior/state changes (includes persisted state without When). SEC = auth/permissions.
+
+---
+
+## Quality Rules
+
+### Assertion Quality
+
+1. **No bare `is visible`** — `User see [T] type` already asserts visibility. Only use `is hidden` for negation.
+2. **Assert content, not existence** — add `with {{value}}` or `is state`. Every assertion answers: what EXACTLY should the user see?
+3. **Group related assertions** — one scenario can have 3-7 Then/And steps. Don't waste a scenario on one element.
+
+### Action-Result Coherence
+
+1. **`When click [X]`** → Then must assert a **new element** (dialog, dropdown, page) or **state change** on X (disabled, checked). Never assert X unchanged.
+2. **`When fill [X]`** → Then must assert the **visible result** (search results, validation error). Don't re-assert the field value.
+3. **UI-only scenarios** (no action needed) → use Given + Then without When.
+4. **Scenario name must match the assertion**, not the action.
+
+### @manual Rules
+
+Only use `@manual` when environment can't be set up automatically:
+- Real files on disk, network simulation, backend-only state, timing-dependent
+
+Do NOT mark `@manual` when data is visible in snapshot or documented in spec — hardcode it in test-data.yaml.
+
+`@manual` scenarios must still have complete Given/When/Then + comment explaining why manual.
+
+---
+
+## Checklist (auto-fix on detection)
+
+1. **Redundant scenarios** — keep stronger assertion, remove weaker duplicate
+2. **Misclassified VP** — UI tests behavior? Move to LOGIC. Logic tests appearance? Move to UI
+3. **Dynamic content** — exact match on counters/timestamps? Use `contains` instead
+4. **Duplicate across sections** — SEC scenario identical to UI? Remove duplicate
+5. **Always-enabled elements** — `is enabled` on never-disabled element? Remove
+6. **Test-data completeness** — every `{{var}}` must exist in test-data.yaml
+7. **Missing negative/boundary** — every form section needs at least: empty field, invalid format, boundary value
+
+---
+
+## Output Format
+
+```markdown
+## Review: <screen>
+
+| Dimension | Score | Max |
+|---|---|---|
+| Syntax | <n> | 30 |
+| Coverage | <n> | 40 |
+| Viewpoint | <n> | 30 |
+| **Total** | **<n>%** | **100** |
+
+### Issues
+1. [SYNTAX] ...
+2. [COVERAGE] ...
+3. [VIEWPOINT] ...
+
+### Recommendations (if < 60%)
+- ...
+```

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

@@ -0,0 +1,188 @@
+---
+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.'
+user-invocable: false
+---
+
+## 4 Viewpoints
+
+| VP | Focus | Keyword |
+|---|---|---|
+| **UI/UX** | Interface states, layout, feedback | VP-UI |
+| **Data & Validate** | Input constraints, data integrity, error messages | VP-VAL |
+| **Logic** | Business rules, interactions, state changes | VP-LOGIC |
+| **Security** | Auth, injection, permissions | VP-SEC |
+
+---
+
+## 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
+
+**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)
+
+**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
+- Failure Flow: server error retains form data + shows system error
+
+**Security**
+- Injection Protection: XSS/SQL injection sanitized to plain text, never executed
+
+---
+
+## 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
+- 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
+
+**Logic**
+- Sorting: column sort refreshes data 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
+
+---
+
+## 3. Search
+
+**UI/UX**
+- No Results: "No results found" message, list empty, Clear button visible
+- Loading State: spinner/skeleton, list dimmed, interaction locked
+- 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
+
+**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
+
+**Security**
+- Injection: XSS/SQL encoded as plain text, never executed
+- Wildcards: `%, _, *` treated as normal text (escaped)
+
+---
+
+## 4. 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
+
+**Data & Validate**
+- Range Validation: start > end or min > max shows field error, Apply button disabled
+- Dropdown Integrity: options match 100% of actual data, hide unauthorized values
+
+**Logic**
+- Logic AND/OR: 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
+
+**Security**
+- URL Manipulation: erroneous URL params ignored, defaults assigned, no 500 error
+
+---
+
+## 5. 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
+
+**Data & Validate**
+- Label Consistency: "Viewing X of Y" matches actual data
+- 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
+
+---
+
+## 6. Modal / Dialog
+
+**UI/UX**
+- Overlay & Backdrop: 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
+
+**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
+- 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)
+
+---
+
+## 7. List / Card
+
+**UI/UX**
+- Visual States: empty state when empty, skeleton when loading, hover effect (shadow/scale) on card
+- Content: text truncation without breaking card height, placeholder image on broken image
+
+**Data & Validate**
+- Integrity: data fields (price, status, tag) 100% accurate vs system
+- Total Count: matches actual database count after filtering
+
+**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
+- 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
+
+---
+
+## 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`.
+
+```gherkin
+@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).

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

@@ -1,6 +1,6 @@
 ---
 name: sungen-add-screen
-description: 'Add a new Sungen screen — scaffolds directories and delegates to /sungen-make-tc for test case creation'
+description: 'Add a new Sungen screen — scaffolds directories and delegates to /sungen-create-test for test case creation'
 argument-hint: '[screen-name] [url-path]'
 agent: 'agent'
 tools: [vscode, execute, read, agent, edit, search, web, browser, todo]
@@ -36,11 +36,11 @@ Ask the user: "Would you like to fill in `requirements/spec.md` now? This helps
 
 Ask the user: "Would you like to create test cases now?"
 
-If yes → **tell the user to run `/sungen-make-tc ${input:screen}` as a separate command.** Do NOT attempt to generate test cases yourself in this session — the `make-tc` 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.
+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-make-tc` to create test cases
-- Run `/sungen-make-test` to generate selectors, compile, and run tests
+- Run `/sungen-create-test` to create test cases
+- Run `/sungen-run-test` to generate selectors, compile, and run tests