@sun-asterisk/sungen 3.2.28 → 3.2.29

package/dist/orchestrator/templates/ai-src/skills/sungen-tc-generation/SKILL.md

@@ -309,7 +309,7 @@ Security:         [S1 – admin only]
 **Depth is a GATE dimension (harness-roadmap P1) — self-raise, never silently go shallow:**
 - For every data-correctness theme the catalog marks `depth.requires: data-assertion`, emit its `depth.template` shape by **default** — don't wait for the repair loop. `sungen audit` measures `businessDepth` (ratio of these scenarios that assert data) against an intent threshold (functional ≥ 0.70); below it the **gate FAILs**.
 - **Verify depth deterministically before the gate:** run `sungen depth-lint --screen <name>`. It classifies every shallow business-critical scenario into **deepen-in-place** (add the theme's value assertion — the printed `template` is a hint, fit it to the actual claim) vs **cross-screen** (route to a flow / `@manual:Mx`). Clear the `deepen` list first — this is the mechanical way to hit `businessDepth` on the first pass instead of churning repair rounds. Never fake a value assertion onto a visibility/behavior scenario the lint over-counts; leave it and note the over-count.
-- `depth.cross_screen: true` (cart / detail / filter / brand correctness) → write the deep capture/compare shape as an **automated flow scenario** (in the flow — do NOT leave a full-step `@manual` duplicate on the screen). `@manual` is **only** for genuine judgment (M6 visual/UX · M8 not-worth · M9 human) or a missing capability (M1–M5/M7), and it **must** carry a reason code (`@manual:Mx`, or a reason comment the planner can infer). A `@manual` scenario that still has full automatable steps (a data assertion, no visual/mock/a11y judgment) is now flagged by `sungen audit` as `MANUAL-AUTOMATABLE`, and business-critical scenarios you defer to `@manual` are reported as `DEPTH-DEFERRED` (they do NOT silently inflate `businessDepth`). Deferring automatable work to `@manual` lowers quality — automate it in the flow instead.
+- `depth.cross_screen: true` (cart / detail / filter / brand correctness) → write the deep capture/compare shape as an **automated flow scenario** (in the flow — do NOT leave a full-step `@manual` duplicate on the screen). `@manual` is **only** for genuine judgment (M6 visual/UX · M8 not-worth · M9 human), a device/OS limit on mobile (M10 OS capability · M11 real-device only), or a missing capability (M1–M5/M7), and it **must** carry a reason code (`@manual:Mx`, or a reason comment the planner can infer). A `@manual` scenario that still has full automatable steps (a data assertion, no visual/mock/a11y judgment) is now flagged by `sungen audit` as `MANUAL-AUTOMATABLE`, and business-critical scenarios you defer to `@manual` are reported as `DEPTH-DEFERRED` (they do NOT silently inflate `businessDepth`). Deferring automatable work to `@manual` lowers quality — automate it in the flow instead.
 - **Pick the right `@manual:Mx` code — it decides which driver can later automate the case** (`sungen audit` flags a code↔reason mismatch). Tag the code that matches the **oracle the reason describes**:
 
   | The reason needs… | Code | Unblocked by |
@@ -321,9 +321,11 @@ Security:         [S1 – admin only]
   | an external dependency (email, payment gateway, download) | `M5` | mail-file / contract |
   | visual / UX / responsive / a11y judgment | `M6` | — (keep manual) |
   | not worth automating · true human judgment | `M8` / `M9` | — (keep manual) |
+  | **mobile** — what the OS/driver will not expose (notification shade, app switcher/recents, permission variance by OS version, call interruption) | `M10` | — (keep manual) |
+  | **mobile** — what an emulator/simulator cannot be (biometrics, real camera, NFC, a real push token) | `M11` | — (keep manual) |
 
   e.g. "submit a payload then check the subscribers **table**" is an API+DB oracle → `@manual:M2` (NOT `M1`); "seed a DB with zero products" is a data state → `M1`; "throttle the network" → `M3`.
-- **Prefer automation-ready `@requires:<cap>` over prose `@manual`.** When you *can* write the steps for a capability-manual case (an API/DB oracle, a seeded state), write it **automation-ready** — the real `@api`/`@query`/… steps tagged `@requires:<cap>` (e.g. `@requires:db @query:subscriber_row`) — instead of a prose `@manual:M2`. It compiles to a skipped-with-reason stub until `sungen capability add <cap>`, then runs as a real test with **no rewrite**. Reserve prose `@manual:Mx` for cases whose steps genuinely can't be expressed (M6/M8/M9 judgment, or a capability with no driver). `sungen audit` reports these as `AUTOMATION-READY-PENDING` (not a gap, not manual).
+- **Prefer automation-ready `@requires:<cap>` over prose `@manual`.** When you *can* write the steps for a capability-manual case (an API/DB oracle, a seeded state), write it **automation-ready** — the real `@api`/`@query`/… steps tagged `@requires:<cap>` (e.g. `@requires:db @query:subscriber_row`) — instead of a prose `@manual:M2`. It compiles to a skipped-with-reason stub until `sungen capability add <cap>`, then runs as a real test with **no rewrite**. Reserve prose `@manual:Mx` for cases whose steps genuinely can't be expressed (M6/M8/M9 judgment, M10/M11 device-or-OS limits on mobile, or a capability with no driver). `sungen audit` reports these as `AUTOMATION-READY-PENDING` (not a gap, not manual).
 - **If the spec lacks the concrete value** a deep assertion needs (exact message, price, count): still write the deep shape with a `{{var}}` placeholder and leave a `# SPEC-GAP: <field> value not in spec` comment — do **not** downgrade to `see [X] section`. A visible gap is better than a silent shallow pass.
 - **Blind-Spot Memory:** before finishing, run `sungen blindspot list --prompt` (Bash) and make sure the suite satisfies each recorded pattern (e.g. "for any Add/Create action: check success + resulting data state + duplicate/double-submit"). These are gaps QA hit before — don't repeat them.
 
@@ -478,6 +480,90 @@ And User wait for [Page Title] heading is visible
 
 ---
 
+## Mobile — the two axes web has no concept of
+
+Applies to a `@platform:mobile/android/ios` unit. Read `sungen-viewpoint` →
+`group-f-mobile-native.md` for *what to check* per native pattern (it carries the theme↔catalog
+map the audit scores against); this section is the two **cross-cutting** axes that multiply every
+other scenario on a device, and that a web-shaped coverage map has no row for.
+
+### Axis 1 — the app lifecycle state machine
+
+A browser tab is either open or closed. An app has five states, and a screen can be wrong in any of
+them. Generate lifecycle scenarios from the transitions, not from the states.
+
+```
+                         launch (cold)
+                               │
+                               ▼
+        ┌──────────────► FOREGROUND ──────────────┐
+        │                     │                   │
+        │       background N seconds        restart (kill)
+        │                     ▼                   ▼
+        │               BACKGROUNDED         RELAUNCHED  ── reinstall ──► FIRST-RUN
+        │                     │                                          (install state cleared)
+        └──── resume ─────────┤
+                              ▼
+                        PROCESS DEATH   (the OS reclaims a backgrounded app)
+```
+
+| Transition | Step | Availability |
+|---|---|---|
+| foreground → backgrounded → resumed | `User background the app for 5 seconds` | both OSes |
+| foreground → killed → relaunched | `User restart the app` | both OSes — **the** persistence oracle |
+| → first-run | `User reinstall the app` | both OSes; needs the session to have installed via `APP_APK` / `IOS_APP` |
+| a clean state *between* scenarios | `@reset:none\|soft\|data\|full` on the Feature | a tag, never a step — a step that tries reports **SG-W023** |
+| backgrounded → process death → resumed | *no step* | `@manual:M10` (OS capability) |
+
+**Every lifecycle scenario needs a DATA oracle.** "The screen is still there" passes on an empty
+shell and on a silently re-logged-in session. Assert the value that must have survived:
+
+```gherkin
+@high @platform:mobile
+Scenario: VP-LOGIC-001 The session survives a cold restart
+  Given User is on [Account] screen
+  When User restart the app
+  Then User see [Account Name] text contains {{user_name}}
+```
+
+Minimum for any mobile unit: **one resume scenario** (the screen owes its own data back) and, when
+the screen persists anything — a session, a setting, a dismissal, a show-once card — **one restart
+scenario per persisted thing**. Rotation belongs here too: `User rotate to landscape` must not lose
+entered values or fire the request twice.
+
+### Axis 2 — permission × network decision table
+
+These two multiply: a permission-gated feature behaves differently offline, and the honest expected
+result is often "which message wins". Build the table, then **test only the rows with distinct
+outcomes** — the usual decision-table discipline, not all 12 combinations.
+
+| # | Permission | Network | Expected | How |
+|---|---|---|---|---|
+| 1 | granted | online | the happy path, feature content asserted | `User grant camera permission` — both OSes (iOS Simulator needs `applesimutils`) |
+| 2 | granted | offline | the spec's cached/queued behaviour + a clear message; entered data never silently lost | `User turn wifi off` → `@platform:android` (XCUITest cannot toggle connectivity); iOS is `@manual:M10` |
+| 3 | granted | off → on | recovers and refreshes with no manual reload | `@platform:android` |
+| 4 | denied | online | an in-app explanation with a route to Settings — never a crash or a dead button | `@manual:M10` — no step denies a permission |
+| 5 | denied | offline | one message wins per spec; do NOT generate this row unless the spec says which | `@manual:M10` |
+| 6 | never-ask-again | online | no request loop; the Settings route is shown | `@manual:M10` |
+| 7 | revoked while running | online | the app re-checks instead of trusting a stale grant | `@manual:M10` |
+
+Row 1 is `@high` and automated. Rows 2–3 are `@high` and automated **on Android only** — tag them,
+do not write them platform-neutral and hope. Rows 4–7 carry `@manual:M10`, which is a reason code
+and a real oracle, not a shrug: write the steps a human follows and the value they must see.
+
+### Two mobile traps worth naming while generating
+
+- **A `page` assertion proves nothing on mobile.** A native app has no URL, so `Then User see [Login]
+  page` compiles to an empty comment (**SG-W022**) and the scenario passes without looking. The
+  `screen` spelling is different and is what you want: it treats the target as a plain element and
+  emits a real visibility assertion — so name a marker only that screen has (`Then User see [Login
+  Submit] button`, or `Then User see [Login] screen` against a screen-root selector), and pair it
+  with the previous screen's marker going `is hidden`.
+- **An `open [X] page` / `navigate to` step on mobile navigates nowhere** (**SG-W026**) — the app was
+  already launched by the capabilities. Change screens with a real tap or gesture.
+
+---
+
 ## Cleanup & Hooks
 
 Add cleanup tags per the `sungen-gherkin-syntax` Cleanup table. Key rules:

package/dist/orchestrator/templates/ai-src/skills/sungen-tc-review/SKILL.md

@@ -84,6 +84,7 @@ Hard-fail gate. Any ✗ is a syntax error — must be fixed; do not score furthe
 - [ ] A spec `Format:` line → `matches "<format>"`, NOT `with {{v}}` (an exact value pins data that changes daily; `contains` proves nothing)
 - [ ] 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
+- [ ] Table on a `<div>` list (no `<table>` / `role="row"` in the app): the table entry declares `rows:` — without it `is hidden`/`is empty` pass on 0 rows (`SG-W016`). A row label's own `type: locator` entry is ONE positioned row, never the shape
 
 ### A5. Alert / Scope / Background
 
@@ -107,6 +108,30 @@ Hard-fail gate. Any ✗ is a syntax error — must be fixed; do not score furthe
 - [ ] `@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":`)
 
