@sun-asterisk/sungen 3.0.0-beta.79 → 3.0.0-beta.80

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

@@ -105,6 +105,9 @@ Auto-detected by `create-test` before invoking this skill:
   2. Each row / bullet / item = 1 viewpoint → add to `Viewpoint items` in Coverage Map.
   3. Do NOT pre-classify into buckets before scanning — classify only when
      writing the scenario.
+  4. **If it declares viewpoint IDs** (e.g. `VP0`, `VP1`…`VP12`, `MS-HP-001`), capture each
+     item WITH its ID and **reuse that ID as the scenario code** — do not invent a generic
+     `VP-<CAT>` scheme (the harness Taxonomy-match gate FAILs on mismatch).
 - `qa/context.md` — project-wide context set by the QA lead. Read ONCE before building the Coverage Map; apply to every screen. Extraction rules:
   - **Roles** → for each role in the table: add to the `@auth:X` tag pool; generate a VP-SEC blocked-access scenario for every role boundary relevant to this screen.
   - **Testing strategy → Focus areas** → if `security` listed: VP-SEC is mandatory Tier 1 for every free-text input regardless of spec risk level; if `ui` not listed: all VP-UI scenarios move to Tier 2 minimum.
@@ -260,6 +263,26 @@ Security:         [S1 – admin only]
 
 **Balance:** cover all the above (deep) BEFORE expanding subscription / UI-presence / extra validation edge cases. Do not over-invest in subscription while cart/detail/filter correctness are shallow.
 
+#### Harness gates — satisfy on the FIRST pass (don't make the repair loop fix them)
+
+`sungen audit` enforces these. Generate compliant output up front:
+
+1. **Taxonomy-match** (`VP-TAXONOMY-MISMATCH`, gate-FAIL) — when `test-viewpoint.md` declares its own viewpoint IDs (e.g. `VP0`, `VP1`, … `VP12`, `MS-HP-001`, `MS-EH-001`), **reuse those IDs verbatim as the scenario codes**. Do NOT invent a generic `VP-UI / VP-LOGIC / VP-VAL` scheme — that breaks the coverage matrix. Only fall back to `VP-<CATEGORY>-<NNN>` when the viewpoint file declares no IDs.
+2. **Spec-coverage triggers** (`TRIGGER-UNCOVERED`, gate-FAIL) — the Validation-Rules table lists a **trigger** per constraint (e.g. `blur, submit`). Generate one scenario **per (constraint × trigger)** — a `format` rule validating *on blur AND on submit* needs BOTH a blur scenario (`press Tab`) and a submit scenario (`click [Submit]` / `press Enter`). Never collapse the trigger × input matrix to one representative case.
+3. **Claim-Proof** (`CLAIM-UNPROVEN`) — a title claiming `all`/`only`/`every`/`single`/`correct`/`same`/`changes`/`hidden`/`cleared`/`restored`/`independent`/`sanitized`/`announces` MUST have the matching assertion (`see all …`, count, `remember`+compare, `is hidden`, return-and-assert-empty, etc.). If the title promises it, the steps must prove it.
+4. **Downstream-scope** (`DOWNSTREAM-SCOPE-MISSING`) — when the spec's Navigation Flow / success target is **another screen** (e.g. a confirmation/sent page), don't stop at a terminal `see [X] page`. Either cover that screen's content/guards (if its viewpoint items are in scope — they often have their own `MS-*` IDs), or scaffold it (`sungen add --screen <name>`) and note the handoff. Do not silently drop the downstream surface.
+5. **Manual-oracle** (`MANUAL-STEPS-INSUFFICIENT`) — every `@manual` scenario needs **setup · action · observable expected · oracle/tool**, not a one-line note. Use this comment shape:
+   ```gherkin
+   @high @manual
+   Scenario: VP-… <claim>
+     # MANUAL: <why it can't be automated — needs network capture / inbox / screen-reader / multi-tab>
+     # Tester verifies:
+     #   1. <setup>            e.g. seed a registered email; throttle the network
+     #   2. <action>           e.g. click [Submit] with the request in flight
+     #   3. <observable>       e.g. only ONE POST is dispatched
+     #   4. Oracle: <tool>     e.g. DevTools Network panel / mail-catcher / NVDA
+   ```
+
 #### Tier 1 guard — minimum before writing scenarios
 
 | Spec section | Minimum requirement | Tag |
