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

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

@@ -1,320 +0,0 @@
----
-name: sungen-tc-review
-description: 'Test case review — 7-dimension rubric (100 pts), Syntax gate + Coverage matrix. Auto-loaded by review command.'
-user-invocable: false
----
-
-## How to use this skill
-
-Review one `.feature` (plus `selectors.yaml` + `test-data.yaml` if present) in 3 steps:
-
-1. **Syntax Gate (Layer A)** — check Sungen syntax. On a hard-fail, return to the author; do NOT proceed to detailed scoring.
-2. **Coverage Matrix (Layer B)** — map against Sun Common Checklist viewpoints; list the gaps.
-3. **Scoring (Layer C)** — score the 7-dimension/100-pt rubric. Layers A and B are *how* to evaluate each dimension, not separate bonus points.
-
-> Scope: Sungen tests run through Playwright — **UI-only**. No DB/API/email-body/server-side. Out-of-scope viewpoints (see Out-of-scope) are NOT penalized; if required, mandate `@manual` + a technical reason.
-
----
-
-## Scoring (7 dimensions, 100 points)
-
-**≥ 70**: PASS | **50–69**: CONDITIONAL (fix before execution) | **< 50**: FAIL (revise & re-review)
-
-**Scoring convention**: Each row in a dimension table is scored independently. Full points if satisfied across all in-scope TCs; otherwise deduct ~1 pt per distinct violation, floor 0 per row (never negative). A row whose technique has no relevant case → 0 for that row only, it does not zero the whole dimension. Sum the rows for the dimension total.
-
-| Dimension | Pts |
-|---|---|
-| Structure & Format | 15 |
-| Coverage (6 sub-dimensions) | 30 |
-| Assertion Quality | 20 |
-| Test Data | 10 |
-| Security & Permission | 10 |
-| Automation Readiness | 10 |
-| Maintainability | 5 |
-| **Total** | **100** |
-
----
-
-## Layer A — Syntax Gate (against `sungen-gherkin-syntax`)
-
-Hard-fail gate. Any ✗ is a syntax error — must be fixed; do not score further while errors remain.
-
-### A1. Structure & Keyword
-
-- [ ] Correct shape: `User <Action> [Target] <Type> [in [Parent] pType] [with {{v}}] [is State]`
-- [ ] Actor is always `User`, active voice
-- [ ] `Given` → only `is on` · `When` → action (click/fill/select/press/clear/check/uncheck/hover/wait) · `Then` → only `see` · `And` inherits the preceding keyword
-- [ ] NO `Given User see…` (→ `Then`, or entry assertion `Given User is on [X] page`)
-- [ ] NO `When … And User is on [X] dialog` (→ `And User see` or a separate `Given`)
-- [ ] NO literal-URL navigation (`navigate to "/x"`) → `User is on [X] page` + declare in `selectors.yaml`
-
-### A2. Action → Element type
-
-- [ ] checkbox/toggle → `check`/`uncheck` (NOT `click`)
-- [ ] dropdown → `select … with {{v}}` · field/textarea/search → `fill … with {{v}}` · button/tab/link/icon → `click`
-- [ ] radio: select another option via `check [Other] radio`, NOT `uncheck` a radio
-- [ ] `press` only for keys (`press Enter key`), NOT `press [Submit] button`
-- [ ] Element type is in the valid type table (Context/Input/Trigger/Data/Feedback/System)
-- [ ] `wait for` only for Spinner/Modal, minimize usage
-
-### A3. Value — State — click-rule
-
-- [ ] Dynamic data: `with {{snake_case}}`, NO hardcoding (`with {{admin@mail.com}}` → ✗ `with {{invalid_email}}`)
-- [ ] State: `is <state>` (hidden/visible/disabled/checked/empty/loading…), NOT `{{disabled}}`, NOT missing `is`
-- [ ] **click + value**: static (`button/link/icon/tab`) takes NO value; dynamic (`row/item/card/option`) takes `with {{v}}`
-- [ ] `fill` always has a target type (`fill [email] field with {{v}}`, not `fill [email] with {{v}}`)
-
-### A4. Assertion (8 patterns → determines the Playwright assertion)
-
-- [ ] Visibility `see [T] type` → NO redundant `is visible`; hidden uses `is hidden`
-- [ ] Correct pattern: text(`message/header/label with {{v}}`) · partial(`text contains {{v}}`) · input(`field/dropdown with {{v}}`) · state(`is …`) · attribute(`image/link with {{v}}`) · count(`row with {{count}}`) · page(`[T] page`)
-- [ ] Table: `[Col] column in [Table] table`, `[Ref] row in [Table] table with {{v}}`, `table with {{count}}`/`is empty`, `table match data:`; row scope used correctly
-
-### A5. Alert / Scope / Background
-
-- [ ] Alert step appears **before** the action that triggers the dialog
-- [ ] Scope-dependent flow (dialog/frame) → use `@steps`/`@extend`, do NOT cram into `Background`
-- [ ] `@extend`: entry assertion must be `Given User is on [X] type`, NOT `Given User see`; name `@steps:module__action` (snake/kebab)
-- [ ] Scenario name matches the step's element type (a scenario that says "modal" must use `[X] dialog/modal` consistently)
-
-### A6. YAML & Variables
-
-- [ ] Selector keys: lowercase, keep Unicode, use **spaces** (no underscores/dots); same label → `--type`/`--N` suffix; names >30 chars → shorten to 1–3 words
-- [ ] Types requiring explicit YAML: `date-picker`, `uploader`, `overlay`, `frame`, `step`
-- [ ] Every `{{var}}` in `.feature` exists in `test-data.yaml`; NO orphan keys
-- [ ] Dynamic vars (`{{$timestamp}}`/`{{$uuid}}`/`{{$random:a:b}}`) used correctly for run-unique data (CRUD)
-- [ ] `locator` (CSS) only as a last resort
-
-### A7. Tags & Flow
-
-- [ ] Exactly **one** priority tag per scenario (`@high`/`@normal`/`@low`…)
-- [ ] `@manual`/`@auth:role`/`@no-auth`/`@cleanup:*`/`@parallel`/`@flow` used in the right context
-- [ ] `@parallel` is REQUIRED when a feature mixes auth groups (`@auth:user` + `@no-auth`)
-- [ ] `@flow`: `[Screen:Element]` namespace is consistent; YAML keys quoted with the colon (`"login:submit":`)
-
----
-
-## Layer B — Coverage Matrix (against Sun Common Checklist for QA)
-
-Build a mapping table: for each applicable group, does the feature have a matching scenario → list the **gaps**. Each group maps to a Sungen VP classification.
-
-| Category | Sub-viewpoint to check | VP map | Sungen representation |
-|---|---|---|---|
-| **Check Accessing** | Not logged in → redirect login; logged in with correct role; wrong role → access denied/hide menu | VP-SEC | `@no-auth` (→ login), `@auth:role` (right/wrong role) |
-| **Check Initial** | Default field state; autofocus; tab order; display per spec | VP-UI | `Then User see [T] field is empty/focused`, `see [T] page` |
-| **Check Required** | Submit with one / multiple required fields blank | VP-VAL | empty `fill` → `see [Err] message with {{v}}` |
-| **Check Format** | Email/phone… invalid format; leading/trailing space; uppercase | VP-VAL | `with {{invalid_email}}` → error |
-| **Check Maxlength** | Exceed maxlength per field | VP-VAL | `with {{over_max_name}}` → error/blocked input |
-| **Check Exist/Duplicate** | Duplicate email/username | VP-VAL | `with {{existing_email}}` → "already exists" |
-| **Check Valid** | Happy path: all valid fields; required-only | VP-UI/LOGIC | real data → success message + post-action state |
-| **Check Expire** | OTP/token/link expired | VP-LOGIC | usually `@manual` (time-dependent) |
-| **Behavior Handling** | Rapid double-click; slow network; reload keeps/loses data; copy-paste; Enter in field | VP-LOGIC | `double click`, `wait for [Spinner]`, `press Enter key` |
-| **Account Status** | Deleted / blocked / inactive account login | VP-LOGIC | corresponding account data → error message |
-| **Security** | SQL Injection; XSS; Data Integrity (edit dropdown/remove `disabled` via DevTools → server rejects). SQL on LIKE/search fields → 2 TCs per the `sungen-viewpoint` SQL 2-layer rule. | VP-SEC | `with {{xss_*}}`/`{{sql_*}}`; data-integrity usually `@manual` |
-| **Cross-surface outcomes** | Admin action → outcome on user-facing surface (portal, mobile, widget); spec defines display condition on another URL | VP-LOGIC-CS | `@high @manual` per surface per business rule — at minimum 1 per cross-surface rule; use `@auth:role` + `@extend` if surface reachable in same test run |
-
-**Tier-aware**: if the suite only has `@high` (Tier 1) → do NOT penalize missing pure VP-UI (deferred to Tier 2). Require full VP coverage only on a Full review.
-
-### EP/BVA rules when mapping
-
-- **EP**: keep only **one representative** per invalid class; same-class duplicates → flag as redundant.
-- **BVA**: spec defines min/max → cover `min-1`, `min`, `max`, `max+1` (Maxlength, counts…).
-- Error messages must match the spec **word-for-word**, not generic.
-- **Data-driven (`@cases`)**: a `@cases:<dataset>` scenario legitimately covers many inputs in ONE scenario (one row per EP class / boundary / rule). Do **not** flag it as "too few negative cases" or as duplication — instead review the **dataset rows**: are all EP classes / boundary triples present, each labelled, expected values exact? N near-identical scenarios that differ only by input value → flag and recommend collapsing to `@cases`.
-
----
-
-## Layer C — Dimension details
-
-### Structure & Format (15)
-
-| Check | Pts |
-|---|---|
-| ID format `VP-<CAT>-<NNN>` (e.g. `VP-LOGIC-001`, `VP-VAL-001`); deleted IDs never reused | 3 |
-| Clear title: `[object] + [result/behavior] + [condition]` | 3 |
-| Correct module/screen + exactly **one** priority tag | 2 |
-| `Given` = state (`User is on [T] page`), not an action | 3 |
-| `When`/`And` = atomic steps (1 action), no vague words, last step is the trigger | 2 |
-| `Then` is specific & measurable (`see [T] type with {{v}}`/`is state`), not mere existence | 2 |
-
-### Coverage (30) — 6 sub-dimensions
-
-| Sub | Technique | Pts | What to check |
-|---|---|---|---|
-| Happy paths | — | 5 | ≥1 happy path per core function; realistic data; full result assertions |
-| Negative | EP | 6 | one representative per invalid class, no duplicates; error matches spec |
-| Edge | EP | 5 | empty/whitespace, special chars (XSS/SQLi), long strings, abnormal file uploads |
-| Boundary | BVA | 6 | `min-1/min/max/max+1` per range |
-| State transition | ST | 4 | all valid transitions + ≥3 blocked transitions (**UI-only**; full points if all spec states covered) |
-| Condition combo | DT | 4 | decision table for ≥2 dependent conditions; test only rules with distinct outcomes |
-
-> Use the quick estimate `(VPs_covered / 6) * 30` ONLY when cases can't be inspected in depth (portfolio scan); never combine the two methods in one score.
-
-### Assertion Quality (20)
-
-| Check | Pts |
-|---|---|
-| Specific, not generic — "if this assertion PASSES, am I sure the feature works?" must be a confident yes | 6 |
-| Avoids anti-patterns: re-asserting input just typed; exact-match on dynamic content; missing negative assertions | 6 |
-| **Syntax compliance** — steps match `sungen-gherkin-syntax` patterns, correct `[Ref] type with {{v}}`, no bare `is visible` | 4 |
-| Grouping — each case has 2–7 related assertions for the same action | 4 |
-
-### Test Data (10)
-
-| Check | Pts |
-|---|---|
-| No hardcoded env values in `.feature` — use `{{variables}}` | 3 |
-| **Allow test credentials** in `test-data.yaml` if: (a) `.feature` uses `{{var}}` not hardcoded, (b) dedicated test accounts (not prod/personal), (c) env-specific values via `<screen>.<env>.yaml` overrides | 3 |
-| Idempotent — has teardown or unique data (`{{$timestamp}}`/`{{$uuid}}`) so it can run repeatedly | 2 |
-| Realistic data — accented names, real formats, not `abc`/`1` | 2 |
-
-### Security & Permission (10) — UI-level
-
-| Check | Pts |
-|---|---|
-| Authentication — `@no-auth` → redirect login; expired/forged token tests are `@manual` + reason | 3 |
-| Authorization — via `@auth:role`: each role sees the correct elements/pages | 3 |
-| Viewpoint classification — VP-UI/VAL/LOGIC/SEC assigned correctly | 2 |
-| Input security — XSS/SQLi via `{{xss_*}}`/`{{sql_*}}` | 2 |
-
-### Automation Readiness (10)
-
-| Check | Pts |
-|---|---|
-| `@manual` has a valid **technical** reason (not "don't know how to automate" — document as `# TODO: automate when...` comment instead) | 3 |
-| Stable selectors — per `sungen-selector-keys`: keys use spaces, standard types, `locator` only as last resort | 3 |
-| Each step names a concrete element by name/label/role (enough to implement without asking) | 2 |
-| Idempotent + no fixed waits (`wait for [T] dialog` instead of `wait N seconds`) | 2 |
-
-### Maintainability (5)
-
-| Check | Pts |
-|---|---|
-| Title reflects the **assertion**, not the action (reading the title tells you when it FAILS) | 2 |
-| No duplicate TCs; remove obsolete tests when a feature is removed; no same-class VP/EP redundancy | 1 |
-| Short enough: `Background` ≤2 lines, scenario ≤10 steps, 2–7 assertions | 1 |
-| Comments where needed: `# --- Section:` for VP grouping; `@manual` explains why | 1 |
-
----
-
-## Out-of-scope (UI-only Sungen)
-
-Do NOT deduct points when a `.feature` lacks the following viewpoints (Playwright UI cannot verify them). If required → `@manual` + reason, or move to another test layer:
-
-- `API Behavior` (direct status/body response)
-- `Email Verification` content (header/from/to/body/link) — only the post-click UI is verifiable
-- Server-side `Data Integrity` (DevTools edits payload → server rejects)
-- `Performance/Load`, `Rate limit`
-- DB/record verification after an action
-
----
-
-## Quick Scan (run first, ~2 minutes)
-
-10 questions; many "No" → return to author, skip detailed review.
-
-1. ID unique + correct format `VP-<CAT>-<NNN>`?
-2. Title understandable immediately, no context needed?
-3. Every step uses the right keyword (`Given`=is on / `When`=action / `Then`=see)?
-4. Every `{{var}}` exists in `test-data.yaml`?
-5. At least one happy path?
-6. Negative cases for invalid classes (EP)?
-7. Boundary covers the 4 points (`min-1/min/max/max+1`)?
-8. `Then` specific, not generic, no redundant `is visible`?
-9. Test data doesn't hardcode env/static values?
-10. Exactly one priority tag + valid functional tags?
-
-**Interpret**: 9–10 Yes → detailed review | 6–8 Yes → review with caveats | <6 Yes → return for revision.
-
----
-
-## Auto-fix (on detection → suggest fix)
-
-> **Never renumber existing `VP-<CAT>-<NNN>` IDs while fixing** (e.g. after removing an EP duplicate). IDs are the dashboard's tracking key — renumbering survivors loses their pass/fail history. Leave gaps; only assign the next unused number to genuinely new scenarios.
-
-1. **Wrong keyword/action-type** → correct it (`click checkbox` → `check checkbox`; `Given … see` → `Then …`).
-2. **Hardcoded data** → `with {{snake_case}}` + add the key to `test-data.yaml`.
-3. **Redundant `is visible` / state as value** → drop `is visible`; `{{disabled}}` → `is disabled`.
-4. **Missing target type** → add the type (`fill [email] field with {{v}}`).
-5. **click static with value** → remove value; **click dynamic missing value** → add `with {{v}}`.
-6. **Same-class EP duplicates** → keep one representative.
-7. **Generic expected result** → rewrite to assert specific field/element/state.
-8. **Missing BVA** → add `min-1/min/max/max+1`.
-9. **Missing negative path** → map invalid classes, add scenarios.
-10. **All `@high`** → reset by user impact per the `sungen-gherkin-syntax` priority table (auth/CRUD/security/required → `@high`; format/standard-range boundary/search → `@normal`; cosmetic → `@low`).
-11. **`@manual` without reason** → add a technical reason comment explaining why automation is not possible.
-12. **Orphan var in test-data** → delete or reconnect.
-13. **Unnecessary CSS/locator selector** → switch to role+name/label/text; keys use spaces.
-14. **Scope crammed into `Background`** → split into `@steps`/`@extend`.
-15. **Mixed auth groups missing `@parallel`** → add `@parallel`.
-16. **Missing secondary behaviors** — spec defines tiebreaker, fallback rule, or secondary sort but no scenario tests it? Add 1 `@high` TC per rule.
-17. **Missing concurrency scenarios** — spec or test-viewpoint mentions multi-tab, multi-user, or simultaneous actions but no `@manual` scenario exists? Add 1 `@manual` TC per risk (`@normal` by default; `@high` if data integrity at risk).
-
----
-
-## Unverified Selectors (non-scoring metric)
-
-If `selectors/<name>.yaml` exists, count lines matching `@needs-live-verify` (provisional selectors from Figma, not yet checked against a live page).
-- Report the count in the review output; **never** deduct points — the suite can PASS with unverified selectors.
-- If the count > 0, add to the summary: `⚠ <N> selectors flagged @needs-live-verify — run run-test against a live URL to verify.`
-- If `selectors.yaml` does not exist yet (not generated) → omit this metric entirely.
-
----
-
-## Output Format
-
-```markdown
-## Review: <screen / feature>
-**Date**: YYYY-MM-DD  |  **Total TCs**: <n>  |  **Tier**: <1/2>  |  **Unverified selectors**: <n / n/a>
-
-| Dimension              | Score | Max | Notes |
-|------------------------|-------|-----|-------|
-| Structure & Format     |       | 15  |       |
-| Coverage               |       | 30  | x/6 sub-dimensions |
-| Assertion Quality      |       | 20  |       |
-| Test Data              |       | 10  |       |
-| Security & Permission  |       | 10  |       |
-| Automation Readiness   |       | 10  |       |
-| Maintainability        |       | 5   |       |
-| **Total**              |       | 100 | **PASS / CONDITIONAL / FAIL** |
-
-### Syntax Gate (Layer A — hard-fail)
-- [ ] Keyword→Action correct
-- [ ] Action→Type correct; click-rule correct
-- [ ] Assertions follow the 8 patterns, no redundant `is visible`
-- [ ] Every {{var}} exists in test-data.yaml; no orphan keys
-- [ ] Selector keys follow sungen-selector-keys; locator only as last resort
-- [ ] Tags valid; @parallel when mixing auth groups
-- Syntax errors found: <n>
-
-### Coverage Matrix (Layer B)
-| Category | Has scenario? | Gap |
-|---|---|---|
-| Check Accessing | ✓/✗ | ... |
-| Check Required/Format/Maxlength/Duplicate/Valid | ... | ... |
-| Behavior Handling / Account Status | ... | ... |
-| Security (XSS/SQLi) | ... | ... |
-| Cross-surface outcomes | ... | ... |
-
-### ✗ Must-fix
-1. [DIMENSION] VP-XXX issue description
-   → Fix: ...
-
-### ⚠ Suggested
-1. [TEST-DATA] ...
-
-### ✓ Strengths
-- ...
-
-### Recommendations (if CONDITIONAL/FAIL)
-- ...
-```
-
----
-
-## Scope & Maintenance
-
-- **When NOT to apply**: exploratory charters, performance/load scripts, pure NFR specs — this rubric grades functional test cases.
-- **Adapting weights**: a project may rebalance the 7 dimensions (e.g. security-critical service: Security→15, Maintainability→0) as long as the total stays 100 and the PASS/CONDITIONAL/FAIL thresholds are restated. Record any change in this section.
-- **References**: detailed syntax → `sungen-gherkin-syntax`; selector keys → `sungen-selector-keys`; VP classification → `sungen-viewpoint`; generation workflow → `sungen-tc-generation`.
-- **Owner / version**: Owner: `<QA Lead>` · Version: `2.0` · Last updated: `2026-06-03`.

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