+### A8. Mobile (`@platform:mobile/android/ios` units only)
+
+Hard-fail rules — each one is a scenario that PASSES while proving nothing, which is worse than a
+failing one. Skip this section entirely for a web unit.
+
+- [ ] **`Then User see [X] page` → FAIL.** A native app has no URL: the step compiles to an empty
+      comment (**SG-W022**) and the scenario goes green without looking at the app. Require a marker
+      element (`see [X] screen` against a screen-root selector, or a button/text unique to the
+      screen) plus the previous screen's marker going `is hidden`.
+- [ ] **`When User open [X] page` / `navigate to` → FAIL.** It navigates nowhere (**SG-W026**) — the
+      app was already launched by the wdio capabilities. Require a real tap or gesture.
+      `Given User is on [X] screen` is the legitimate app-launch anchor and is NOT a violation.
+- [ ] **A step that establishes app state → FAIL.** `Given the user is logged out` compiles to a
+      comment (**SG-W023**); auth lives in the keychain, not in cookies. Require `@reset:data|full`
+      on the Feature instead.
+- [ ] **Android-only vocabulary without `@platform:android` → FAIL.** `turn airplane mode|wifi|mobile
+      data …`, `open notifications` and `turn device location …` throw on iOS; `hide keyboard` is
+      worse — its iOS path is guarded out with **no** throw, so the scenario passes having done
+      nothing. Cross-check `docs/spec/step-support-matrix.md` (the `iOS` column) when unsure.
+- [ ] **A web-only step on a mobile unit → FAIL.** Tables, browser storage, tab order, `@mock`, the
+      uploader and `hover` have no native equivalent — see `sungen-gherkin-syntax` → Platform Support.
+- [ ] No `{{variable}}` used as a coordinate in `set location to …` — the numbers are resolved at
+      compile time and a variable silently becomes `0, 0`. Literal digits only.
+
 ---
 
 ## Layer B — Coverage Matrix (against Sun Common Checklist for QA)