@@ -376,7 +399,7 @@ Add cleanup tags per the `sungen-gherkin-syntax` Cleanup table. Key rules:
 **Files:** `qa/screens/<screen>/features/<screen>.feature` + `qa/screens/<screen>/test-data/<screen>.yaml`
 
 Use step patterns and element types from `sungen-gherkin-syntax`.
-**Naming**: `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
+**Naming**: reuse the **project's `test-viewpoint.md` IDs** when it declares them (e.g. `VP0`, `MS-HP-001`); otherwise `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
 
 **Test data** — grouped by section, loaded at runtime:
 

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

@@ -105,6 +105,17 @@ Auto-detected by `create-test` before invoking this skill:
   2. Each row / bullet / item = 1 viewpoint → add to `Viewpoint items` in Coverage Map.
   3. Do NOT pre-classify into buckets before scanning — classify only when
      writing the scenario.
+  4. **If it declares viewpoint IDs** (e.g. `VP0`, `VP1`…`VP12`, `MS-HP-001`), capture each
+     item WITH its ID and **reuse that ID as the scenario code** — do not invent a generic
+     `VP-<CAT>` scheme (the harness Taxonomy-match gate FAILs on mismatch).
+- `qa/context.md` — project-wide context set by the QA lead. Read ONCE before building the Coverage Map; apply to every screen. Extraction rules:
+  - **Roles** → for each role in the table: add to the `@auth:X` tag pool; generate a VP-SEC blocked-access scenario for every role boundary relevant to this screen.
+  - **Testing strategy → Focus areas** → if `security` listed: VP-SEC is mandatory Tier 1 for every free-text input regardless of spec risk level; if `ui` not listed: all VP-UI scenarios move to Tier 2 minimum.
+  - **Testing strategy → Mandatory coverage** → each line is a hard override applied to this screen regardless of spec risk; document in `Context constraints` of the Coverage Map.
+  - **Testing strategy → Deprioritize/skip** → record in `Context constraints`; suppress those VP categories from Tier 1 generation.
+  - **Global business rules** → add each to the `Business rules` section tagged `[G]` (e.g. `[G1 – soft-delete only]`); treat as `HIGH` risk unless stated otherwise.
+  - **Error patterns** → use as fallback only when `spec.md` does not give exact error text; never override spec-specified messages.
+  - If `qa/context.md` is absent: proceed without it — no impact on the generation flow.
 
 **Single screen focus**: one URL = one screen. Modals on same page = part of this screen.
 This means: do not test other screens' UI layout or navigation. It does NOT mean skip documenting business outcomes that your screen's actions cause on other surfaces. Those cross-surface outcomes must appear in the Coverage Map and be covered by at least `@manual` scenarios.
@@ -129,6 +140,11 @@ Read `spec.md` fully, then extract into a Coverage Map **before writing any scen
 **Risk tags:** HIGH = complex business rules, cascading fields, multi-step state changes, auth/integration. LOW = display-only, static labels, read-only fields.
 
 ```
+Context constraints: [populated from qa/context.md before writing any scenario]
+                     roles: [list roles, e.g. admin / manager / staff]
+                     strategy: [active overrides, e.g. "VP-SEC mandatory T1", "VP-UI → T2 only"]
+                     global rules: [G1 – ...] → also appear in Business rules below tagged [G]
+                     → leave empty if qa/context.md is absent or has no entries applicable to this screen
 User journeys:       [J1 – ...], [J2 – ...]
 Validation rules:    [V1 – field → "exact error text"], [V2 – ...]
 Business rules:      [B1 HIGH – ...], [B2 LOW – ...]
@@ -221,7 +237,7 @@ Security:         [S1 – admin only]
 | **auth** | valid-login · invalid-credential · access-control |
 
 **Required assertion shapes (use these, not bare visibility):**
-- Card info: assert at **card level** (image+name+price together), e.g. `User see all [Product Card] contain {{...}}` — not `see [Section]`.
+- Card info: assert at **card level** (image+name+price together), e.g. `User see all [Product Card] contain {{...}}` — not `see [Section]` (section-level passes even if one card lacks price).
 - Cross-screen consistency (detail/cart): **capture then compare** —
   ```gherkin
   When User remember [Product Name] text as {{selected_product_name}}
@@ -239,13 +255,33 @@ Security:         [S1 – admin only]
 - **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.
 
