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

package/src/orchestrator/templates/ai-instructions/claude-skill-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/claude-skill-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.

package/src/orchestrator/templates/ai-instructions/copilot-cmd-add-flow.md

@@ -1,86 +0,0 @@
----
-name: sungen-add-flow
-description: 'Add a new Sungen flow — scaffolds directories for E2E cross-screen testing, helps fill spec.md, and can capture visuals via the capture skills'
-argument-hint: '[flow-name] [--path <start-url>]'
-agent: 'agent'
-tools: [vscode, execute, read, agent, edit, search, todo]
----
-
-**Input**: Flow name and optional starting URL (e.g., `/sungen-add-flow award-submission --path /login`).
-
-You are adding a new Sungen flow for E2E cross-screen test generation.
-
-## Parameters
-
-- **flow** — ${input:flow:flow name (e.g., award-submission, user-onboarding)}
-- **--path \<url\>** — starting page URL path (default: `/login`)
-- **--description \<text\>** — flow description (optional)
-
-## Steps
-
-### 1. Scaffold the flow
-
-Run with #tool:terminal:
-```bash
-sungen add-flow --flow ${input:flow} --path ${input:path}
-```
-
-This creates:
-```
-qa/flows/${input:flow}/
-├── features/${input:flow}.feature        # Gherkin with @flow tag, Background, sample scenarios
-├── selectors/${input:flow}.yaml          # Namespaced keys: "login:submit", "awards:submit"
-├── test-data/${input:flow}.yaml          # Namespaced data: login.email, submission.nominee
-└── requirements/
-    ├── spec.md                    # Flow specification
-    └── ui/                        # Screenshots, mockups
-```
-
-### 1a. Identify the screens in the flow
-
-Ask the user: "Which screens does this flow visit, in order? (e.g., login → dashboard → award-form → confirmation)"
-
-Record the screen list — you will need it for:
-- Filling `spec.md` (Step 3)
-- Suggesting `[Screen:Element]` namespace prefixes
-- Capturing visuals per screen (Step 2)
-
-### 2. Capture visual source
-
-Ask: *"Pick a visual source for this flow's screens:"*
-- **Figma designs** (Recommended for pre-launch) — invoke `sungen-capture` skill (mode figma-mcp) for each screen
-- **Live page scan** (dev/staging is up) — invoke `sungen-capture` skill (mode live) for each screen URL
-- **Local images** — invoke `sungen-capture` skill (mode local) to load from `requirements/ui/`
-- **Skip** — user will drop images manually into `requirements/ui/` later
-
-Each capture skill writes outputs into `qa/flows/${input:flow}/requirements/ui/` and reports back a summary. Do not inline capture logic here — always delegate to the skill.
-
-### 3. Fill spec.md
-
-Ask: *"Fill `spec.md` now? (You can reference the captured visuals)"* — offer **Yes, fill now (Recommended)** / **Skip, fill later**.
-
-If yes → open `qa/flows/${input:flow}/requirements/spec.md` and help the user fill:
-- **Screens list** — ordered list of screens with URL paths
-- **Flow steps** — what the user does at each screen
-- **Transitions** — what triggers navigation between screens
-- **Business rules** — cross-screen validation, state that persists
-- **Test data** — what data is entered at each screen
-
-Reference the captured visuals from Step 2 to suggest field names, form elements, and UI states.
-
-### 4. Next steps
-
-Tell the user what was created and offer next steps:
-
-- **`/sungen-create-test ${input:flow}`** — Generate test scenarios for the flow (Recommended)
-- **Done for now** — I'll come back later
-
-## Key Rules
-
-- Flows are **independent** from screens — own selectors, own test-data
-- Selectors use `[Screen:Element]` namespace format with colon
-- YAML keys must be **quoted** due to colon: `"login:submit":`
-- Test data namespaced by phase: `login.email`, `submission.nominee`
-- `@flow` tag required at feature level
-- `Background:` should only contain the starting page navigation
-- Each scenario = one phase of the journey

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