@@ -1,118 +0,0 @@
----
-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
-
-Apply selectively — not every screen needs all four techniques. Use the technique only when the spec provides the trigger condition.
-
-| Technique | Apply when spec mentions | Skip when |
-|---|---|---|
-| EP (Equivalence Partitioning) | Input types, categories, roles, valid/invalid ranges | No validation or only a required-field check |
-| BVA (Boundary Value Analysis) | Numeric range, string length, date range, count limit | No boundary defined in spec |
-| Decision Table | 2+ mutually dependent conditions with different outcomes | Conditions are independent of each other |
-| State Transition | Entity lifecycle, workflow states, status changes | No state machine in spec |
-
-**Rule:** These techniques determine **how many** and **which** scenarios to generate. `sungen-viewpoint` determines **which viewpoints** to cover.
-
-**Implementing the data table → `@cases` (data-driven):** when EP classes / BVA boundary triples /
-decision-table rows share the *same step shape* and differ only by input/expected values, encode
-them as ONE `@cases:<dataset>` scenario (each class/boundary/rule = one row in the test-data list,
-labelled by a `case` column) instead of N near-duplicate scenarios. The technique still decides the
-rows; `@cases` is how you write them compactly. See `sungen-gherkin-syntax` → Data-driven.
-
----
-
-## 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` | High-risk fields with `@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) — 4 TCs per range:
-- `VP-VAL-010 Below minimum (0) is rejected`
-- `VP-VAL-011 Minimum boundary (1) is accepted`
-- `VP-VAL-012 Maximum boundary (10) is accepted`
-- `VP-VAL-013 Above maximum (11) is rejected`
-
-**Priority by field risk:**
-- Critical field / inclusive operator (`<=`, `>=`) / business-rule boundary → `@high` (Tier 1)
-- Standard field with a spec-defined range → `@normal` (Tier 2)
-
-**Low-risk fields:** Apply EP only (valid class + invalid class) — skip BVA entirely. Reserve BVA for fields where off-by-one errors have user impact (quantity limits, file size, password length, date ranges).
-
----
-
-## 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
-- `@high` Form valid + has permission → succeeds
-
-**Tier mapping for DT rows:**
-- Row with a **distinct outcome not covered by any other row** → Tier 1 `@high`
-- Row whose outcome is already tested by another row (same result, different condition path) → Tier 2 `@normal`
-- When >3 boolean conditions (>8 rows): keep all distinct-outcome rows as Tier 1, move redundant-outcome rows to Tier 2 or `@manual`.
-
----
-
-## 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/github-skill-sungen-viewpoint-group-a-data-entry.md