-**First-pass anti-patterns (exactly what the gate/reviewer reject — avoid them):**
-- Title↔steps mismatch (e.g. a "no-result" scenario that clicks a query which returns products).
-- Tautology `Then`: `click [Next Slide]` → `see [Carousel] section` (proves nothing).
-- Business-critical scenario ending at `see [Added] modal` / `see [Cart] page` with no data assertion.
+**First-pass anti-patterns (these are exactly what the gate/reviewer reject — avoid them):**
+- Title↔steps mismatch: e.g. a "no-result state" scenario that clicks a query which **returns** products. Steps must create the condition the title claims.
+- Tautology `Then`: `click [Next Slide]` → `see [Carousel] section` (always visible, proves nothing). Assert the change (new slide title differs).
+- Business-critical scenario ending at `see [Added] modal` / `see [Cart] page` / `see [Category Products] page` with no data assertion.
 - Brand filter covered only as navigation (must assert products belong to the brand).
 
-**Balance:** cover all the above (deep) BEFORE expanding subscription / UI-presence / extra validation edge cases.
+**Balance:** cover all the above (deep) BEFORE expanding subscription / UI-presence / extra validation edge cases. Do not over-invest in subscription while cart/detail/filter correctness are shallow.
+
+#### Harness gates — satisfy on the FIRST pass (don't make the repair loop fix them)
+
+`sungen audit` enforces these. Generate compliant output up front:
+
+1. **Taxonomy-match** (`VP-TAXONOMY-MISMATCH`, gate-FAIL) — when `test-viewpoint.md` declares its own viewpoint IDs (e.g. `VP0`, `VP1`, … `VP12`, `MS-HP-001`, `MS-EH-001`), **reuse those IDs verbatim as the scenario codes**. Do NOT invent a generic `VP-UI / VP-LOGIC / VP-VAL` scheme — that breaks the coverage matrix. Only fall back to `VP-<CATEGORY>-<NNN>` when the viewpoint file declares no IDs.
+2. **Spec-coverage triggers** (`TRIGGER-UNCOVERED`, gate-FAIL) — the Validation-Rules table lists a **trigger** per constraint (e.g. `blur, submit`). Generate one scenario **per (constraint × trigger)** — a `format` rule validating *on blur AND on submit* needs BOTH a blur scenario (`press Tab`) and a submit scenario (`click [Submit]` / `press Enter`). Never collapse the trigger × input matrix to one representative case.
+3. **Claim-Proof** (`CLAIM-UNPROVEN`) — a title claiming `all`/`only`/`every`/`single`/`correct`/`same`/`changes`/`hidden`/`cleared`/`restored`/`independent`/`sanitized`/`announces` MUST have the matching assertion (`see all …`, count, `remember`+compare, `is hidden`, return-and-assert-empty, etc.). If the title promises it, the steps must prove it.
+4. **Downstream-scope** (`DOWNSTREAM-SCOPE-MISSING`) — when the spec's Navigation Flow / success target is **another screen** (e.g. a confirmation/sent page), don't stop at a terminal `see [X] page`. Either cover that screen's content/guards (if its viewpoint items are in scope — they often have their own `MS-*` IDs), or scaffold it (`sungen add --screen <name>`) and note the handoff. Do not silently drop the downstream surface.
+5. **Manual-oracle** (`MANUAL-STEPS-INSUFFICIENT`) — every `@manual` scenario needs **setup · action · observable expected · oracle/tool**, not a one-line note. Use this comment shape:
+   ```gherkin
+   @high @manual
+   Scenario: VP-… <claim>
+     # MANUAL: <why it can't be automated — needs network capture / inbox / screen-reader / multi-tab>
+     # Tester verifies:
+     #   1. <setup>            e.g. seed a registered email; throttle the network
+     #   2. <action>           e.g. click [Submit] with the request in flight
+     #   3. <observable>       e.g. only ONE POST is dispatched
+     #   4. Oracle: <tool>     e.g. DevTools Network panel / mail-catcher / NVDA
+   ```
 
 #### Tier 1 guard — minimum before writing scenarios
 
@@ -363,7 +399,7 @@ Add cleanup tags per the `sungen-gherkin-syntax` Cleanup table. Key rules:
 **Files:** `qa/screens/<screen>/features/<screen>.feature` + `qa/screens/<screen>/test-data/<screen>.yaml`
 
 Use step patterns and element types from `sungen-gherkin-syntax`.
-**Naming**: `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
+**Naming**: reuse the **project's `test-viewpoint.md` IDs** when it declares them (e.g. `VP0`, `MS-HP-001`); otherwise `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
 
 **Test data** — grouped by section, loaded at runtime:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sun-asterisk/sungen",