@@ -1,131 +0,0 @@
----
-name: sungen-add-screen
-description: 'Add a new Sungen screen or a sub-feature to an existing one — scaffolds directories, helps fill spec.md, and can auto-capture a live-page screenshot via Playwright MCP'
-argument-hint: '[screen-name] [url-path] [--feature <name>] [--figma <url>]'
-agent: 'agent'
-tools: [vscode, execute, read, agent, edit, search, web, browser, todo, 'playwright/*']
----
-
-**Input**: Screen name and URL path (e.g., `/sungen-add-screen login /login`).
-Optionally include a Figma URL: `/sungen-add-screen login /login --figma https://www.figma.com/design/...`.
-To add a sub-feature file to an existing screen: `/sungen-add-screen awards --feature modal`.
-
-You are adding a new Sungen screen for test generation, or extending an existing screen with an additional `.feature` file (sub-feature).
-
-## Parameters
-
-- **screen** — ${input:screen:screen name (e.g., login, dashboard)}
-- **path** — ${input:path:URL path (e.g., /login, /dashboard)} — optional when --figma is provided or when adding a sub-feature
-- **`--feature <name>`** — sub-feature name to add to an existing screen (e.g., `modal`, `filter`, `create-flow`). Creates `<screen>-<feature>.feature` + matching `selectors/<screen>-<feature>.yaml` + `test-data/<screen>-<feature>.yaml` without touching the screen's other files. Use this when one screen has multiple `.feature` files.
-- **`--figma <url>`** — Figma share URL (optional)
-- **`--refresh`** — bypass Figma cache and re-fetch (optional, use with --figma)
-- **`--scale <n>`** — PNG export scale factor, default 2 (optional)
-- **`--hi-res`** — export at 4× scale, shorthand for --scale 4 (optional)
-
-**Mode detection** — before invoking the CLI, check whether `qa/screens/<screen>/` already exists:
-- Screen does NOT exist → fresh screen creation (need `--path` unless `--figma` provided)
-- Screen exists AND `--feature <name>` provided → sub-feature mode (skip spec.md, only generate the 3 new files)
-- Screen exists AND no `--feature` → ask the user whether they meant to add a sub-feature (offer `--feature <suggested-name>`) or refresh visuals only (with `--figma`)
-
-## Steps
-
-### 1. Scaffold the screen (or sub-feature)
-
-**Standard path (no --figma, no --feature):**
-
-Run with #tool:terminal:
-```bash
-sungen add --screen ${input:screen} --path ${input:path}
-```
-
-**Sub-feature mode (`--feature <name>` provided):**
-
-Run with #tool:terminal:
-```bash
-sungen add --screen ${input:screen} --feature <name> [--path ${input:path}]
-# Generates qa/screens/${input:screen}/{features,selectors,test-data}/${input:screen}-<name>.{feature,yaml,yaml}
-# Existing screen files (spec.md, awards.feature, …) are untouched.
-# --path is optional — defaults to /${input:screen} when omitted.
-```
-
-**Figma branch (when --figma \<url\> is provided):**
-
-Run with #tool:terminal:
-```bash
-sungen add --screen ${input:screen} --figma <figma-url> [--path ${input:path}] [--feature <name>] [--refresh] [--scale <n>]
-# --feature can be combined with --figma when the new sub-feature has its own Figma frame.
-```
-
-This CLI command automatically:
-1. Parses the Figma URL and fetches the design node.
-2. Downloads frame + variant PNGs to `qa/screens/${input:screen}/requirements/ui/`.
-3. Writes `qa/screens/${input:screen}/requirements/spec_figma.md` (auto-generated, always overwritten on re-run).
-4. Creates `qa/screens/${input:screen}/requirements/spec.md` stub **only if the file does not already exist** — never overwrites existing human content.
-
-**Important coexistence rules:**
-- `--figma` and `--path` can be passed together.
-- `spec.md` is the human-authored source of truth — never modify it automatically.
-- `spec_figma.md` is auto-generated — tell the user to copy useful sections into `spec.md`.
-- `--capture` (Playwright screenshot) and `--figma` can be used simultaneously.
-
-**If Figma auth is missing**, guide the user to run `sungen figma auth set` and retry.
-
-### 1a. Synthesize narrative sections (Figma branch only)
-
-After `sungen add --figma` succeeds, the envelope of `spec_figma.md` is deterministic but the narrative below the `<!-- SYNTHESIS-BELOW -->` marker is empty. Invoke the `sungen-capture` skill (mode figma-pat):
-
-1. Read `qa/screens/${input:screen}/requirements/spec_figma.md` frontmatter for `file_key`, `node_id`, `figma_version_id`.
-2. Read the cached raw node JSON at `.sungen/figma-cache/<file_key>/<figma_version_id>/<safe_node_id>-raw.json` (colons in node_id become underscores).
-3. Follow the skill's 7-section template (Purpose / ASCII Layout / Regions / Actions / Form Fields / Data Columns / Navigation) and **replace** everything from the marker to EOF.
-4. Preserve the envelope above the marker byte-for-byte.
-
-**Review gate.** Before moving on, show the user the synthesized narrative and ask:
-
-- **1) Approve** — narrative looks right, continue to Step 2
-- **2) Edit** — user will tweak `spec_figma.md` now; wait for confirmation before continuing
-- **3) Cancel** — abort; advise the user that `spec.md` was NOT modified and they can re-run `sungen add --figma --refresh` later
-
-### 2. Capture visual source
-
-**If Figma branch (Step 1) already downloaded PNGs** → visuals already exist. Offer:
-- **1) Continue** — Figma visuals are enough (Recommended)
-- **2) Also capture live page** — supplement Figma with real page scan (invoke `sungen-capture` skill (mode live))
-
-**If standard path (no --figma)** → go straight to source selection:
-- **1) Figma design** (Recommended for pre-launch) — invoke `sungen-capture` skill (mode figma-mcp)
-- **2) Live page scan** (dev/staging is up) — invoke `sungen-capture` skill (mode live)
-- **3) Skip** — user will drop images manually into `requirements/ui/` later
-
-Each capture skill writes outputs into `qa/screens/${input:screen}/requirements/ui/` and reports back. Do not inline capture logic here — delegate to the skill so behavior stays consistent with `/sungen-create-test`.
-
-### 3. Fill spec.md
-
-**Skip this step when `--feature` was used** — the screen's existing `spec.md` is reused for all sub-features; only suggest the user append a new section for the sub-feature if useful (e.g. `## Modal — Confirm Withdrawal`).
-
-For fresh screen creation, ask: *"Fill `spec.md` now? (You can reference the captured visuals)"* — offer **1) Yes, fill now (Recommended)** / **2) Skip, fill later**.
-
-If yes → open `qa/screens/${input:screen}/requirements/spec.md` and help the user fill sections, fields, validation rules, business rules, and states. Reference the captured visuals from Step 2 to suggest field names, form elements, and UI states. Especially prompt for the optional **Figma URL** and **Live URL** fields in Overview — those unlock auto-capture without re-asking next run.
-
-### 4. Next steps
-
-Tell the user what was created. When `--feature` was used, list the 3 new files explicitly (`features/${input:screen}-<name>.feature`, `selectors/${input:screen}-<name>.yaml`, `test-data/${input:screen}-<name>.yaml`) and remind that `/sungen-create-test` currently operates at the screen level — it will see both the parent feature and the new sub-feature and ask which one to update.
-
-Then offer next steps:
-
-- **`/sungen-create-test ${input:screen}`** — Create test cases from requirements/designs (Recommended)
-- **Done for now** — I'll come back later
-
-## CLI Reference
-
-```
-sungen add --screen <name>
-  [-p, --path <path>]            URL route (e.g., /awards). Required for capture; defaults to /<screen> when omitted.
-  [-f, --feature <name>]         Add a sub-feature .feature file to an existing screen.
-                                 Output filename = <screen>-<feature>.{feature,yaml,yaml}.
-  [-c, --capture]                Auto-capture a live screenshot to requirements/ui/ (needs --path).
-  [-d, --description <text>]     Screen description (used in spec.md stub).
-  [--figma <url>]                Figma share URL — generates spec_figma.md + ui/*.png.
-  [--refresh]                    Bypass Figma cache (use with --figma).
-  [--scale <n>]                  PNG export scale (default 2).
-  [--hi-res]                     Shorthand for --scale 4.
-```

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

