@sun-asterisk/sungen 3.1.2-beta.102 → 3.1.2-beta.103

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

@@ -69,6 +69,20 @@ A screen often matches several patterns at once — a login screen is *both* a f
 - VP-LOGIC = outcome depends on the user's *action* (click, submit, navigate)
 - VP-SEC = checks access control and malicious input
 
+### Domain category codes — required for the coverage-balance gate
+
+The 4 viewpoints above are the *generic* axes. On a domain screen, the `VP-<CAT>` code must use the **canonical short code** for what the scenario exercises, so the audit's coverage-balance gate buckets it correctly. Use these exact codes — **never long-form or freeform** (`VP-NAV` not `VP-NAVIGATION`, `VP-SUB` not `VP-SUBSCRIPTION`, `VP-FILTER` not `VP-FILTERING`):
+
+| Bucket | Codes | Use for |
+|---|---|---|
+| **business-core** | `LIST` · `CART` · `PRODUCT` · `FILTER` · `CHECKOUT` · `ORDER` | the screen's core domain data/actions (product list, cart, checkout, order, filtered results) |
+| presentation | `UI` | layout / visual state |
+| validation-security | `VAL` · `SEC` · `SUB` | input validation · access/injection · subscribe/newsletter |
+| behavior | `LOGIC` | action-driven state changes |
+| navigation | `NAV` | landing on / moving between pages |
+
+**On a business-core page** (product list, cart, checkout, search results), the core data scenarios MUST carry a **business-core** code (`VP-LIST-*`, `VP-CART-*`, `VP-PRODUCT-*`, …) — not a generic `VP-UI`/`VP-LOGIC` or a freeform `VP-<word>`. A freeform/long-form prefix parses as `NONE`, scores **0 on the balance axis**, and drops the audit score (~9.3 → ~7.7 in practice). Keep `VP-UI/VAL/LOGIC/SEC` for the cross-cutting checks; give the domain scenarios their domain code.
+
 ---
 
 ## Shared Checks

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

@@ -69,6 +69,20 @@ A screen often matches several patterns at once — a login screen is *both* a f
 - VP-LOGIC = outcome depends on the user's *action* (click, submit, navigate)
 - VP-SEC = checks access control and malicious input
 
+### Domain category codes — required for the coverage-balance gate
+
+The 4 viewpoints above are the *generic* axes. On a domain screen, the `VP-<CAT>` code must use the **canonical short code** for what the scenario exercises, so the audit's coverage-balance gate buckets it correctly. Use these exact codes — **never long-form or freeform** (`VP-NAV` not `VP-NAVIGATION`, `VP-SUB` not `VP-SUBSCRIPTION`, `VP-FILTER` not `VP-FILTERING`):
+
+| Bucket | Codes | Use for |
+|---|---|---|
+| **business-core** | `LIST` · `CART` · `PRODUCT` · `FILTER` · `CHECKOUT` · `ORDER` | the screen's core domain data/actions (product list, cart, checkout, order, filtered results) |
+| presentation | `UI` | layout / visual state |
+| validation-security | `VAL` · `SEC` · `SUB` | input validation · access/injection · subscribe/newsletter |
+| behavior | `LOGIC` | action-driven state changes |
+| navigation | `NAV` | landing on / moving between pages |
+
+**On a business-core page** (product list, cart, checkout, search results), the core data scenarios MUST carry a **business-core** code (`VP-LIST-*`, `VP-CART-*`, `VP-PRODUCT-*`, …) — not a generic `VP-UI`/`VP-LOGIC` or a freeform `VP-<word>`. A freeform/long-form prefix parses as `NONE`, scores **0 on the balance axis**, and drops the audit score (~9.3 → ~7.7 in practice). Keep `VP-UI/VAL/LOGIC/SEC` for the cross-cutting checks; give the domain scenarios their domain code.
+
 ---
 
 ## Shared Checks

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sun-asterisk/sungen",
-  "version": "3.1.2-beta.102",
+  "version": "3.1.2-beta.103",
   "description": "Deterministic E2E Test Compiler - Gherkin + Selectors → Playwright tests",
   "main": "src/index.ts",
   "types": "src/index.ts",