@@ -128,6 +153,22 @@ Build a mapping table: for each applicable group, does the feature have a matchi
 | **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 |
 
+**Mobile units add four categories** (`@platform:mobile/android/ios` only). Each maps to a theme the
+`sungen audit` mobile catalog scores, so a gap here is a scored gap, not a stylistic note — the
+per-pattern checklists are in `sungen-viewpoint` → `group-f-mobile-native.md`:
+
+| Category | Sub-viewpoint to check | VP map | Sungen representation |
+|---|---|---|---|
+| **App lifecycle** | Resume after background restores the screen's data; a restart preserves what the spec says persists (session, setting, dismissal, show-once); rotation loses nothing and does not double-submit | VP-LOGIC | `background the app for N seconds` · `restart the app` · `rotate to landscape\|portrait`, each with a **value** assertion |
+| **Permission** | Granted path works; denied path explains and routes to Settings; never-ask-again does not loop; a revoked grant is re-checked | VP-LOGIC/SEC | `grant [X] permission` for the granted row; the other three are `@manual:M10` with a real oracle |
+| **Gesture reachability** | The target is reachable — off-screen needs `scroll to`, occluded-by-a-floating-bar needs `tap top of` (scroll is a no-op there); swipe-revealed actions are asserted, not assumed | VP-LOGIC | `swipe <dir> on [X]` · `scroll to [X]` · `tap top of [X]` · `pull to refresh [X]` |
+| **Connectivity** | Offline banner; cached content survives; an action while offline fails clearly without losing input; recovery refreshes without a manual reload | VP-LOGIC | `turn wifi off` → `@platform:android`; iOS `@manual:M10` |
+
+**Deduct when a mobile suite has no lifecycle, permission, or gesture oracle at all** — those are the
+three concerns a web-shaped test set always misses, and their absence is the single strongest signal
+that the suite was written for a browser and re-tagged. A screen that genuinely owes none of them
+(a static read-only screen with no permissions) is not penalised — say so in the notes.
+
 **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
