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

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

@@ -1,177 +0,0 @@
-# GROUP E: IDENTITY & AUTHENTICATION
-
-> The user creates an account, authenticates their identity, and manages credentials.
-
-Patterns: 15. Login / Logout · 16. Register · 17. Password Management
-See `SKILL.md` for the 4 Viewpoints, Shared Checks, and Security Tag Rules.
-
----
-
-## 15. Login / Logout
-
-**Apply when**: the screen has a login form and/or a logout button.
-
-**Inherits**: Form & Inputs — field-level validation (required, format, maxlength, whitespace, real-time error clear). Generate those once here; this pattern adds the auth-specific rules below.
-
-**Shared checks applied**: XSS/Injection
-
----
-
-### Tier 1 — @high
-
-**[VP-LOGIC] Auth behavior**
-
-- Enter the correct email + password → login succeeds, redirect to the dashboard/home, a session is created with a valid token
-- Click Logout → the session is destroyed server-side, redirect to the Login page, the old token no longer works
-- After logout, use the browser Back button to a protected page → redirect to Login (no cached content shown)
-- "Remember me" checked → the session persists after closing/reopening the browser (cookie expiry longer than the default session)
-
-**[VP-VAL]**
-
-- Correct email, wrong password → a generic error message "Email or password is incorrect" (does not state which field is wrong, to avoid enumeration)
-- An email not in the system → the same generic error as a wrong password (does not reveal "email not registered")
-- Wrong password N times in a row (N per config) → the account is temporarily locked, the error states the wait time
-
-**[VP-SEC]**
-
-- Access a protected page while not logged in → redirect to Login, the intended URL is preserved in a query param so post-login redirects correctly
-- Login succeeds → a new session token is issued (session fixation prevention), the old pre-login token no longer works
-- Password field: the value is not visible in the page source, not logged in the browser console or the network payload
-
----
-
-### Tier 2 — @normal + @low
-
-**[VP-UI] Interface states**
-
-- [@normal] Password field: the show/hide toggle works, the eye/eye-off icon changes to the correct state
-- [@normal] Submit button: disabled or showing a loading spinner while the API is being called (prevents double submit)
-- [@normal] Login failure: the form keeps the entered email, only the password field is cleared
-- [@low] Caps Lock warning: when Caps Lock is on → a warning text shows near the password field
-
-**[VP-VAL] Edge cases**
-
-- [@normal] Email with uppercase characters → login succeeds even when entering "User@Email.com" instead of "user@email.com" (case-insensitive)
-- [@low] Session timeout while in use → redirect to Login with a toast "Your session has expired"
-
----
-
-### ⚡ Cross-pattern interactions
-
-- **+ Navigation**: After a successful login → the active menu item reflects the first page the user is redirected to
-- **+ Notification**: The API returns 401 while in use → a toast "Your session has expired" shows before redirecting to Login
-
----
-
-## 16. Register
-
-**Apply when**: the screen has a form to create a new account (email/password) or sign up via SSO (Google, Microsoft, Facebook…).
-
-**Inherits**: Form & Inputs — field-level validation (required, format, maxlength, whitespace, real-time error clear). Generate those once here; this pattern adds the registration-specific rules below.
-
-**Shared checks applied**: XSS/Injection
-
----
-
-### Tier 1 — @high
-
-**[VP-LOGIC] Registration flow**
-
-- Fill in all valid information, submit → the account is created, the user receives a verification email, redirect to a confirmation page
-- Sign up via SSO: click a provider button → redirect to the provider to authorize → redirect back to the app, the account is created/linked automatically, the user enters the app immediately without email verification
-- Verification email link → click → the account is activated, the user can log in immediately
-- An unverified account tries to access a protected page → blocked, a message asks for verification with a "Resend email" button
-
-**[VP-VAL]**
-
-- An email already in the system → submit is blocked, inline error "This email is already registered"
-- A password that is not strong enough (below min length, missing a character type per the rule) → error at the field, no submit
-- Confirm password differs from password → inline error "Passwords do not match", no submit
-- Wrong email format → inline error at the email field, no submit
-
-**[VP-SEC]**
-
-- Submit without a CSRF token → the server rejects the request, no account is created
-- The POST body contains an extra field `role=admin` → the server ignores that field, the account is created with the default role (user)
-
----
-
-### Tier 2 — @normal + @low
-
-**[VP-UI] Interface states**
-
-- [@normal] Password strength indicator: updates in real time as the user types, the color changes correctly by level (weak/medium/strong)
-- [@normal] Terms & Conditions checkbox: Submit disabled while unchecked, enabled after checking
-- [@normal] SSO buttons: the provider logos are correct, the button switches to loading/disabled while redirecting
-- [@low] Resend verification email: the button only activates after the cooldown ends, disabled + a countdown timer shows during the wait
-
-**[VP-VAL] Edge cases**
-
-- [@normal] Register with a sub-address email (user+tag@gmail.com) → treated as a unique email, creation succeeds
-- [@low] Browser autofill fills the fields → the form receives the correct values, no conflict with a custom input component
-
----
-
-### ⚡ Cross-pattern interactions
-
-- **+ Login**: After register + email verification succeeds → the user can log in immediately with the just-created credentials
-- **+ Notification**: Register success → a toast "Check your email to complete registration"; resend email → a cooldown toast with a countdown
-
----
-
-## 17. Password Management
-
-**Apply when**: the screen has a Forgot Password function, a Reset Password via email function, or a Change Password while logged in function.
-
-**Inherits**: Form & Inputs — field-level validation (required, format, maxlength, whitespace, real-time error clear). Generate those once here; this pattern adds the password-specific rules below.
-
-**Shared checks applied**: (no default shared check)
-
----
-
-### Tier 1 — @high
-
-**[VP-LOGIC] Password flow**
-
-- *Forgot Password:* Enter a registered email → a reset-link email is sent to the inbox, an "email sent" message shows in the UI
-- *Reset Password:* Click the link in the email → a set-new-password form opens; submit a valid password → the password is changed, the user can log in immediately with the new password
-- *Single-use reset link:* Reuse an already-used link → 400/410, a message "Link already used", no second reset
-- *Expired reset link:* Use a link past its expiry → 400/410, a message "Link expired" with a link back to the Forgot Password page
-- *Change Password:* Enter the correct current password + a valid new password → the password is changed, all other sessions are invalidated immediately
-
-**[VP-VAL]**
-
-- *Forgot Password:* Enter an email not in the system → the same "email sent" message (does not reveal "email not registered")
-- *Reset Password:* A new password that is not strong enough → error at the field, no submit
-- *Reset Password:* Confirm password differs → inline error "Passwords do not match"
-- *Change Password:* Enter the wrong current password → error "Current password is incorrect", the new password is not saved
-- *Change Password:* The new password equals the current password → error "New password must differ from the old one"
-
-**[VP-SEC]**
-
-- A tampered/forged reset token in the URL → the server rejects it, 400 error, the password is unchanged
-- The token is invalidated immediately after use: after a successful reset, reusing the same link → rejected
-- The Change Password endpoint without authentication → 401 Forbidden, the password is unchanged
-
----
-
-### Tier 2 — @normal + @low
-
-**[VP-UI] Interface states**
-
-- [@normal] Forgot Password form: only 1 email field + a Submit button + a back-to-Login link, no extra fields
-- [@normal] Reset Password form: both password fields are type=password with a show/hide toggle, a strength indicator updates in real time
-- [@normal] Change Password form: 3 separate fields (current, new, confirm), fully separated from the profile form
-- [@low] Rate limiting: send many reset requests in a row in a short time → the Submit button is on cooldown or a Captcha appears
-
-**[VP-VAL] Edge cases**
-
-- [@normal] Forgot Password sent multiple times for the same email → only the latest link is valid, all older links are invalidated
-- [@low] Click a reset link from browser history after it was used → rejected immediately with a "Link already used" message
-
----
-
-### ⚡ Cross-pattern interactions
-
-- **+ Login**: Reset succeeds → redirect to Login with a toast "Password changed successfully, please log in again"
-- **+ Notification**: Change Password succeeds → a success toast in the UI + an email notification "Your account password was just changed" sent to the inbox

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

