@sun-asterisk/sungen 3.0.0-beta.84 → 3.0.0-beta.92

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

@@ -105,9 +105,6 @@ 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.
@@ -263,27 +260,6 @@ 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.
-   - **Negative / absence claims** (`does not` / `no` / `never` / `prevents` / `không` / `chưa` — any language; `no-side-effect/no-duplicate`, `negative-claim/absence`): the `Then` must **differ** between the claim holding and not holding. A terminal `see [X] page` that looks identical whether or not the bad thing happened proves nothing. For a side-effect that should NOT repeat (re-submit on back, re-charge, duplicate order, resend OTP), assert the **count is unchanged** (`User see [Records] table with {{one}}` / `row with {{count}}`); if it's not UI-observable, mark `@manual` with a request-count oracle (shape below). This is general — it covers any side-effect, not a fixed verb list.
-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 |
@@ -400,7 +376,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**: 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.
+**Naming**: `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,17 +105,6 @@ 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.
@@ -140,11 +129,6 @@ 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 – ...]
@@ -237,7 +221,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]` (section-level passes even if one card lacks price).
+- Card info: assert at **card level** (image+name+price together), e.g. `User see all [Product Card] contain {{...}}` — not `see [Section]`.
 - Cross-screen consistency (detail/cart): **capture then compare** —
   ```gherkin
   When User remember [Product Name] text as {{selected_product_name}}
@@ -255,34 +239,13 @@ 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 (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.
+**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.
 - 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. 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.
-   - **Negative / absence claims** (`does not` / `no` / `never` / `prevents` / `không` / `chưa` — any language; `no-side-effect/no-duplicate`, `negative-claim/absence`): the `Then` must **differ** between the claim holding and not holding. A terminal `see [X] page` that looks identical whether or not the bad thing happened proves nothing. For a side-effect that should NOT repeat (re-submit on back, re-charge, duplicate order, resend OTP), assert the **count is unchanged** (`User see [Records] table with {{one}}` / `row with {{count}}`); if it's not UI-observable, mark `@manual` with a request-count oracle (shape below). This is general — it covers any side-effect, not a fixed verb list.
-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
-   ```
+**Balance:** cover all the above (deep) BEFORE expanding subscription / UI-presence / extra validation edge cases.
 
 #### Tier 1 guard — minimum before writing scenarios
 