@@ -180,6 +221,18 @@ Build a mapping table: for each applicable group, does the feature have a matchi
 - **error (4xx)** — the status IS the assertion; also check the error-message field when the contract defines one.
 - **anti-pattern (counts against "Avoids anti-patterns")** — re-asserting the input just sent instead of a server-derived value.
 
+**Mobile scenarios — depth rubric:** the mobile catalog marks most themes as needing a **data**
+oracle, so a sighting where a value is owed fails the "Specific" check:
+- **a lifecycle/persistence claim asserted by a sighting = fail.** "The screen is still there" after
+  `restart the app` passes on an empty shell and on a silent re-login. Require the value that had to
+  survive (`text contains {{v}}`, `field with {{v}}`).
+- **a list claim asserted by a count or a sighting = fail.** `see all [List Item] text contains {{v}}`
+  is the oracle; a row count passes on the wrong rows.
+- **a navigation claim asserted by one marker = weak.** Require the destination's marker AND the
+  origin's marker going `is hidden` — one marker passes when the app never moved.
+- **`keyboard-overlap` is the exception**: its honest oracle IS a sighting (the covered element is
+  visible again). Do not deduct for the absence of a value assertion there.
+
 ### Test Data (10)
 
 | Check | Pts |
@@ -271,6 +324,10 @@ Do NOT deduct points when a `.feature` lacks the following viewpoints (Playwrigh
 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).
+18. **Mobile: `see [X] page` oracle** → replace with a marker element on the destination screen + the origin's marker `is hidden` (SG-W022 — the original passes having proven nothing).
+19. **Mobile: `open [X] page` / `navigate to`** → replace with the real tap/gesture that changes screens (SG-W026).
+20. **Mobile: Android-only step without a platform tag** → add `@platform:android`, and add the iOS counterpart as `@manual:M10` if the spec owes iOS coverage.
+21. **Mobile: no lifecycle scenario** → add 1 resume scenario (`background the app for N seconds` + a value assertion) and 1 restart scenario per persisted thing.
 
 ---
 