@@ -1,93 +0,0 @@
----
-name: sungen-create-test
-description: 'Create or update test cases for a Sungen screen — generates feature + test-data files (tier-based: critical+high first, expand later). Uses sungen-gherkin-syntax and sungen-tc-generation skills.'
-argument-hint: '[screen-name]'
-agent: 'agent'
-tools: [vscode, execute, read, agent, edit, search, web, browser, todo, 'playwright/*']
----
-
-**Input**: Screen or flow name (e.g., `/sungen-create-test admin-users`).
-
-## Role
-
-You are a **Senior QA Engineer**. You structure test cases by viewpoint categories and translate UI into Gherkin test cases following the `sungen-gherkin-syntax` and `sungen-tc-generation` skills. **Tier 1 (critical+high) first** — expand coverage later. **Gherkin scenarios and test data only** — selectors are handled during `/sungen-run-test`.
-
-**Quality is built in.** After generating, run a **harness loop**: `sungen audit` measures the output and you **repair the findings** until critical viewpoints are covered — the user does not ask for this. Use the `sungen-harness-audit` skill. (`/sungen-design` is an **alias** of this command.)
-
-## Parameters
-
-- **name** — ${input:name:screen or flow name (e.g., login, award-submission)}
-
-**Auto-detect context**: check if `qa/api/<name>/` or `qa/api/flows/<name>/` exists → **API unit mode** (below). Else if `qa/flows/<name>/` → flow mode (base path: `qa/flows/<name>/`). Else `qa/screens/<name>/` → screen mode (base path: `qa/screens/<name>/`).
-
-## API unit mode (driver-api)
-
-If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the design loop differs — **no visual capture, no selectors**; the contract is the named-endpoint catalog. **Follow the `sungen-api-design` skill end-to-end** instead of the screen/flow steps: `sungen context --area <name>` (discover) → API viewpoint overview → generate `@api`/`@cases`/flow/`@concurrent`/`@query` scenarios → **`sungen audit --area <name>` gate + reviewer + repair loop to businessDepth ≥ 0.7** → record + trace. Then recommend `/sungen-run-test <name>`. The capture / viewpoint-group / selector steps do **not** apply.
-
-## Steps
-
-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 update mode (options depend on which tiers already exist — see `sungen-tc-generation` skill for details).
-   - If no → fresh creation. **Write the feature file incrementally** (successive writes/edits, ≈10-15 scenarios per call) — never emit the whole suite in one response, or it can exceed the model's output-token cap (`response exceeded the N output token maximum`). Ask generation scope:
-     - **1) Tier 1 — Critical & High priority** — ~10-15 scenarios/section: happy paths, core validation, security basics **(Recommended)**
-     - **2) Full coverage (incremental)** — Tier 1 + 2 + 3, written tier-by-tier in batches. Safe on any output-token budget.
-     - **3) Full coverage (single pass)** — everything in one go (~40-60 scenarios/section). Faster, but **only if you raised your output cap** (`CLAUDE_CODE_MAX_OUTPUT_TOKENS ≥ 64000`) — otherwise it errors mid-generation. For power users on a high-token model/config.
-3. **Read project context + screen requirements**
-
-   **Project context** — check `qa/context.md` (project root, not screen-specific):
-   - If exists → read it. Extract: roles, testing strategy directives, global business rules, error patterns.
-   - Summarize what you found in one line (e.g. `"Roles: admin/staff/user | Strategy: focus security, skip VP-UI T1 | 2 global rules"`).
-   - These are carried into the Coverage Map when invoking the `sungen-tc-generation` skill.
-   - If absent → continue without it, no action needed.
-
-   **Screen requirements** — 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:
-     - **1) Fill test-viewpoint.md first** — identify edge cases, known issues, and design decisions before generating tests
-     - **2) Continue without it** — generate tests from spec and other sources only
-
-   **Auto-detect visual source** — do NOT ask the user to pick a source. Instead, check what already exists and use it:
-   1. If `spec_figma.md` exists → read it as Figma supplement (PAT flow already completed during `add-screen`). Do NOT call any `mcp__figma__*` tool.
-   2. If `ui/` has images (`.png`, `.jpg`, etc.) → read them for visual context (layout, element positions, states).
-   3. If neither exists → ask: *"No visual source found. Pick one:"* — then invoke the **`sungen-capture`** skill with the matching **mode** (read only that mode's file):
-      - **1) Figma PAT** — ask for URL, run `sungen add --screen ${input:name} --figma '<url>'`, then `sungen-capture` **mode figma-pat**
-      - **2) Figma MCP** — `sungen-capture` **mode figma-mcp**
-      - **3) Live page scan** — `sungen-capture` **mode live**
-      - **4) Skip** — generate from spec.md only
-
-   (When `spec_figma.md` exists, that is also `sungen-capture` **mode figma-pat**; when `ui/` images exist, that is **mode local**.)
-
-   **Cross-check**: if both `spec.md` and visual sources exist, flag any discrepancies (missing fields, different labels) before moving on. When `spec_figma.md` is present, follow the Figma supplement rules in `sungen-tc-generation` skill (reading order, Text Inventory, conflict handling).
-
-   Summarize what you found in requirements and present to the user.
-
-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. **For Tier 1**, apply the **Lightweight Guard** — verify required fields, validation rules, business rules, security checks, and key state transitions all have TCs after generation. **For Tier 2+**, **MUST** apply the full **Mapping Contract** — walk every `spec.md` section top-to-bottom and produce the indicated TCs per Table 1; handle `test-viewpoint.md` per Table 2. Do not silently skip sections. 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. Generate **group-by-group** (one viewpoint group at a time, tier-by-tier `Write`/`Edit` batches) to stay under the output-token cap. **For flows**: use `[Screen:Element]` namespace format, namespace test-data by phase, add `@flow` tag.
-   > **No parallel fan-out here.** Copilot has no sub-agents, so generation is sequential (the Claude Code variant fans out one `sungen-generator` per viewpoint group and merges). Same output, no speedup.
-5.4. **Depth self-check (deterministic — BEFORE the audit).** Run `sungen depth-lint --screen ${input:name}`. It splits every shallow business-critical scenario into **DEEPEN IN PLACE** (add a real value assertion — the printed `template` is a theme-keyed hint, apply judgment to the actual claim; never fake one onto a visibility/behavior scenario) and **CROSS-SCREEN** (route to a flow / tag `@manual:Mx` + reason — removes it from the depth denominator honestly). Act on both, re-run until `deepen` is empty (or only honest over-counts remain), THEN gate. Lifts first-pass `businessDepth` mechanically instead of via 2–3 repair rounds.
-5.5. **Quality gate & repair (harness — always run).** Per `sungen-harness-audit`: run `sungen audit --screen ${input:name}` (structural), THEN do an **independent semantic review inline** using the `sungen-reviewer` criteria (does each scenario's steps PROVE its title/viewpoint? observable Thens? business-critical assertion depth?). Merge both sets of issues; if gate FAILs / findings exist, repair (budget 3) and re-audit — GATE missing theme → generate it (cross-screen → **automate it in the flow** via `/sungen:add-flow`, NOT a full `@manual` screen duplicate — `sungen audit` flags an automatable `@manual` as `MANUAL-AUTOMATABLE`; reserve `@manual:Mx` for true judgment/missing-capability); DEPTH → add data assertions; BALANCE → add business-core first; TRACE → align VP ids. Never fake a pass.
-5.6. **Record.** `sungen manifest --screen ${input:name}`. Ledger **each phase** (not just repair) — pick one `runId` at the start and pass it so `trace`/`ledger report` show THIS run, not a mix: `sungen ledger record --screen ${input:name} --run <runId> --step <discovery|viewpoint|gherkin|audit|repair:N> --ms <elapsed>`. On re-run, start with `sungen manifest --screen ${input:name} --diff` and only regenerate changed sections.
-6. **Converge — show the trace.** Run `sungen trace --screen ${input:name}` and present: process map (phases + repair rounds), bottlenecks, **HUMAN-LOOP FOCUS** (@manual to verify), audit score + gate + residual gaps. Then offer next steps based on which tier was just generated:
-
-   > The harness gate + reviewer already ran above — `/sungen-review` is the independent checkpoint (hand/prompt-authored or pre-delivery), not a needed next step here.
-
-   **Optional — exploration mode (Loop 2).** The suite above is the deterministic official output. To push past "same output every time", offer the **challenge pass**: run `sungen challenge --screen ${input:name}` (deterministic structural critics), then apply the `sungen-challenge` criteria inline for semantic + novelty candidates. Advisory only — surfaces blind spots + ≤20% novelty candidates, never auto-merges. Record a confirmed recurring miss with `sungen blindspot add` so future runs don't repeat it.
-
-   **After Tier 1 generation:**
-   - **`/sungen-run-test ${input:name}`** — Generate selectors and run tests now (Recommended)
-   - **`/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-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-run-test ${input:name}`** — Generate selectors and run tests now (Recommended)
-   - **`/sungen-create-test ${input:name}`** — Add more sections if the screen changed
-   - **Done for now** — I'll come back later
-
-**No selectors.yaml** — selectors are generated during `/sungen-run-test`.