@@ -400,7 +363,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**: 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.
+**Naming**: `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.84",
+  "version": "3.0.0-beta.92",
   "description": "Deterministic E2E Test Compiler - Gherkin + Selectors → Playwright tests",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -12,7 +12,7 @@
     "copy-templates": "mkdir -p dist/generators/test-generator/adapters/playwright/templates/steps && mkdir -p dist/generators/test-generator/templates && mkdir -p dist/orchestrator/templates && mkdir -p dist/dashboard/templates && cp -r src/generators/test-generator/adapters/playwright/templates/*.hbs dist/generators/test-generator/adapters/playwright/templates/ 2>/dev/null || true && cp -r src/generators/test-generator/adapters/playwright/templates/steps dist/generators/test-generator/adapters/playwright/templates/ && cp src/generators/test-generator/templates/*.hbs dist/generators/test-generator/templates/ 2>/dev/null || true && cp -r src/orchestrator/templates/* dist/orchestrator/templates/ && cp src/dashboard/templates/index.html dist/dashboard/templates/index.html && mkdir -p dist/harness/catalog && cp src/harness/catalog/*.yaml dist/harness/catalog/",
     "build:dashboard": "cd dashboard && npm install --silent && npm run build && cd .. && cp dashboard/dist/index.html src/dashboard/templates/index.html",
     "dev": "tsx src/cli/index.ts",
-    "test": "tsx tests/golden/run.ts && tsx tests/audit/run.ts && tsx tests/ingest/run.ts && tsx tests/eval/run.ts",
+    "test": "tsx tests/golden/run.ts && tsx tests/audit/run.ts && tsx tests/ingest/run.ts",
     "test:update": "tsx tests/golden/run.ts --update && tsx tests/audit/run.ts --update && tsx tests/ingest/run.ts --update",
     "prepublishOnly": "npm run build:dashboard && npm run build"
   },

package/src/cli/commands/audit.ts

@@ -65,18 +65,6 @@ function render(r: AuditReport): void {
     if (!r.spec.triggerGaps.length && !r.spec.uncoveredMust.length) L('      ✓ every MUST FR + per-constraint trigger covered');
     L('');
   }
-  if (r.ledger.hasViewpoint && r.ledger.total > 0) {
-    L(`  ⑧ Viewpoint atomic coverage — ${r.ledger.covered}/${r.ledger.total} items (${(r.ledger.ratio * 100).toFixed(0)}%)`);
-    for (const m of r.ledger.missing.slice(0, 8)) L(`      ○ missing: ${m.id ? m.id + ' — ' : ''}${m.text.slice(0, 70)}`);
-    if (r.ledger.missing.length > 8) L(`      … +${r.ledger.missing.length - 8} more`);
-    L('');
-  }
-  if (r.calibration) {
-    const ax = Object.entries(r.calibration.axes).map(([k, v]) => `${k}=${(v * 100).toFixed(0)}%`).join(' · ');
-    L(`  ⑨ Calibration — ${ax}`);
-    L(`      weakest: ${r.calibration.weakest.axis} ${(r.calibration.weakest.value * 100).toFixed(0)}%${r.calibration.inflated ? '  ⚠ SCORE-INFLATED-BY-BREADTH' : ''}`);
-    L('');
-  }
   L('  ── Findings (Repair targets) ──');
   if (r.findings.length === 0) L('      ✓ none — output passes the harness');
   for (const f of r.findings) L(`      • ${f}`);

package/src/cli/index.ts

@@ -16,7 +16,6 @@ import { registerAddFlowCommand } from './commands/add-flow';
 import { registerDashboardCommand } from './commands/dashboard';
 import { registerAuditCommand } from './commands/audit';
 import { registerIngestCommand } from './commands/ingest';
-import { registerEvalCommand } from './commands/eval';
 import { registerManifestCommand } from './commands/manifest';
 import { registerLedgerCommand } from './commands/ledger';
 import { registerFeedbackCommand } from './commands/feedback';
@@ -63,7 +62,6 @@ async function main() {
   registerCapabilityCommand(program);
   registerFlowCheckCommand(program);
   registerIngestCommand(program);
-  registerEvalCommand(program);
 
   await program.parseAsync(process.argv);
 }

package/src/harness/audit.ts

@@ -15,10 +15,7 @@ import {
 } from './sensors';
 import { readIntent, projectRootFromScreenDir, IntentProfile } from './intent';
 import { getProvenance, Provenance } from './provenance';
-import { specCoverage, SpecCoverageResult, parseSpecClauses } from './spec-coverage';
-import { downstreamScope, manualOracle, readText, DownstreamResult, ManualOracleResult,
-  negativeSideEffect, sourceBacked, crossArtifactOwnership } from './quality-gates';
-import { viewpointLedger, parseViewpointItems, LedgerResult } from './viewpoint-ledger';
+import { specCoverage, SpecCoverageResult } from './spec-coverage';
 
 export interface AuditReport {
   screen: string;
@@ -30,15 +27,6 @@ export interface AuditReport {
   balance: BalanceResult;
   duplicates: DuplicateResult;
   trace: TraceResult;
-  taxonomyMismatch: boolean;    // scenarios use IDs not in the project's test-viewpoint.md
-  downstream: DownstreamResult; // downstream screens referenced but under-covered
-  manualOracle: ManualOracleResult; // @manual scenarios lacking setup/action/oracle
-  ledger: LedgerResult;         // atomic viewpoint-item coverage (per-bullet status)
-  calibration: {                // #8 — multi-axis score so a high overall can't hide a weak axis
-    axes: Record<string, number>;
-    weakest: { axis: string; value: number };
-    inflated: boolean;
-  };
   score: {
     overall: number;            // 0..10, business-weighted
     coverage: number;           // 0..1
@@ -75,15 +63,6 @@ export function runAudit(screenDir: string, screenName: string): AuditReport {
   const balance = coverageBalance(scenarios);
   const duplicates = duplicateClusters(scenarios);
   const trace = traceability(scenarios, viewpoints);
-  // #1 taxonomy-match: when the project defines a viewpoint taxonomy, scenarios must use it.
-  const taxonomyMismatch = viewpoints.length > 0 && trace.withVpCode > 0 && trace.mappedRatio < 0.6;
-  // #2 downstream-scope + #4 manual-oracle
-  const downstream = downstreamScope(readText(specPath), scenarios);
-  const manualOracleResult = manualOracle(featureText);
-  const ledger = viewpointLedger(viewpointPath, scenarios, featureText);
-  const negSideEffect = negativeSideEffect(scenarios);
-  const ownership = crossArtifactOwnership(screenDir, scenarios);
-  const unsourced = sourceBacked(scenarios, parseSpecClauses(specPath).frs.map((f) => f.id), parseViewpointItems(viewpointPath).map((i) => i.text), viewpoints.map((v) => v.id), featureText);
 
   // Sub-scores
   const coverage = gate.coverageRatio;
@@ -134,59 +113,16 @@ export function runAudit(screenDir: string, screenName: string): AuditReport {
   for (const u of spec.uncoveredMust) {
     findings.push(`SPEC-UNCOVERED: ${u.id} (MUST) has no covering scenario — "${u.text}" → add a scenario or tag one @spec:${u.id}.`);
   }
-  if (taxonomyMismatch) {
-    findings.push(`VP-TAXONOMY-MISMATCH: only ${(trace.mappedRatio * 100).toFixed(0)}% of scenarios use the viewpoint IDs declared in test-viewpoint.md — scenarios invented a generic VP-<CAT> scheme. Re-tag to the project's viewpoint IDs so the coverage matrix is accurate.`);
-  }
-  for (const d of downstream.underCovered) {
-    findings.push(`DOWNSTREAM-SCOPE-MISSING: "${d.route}" is a navigation target but is covered only by a page-nav assertion — cover its content/guards, or scaffold it (\`sungen add --screen ${d.slug}\`).`);
-  }
-  for (const m of manualOracleResult.insufficient.slice(0, 8)) {
-    findings.push(`MANUAL-STEPS-INSUFFICIENT: "${m}" — a @manual scenario needs setup · action · observable expected · oracle/tool (not just a one-line note).`);
-  }
-  if (ledger.hasViewpoint && ledger.missing.length) {
-    const sample = ledger.missing.slice(0, 6).map((m) => m.id || `"${m.text}"`).join(', ');
-    findings.push(`VIEWPOINT-ITEM-MISSING: ${ledger.missing.length}/${ledger.total} atomic viewpoint items have no covering scenario (${(ledger.ratio * 100).toFixed(0)}% covered) — e.g. ${sample}. Cover each item or mark it deferred/spec-gap.`);
-  }
-  for (const n of negSideEffect.slice(0, 6)) {
-    findings.push(`NEGATIVE-SIDE-EFFECT-UNPROVEN: "${n}" — the title claims something must NOT happen but the steps don't prove the absence (assert a count / negative state, or make it @manual with an oracle).`);
-  }
-  for (const d of ownership.duplicates.slice(0, 6)) {
-    findings.push(`DUPLICATE-FLOW-OWNERSHIP: "${d.scenario}" has the same shape as a scenario in flow "${d.flow}" — keep one owner (screen-local vs flow); the other should only reference/set up.`);
-  }
-  for (const u of unsourced.slice(0, 6)) {
-    findings.push(`UNSOURCEABLE-SCENARIO: "${u}" doesn't trace to any FR / viewpoint item — link it to a source, or tag it @exploration (not part of the official suite).`);
-  }
-
-  // #8 — multi-axis calibration: a high overall must not hide a weak axis.
-  const manualCompleteness = manualOracleResult.manualTotal
-    ? 1 - manualOracleResult.insufficient.length / manualOracleResult.manualTotal : 1;
-  const axes: Record<string, number> = {
-    coverage: Math.round(coverage * 100) / 100,
-    businessDepth: Math.round(businessDepth * 100) / 100,
-    claimProof: Math.round(claim.ratio * 100) / 100,
-    specFR: spec.frTotal ? Math.round((spec.frCovered / spec.frTotal) * 100) / 100 : 1,
-    atomicLedger: Math.round(ledger.ratio * 100) / 100,
-    manualOracle: Math.round(manualCompleteness * 100) / 100,
-    taxonomy: taxonomyMismatch ? 0 : Math.round(trace.mappedRatio * 100) / 100,
-  };
-  const weakestEntry = Object.entries(axes).sort((a, b) => a[1] - b[1])[0];
-  const weakest = { axis: weakestEntry[0], value: weakestEntry[1] };
-  const inflated = overall >= 8 && weakest.value < 0.6;
-  if (inflated) {
-    findings.push(`SCORE-INFLATED-BY-BREADTH: overall ${Math.round(overall * 10) / 10}/10 but the weakest axis "${weakest.axis}" is ${(weakest.value * 100).toFixed(0)}% — breadth is hiding a weak dimension. Raise "${weakest.axis}" before trusting the headline.`);
-  }
-  const calibration = { axes, weakest, inflated };
 