@@ -338,5 +395,5 @@ If `selectors/<name>.yaml` exists, count lines matching `@needs-live-verify` (pr
 
 - **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`.
+- **References**: detailed syntax → `sungen-gherkin-syntax`; selector keys → `sungen-selector-keys`; VP classification → `sungen-viewpoint` (mobile-native patterns → its `group-f-mobile-native.md`); mobile step vocabulary → `sungen-mobile-gestures`; per-OS support → `docs/spec/step-support-matrix.md`; generation workflow → `sungen-tc-generation`.
 - **Owner / version**: Owner: `<QA Lead>` · Version: `2.0` · Last updated: `2026-06-03`.

package/dist/orchestrator/templates/ai-src/skills/sungen-test-design-techniques/SKILL.md

@@ -116,3 +116,16 @@ Scenario: VP-VAL-003 Above maximum is rejected           # value = 101
 - `@normal` Invalid: Completed → Draft (blocked), Pending → Completed (skip approval)
 
 **test-data:** Use named state keys (`order_in_draft`, `order_in_pending`).
+
+**On mobile, three state machines exist that no spec draws** — apply this technique to them even
+when `spec.md` has no diagram, because the states are imposed by the platform rather than the
+product:
+
+| Machine | States | Transition steps that compile |
+|---|---|---|
+| App lifecycle | foreground · backgrounded · relaunched · first-run · process-death | `background the app for N seconds` · `restart the app` · `reinstall the app`; process-death is `@manual:M10` |
+| Screen entry / exit | entered by tap · entered by deep link · left by OS back · left by in-app control | `open deep link {{url}}` · `go back` (OS/hardware) · a tap on the in-app control — **the last two are different transitions**, since system back skips the screen's own handler unless the app wires it |
+| Connectivity | online · offline · recovering | `turn wifi off` / back on → `@platform:android` (XCUITest cannot toggle connectivity) |
+
+Full matrices and the permission axis → `sungen-tc-generation` → "Mobile — the two axes web has no
+concept of". Per-pattern checklists → `sungen-viewpoint` → `group-f-mobile-native.md`.

package/dist/orchestrator/templates/ai-src/skills/sungen-viewpoint/SKILL.md

@@ -1,13 +1,13 @@
 ---
 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.'
+description: '32 UI patterns (17 web + 15 mobile-native) 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.
+This skill is a **router**. The detailed checklists live in 6 group files — load only the ones relevant to the screen under test. Groups A–E are the 17 platform-agnostic patterns; Group F is the mobile-native layer, read IN ADDITION on a `@platform:mobile/android/ios` unit.
 
 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.
@@ -36,6 +36,22 @@ This skill is a **router**. The detailed checklists live in 5 group files — lo
 | 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` |
+| **Native app screen (`@platform:mobile/android/ios`) — read Group F IN ADDITION to the patterns above** | | |
+| Sheet sliding up from the bottom edge | 18. Bottom Sheet | `group-f-mobile-native.md` |
+| Persistent bar of 3–5 destinations at the bottom | 19. Tab Bar / Bottom Navigation | `group-f-mobile-native.md` |
+| Horizontal swipe on a row reveals actions | 20. Swipe-to-Delete Row | `group-f-mobile-native.md` |
+| Field opening an OS wheel / date / dropdown picker | 21. Native Picker | `group-f-mobile-native.md` |
+| Runtime permission — camera, location, notifications | 22. Permission Dialog | `group-f-mobile-native.md` |
+| Fingerprint / Face ID / app lock | 23. Biometric Prompt | `group-f-mobile-native.md` |
+| Leaves the app for the system camera or photo library | 24. Camera / Gallery Picker | `group-f-mobile-native.md` |
+| Push messages / notification routing | 25. Push Notification | `group-f-mobile-native.md` |
+| External link, notification payload, or QR opens a screen | 26. Deep-link Entry | `group-f-mobile-native.md` |
+| Offline banner, cached content, retry control | 27. Offline Banner | `group-f-mobile-native.md` |
+| First-launch intro slides / tutorial | 28. Onboarding Carousel | `group-f-mobile-native.md` |
+| Feed reloading by drag-down, paging, Load More | 29. Pull-to-Refresh List | `group-f-mobile-native.md` |
+| Any text field — the soft keyboard covers the screen | 30. Soft-Keyboard Overlap | `group-f-mobile-native.md` |
+| List of switches / preferences | 31. Settings Toggle List | `group-f-mobile-native.md` |
+| Every mobile screen (background, rotate, relaunch) | 32. App Lifecycle & Orientation | `group-f-mobile-native.md` |
 
 ## Pattern selection (precedence & inheritance)
 
@@ -54,6 +70,8 @@ A screen often matches several patterns at once — a login screen is *both* a f
    | 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 |
 
+5. **On mobile, Group F is ADDITIVE — never a replacement.** A native screen is still whatever it functionally is: a native login screen is **15**, a native product list is **10**, and the harness routes such a screen to `auth` / `ecommerce-list` deliberately, not to a `mobile-*` page-type. Route by function first (1–17), then add the Group F patterns for the native surfaces present, and generate each check **once** — a native form is **1. Form & Inputs** *and* **30. Soft-Keyboard Overlap**, with the field rules living only in pattern 1. `group-f-mobile-native.md` carries the theme↔catalog map and the precedence detail.
+
 ## 4 Viewpoints
 
 | VP | Focus | Tag |
@@ -90,16 +108,32 @@ The 4 viewpoints above are the *generic* axes. On a domain screen, the `VP-<CAT>
 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 |
+The `Platform` column decides which checks a screen owes. Applying the web three to a native
+screen is wasted work — a `<script>` payload cannot execute in a native text view and there is no
+URL to manipulate — while the native surfaces (deep-link params, clipboard, the recents thumbnail)
+go unchecked unless they are named here.
+
+| Check | Condition → Expected | VP | Priority | Platform |
+|---|---|---|---|---|
+| **Loading State** | Data fetch in progress → spinner/skeleton shown, user cannot interact | UI | @normal | both |
+| **Empty State** | Query returns 0 records → clear message shown, layout does not break | UI | @normal | both |
+| **XSS** | Script tag entered into a field → rendered as literal text, not executed | SEC | @high | web |
+| **SQL injection** | SQL payload entered into a field → DB unaffected, no data exposed | SEC | @high | web |
+| **URL Manipulation** | URL params wrong/missing/out-of-range → fallback to default, no 500 crash | SEC | @high | web |
+| **Deep-link param injection** | An external link carries a traversal / script / oversized param → treated as data, no crash, no privileged screen reached | SEC | @high | mobile |
+| **Clipboard leak** | A field holding sensitive data (password, token, card) → the value cannot be copied out, or is excluded from the clipboard | SEC | @high | mobile |
+| **Recents / screenshot leak** | Background the app on a screen showing sensitive data → the app-switcher thumbnail is masked, screenshots blocked where the spec requires it | SEC | @high | mobile |
+| **Root / jailbreak posture** | The app runs on a rooted/jailbroken device → the spec's response (warn, degrade, or block), never a silent full-trust run | SEC | @normal | mobile |
+| **Certificate pinning** | Traffic through an intercepting proxy with a substituted certificate → the app refuses the connection rather than transmitting | SEC | @high | mobile |
+| **Permission over-request** | Cold launch → only the permissions the current feature needs are requested, and each is asked in context | SEC | @normal | mobile |
 
 > **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.
 
+> **Two mobile edges the table simplifies.** A screen rendered inside a **WebView** is web for these
+> purposes — apply XSS there. And a native app hits the same API as the web client, so the API-level
+> SQL-injection layer above is still owed by the *system*; it is just not a screen-unit check on a
+> mobile unit. Record it once at the API layer (`qa/api/`), not per mobile screen.
+
 ---
 
 ## Security Tag Rules
@@ -108,6 +142,8 @@ For VP-SEC scenarios testing **unauthorized access** (no login, wrong role, dire
 - Use the **`@no-auth`** tag — runs without authentication to verify the redirect/block.
 - Do NOT use `@manual` for these — they are automatable.
 
+On **web** the redirect target is a URL, so asserting the page is a real check:
+
 ```gherkin
 @high @no-auth
 Scenario: VP-SEC-001 Unauthenticated user cannot access admin page
@@ -115,4 +151,17 @@ Scenario: VP-SEC-001 Unauthenticated user cannot access admin page
   Then User see [Login] page
 ```
 
+On **mobile** that same shape is a false pass. A native app has no URL: the assertion compiles to an
+empty comment and reports **SG-W022**, so the scenario goes green having proven nothing. Assert a
+marker element that only exists on the login screen, plus the protected screen's own marker going
+`is hidden`:
+
+```gherkin
+@high @no-auth @platform:mobile
+Scenario: VP-SEC-001 An unauthenticated launch stops at the login screen
+  Given User is on [Login] screen
+  Then User see [Login Submit] button
+  And User see [Account Name] is hidden
+```
+
 Use `@manual` only when the environment truly cannot be set up automatically.