@@ -1,203 +0,0 @@
-# GROUP A: DATA ENTRY
-
-> The user feeds data into the system — field by field, file by file, or in bulk.
-
-Patterns: 1. Form & Inputs · 2. File Upload · 3. Import / Export
-See `SKILL.md` for the 4 Viewpoints, Shared Checks, and Security Tag Rules.
-
----
-
-## 1. Form & Inputs
-
-> **Base pattern.** The field-level validation here is inherited by Create (4), Update (5), Login (15), Register (16), Password (17). Generate this as a standalone section only for a plain form with no more-specific role (settings, profile, contact) — see *Pattern selection* in `SKILL.md`.
-
-**Apply when**: the screen has at least 1 input field and 1 submit button that sends data to the server, and no more-specific pattern (4/5/15/16/17) applies.
-
-**Shared checks applied**: XSS/Injection
-
----
-
-### Tier 1 — @high
-
-**[VP-LOGIC] Business behavior**
-
-- All required fields empty → Submit button is disabled, no request is sent on click
-- All required fields filled validly → Submit button becomes enabled and clickable
-- Submit the form with valid data → success feedback appears (toast/message/redirect), data is saved to the system
-- Submit the form → server returns an error (5xx, business error) → error message appears, all entered data is preserved on the form
-- User clicks submit twice in a row before the response arrives → only 1 request is sent, no duplicate record is created
-- Field A value changes → Field B updates its options accordingly immediately (field dependency; override if the spec uses field visibility: Field B is shown/hidden instead of changing options)
-
-**[VP-VAL] Input validation**
-
-- Submit while a required field is empty (applies if Submit is not disabled — Pattern B) → error message appears right at that field, not only a generic toast
-- Enter beyond max length → field accepts no more characters (HTML maxlength default; override if the spec uses server-side: input accepted but rejected on submit with an error stating the limit)
-- Enter the wrong format (email, phone, date…) → error message appears at the field, field is highlighted (text comes from {{format_error}} in test-data.yaml)
-- User fixes the field after an error → the error clears immediately once the value becomes valid (real-time clear)
-- Input containing only whitespace → treated as empty, submit shows the required error (override if the spec requires auto-trim and accept)
-
-**[VP-SEC]** → Apply Shared Check: XSS/Injection
-
----
-
-### Tier 2 — @normal + @low
-
-**[VP-UI] Interface states**
-
-- [@normal] Required fields have a visual indicator (asterisk, color, "Required" label)
-- [@normal] Disabled fields: visually dimmed, cursor not-allowed, accept no input
-- [@normal] Focused field: border/outline highlight is clear, distinguishable from an unfocused field
-- [@low] Tab order: the Tab key moves focus in a logical order, top to bottom, left to right
-- [@low] Placeholder text: shows the correct hint text per spec, disappears once the user starts typing
-- [@low] Character counter (if the spec has one): shows the remaining character count, changes color near or at the limit
-
-**[VP-VAL] Boundary values**
-
-4 TCs per range (min-1, min, max, max+1). Default tag = @normal (Tier 2).
-**Override to @high (Tier 1)** when the field is on a critical business rule or the spec uses inclusive operators (`<=`, `>=`).
-
-- [@normal] Exactly the min value → accepted, no error
-- [@normal] Exactly the max value → accepted, no error
-- [@normal] Min - 1 unit → rejected, appropriate error
-- [@normal] Max + 1 unit → rejected, appropriate error
-
----
-
-### ⚡ Cross-pattern interactions
-
-- **+ Modal/Dialog**: Form inside a modal → on submit success the modal closes, background data updates immediately without a full-page reload
-- **+ Create/Add**: Apply this entire checklist. Add: the form opens as a blank slate, no data cached from a previous submit or a previous open
-- **+ Update/Edit**: Apply this entire checklist. Add: the form pre-fills the correct current data from the DB
-- **+ Notification**: Submit success → toast shows {{success_message}} from test-data.yaml, auto-dismisses after a few seconds
-
----
-
-## 2. File Upload
-
-**Apply when**: the screen has a component letting the user upload a file (image, PDF, video, document…). It can be standalone or a field within a larger form.
-
-**Shared checks applied**: XSS/Injection (via file name)
-
----
-
-### Tier 1 — @high
-
-**[VP-LOGIC] Upload behavior**
-
-- Upload a file of the right type and size → upload succeeds, file name/thumbnail/preview appears in the UI
-- Upload in progress → progress indicator appears, the form's submit button is disabled until the upload completes
-- Upload fails (network error, server timeout) → error message states the reason clearly, the user can retry
-- User removes an uploaded file → the file is removed from the form and deleted from the server immediately (override if the spec uses lazy delete: only deleted on form submit)
-- Multiple files (if the spec allows) → each file has its own upload progress and status
-
-**[VP-VAL] File constraints**
-
-- Upload a file with a disallowed extension (not in the whitelist) → rejected immediately, error lists the allowed types
-- Upload a file exceeding the size limit → rejected, error states the limit and the actual size of the selected file
-- Submit the form without uploading a file (field required) → "file required" error appears, the form does not submit
-- Upload an empty file (0 bytes) → rejected with an appropriate error
-
-**[VP-SEC]**
-
-- Upload a file with a valid extension but whose real MIME type is executable (file-type spoofing) → server validates the real MIME type and rejects it
-- File name containing a path-traversal string (`../../etc/passwd`, `../config`) → file name is sanitized, not executed, no path is exposed
-- Upload without authentication → 401/403, the file is not stored on the server
-
----
-
-### Tier 2 — @normal + @low
-
-**[VP-UI] Interface states**
-
-- [@normal] Drop zone or "Choose file" button is clearly visible and easy to recognize
-- [@normal] The list of accepted file types and the size limit appear in the UI (helper text or tooltip)
-- [@normal] During upload: progress bar or percentage is shown, a cancel button is available
-- [@normal] Upload success: thumbnail (image) or file icon + file name + size are clearly shown
-- [@normal] Multiple upload with a limit: a "2/5 files" counter shows, the upload button hides/disables when the limit is reached
-- [@low] Drag & drop: dragging a file over the zone → drop zone highlights, upload starts automatically on drop
-
-**[VP-VAL] Edge cases**
-
-- [@normal] Upload a file with the same name as an existing one → rejected, error "File already exists" (override if the spec defines overwrite or auto-rename to file(1))
-- [@normal] File name with special characters or Unicode (accented Vietnamese) → upload succeeds, the name is displayed correctly
-
----
-
-### ⚡ Cross-pattern interactions
-
-- **+ Form & Inputs**: Upload is a field in the form → the form cannot submit if the upload is incomplete or failed
-- **+ Create/Add**: The created record includes the correct file reference, the file is accessible after reopening the record
-- **+ Update/Edit**: The current file is shown → the user can replace it (new upload overwrites the old) or remove it separately
-- **+ Modal/Dialog**: Upload inside a modal → the modal does not close while uploading, progress is not lost
-- **+ Notification**: Upload success/fail → toast shows the correct message and the correct type (success/error)
-
----
-
-## 3. Import / Export
-
-**Apply when**: the screen has a function to bulk-import data from a file (CSV, Excel) or export the current data to a file.
-
-**Shared checks applied**: Loading State
-
----
-
-### Tier 1 — @high
-
-**[VP-LOGIC] Import behavior**
-
-*No preview:*
-- Upload a valid file (correct format, all required columns, valid data) → import succeeds, the number of imported records is clearly shown
-- After import → new data appears in the list/table immediately without a reload (override if the spec requires a manual reload)
-- Large file (many records, async processing) → UI shows "processing", the user gets a notification when done
-
-*With preview:*
-- Upload a file → a preview table appears with the parsed data, the user sees it before confirming
-- Preview shows inline errors for each invalid row: highlights the row, states the column and the reason
-- User confirms after viewing the preview → valid records are imported, invalid rows are skipped with a row-level error summary (override if the spec requires rejecting all when any row is invalid)
-- User cancels at the preview step → no record is created, the system returns to the state before the upload
-
-*Export:*
-- User clicks Export → the file download starts automatically, format CSV (override if the spec uses XLSX or another format)
-- Export with an active filter → the file contains only the filtered data, not the entire dataset
-- Export success → the file downloads without navigating the user away from the current page
-
-**[VP-VAL] File & data validation**
-
-- Import a file in the wrong format (not CSV/Excel, wrong delimiter) → rejected, error states the required format with an example
-- Import a file missing required columns → rejected, error lists the missing column names
-- Import a file with a wrong column header name → rejected, error lists the required column names (override if the spec allows partial import ignoring unknown columns)
-- Import records with a key that already exists → skip that row, count it under "Y skipped" in the result summary (override if the spec requires overwrite or rejecting the whole file)
-- Import a file with invalid data in cells (wrong type, over max length) → row-level errors state the row number, column, and reason
-
-**[VP-SEC]**
-
-- Import an Excel file containing formula injection (`=HYPERLINK(...)`, `=CMD(...)` in a cell) → the cell value is sanitized to plain text, not executed
-- Export another user's/tenant's data via IDOR (changing a param in the URL/request) → blocked, 403 Forbidden
-
----
-
-### Tier 2 — @normal + @low
-
-**[VP-UI] Interface states**
-
-- [@normal] Import: accepted file types, size limit, and a "download template" link appear clearly before the user picks a file
-- [@normal] Import processing: progress/spinner shows, the Import button is disabled to prevent a double submit
-- [@normal] Import result summary: "X records imported, Y skipped, Z failed" is clearly shown, with a downloadable error report if the spec requires
-- [@normal] Export: the Export button switches to a loading state while generating the file
-- [@low] Template download: the template file has the correct column headers and at least 1 row of example data
-
-**[VP-VAL] Edge cases**
-
-- [@normal] Import an empty file (header row only, no data) → warning "No data to import", no crash, no record created
-- [@normal] Export when data is empty → the file still downloads, with the header row only and no data rows (override if the spec wants to block the download and show a "No data to export" toast)
-- [@normal] Export a large file (10k+ records) → the file generates within the allowed timeout, no 504 error
-- [@normal] Export encoding is correct: opening the CSV in Excel shows no broken Vietnamese font (UTF-8 BOM)
-
----
-
-### ⚡ Cross-pattern interactions
-
-- **+ Data Table**: After import → the table auto-refreshes to show new records; Export takes exactly the data currently shown in the table
-- **+ Filter**: Export with an active filter → the exported file count matches the number of records shown in the UI
-- **+ Pagination**: After import → the total count in the pagination updates correctly
-- **+ Notification**: Import/Export complete (especially async) → toast or notification shows the result summary