-  // Gate spans coverage (viewpoint themes), depth, claim-proof, spec-clause coverage,
-  // AND taxonomy-match (scenarios must use the project's viewpoint IDs when defined).
+  // Gate spans coverage (viewpoint themes), depth (data-correctness), claim-proof,
+  // AND spec-clause coverage (every MUST clause + every mandated validation trigger).
   const gateStatus: 'PASS' | 'FAIL' =
-    gate.gaps.length === 0 && depth.verdict !== 'fail' && claim.verdict !== 'fail' && spec.verdict !== 'fail' && !taxonomyMismatch ? 'PASS' : 'FAIL';
+    gate.gaps.length === 0 && depth.verdict !== 'fail' && claim.verdict !== 'fail' && spec.verdict !== 'fail' ? 'PASS' : 'FAIL';
 
   return {
     screen: screenName,
     scenarioCount: scenarios.length,
     gate, depth, claim, taxonomy, balance, duplicates, trace, spec,
-    taxonomyMismatch, downstream, manualOracle: manualOracleResult, ledger, calibration,
     score: {
       overall: Math.round(overall * 10) / 10,
       coverage: Math.round(coverage * 100) / 100,

package/src/harness/parse.ts

@@ -29,18 +29,6 @@ export interface ScenarioInfo {
   stepSkeleton: string;       // normalized steps for duplicate clustering
   haystack: string;           // lowercase name + steps text (for keyword coverage)
   stepsText: string;          // lowercase steps ONLY (name excluded) — for claim-proof
-  vpId?: string;              // raw leading ID token of the title (project's scheme: VP0-001, MS-HP-001, VP-LIST-001)
-}
-
-/** Format-tolerant: is this token an ID (project's scheme), not a prose word?
- * Accepts VP0, VP0-001, MS-HP-001, TV-01, VP-LIST-001 — requires a digit + uppercase start. */
-export function isIdLike(s: string): boolean {
-  return /^[A-Z][A-Za-z0-9.-]*$/.test(s) && /\d/.test(s) && s.length >= 3;
-}
-
-/** The ID minus its trailing -NNN sequence number (VP0-001 → VP0, MS-HP-001 → MS-HP). */
-export function idPrefix(id: string): string {
-  return id.replace(/[-.]\d{1,4}$/, '');
 }
 
 // ---------- test-viewpoint.md ----------
@@ -62,7 +50,7 @@ export function parseViewpointOverview(filePath: string): ViewpointEntry[] {
       const cells = line.split('|').map((c) => c.trim()).filter((_, i, a) => i > 0 && i < a.length - 1);
       if (cells.length >= 3) {
         const id = cells[0];
-        if (isIdLike(id) && !/^-+$/.test(cells[1])) {
+        if (/^VP[-A-Z0-9]/i.test(id) && !/^vp$/i.test(id) && !/^-+$/.test(cells[1])) {
           const pr = /high/i.test(cells[1]) ? 'High' : /medium/i.test(cells[1]) ? 'Medium' : /low/i.test(cells[1]) ? 'Low' : 'Unknown';
           entries.set(id.toUpperCase(), { id: id.toUpperCase(), priority: pr as any, reason: cells[2] });
         }
@@ -78,8 +66,8 @@ export function parseViewpointOverview(filePath: string): ViewpointEntry[] {
     if (g) { group = (g[1][0].toUpperCase() + g[1].slice(1).toLowerCase()) as any; continue; }
     if (/^##\s/.test(line)) { group = undefined; }
     if (group) {
-      const m = line.match(/^[-*+]\s+([A-Za-z][A-Za-z0-9.-]*)/);
-      if (m && isIdLike(m[1])) {
+      const m = line.match(/^-\s+(VP[-A-Z0-9]+)/i);
+      if (m) {
         const id = m[1].toUpperCase();
         const existing = entries.get(id);
         if (existing) existing.group = group;
@@ -104,9 +92,6 @@ function classifyScenario(sc: ParsedScenario): ScenarioInfo {
   const codeMatch = sc.name.match(/\bVP-([A-Z]+)-\d+/i);
   const vpCode = codeMatch ? codeMatch[0].toUpperCase() : undefined;
   const category = codeMatch ? codeMatch[1].toUpperCase() : undefined;
-  // Project-scheme ID: the leading token of the title (VP0-001 / MS-HP-001 / VP-LIST-001).
-  const leadMatch = sc.name.match(/^\s*([A-Za-z][A-Za-z0-9.-]*)/);
-  const vpId = leadMatch && isIdLike(leadMatch[1]) ? leadMatch[1].toUpperCase() : undefined;
 
   // Then-phase detection (And/But inherit previous primary keyword)
   let last = 'Given';
@@ -151,7 +136,6 @@ function classifyScenario(sc: ParsedScenario): ScenarioInfo {
     stepSkeleton: skeletonParts.join(' | '),
     haystack: textParts.join(' ').toLowerCase(),
     stepsText: stepTextParts.join(' ').toLowerCase(),
-    vpId,
   };
 }
 

package/src/harness/sensors.ts

@@ -9,7 +9,7 @@
 import * as fs from 'fs';
 import * as path from 'path';
 import { parse as parseYaml } from 'yaml';
-import { ScenarioInfo, ViewpointEntry, idPrefix } from './parse';
+import { ScenarioInfo, ViewpointEntry } from './parse';
 
 // Business-critical category codes (project VP-<CAT> prefixes). Configurable later.
 const BUSINESS_CRITICAL_CATS = ['LIST', 'CART', 'PRODUCT', 'FILTER', 'CHECKOUT', 'ORDER'];
@@ -263,23 +263,17 @@ export interface TraceResult {
 
 export function traceability(scenarios: ScenarioInfo[], viewpoints: ViewpointEntry[]): TraceResult {
   const overviewIds = new Set(viewpoints.map((v) => v.id.toUpperCase()));
-  // A scenario carries an ID if it has a project-scheme leading ID (vpId) or a VP-CAT code.
-  const withCode = scenarios.filter((s) => s.vpId || s.vpCode);
-  // Maps to overview if the scenario's ID, its sequence-stripped prefix, or its VP-CAT code
-  // matches a declared viewpoint ID (format-tolerant: VP0-001↔VP0, MS-HP-001↔MS-HP-001).
-  const mapped = withCode.filter((s) => {
-    const id = (s.vpId || s.vpCode || '').toUpperCase();
-    if (overviewIds.has(id) || overviewIds.has(idPrefix(id))) return true;
-    return [...overviewIds].some((oid) => id.startsWith(oid) || oid.startsWith(idPrefix(id)) || (!!s.category && oid.includes(s.category)));
-  });
+  const withCode = scenarios.filter((s) => s.vpCode);
+  // A scenario maps to overview if its full VP code OR its category-derived id exists in overview.
+  const mapped = withCode.filter((s) => overviewIds.has(s.vpCode!) || [...overviewIds].some((id) => id.includes(s.category || '###')));
   return {
     total: scenarios.length,
     withVpCode: withCode.length,
     mappedToOverview: mapped.length,
     withVpCodeRatio: scenarios.length ? withCode.length / scenarios.length : 0,
     mappedRatio: scenarios.length ? mapped.length / scenarios.length : 0,
-    note: withCode.length && mapped.length < withCode.length * 0.5
-      ? 'Scenario IDs do not match the viewpoint-overview ids (weak traceability — re-tag to the project viewpoint IDs).'
+    note: mapped.length < withCode.length * 0.5
+      ? 'Scenarios use ad-hoc VP-<CAT>-NNN codes not linked to viewpoint-overview ids (weak traceability — see review Gate 4).'
       : 'Traceable.',
   };
 }
@@ -373,85 +367,14 @@ const CLAIM_RULES: ClaimRule[] = [
     hint: 'capture the before-state and assert the after-state differs, or assert the visible/hidden transition.',
     severity: 'warn',
   },
-  {
-    // GENERAL — mutation-absence. A title asserts that a STATE-CHANGING action does NOT
-    // happen / does not repeat (submit, send, create, charge, order, pay, email, request,
-    // OTP, register, book, a re-/double-/again repeat…) paired with a negation in EITHER
-    // language. A mutation's absence is NOT observable from a positive `see [X] page` —
-    // that page looks identical whether or not the mutation fired — so it MUST prove a
-    // count/contrast (record count unchanged) or defer to @manual. This is the general
-    // category behind "browser back does not re-submit", "does not re-charge the card",
-    // "double-click does not create two orders" — not a per-feature keyword.
-    claim: 'no-side-effect/no-duplicate',
-    title: /(?=.*\b(submit|sen[dt]|resend|resubmit|re-?fire|re-?issue|re-?post|repost|create|charge|order|payment|\bpay\b|email|request|\botp\b|insert|register|book|duplicate|double[- ]?submit|again|twice)\b)(?=.*(\bno\b|\bnot\b|n['’]t\b|\bnever\b|\bwithout\b|\bcannot\b|prevent|block|avoid|reject|disabl|\bdeny\b|denies|\bkhông\b|\bchưa\b))/i,
-    proof: /\bcount\b|row with \{\{|table with|tohavecount|is hidden|are hidden|not complete|no longer/,
-    need: 'a record/request-count proof (count stays at one, e.g. `User see [Table] row with {{count}}`) or @manual with a request-count oracle',
-    hint: 'a "does-not-happen / does-not-repeat" claim about a state-changing action is NOT proven by a terminal `see [...] page` — that page is identical whether or not the action (re-)fired. Prove the side-effect count is unchanged, or mark @manual with a setup→action→assert-no-duplicate oracle.',
-    severity: 'fail',
-  },
   {
     claim: 'hidden/rejected/not-complete',
-    title: /\b(hidden|closed|dismiss(es|ed)?|not complete|rejected|inert)\b/,
+    title: /\b(hidden|closed|dismiss(es|ed)?|does not|doesn't|not complete|rejected|inert)\b/,
     proof: /\bis hidden\b|\bare hidden\b|message is hidden|not complete|\bhidden\b/,
     need: 'a negative / hidden assertion (`… is hidden`)',
     hint: 'assert the absence/hidden state that the title claims, not just an unrelated visible element.',
     severity: 'fail',
   },
-  {
-    claim: 'cleared/emptied',
-    title: /\b(cleared|clears|emptied|empties|reset to empty|wiped)\b/,
-    proof: /\bis empty\b|with \{\{empty|with ['"]?['"]?\s*$|\bempty\b/,
-    need: 'an empty/cleared assertion after the action (e.g. `field with {{empty_value}}` / `is empty`)',
-    hint: 'prove the value is actually gone — return to the screen and assert the field is empty, not just that the action ran.',
-    severity: 'fail',
-  },
-  {
-    claim: 'restored/preserved',
-    title: /\b(restored|preserved|persists?|retained|remembered|kept)\b/,
-    proof: /\bremember\b|with \{\{|field with/,
-    need: 'the value re-asserted after the transition (capture or `field with {{v}}` after returning)',
-    hint: 'prove the value survives — assert the field still holds the typed value after the reload/return, not just that it was typed.',
-    severity: 'warn',
-  },
-  {
-    claim: 'independent/separate',
-    title: /\b(independent|separate|isolat(ed|es)|per[- ]tab|two tabs|each tab)\b/,
-    proof: /\bcontext\b|tab a|tab b|second (tab|context)/,
-    need: 'a multi-context proof (tab A vs tab B)',
-    hint: 'independence across tabs/contexts is rarely DSL-expressible — mark @manual with a clear setup/action/oracle.',
-    severity: 'warn',
-  },
-  {
-    claim: 'sanitized/inert',
-    title: /\b(sanitized|sanitised|escaped|inert|not executed|not rendered|stripped)\b/,
-    proof: /field with \{\{|payload|inert|toContainText|is hidden/,
-    need: 'the payload echoed as inert text (`field with {{payload}}`) + no execution',
-    hint: 'prove the payload round-trips as literal text and triggers nothing — assert the field value and the absence of any effect.',
-    severity: 'warn',
-  },
-  {
-    claim: 'announces/aria',
-    title: /\b(announce[sd]?|aria|screen[- ]reader|programmatically associated)\b/,
-    proof: /aria|role|@manual|describedby|is focused/,
-    need: 'an aria/role assertion (or @manual with a screen-reader oracle)',
-    hint: 'ARIA announcement is usually not DSL-expressible — assert aria attributes if possible, else @manual with an NVDA/VoiceOver oracle.',
-    severity: 'warn',
-  },
-  {
-    // GENERAL CATCH-ALL (last) — any negative/absence title not handled by a specific
-    // rule above. Language-aware negation, NO verb list: if the title says "no / not /
-    // never / without / không / prevents …" the steps must carry a NEGATIVE/contrast
-    // assertion (hidden, empty, error, count, no-longer, a remembered before/after) — not
-    // only a positive presence. WARN, because a positive proxy is sometimes a valid
-    // negative proof (e.g. "stayed on the login page"); the semantic reviewer is the
-    // authoritative recall layer for the residue this can't judge structurally.
-    claim: 'negative-claim/absence',
-    title: /(\bno\b|\bnot\b|n['’]t\b|\bnever\b|\bwithout\b|\bcannot\b|prevent|block|avoid|reject|disabl|\bdeny\b|denies|\bkhông\b|\bchưa\b)/i,
-    proof: /is hidden|are hidden|is empty|no longer|not complete|disabl|invalid|rejected|\berror\b|\bcount\b|row with \{\{|table with|\bremember\b|\bexactly\b|tohavecount/i,
-    need: 'a proof of the ABSENCE — a contrast/empty/hidden/error/count assertion, or @manual with an oracle',
-    hint: 'a negative claim ("no / not / không …") is not proven by a positive `see [X]` that looks the same whether or not the claim holds. Assert the contrast (state hidden/empty, error shown, count unchanged), or mark @manual.',
-    severity: 'warn',
-  },
 ];
 
 // ---------- Viewpoint taxonomy-lint (harness-roadmap §0.5 Q3) ----------

package/src/orchestrator/templates/ai-instructions/claude-agent-reviewer.md

@@ -14,7 +14,6 @@ You are an **independent Senior QA Reviewer**. You did **not** write these tests
 
 ## What to judge (semantic — the gate misses these)
 1. **Title ↔ steps proof.** For every scenario, do the **steps actually prove the title/viewpoint**? Flag "title claims X but steps only assert Y". (e.g. title "adds the selected product, not a random one" but Then only `see [Added] modal`.)
-   - **Negative / "does-not-happen" claims** (any language — "does not", "no", "prevents", "không", "chưa"): the proof must be a step whose result **differs** between the claim holding and not holding. Ask: *would this `Then` still pass if the bad thing happened?* If yes, it proves nothing. The classic trap: title "browser back does **not** re-submit" with `Then see [sent] page` — that page is identical whether or not the request re-fired. Demand a **contrast/count** proof (record count unchanged, state hidden/empty, error shown) or a justified `@manual` with a setup→action→assert-absence oracle. This generalises to every side-effect (re-charge, duplicate order, resend OTP, data leak), not just re-submit.
 2. **Observable Then.** Is each `Then` an **observable outcome**, not a restated action or a tautology (e.g. `Then User see [Carousel] section` after clicking next — proves nothing changed)?
 3. **Business-critical depth.** For cart / product-detail / filter / list viewpoints, do steps assert **DATA** (name, price, quantity, all-items-belong) — not just page/modal visibility? Recommend the concrete deep step: `User remember [X] text as {{v}}` + `... with {{v}}`, or `User see all [X] contain {{v}}`.
 4. **@manual justification.** Is each `@manual` genuinely unautomatable (cross-screen/external/visual) — or a cop-out to dodge the gate? Cross-screen → should be a flow.

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

@@ -105,9 +105,6 @@ 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.
@@ -263,27 +260,6 @@ 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.
-   - **Negative / absence claims** (`does not` / `no` / `never` / `prevents` / `không` / `chưa` — any language; `no-side-effect/no-duplicate`, `negative-claim/absence`): the `Then` must **differ** between the claim holding and not holding. A terminal `see [X] page` that looks identical whether or not the bad thing happened proves nothing. For a side-effect that should NOT repeat (re-submit on back, re-charge, duplicate order, resend OTP), assert the **count is unchanged** (`User see [Records] table with {{one}}` / `row with {{count}}`); if it's not UI-observable, mark `@manual` with a request-count oracle (shape below). This is general — it covers any side-effect, not a fixed verb list.
-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 |
@@ -400,7 +376,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**: 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.
+**Naming**: `VP-<CATEGORY>-<NNN>`. Scenario name must use the **same element type** as the steps.
 
 **Test data** — grouped by section, loaded at runtime: