@sun-asterisk/sungen 2.6.5 → 2.6.7

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

@@ -266,7 +266,7 @@ For VP-SEC scenarios testing **unauthorized access** (no login, wrong role, dire
 - Do NOT use `@manual` for these — they are automatable.
 
 ```gherkin
-@critical @no-auth
+@high @no-auth
 Scenario: VP-SEC-001 Unauthenticated user cannot access admin page
   Given User is on [Admin] page
   Then User see [Login] page

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

@@ -22,7 +22,11 @@ You are a **Senior QA Engineer**. You structure test cases by viewpoint categori
 
 1. **Flow**: Verify `qa/flows/${input:name}/` exists. If not → `/sungen-add-flow` first.
    **Screen**: Verify `qa/screens/${input:name}/` exists. If not → `/sungen-add-screen` first.
-2. Check if `.feature` already has scenarios. If yes → summarize existing coverage and ask: **1) Add new sections**, **2) Add viewpoints to existing sections**, or **3) Replace all**. See `sungen-tc-generation` skill for update mode details.
+2. Check if `.feature` already has scenarios.
+   - If yes → summarize existing coverage and ask update mode (options depend on which tiers already exist — see `sungen-tc-generation` skill for details).
+   - If no → fresh creation. Ask generation scope:
+     - **1) Tier 1 — Critical & High priority** — ~10-15 scenarios/section covering happy paths, core validation, security basics **(Recommended)**
+     - **2) Full coverage — All tiers at once** — generates Tier 1 + 2 + 3 in one run. Large output (~40-60 scenarios/section), best for experienced users who want complete coverage immediately
 3. **Read requirements & resolve visual source** — check `<base>/${input:name}/requirements/`:
    - If `spec.md` exists → read it as PRIMARY source (sections, fields, validation rules, business rules, states).
    - If `test-viewpoint.md` exists → read it. If it only contains HTML comments (scaffold template), ask:
@@ -44,11 +48,23 @@ You are a **Senior QA Engineer**. You structure test cases by viewpoint categori
 
 4. Follow the `sungen-tc-generation` skill for section identification, viewpoint generation, and output format. **For flows**, use the "Flow Test Generation" section in the skill. When requirements exist, use the "Requirements-Driven Generation" strategy. Present sections as a numbered list and let user pick.
 5. Generate or update `.feature` + `test-data.yaml` following `sungen-gherkin-syntax` and `sungen-tc-generation` skills. **For flows**: use `[Screen:Element]` namespace format, namespace test-data by phase, add `@flow` tag.
-6. Show summary and offer next steps:
+6. Show summary and offer next steps based on which tier was just generated:
 
-- **`/sungen-review ${input:name}`** — Review syntax, coverage, viewpoint quality (Recommended)
-- **`/sungen-run-test ${input:name}`** — Skip review, generate selectors and run tests now
-- **`/sungen-create-test ${input:name}`** — Expand coverage: add @normal + @low scenarios
-- **Done for now** — I'll come back later
+   **After Tier 1 generation:**
+   - **`/sungen-review ${input:name}`** — Review syntax, coverage, viewpoint quality (Recommended)
+   - **`/sungen-run-test ${input:name}`** — Skip review, generate selectors and run tests now
+   - **`/sungen-create-test ${input:name}`** — Expand coverage: add @normal + @low scenarios (Tier 2)
+   - **Done for now** — I'll come back later
+
+   **After Tier 2 generation:**
+   - **`/sungen-create-test ${input:name}`** — Deep coverage: add BVA combos, cross-field validation, negative inputs, race conditions (Tier 3) (Recommended)
+   - **`/sungen-review ${input:name}`** — Review syntax, coverage, viewpoint quality
+   - **`/sungen-run-test ${input:name}`** — Generate selectors and run tests now
+   - **Done for now** — I'll come back later
+
+   **After Tier 3 or Full generation:**
+   - **`/sungen-review ${input:name}`** — Review syntax, coverage, viewpoint quality (Recommended)
+   - **`/sungen-run-test ${input:name}`** — Generate selectors and run tests now
+   - **Done for now** — I'll come back later
 
 **No selectors.yaml** — selectors are generated during `/sungen-run-test`.

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

@@ -56,8 +56,8 @@ Parse **name** from `$ARGUMENTS`. If missing, ask the user.
 
 ## Run & Fix (phased — per `sungen-selector-fix` skill)
 
-5. **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.
-6. **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.
+5. **Phase 1 — Smoke Check**: Run first 5 `@high` scenarios only. If failures → diagnose, fix fundamentals (page selector, auth, base @steps), re-run. Max 2 attempts. If still broken → ask user.
+6. **Phase 2 — Priority Wave**: Run all `@high` scenarios. Fix only failures from this wave. Max 2 attempts. Shared selectors fixed here cascade to later phases.
 7. **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.
 8. **Phase 4 — Regression**: One final full run. Report results. No more fix loops.
 

package/dist/orchestrator/templates/ai-instructions/github-skill-sungen-delivery.md

@@ -68,7 +68,7 @@ The CLI reads the **per-target result file first** (co-located with `.spec.ts`),
 | Test Data | `{{vars}}` from scenario resolved via test-data.yaml → `key: value; key2: value2` |
 | Steps | `.spec.ts` code comments for interactions (numbered) |
 | Expected results | `.spec.ts` `expect(...)` comments (numbered) |
-| Priority | Tag: `@critical`/`@high`/`@normal`/`@low` (default: Normal) |
+| Priority | Tag: `@high`/`@normal`/`@low` (default: Normal) |
 | Testcase type | `@manual` → Manual, else Auto. Not compiled → "Not compiled" |
 | Test Result | results.json status: passed→Passed, failed/timedOut→Failed, skipped→N/A, else Pending |
 | Executed Date | results.json startTime formatted as `dd/mm/yyyy` |

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

@@ -192,18 +192,17 @@ Any tag not listed above passes through to Playwright `{ tag: [...] }`. Feature-
 |---|---|
 | `@smoke` | Quick sanity check — run after every deploy |
 | `@regression` | Full test suite — run nightly or before release |
-| `@critical` | Priority: system unusable if fails (login, auth, core CRUD) |
-| `@high` | Priority: major feature broken (required validation, key business rules) |
-| `@normal` | Priority: degraded experience (UI layout, secondary flows) |
-| `@low` | Priority: minor/cosmetic (tooltips, hover states, empty states) |
+| `@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 |
 
 **Run filtered:**
 ```bash
 npx playwright test --grep "@smoke"          # only smoke tests
-npx playwright test --grep "@critical"       # only critical priority
-npx playwright test --grep "@smoke|@critical" # smoke OR critical
+npx playwright test --grep "@high"           # only high priority
+npx playwright test --grep "@smoke|@high"    # smoke OR high
 ```
 
 ### Serial vs Parallel (test execution mode)

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

@@ -179,7 +179,7 @@ Skip if `specs/.auth/<role>.json` already exists and a probe navigation reaches
 
 ## Phase 1: Smoke Check (catch fundamentals)
 
-Run **up to 5 scenarios** — pick the first `@critical` or `@high` scenarios in the feature file.
+Run **up to 5 scenarios** — pick the first `@high` scenarios in the feature file.
 
 ```bash
 npx playwright test --grep "VP-.*-001|VP-.*-002|VP-.*-003|VP-.*-004|VP-.*-005" --reporter=line
@@ -195,15 +195,15 @@ npx playwright test --grep "VP-.*-001|VP-.*-002|VP-.*-003|VP-.*-004|VP-.*-005" -
 
 ---
 
-## Phase 2: Priority Wave (@critical + @high)
+## Phase 2: Priority Wave (@high)
 
-Run all `@critical` and `@high` scenarios:
+Run all `@high` scenarios:
 
 ```bash
-npx playwright test --grep "@critical|@high" --reporter=line
+npx playwright test --grep "@high" --reporter=line
 ```
 
-If your Playwright config doesn't support tag grep, use scenario name grep from the feature file — collect VP IDs of `@critical` and `@high` scenarios.
+If your Playwright config doesn't support tag grep, use scenario name grep from the feature file — collect VP IDs of `@high` scenarios.
 
 **Fix only failures from this wave.** Most shared selectors (buttons, headings, navigation) get fixed here because critical/high scenarios exercise them.
 
@@ -353,8 +353,8 @@ user detail:
 |---|---|---|---|
 | 0. Pre-gen | Playwright MCP snapshot → write selectors.yaml | 1 snapshot | Ask user — skip or retry navigation |
 | 0.5. Auth | Manual login in MCP browser → `browser_storage_state` → `specs/.auth/<role>.json` | 1 login | Ask user — retry login or fall back to `sungen makeauth` |
-| 1. Smoke | First 5 @critical/@high | 2 | Ask user — fundamentals broken |
-| 2. Priority | All @critical + @high | 2 | Report failures, continue to Phase 3 |
+| 1. Smoke | First 5 @high | 2 | Ask user — fundamentals broken |
+| 2. Priority | All @high | 2 | Report failures, continue to Phase 3 |
 | 3. Full | All tests | 1 | Report @low/@normal failures, continue |
 | 4. Regression | All tests | 0 | Report final results |
 

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

@@ -12,19 +12,39 @@ Generate **focused test cases per screen section** using a **tier-based approach
 
 | Tier | Priority | What to generate | When |
 |---|---|---|---|
-| **Tier 1** (default) | `@critical` + `@high` | Happy paths, required validation, core business rules, security basics | First run of `create-test` |
+| **Tier 1** (default) | `@high` | Happy paths, required validation, core business rules, security basics | First run of `create-test` |
 | **Tier 2** (expand) | `@normal` + `@low` | UI presence, optional validation, edge cases, cosmetic checks | User runs `create-test` again with "Add viewpoints" mode |
+| **Tier 3** (deep) | `@high` + `@normal` | Extra BVA combinations, cross-field validation, negative/destructive inputs, concurrent/race conditions, complex state transitions | Recommended after Tier 2 completes |
+| **Full** (all-at-once) | All | Tier 1 + 2 + 3 combined in one run | Option at first run, **not recommended** — large output |
 
-**Round 1 (Tier 1)** targets **~10-15 scenarios per section** — enough to cover critical flows and catch real bugs. This is the default behavior.
+**Round 1 (Tier 1)** targets **~10-15 scenarios per section** — enough to cover critical flows and catch real bugs. This is the default behavior. A **Full** option is available but not recommended — it generates all tiers at once, producing very large output (~40-60 scenarios/section).
 
-**Round 2 (Tier 2)** expands to full coverage when the user explicitly chooses "Add viewpoints" or "Add new sections" update mode. Only then generate `@normal` + `@low` scenarios to fill coverage gaps.
+**Round 2 (Tier 2)** expands coverage when the user explicitly chooses "Add viewpoints" or "Add new sections" update mode. Only then generate `@normal` + `@low` scenarios to fill coverage gaps.
+
+**Round 3 (Tier 3)** deepens coverage with advanced test design techniques after Tier 2 is complete. This tier focuses on scenarios that Tier 1+2 didn't cover:
+- **Extra BVA combinations**: additional boundary points not covered in Tier 1 (e.g., `min+1`, `max-1`, typical values between boundaries)
+- **Cross-field validation**: field A value affects field B behavior (dependent fields, conditional required, cascading dropdowns)
+- **Negative/destructive inputs**: SQL injection, XSS payloads, special characters, excessively long strings, unicode edge cases
+- **Concurrent/race conditions**: double submit, back button after submit, multiple tabs, session expiry mid-action
+- **Complex state transitions**: multi-step state changes, undo/redo, conflicting state updates, transition from every non-obvious state
 
 ## Update Mode
 
-When `.feature` already has scenarios, summarize and ask:
+When `.feature` already has scenarios, summarize existing coverage and ask:
+
+**If only Tier 1 exists** (only `@high` scenarios):
 1. **Add new sections** — append new sections with Tier 2 (`@normal` + `@low`) scenarios, continue numbering
 2. **Add viewpoints** — expand existing sections with Tier 2 (`@normal` + `@low`) scenarios
-3. **Replace all** — overwrite with fresh Tier 1 (`@critical` + `@high`) generation
+3. **Replace all** — overwrite with fresh Tier 1 (`@high`) generation
+
+**If Tier 1 + 2 exist** (`@high` + `@normal` + `@low` scenarios):
+1. **Deep coverage (Tier 3)** — add advanced scenarios: extra BVA, cross-field validation, negative inputs, race conditions **(Recommended)**
+2. **Add new sections** — append new sections with Tier 2 scenarios, continue numbering
+3. **Replace all** — overwrite with fresh Tier 1 (`@high`) generation
+
+**If Tier 1 + 2 + 3 exist** (full coverage already):
+1. **Add new sections** — append new sections if screen has changed
+2. **Replace all** — overwrite with fresh Tier 1 (`@high`) generation
 
 For append: read highest `VP-<CAT>-<NNN>`, continue from next number. Never modify existing scenarios.
 
@@ -102,8 +122,15 @@ Apply `sungen-test-design-techniques` to spec-extracted conditions:
 Use `sungen-viewpoint` skill for per-pattern checklists across 4 viewpoints: UI/UX, Data & Validate, Logic, Security.
 
 **Tier-aware gap filling:**
-- **Tier 1 (first run)**: only add `@critical` and `@high` items from the checklists — core security checks (VP-SEC), required field validation (VP-VAL), key state transitions (VP-LOGIC). Skip `@normal`/`@low` items like hover states, empty states, tooltips.
+- **Tier 1 (first run)**: only add `@high` items from the checklists — core security checks (VP-SEC), required field validation (VP-VAL), key state transitions (VP-LOGIC). Skip `@normal`/`@low` items like hover states, empty states, tooltips.
 - **Tier 2 (expand run)**: add `@normal` + `@low` scenarios — UI presence, optional validation, edge cases, cosmetic checks, keyboard nav, hover effects.
+- **Tier 3 (deep run)**: do NOT use viewpoint checklists. Instead, re-apply test design techniques with deeper analysis:
+  - **BVA**: expand from 4-point to 6-point (`min-1`, `min`, `min+1`, `max-1`, `max`, `max+1`) + typical mid-range value
+  - **Decision Table**: enumerate combinations previously capped — cover remaining outcome rows
+  - **Cross-field**: identify field dependencies from spec, generate one scenario per dependency
+  - **Negative inputs**: add security-oriented inputs (SQL `' OR 1=1`, XSS `<script>`, special chars `<>&"'`, max+100 length)
+  - **Race conditions**: double-click submit, browser back after POST, concurrent edit by two users
+- **Full (all-at-once)**: apply Tier 1 + 2 + 3 rules in a single generation pass. Use all techniques at maximum depth.
 
 **Validation rule**: capture actual error messages from live page or spec.md. Use `User see {{error_var}}` — never assert just "is visible".
 
@@ -111,24 +138,29 @@ Use `sungen-viewpoint` skill for per-pattern checklists across 4 viewpoints: UI/
 
 Every scenario **MUST** have exactly one priority tag. Add it before the scenario line (after `@extend:` if present).
 
+**Rule: look at what the WHEN step does and what THEN asserts — that determines the tag.**
+
 | Tag | When to use |
 |---|---|
-| `@critical` | System unusable if fails — login/logout, authentication redirect, main create/submit/delete, permission denied |
-| `@high` | Major feature broken — required field validation, core business rules, data displays correctly, key navigation |
-| `@normal` | Degraded experience — UI layout/element presence, secondary flows, optional field validation, search/filter |
-| `@low` | Minor/cosmetic — tooltips, hover states, empty states, default sort, placeholder text |
+| `@high` | WHEN performs: login/logout, submit happy path, auth-check, primary CRUD action. THEN asserts: success state, redirect, or security gate |
+| `@normal` | WHEN provides invalid/empty input, OR scenario tests search/filter/notification/secondary flow. THEN asserts: error message, secondary feature result |
+| `@low` | THEN only asserts: element visible, text label, placeholder, tooltip, icon, layout. WHEN (if any) is navigation only |
 
 ### Auto-assign heuristics
 
-| Viewpoint + Pattern | Default priority |
+| Scenario type (by WHEN + THEN structure) | Tag |
 |---|---|
-| VP-SEC-* (all security scenarios) | `@critical` |
-| VP-LOGIC-* with create/submit/delete/login | `@critical` |
-| VP-LOGIC-* other state changes | `@high` |
-| VP-VAL-* required field / submit empty | `@high` |
-| VP-VAL-* format, boundary, optional fields | `@normal` |
-| VP-UI-* form fields present, table columns | `@normal` |
-| VP-UI-* hover, tooltip, empty state, placeholder | `@low` |
+| Auth: login / logout / protected page redirect | `@high` |
+| CRUD happy path: create / update / delete → success message or redirect | `@high` |
+| Security: unauthenticated access → redirected to login | `@high` |
+| Primary business flow step completes successfully | `@high` |
+| Validation: invalid / empty input → error message shown | `@normal` |
+| Boundary / format validation (email, length, range) | `@normal` |
+| Secondary features: search, filter, sort, pagination, notification | `@normal` |
+| State transition not on primary success path (cancel, undo, back) | `@normal` |
+| Element / component presence check (is it visible?) | `@low` |
+| Text content: label, placeholder, tooltip, warning message text | `@low` |
+| Visual / cosmetic: alignment, icon, empty state, hover style | `@low` |
 
 **`@steps:` scenarios** do NOT get a priority tag (they are setup blocks, not test cases).
 
@@ -188,11 +220,11 @@ Serial (default) is best for: CRUD flows, sequential user journeys, UI checks on
 @cleanup:forms
 Feature: kudos Screen
 
-  @critical
+  @high
   Scenario: Send kudos
     ...
 
-  @critical @no-auth
+  @high @no-auth
   Scenario: Unauthenticated user is redirected
     ...
 ```
@@ -218,9 +250,9 @@ Feature: <Screen> Screen
     When User click [Create] button
     Then User see [Form] dialog
 
-  # --- Section: Create User Form (Tier 1: @critical + @high) ---
+  # --- Section: Create User Form (Tier 1: @high) ---
 
-  @critical @extend:open_form
+  @high @extend:open_form
   Scenario: VP-LOGIC-001 Submit form with valid data creates record
     Given User is on [Form] dialog
     When User fill [Name] field with {{valid_name}}
@@ -233,7 +265,7 @@ Feature: <Screen> Screen
     When User click [Submit] button
     Then User see [Name error] message with {{name_required_error}}
 
-  # --- Section: User Table (Tier 1: @critical + @high) ---
+  # --- Section: User Table (Tier 1: @high) ---
 
   @high
   Scenario: VP-VAL-010 Table displays correct data
@@ -241,7 +273,7 @@ Feature: <Screen> Screen
       | Name       | Email        |
       | {{name_1}} | {{email_1}}  |
 
-  @critical
+  @high
   Scenario: VP-SEC-010 Unauthorized user cannot access page
     Given User is not logged in
     When User navigate to [Screen] page
@@ -250,6 +282,8 @@ Feature: <Screen> Screen
 
 **Tier 2 (expand run)** adds `@normal` + `@low` scenarios like UI field presence, hover states, tooltips, empty states.
 
+**Tier 3 (deep run)** adds advanced `@high` + `@normal` scenarios: extra BVA boundaries, cross-field validation, negative/destructive inputs, concurrent/race conditions.
+
 ### When to use DataTable vs Row Scope
 
 | Pattern | Use when |
@@ -317,14 +351,14 @@ Feature: Award Submission Flow
   Background:
     Given User is on [Login] page
 
-  @critical
+  @high
   Scenario: User login successfully
     When User fill [Login:Email] field with {{login.email}}
     And User fill [Login:Password] field with {{login.password}}
     And User click [Login:Submit] button
     Then User see [Dashboard] page
 
-  @critical
+  @high
   Scenario: User navigates to awards and submits
     Given User is on [Awards] page
     When User fill [Awards:Nominee] field with {{submission.nominee}}

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

@@ -38,12 +38,12 @@ Score: `(dimensions_covered / 6) * 40`. Validate technique application with `sun
 | All applicable VP present (UI/VAL/LOGIC/SEC) | 10 |
 | Correct classification | 8 |
 | `VP-<CAT>-<NNN>` naming + section grouping | 4 |
-| Priority tag present and correct (`@critical`/`@high`/`@normal`/`@low`) | 4 |
+| Priority tag present and correct (`@high`/`@normal`/`@low`) | 4 |
 | 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.
 
-**Tier-aware scoring**: If the feature file only contains `@critical` + `@high` scenarios (Tier 1), do NOT penalize for missing VP-UI viewpoint — UI scenarios are intentionally deferred to Tier 2. Score "All applicable VP present" based on Tier 1-relevant viewpoints only (VAL, LOGIC, SEC). Note in the review output: *"VP-UI deferred to Tier 2 — run create-test with 'Add viewpoints' to expand."*
+**Tier-aware scoring**: If the feature file only contains `@high` scenarios (Tier 1), do NOT penalize for missing VP-UI viewpoint — UI scenarios are intentionally deferred to Tier 2. Score "All applicable VP present" based on Tier 1-relevant viewpoints only (VAL, LOGIC, SEC). Note in the review output: *"VP-UI deferred to Tier 2 — run create-test with 'Add viewpoints' to expand."*
 
 ---
 
@@ -80,7 +80,7 @@ Do NOT mark `@manual` when data is visible in snapshot or documented in spec —
 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. **Missing/wrong priority tag** — every non-`@steps` scenario needs exactly one of `@critical`/`@high`/`@normal`/`@low`. SEC→`@critical`, VAL required→`@high`, UI layout→`@normal`, hover/tooltip→`@low`
+5. **Missing/wrong priority tag** — every non-`@steps` scenario needs exactly one of `@high`/`@normal`/`@low`. SEC/CRUD happy path/auth→`@high`, validation/secondary features→`@normal`, presence/cosmetic→`@low`
 6. **Always-enabled elements** — `is enabled` on never-disabled element? Remove
 7. **Test-data completeness** — every `{{var}}` must exist in test-data.yaml
 8. **Missing BVA boundaries** — spec defines min/max range but scenarios only test midpoint? Add `min-1`, `min`, `max`, `max+1`

package/dist/orchestrator/templates/ai-instructions/github-skill-sungen-test-design-techniques.md

@@ -53,7 +53,7 @@ Scenario: VP-VAL-003 Above maximum is rejected           # value = 101
 | 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 |
+| **Full 6-point** | `min-1`, `min`, `min+1`, `max-1`, `max`, `max+1` | Critical fields with `@high` priority |
 
 **How to apply** (example: "quantity must be 1-10"):
 - `min-1` = 0 -> invalid
@@ -82,7 +82,7 @@ Scenario: VP-VAL-003 Above maximum is rejected           # value = 101
 - `@normal` Form invalid + no permission → disabled
 - `@normal` Form valid + no permission → disabled
 - `@normal` Has permission + form invalid → disabled
-- `@critical` Form valid + has permission → succeeds
+- `@high` Form valid + has permission → succeeds
 
 ---
 

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

@@ -266,7 +266,7 @@ For VP-SEC scenarios testing **unauthorized access** (no login, wrong role, dire
 - Do NOT use `@manual` for these — they are automatable.
 
 ```gherkin
-@critical @no-auth
+@high @no-auth
 Scenario: VP-SEC-001 Unauthenticated user cannot access admin page
   Given User is on [Admin] page
   Then User see [Login] page

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sun-asterisk/sungen",
-  "version": "2.6.5",
+  "version": "2.6.7",
   "description": "Deterministic E2E Test Compiler - Gherkin + Selectors → Playwright tests",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/cli/index.ts

@@ -21,7 +21,7 @@ async function main() {
   program
     .name('sungen')
     .description('Deterministic E2E Test Compiler — Gherkin + Selectors → Playwright')
-    .version('2.6.5');
+    .version('2.6.7');
 
   // Global options
   program