@@ -33,7 +33,7 @@
     "node": ">=18.0.0"
   },
   "dependencies": {
-    "@sungen/driver-ui": "3.1.2-beta.102",
+    "@sungen/driver-ui": "3.1.2-beta.103",
     "@anthropic-ai/sdk": "^0.71.0",
     "@babel/parser": "^7.28.5",
     "@babel/traverse": "^7.28.5",

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

@@ -69,6 +69,20 @@ A screen often matches several patterns at once — a login screen is *both* a f
 - VP-LOGIC = outcome depends on the user's *action* (click, submit, navigate)
 - VP-SEC = checks access control and malicious input
 
+### Domain category codes — required for the coverage-balance gate
+
+The 4 viewpoints above are the *generic* axes. On a domain screen, the `VP-<CAT>` code must use the **canonical short code** for what the scenario exercises, so the audit's coverage-balance gate buckets it correctly. Use these exact codes — **never long-form or freeform** (`VP-NAV` not `VP-NAVIGATION`, `VP-SUB` not `VP-SUBSCRIPTION`, `VP-FILTER` not `VP-FILTERING`):
+
+| Bucket | Codes | Use for |
+|---|---|---|
+| **business-core** | `LIST` · `CART` · `PRODUCT` · `FILTER` · `CHECKOUT` · `ORDER` | the screen's core domain data/actions (product list, cart, checkout, order, filtered results) |
+| presentation | `UI` | layout / visual state |
+| validation-security | `VAL` · `SEC` · `SUB` | input validation · access/injection · subscribe/newsletter |
+| behavior | `LOGIC` | action-driven state changes |
+| navigation | `NAV` | landing on / moving between pages |
+
+**On a business-core page** (product list, cart, checkout, search results), the core data scenarios MUST carry a **business-core** code (`VP-LIST-*`, `VP-CART-*`, `VP-PRODUCT-*`, …) — not a generic `VP-UI`/`VP-LOGIC` or a freeform `VP-<word>`. A freeform/long-form prefix parses as `NONE`, scores **0 on the balance axis**, and drops the audit score (~9.3 → ~7.7 in practice). Keep `VP-UI/VAL/LOGIC/SEC` for the cross-cutting checks; give the domain scenarios their domain code.
+
 ---
 
 ## Shared Checks

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

@@ -69,6 +69,20 @@ A screen often matches several patterns at once — a login screen is *both* a f
 - VP-LOGIC = outcome depends on the user's *action* (click, submit, navigate)
 - VP-SEC = checks access control and malicious input
 
+### Domain category codes — required for the coverage-balance gate
+
+The 4 viewpoints above are the *generic* axes. On a domain screen, the `VP-<CAT>` code must use the **canonical short code** for what the scenario exercises, so the audit's coverage-balance gate buckets it correctly. Use these exact codes — **never long-form or freeform** (`VP-NAV` not `VP-NAVIGATION`, `VP-SUB` not `VP-SUBSCRIPTION`, `VP-FILTER` not `VP-FILTERING`):
+
+| Bucket | Codes | Use for |
+|---|---|---|
+| **business-core** | `LIST` · `CART` · `PRODUCT` · `FILTER` · `CHECKOUT` · `ORDER` | the screen's core domain data/actions (product list, cart, checkout, order, filtered results) |
+| presentation | `UI` | layout / visual state |
+| validation-security | `VAL` · `SEC` · `SUB` | input validation · access/injection · subscribe/newsletter |
+| behavior | `LOGIC` | action-driven state changes |
+| navigation | `NAV` | landing on / moving between pages |
+
+**On a business-core page** (product list, cart, checkout, search results), the core data scenarios MUST carry a **business-core** code (`VP-LIST-*`, `VP-CART-*`, `VP-PRODUCT-*`, …) — not a generic `VP-UI`/`VP-LOGIC` or a freeform `VP-<word>`. A freeform/long-form prefix parses as `NONE`, scores **0 on the balance axis**, and drops the audit score (~9.3 → ~7.7 in practice). Keep `VP-UI/VAL/LOGIC/SEC` for the cross-cutting checks; give the domain scenarios their domain code.
+
 ---
 
 ## Shared Checks