-  "version": "3.0.0-beta.79",
+  "version": "3.0.0-beta.80",
   "description": "Deterministic E2E Test Compiler - Gherkin + Selectors → Playwright tests",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

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

@@ -105,6 +105,9 @@ Auto-detected by `create-test` before invoking this skill:
   2. Each row / bullet / item = 1 viewpoint → add to `Viewpoint items` in Coverage Map.
   3. Do NOT pre-classify into buckets before scanning — classify only when
      writing the scenario.
+  4. **If it declares viewpoint IDs** (e.g. `VP0`, `VP1`…`VP12`, `MS-HP-001`), capture each
+     item WITH its ID and **reuse that ID as the scenario code** — do not invent a generic
+     `VP-<CAT>` scheme (the harness Taxonomy-match gate FAILs on mismatch).
 - `qa/context.md` — project-wide context set by the QA lead. Read ONCE before building the Coverage Map; apply to every screen. Extraction rules:
   - **Roles** → for each role in the table: add to the `@auth:X` tag pool; generate a VP-SEC blocked-access scenario for every role boundary relevant to this screen.
   - **Testing strategy → Focus areas** → if `security` listed: VP-SEC is mandatory Tier 1 for every free-text input regardless of spec risk level; if `ui` not listed: all VP-UI scenarios move to Tier 2 minimum.
@@ -260,6 +263,26 @@ Security:         [S1 – admin only]
 
 **Balance:** cover all the above (deep) BEFORE expanding subscription / UI-presence / extra validation edge cases. Do not over-invest in subscription while cart/detail/filter correctness are shallow.
 
+#### Harness gates — satisfy on the FIRST pass (don't make the repair loop fix them)
+
+`sungen audit` enforces these. Generate compliant output up front:
+
+1. **Taxonomy-match** (`VP-TAXONOMY-MISMATCH`, gate-FAIL) — when `test-viewpoint.md` declares its own viewpoint IDs (e.g. `VP0`, `VP1`, … `VP12`, `MS-HP-001`, `MS-EH-001`), **reuse those IDs verbatim as the scenario codes**. Do NOT invent a generic `VP-UI / VP-LOGIC / VP-VAL` scheme — that breaks the coverage matrix. Only fall back to `VP-<CATEGORY>-<NNN>` when the viewpoint file declares no IDs.
+2. **Spec-coverage triggers** (`TRIGGER-UNCOVERED`, gate-FAIL) — the Validation-Rules table lists a **trigger** per constraint (e.g. `blur, submit`). Generate one scenario **per (constraint × trigger)** — a `format` rule validating *on blur AND on submit* needs BOTH a blur scenario (`press Tab`) and a submit scenario (`click [Submit]` / `press Enter`). Never collapse the trigger × input matrix to one representative case.
+3. **Claim-Proof** (`CLAIM-UNPROVEN`) — a title claiming `all`/`only`/`every`/`single`/`correct`/`same`/`changes`/`hidden`/`cleared`/`restored`/`independent`/`sanitized`/`announces` MUST have the matching assertion (`see all …`, count, `remember`+compare, `is hidden`, return-and-assert-empty, etc.). If the title promises it, the steps must prove it.
+4. **Downstream-scope** (`DOWNSTREAM-SCOPE-MISSING`) — when the spec's Navigation Flow / success target is **another screen** (e.g. a confirmation/sent page), don't stop at a terminal `see [X] page`. Either cover that screen's content/guards (if its viewpoint items are in scope — they often have their own `MS-*` IDs), or scaffold it (`sungen add --screen <name>`) and note the handoff. Do not silently drop the downstream surface.
+5. **Manual-oracle** (`MANUAL-STEPS-INSUFFICIENT`) — every `@manual` scenario needs **setup · action · observable expected · oracle/tool**, not a one-line note. Use this comment shape:
+   ```gherkin
+   @high @manual
+   Scenario: VP-… <claim>
+     # MANUAL: <why it can't be automated — needs network capture / inbox / screen-reader / multi-tab>
+     # Tester verifies:
+     #   1. <setup>            e.g. seed a registered email; throttle the network
+     #   2. <action>           e.g. click [Submit] with the request in flight
+     #   3. <observable>       e.g. only ONE POST is dispatched
+     #   4. Oracle: <tool>     e.g. DevTools Network panel / mail-catcher / NVDA
+   ```
+
 #### Tier 1 guard — minimum before writing scenarios
 
 | Spec section | Minimum requirement | Tag |