@@ -1,118 +0,0 @@
----
-name: sungen-viewpoint
-description: '17 UI patterns x 4 viewpoints — structured checklist for test case
-  generation and review. Auto-loaded by create-test and review commands.'
-user-invocable: false
----
-
-## How to use this skill
-
-This skill is a **router**. The detailed checklists live in 5 group files — load only the ones relevant to the screen under test.
-
-1. Read the **4 Viewpoints** and **Shared Checks** below (always).
-2. Identify which UI patterns the screen contains, resolve any overlap via **Pattern selection** below, then read **only** the matching group file(s) from the routing table.
-3. Generate Tier 1 (`@high`) scenarios first, then Tier 2 (`@normal` + `@low`). Apply each Shared Check **once per screen**, not once per pattern.
-
-> All checklist items are written in English. Render scenario names, step text, and test IDs in English.
-
-## Routing table
-
-| UI element on the screen | Pattern | Read file |
-|---|---|---|
-| Plain input form (settings, profile, contact) | 1. Form & Inputs **(base)** | `group-a-data-entry.md` |
-| File picker / drop zone | 2. File Upload | `group-a-data-entry.md` |
-| Bulk import / export | 3. Import / Export | `group-a-data-entry.md` |
-| "Add" / "Create" / "New" | 4. Create / Add | `group-b-data-ops.md` |
-| "Edit" / pencil icon / inline edit | 5. Update / Edit | `group-b-data-ops.md` |
-| "Delete" / trash icon | 6. Delete | `group-b-data-ops.md` |
-| Rows + columns grid | 7. Data Table | `group-c-data-explore.md` |
-| Search box / search bar | 8. Search | `group-c-data-explore.md` |
-| Filter controls (dropdown, date range, checkboxes) | 9. Filter | `group-c-data-explore.md` |
-| Card / list grid, infinite scroll, "Load More" | 10. List / Card View | `group-c-data-explore.md` |
-| Charts / KPI cards / dashboard | 11. Chart / Analytics | `group-d-display.md` |
-| Overlay panel on top of the page | 12. Modal / Dialog | `group-d-display.md` |
-| Side menu / tabs / breadcrumb / top nav | 13. Navigation | `group-d-display.md` |
-| Toast / snackbar / alert / banner | 14. Notification / Toast / Alert | `group-d-display.md` |
-| Login form / logout button | 15. Login / Logout | `group-e-identity.md` |
-| Sign-up form / SSO | 16. Register | `group-e-identity.md` |
-| Forgot / reset / change password | 17. Password Management | `group-e-identity.md` |
-
-## Pattern selection (precedence & inheritance)
-
-A screen often matches several patterns at once — a login screen is *both* a form and an authentication flow. Use these rules so the choice is deterministic and scenarios are never duplicated:
-
-1. **Most specific wins.** Pick the most specialized pattern as the screen's primary section. Auth and CRUD forms route to their specific pattern, NOT to Form & Inputs:
-   - Login/logout → **15**, sign-up → **16**, forgot/reset/change password → **17**
-   - Create form → **4**, edit form → **5**
-2. **Form & Inputs (1) is a BASE pattern, not a sibling.** Generate it as its own section only for a plain form with no more-specific role (settings, profile, contact). When a specialization applies, do NOT also create a separate "Form & Inputs" section.
-3. **Inheritance.** A specialized form pattern (4, 5, 15, 16, 17) **inherits** Form & Inputs field-level validation (required, format, maxlength, whitespace, real-time error clear) and adds its own rules. Apply the inherited checks inside the specialized section — generate each check once, never twice.
-4. **Genuinely parallel pairs** — these cover different concerns; choose per the table:
-
-   | If the screen has… | Decision |
-   |---|---|
-   | A grid of records | Pick **7. Data Table** *or* **10. List/Card** by layout (rows+columns → Table; cards/tiles/infinite-scroll → List/Card) — not both for the same surface |
-   | Both a keyword box and filter controls | Apply **8. Search** *and* **9. Filter** (Search = free-text match; Filter = structured narrowing) + one combined AND-logic scenario |
-   | A form rendered inside an overlay | Apply the form's pattern (1/4/5/15…) for fields/submit **and** **12. Modal/Dialog** for open/close/focus-trap/backdrop |
-
-## 4 Viewpoints
-
-| VP | Focus | Tag |
-|---|---|---|
-| **UI/UX** | Interface state, layout, visual feedback | VP-UI |
-| **Data & Validate** | Input constraints, data integrity, error messages | VP-VAL |
-| **Logic** | Business rules, interactions, state changes | VP-LOGIC |
-| **Security** | Authentication, authorization, injection | VP-SEC |
-
-**Classification rules:**
-- VP-UI = state that is always true regardless of what the user does (element present, layout, label)
-- VP-VAL = outcome depends on the input *value* (valid / invalid / boundary)
-- 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
-
-Generate **once per screen**, do not repeat for each pattern.
-Each pattern only points back with "Shared checks applied: [name]".
-
-| Check | Condition → Expected | VP | Priority |
-|---|---|---|---|
-| **Loading State** | Data fetch in progress → spinner/skeleton shown, user cannot interact | UI | @normal |
-| **Empty State** | Query returns 0 records → clear message shown, layout does not break | UI | @normal |
-| **XSS** | Script tag entered into a field → rendered as literal text, not executed | SEC | @high |
-| **SQL injection** | SQL payload entered into a field → DB unaffected, no data exposed | SEC | @high |
-| **URL Manipulation** | URL params wrong/missing/out-of-range → fallback to default, no 500 crash | SEC | @high |
-
-> **SQL injection — 2 layers for search/LIKE fields**: (1) field-level: UI blocks special chars → `@high` automated; (2) API-level: if the field reaches a LIKE query (search, partial-match), send `1 OR 1=1` straight to the API endpoint (bypassing the UI) → verify a parameterized query is used → `@high @manual`. Missing layer 2 = a real attack vector is overlooked even when field validation is correct.
-
----
-
-## Security Tag Rules
-
-For VP-SEC scenarios testing **unauthorized access** (no login, wrong role, direct URL):
-- Use the **`@no-auth`** tag — runs without authentication to verify the redirect/block.
-- Do NOT use `@manual` for these — they are automatable.
-
-```gherkin
-@high @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.