@@ -376,7 +399,7 @@ Add cleanup tags per the `sungen-gherkin-syntax` Cleanup table. Key rules:
 **Files:** `qa/screens/<screen>/features/<screen>.feature` + `qa/screens/<screen>/test-data/<screen>.yaml`
 
 Use step patterns and element types from `sungen-gherkin-syntax`.
-**Naming**: `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
+**Naming**: reuse the **project's `test-viewpoint.md` IDs** when it declares them (e.g. `VP0`, `MS-HP-001`); otherwise `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
 
 **Test data** — grouped by section, loaded at runtime:
 

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

@@ -105,6 +105,17 @@ Auto-detected by `create-test` before invoking this skill:
   2. Each row / bullet / item = 1 viewpoint → add to `Viewpoint items` in Coverage Map.
   3. Do NOT pre-classify into buckets before scanning — classify only when
      writing the scenario.
+  4. **If it declares viewpoint IDs** (e.g. `VP0`, `VP1`…`VP12`, `MS-HP-001`), capture each
+     item WITH its ID and **reuse that ID as the scenario code** — do not invent a generic
+     `VP-<CAT>` scheme (the harness Taxonomy-match gate FAILs on mismatch).
+- `qa/context.md` — project-wide context set by the QA lead. Read ONCE before building the Coverage Map; apply to every screen. Extraction rules:
+  - **Roles** → for each role in the table: add to the `@auth:X` tag pool; generate a VP-SEC blocked-access scenario for every role boundary relevant to this screen.
+  - **Testing strategy → Focus areas** → if `security` listed: VP-SEC is mandatory Tier 1 for every free-text input regardless of spec risk level; if `ui` not listed: all VP-UI scenarios move to Tier 2 minimum.
+  - **Testing strategy → Mandatory coverage** → each line is a hard override applied to this screen regardless of spec risk; document in `Context constraints` of the Coverage Map.
+  - **Testing strategy → Deprioritize/skip** → record in `Context constraints`; suppress those VP categories from Tier 1 generation.
+  - **Global business rules** → add each to the `Business rules` section tagged `[G]` (e.g. `[G1 – soft-delete only]`); treat as `HIGH` risk unless stated otherwise.
+  - **Error patterns** → use as fallback only when `spec.md` does not give exact error text; never override spec-specified messages.
+  - If `qa/context.md` is absent: proceed without it — no impact on the generation flow.
 
 **Single screen focus**: one URL = one screen. Modals on same page = part of this screen.
 This means: do not test other screens' UI layout or navigation. It does NOT mean skip documenting business outcomes that your screen's actions cause on other surfaces. Those cross-surface outcomes must appear in the Coverage Map and be covered by at least `@manual` scenarios.
@@ -129,6 +140,11 @@ Read `spec.md` fully, then extract into a Coverage Map **before writing any scen
 **Risk tags:** HIGH = complex business rules, cascading fields, multi-step state changes, auth/integration. LOW = display-only, static labels, read-only fields.
 
 ```
+Context constraints: [populated from qa/context.md before writing any scenario]
+                     roles: [list roles, e.g. admin / manager / staff]
+                     strategy: [active overrides, e.g. "VP-SEC mandatory T1", "VP-UI → T2 only"]
+                     global rules: [G1 – ...] → also appear in Business rules below tagged [G]
+                     → leave empty if qa/context.md is absent or has no entries applicable to this screen
 User journeys:       [J1 – ...], [J2 – ...]
 Validation rules:    [V1 – field → "exact error text"], [V2 – ...]
 Business rules:      [B1 HIGH – ...], [B2 LOW – ...]
@@ -221,7 +237,7 @@ Security:         [S1 – admin only]
 | **auth** | valid-login · invalid-credential · access-control |
 
 **Required assertion shapes (use these, not bare visibility):**
-- Card info: assert at **card level** (image+name+price together), e.g. `User see all [Product Card] contain {{...}}` — not `see [Section]`.
+- Card info: assert at **card level** (image+name+price together), e.g. `User see all [Product Card] contain {{...}}` — not `see [Section]` (section-level passes even if one card lacks price).
 - Cross-screen consistency (detail/cart): **capture then compare** —
   ```gherkin
   When User remember [Product Name] text as {{selected_product_name}}
@@ -239,13 +255,33 @@ Security:         [S1 – admin only]
 - **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.
 
-**First-pass anti-patterns (exactly what the gate/reviewer reject — avoid them):**
-- Title↔steps mismatch (e.g. a "no-result" scenario that clicks a query which returns products).
-- Tautology `Then`: `click [Next Slide]` → `see [Carousel] section` (proves nothing).
-- Business-critical scenario ending at `see [Added] modal` / `see [Cart] page` with no data assertion.
+**First-pass anti-patterns (these are exactly what the gate/reviewer reject — avoid them):**
+- Title↔steps mismatch: e.g. a "no-result state" scenario that clicks a query which **returns** products. Steps must create the condition the title claims.
+- Tautology `Then`: `click [Next Slide]` → `see [Carousel] section` (always visible, proves nothing). Assert the change (new slide title differs).
+- Business-critical scenario ending at `see [Added] modal` / `see [Cart] page` / `see [Category Products] page` with no data assertion.
 - Brand filter covered only as navigation (must assert products belong to the brand).
 
-**Balance:** cover all the above (deep) BEFORE expanding subscription / UI-presence / extra validation edge cases.
+**Balance:** cover all the above (deep) BEFORE expanding subscription / UI-presence / extra validation edge cases. Do not over-invest in subscription while cart/detail/filter correctness are shallow.
+
+#### Harness gates — satisfy on the FIRST pass (don't make the repair loop fix them)
+
+`sungen audit` enforces these. Generate compliant output up front:
+
+1. **Taxonomy-match** (`VP-TAXONOMY-MISMATCH`, gate-FAIL) — when `test-viewpoint.md` declares its own viewpoint IDs (e.g. `VP0`, `VP1`, … `VP12`, `MS-HP-001`, `MS-EH-001`), **reuse those IDs verbatim as the scenario codes**. Do NOT invent a generic `VP-UI / VP-LOGIC / VP-VAL` scheme — that breaks the coverage matrix. Only fall back to `VP-<CATEGORY>-<NNN>` when the viewpoint file declares no IDs.
+2. **Spec-coverage triggers** (`TRIGGER-UNCOVERED`, gate-FAIL) — the Validation-Rules table lists a **trigger** per constraint (e.g. `blur, submit`). Generate one scenario **per (constraint × trigger)** — a `format` rule validating *on blur AND on submit* needs BOTH a blur scenario (`press Tab`) and a submit scenario (`click [Submit]` / `press Enter`). Never collapse the trigger × input matrix to one representative case.
+3. **Claim-Proof** (`CLAIM-UNPROVEN`) — a title claiming `all`/`only`/`every`/`single`/`correct`/`same`/`changes`/`hidden`/`cleared`/`restored`/`independent`/`sanitized`/`announces` MUST have the matching assertion (`see all …`, count, `remember`+compare, `is hidden`, return-and-assert-empty, etc.). If the title promises it, the steps must prove it.
+4. **Downstream-scope** (`DOWNSTREAM-SCOPE-MISSING`) — when the spec's Navigation Flow / success target is **another screen** (e.g. a confirmation/sent page), don't stop at a terminal `see [X] page`. Either cover that screen's content/guards (if its viewpoint items are in scope — they often have their own `MS-*` IDs), or scaffold it (`sungen add --screen <name>`) and note the handoff. Do not silently drop the downstream surface.
+5. **Manual-oracle** (`MANUAL-STEPS-INSUFFICIENT`) — every `@manual` scenario needs **setup · action · observable expected · oracle/tool**, not a one-line note. Use this comment shape:
+   ```gherkin
+   @high @manual
+   Scenario: VP-… <claim>
+     # MANUAL: <why it can't be automated — needs network capture / inbox / screen-reader / multi-tab>
+     # Tester verifies:
+     #   1. <setup>            e.g. seed a registered email; throttle the network
+     #   2. <action>           e.g. click [Submit] with the request in flight
+     #   3. <observable>       e.g. only ONE POST is dispatched
+     #   4. Oracle: <tool>     e.g. DevTools Network panel / mail-catcher / NVDA
+   ```
 
 #### Tier 1 guard — minimum before writing scenarios
 
@@ -363,7 +399,7 @@ Add cleanup tags per the `sungen-gherkin-syntax` Cleanup table. Key rules:
 **Files:** `qa/screens/<screen>/features/<screen>.feature` + `qa/screens/<screen>/test-data/<screen>.yaml`
 
 Use step patterns and element types from `sungen-gherkin-syntax`.
-**Naming**: `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
+**Naming**: reuse the **project's `test-viewpoint.md` IDs** when it declares them (e.g. `VP0`, `MS-HP-001`); otherwise `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
 
 **Test data** — grouped by section, loaded at runtime: