@sun-asterisk/sungen 3.2.21 → 3.2.22-beta.1

package/src/harness/parse.ts

@@ -38,6 +38,8 @@ export interface ScenarioInfo {
   requiresCaps?: string[];    // @requires:<cap> — automation-ready but needs an opt-in driver (TQ-11)
   deferredToFlow?: boolean;   // @deferred:flow — owned by a flow, not automated on this screen (H6)
   ownedByFlow?: string;       // @owned-by:<flow> — the flow that owns this deferred scenario (H6)
+  /** Ordered steps with their resolved bucket (And/But inherit) — flow handoff analysis (#569). */
+  steps?: Array<{ bucket: 'given' | 'when' | 'then'; text: string }>;
 }
 
 /** Format-tolerant: is this token an ID (project's scheme), not a prose word?
@@ -91,6 +93,29 @@ export function parseViewpointOverview(filePath: string): ViewpointEntry[] {
     }
   }
 
+  // 1b) Flow-style declarations (#569). Flow viewpoint files commonly declare per-item
+  // ids at the END of a bullet ("… → **FL-HP-001**") under phase section headers
+  // ("## FL-HP — Happy Path"). Neither matched the table/group passes, so every flow
+  // audit collapsed to taxonomy=0% / traceability n-a — scenarios correctly tagged
+  // FL-HP-001 were reported as unmapped. Both forms are additive here.
+  for (const raw of lines) {
+    const line = raw.trim();
+    const section = line.match(/^##\s+([A-Z]{2,}(?:-[A-Z0-9]{2,})*)\s+[—–-]\s*(.*)$/);
+    if (section && isViewpointId(section[1] + '-0')) {
+      const id = section[1].toUpperCase();
+      if (!entries.has(id)) entries.set(id, { id, priority: 'Unknown', reason: section[2] ?? '' });
+    }
+    if (/^[-*+]\s/.test(line)) {
+      const arrow = line.match(/(?:→|->)\s*\*{0,2}([A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-\d+[a-zA-Z]?)\*{0,2}\s*$/);
+      if (arrow) {
+        const id = arrow[1].toUpperCase();
+        if (!entries.has(id)) {
+          entries.set(id, { id, priority: 'Unknown', reason: line.replace(/\s*(?:→|->).*$/, '').replace(/^[-*+]\s+/, '') });
+        }
+      }
+    }
+  }
+
   // 2) Viewpoint Grouping: ### Required / ### Recommended / ### Optional → bullet list
   let group: ViewpointEntry['group'] | undefined;
   for (const raw of lines) {
@@ -144,7 +169,9 @@ function classifyScenario(sc: ParsedScenario): ScenarioInfo {
   // Category is everything between `VP-` and the final `-<sequence>` — INCLUDING hyphens, so
   // compound categories (VP-LIST-DISPLAY-01, VP-ADD-TO-CART-03, VP-PRODUCT-DISCOVERY-02) parse,
   // not just single-word ones. A single-word category (VP-CART-001) still works. (H1)
-  const codeMatch = sc.name.match(/\bVP-([A-Z]+(?:-[A-Z]+)*)-\d+/i);
+  // Flows use journey-phase ids (FL-HP-001 / FL-ER-002) — the VP- anchor rejected them, so every
+  // flow scenario had NO category and the whole suite bucketed `other` (taxonomy=0%, #569).
+  const codeMatch = sc.name.match(/\b(?:VP|FL)-([A-Z]+(?:-[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).
@@ -158,12 +185,14 @@ function classifyScenario(sc: ParsedScenario): ScenarioInfo {
   const skeletonParts: string[] = [];
   const textParts: string[] = [sc.name];
   const stepTextParts: string[] = [];
+  const orderedSteps: Array<{ bucket: 'given' | 'when' | 'then'; text: string }> = [];
 
   for (const step of sc.steps as ParsedStep[]) {
     const kw = step.keyword.trim();
     if (kw === 'Given' || kw === 'When' || kw === 'Then') last = kw;
     textParts.push(step.text);
     stepTextParts.push(step.text);
+    orderedSteps.push({ bucket: (kw === 'And' || kw === 'But' ? last : kw).toLowerCase() as 'given' | 'when' | 'then', text: step.text });
     // normalized skeleton: keep [refs] (distinct targets = distinct tests),
     // but neutralize {{vars}} and quoted values so EP/data families collapse.
     const skel = step.text
@@ -199,6 +228,7 @@ function classifyScenario(sc: ParsedScenario): ScenarioInfo {
     stepSkeleton: skeletonParts.join(' | '),
     haystack: textParts.join(' ').toLowerCase(),
     stepsText: stepTextParts.join(' ').toLowerCase(),
+    steps: orderedSteps,
     vpId,
     casesDataset,
     queryRefs: queryRefs.size ? [...queryRefs] : undefined,

package/src/harness/perf.ts

@@ -0,0 +1,112 @@
+/**
+ * Performance budgets — config + percentile math + the per-unit verdict. (#569)
+ *
+ * A flow's regression value includes "still fast enough": after a lib/framework
+ * upgrade the main journeys must not only pass but hold their response-time
+ * budget. Sungen had no perf concept at all — the Playwright JSON parser even
+ * dropped the `duration` field Playwright already emits on every result.
+ *
+ * Scope discipline:
+ *   - This is config + measurement + report over runs sungen already makes.
+ *     Real load tests stay @manual:M8 → a dedicated tool.
+ *   - The AUDIT never reads it: the quality score is documented as a pure
+ *     function of the design artifacts ("reads no test-results, live page, or
+ *     clock"). Perf reports where runs are already read — `sungen delivery`
+ *     and the dashboard. Advisory: a blown budget never fails the design gate.
+ *
+ * Config: qa/perf.yaml
+ *   percentile: p75          # default p75 — "≥75% of runs meet the budget"
+ *   defaults:
+ *     scenario_ms: 30000     # whole-scenario wall clock (Playwright duration)
+ *     page_load_ms: 3000     # Phase B — needs per-transition runtime timing
+ *     transition_ms: 2000    # Phase B
+ *   units:
+ *     place-order: { scenario_ms: 20000 }
+ */
+import * as fs from 'fs';
+import * as path from 'path';
+import { parse as parseYaml } from 'yaml';
+import { readTextFile } from './read-text';
+
+export interface PerfConfig {
+  /** 0..100 — e.g. 75 for p75. */
+  percentile: number;
+  defaults: Record<string, number>;
+  units: Record<string, Record<string, number>>;
+}
+
+export interface PerfVerdict {
+  unit: string;
+  metric: string;            // 'scenario_ms' today; page_load_ms/transition_ms in Phase B
+  percentile: number;        // 75
+  budgetMs: number;
+  measuredMs: number;        // the pXX of the observed durations
+  samples: number;
+  pass: boolean;
+  /** Titles of the slowest offenders (only when failing), for the report. */
+  slowest: Array<{ title: string; ms: number }>;
+}
+
+export function perfConfigPath(projectRoot: string): string {
+  return path.join(projectRoot, 'qa', 'perf.yaml');
+}
+
+/** Absent file → null (perf reporting is opt-in; nothing changes until configured). */
+export function loadPerfConfig(projectRoot: string): PerfConfig | null {
+  const p = perfConfigPath(projectRoot);
+  if (!fs.existsSync(p)) return null;
+  let raw: Record<string, unknown>;
+  try { raw = parseYaml(readTextFile(p)) as Record<string, unknown>; } catch { return null; }
+  if (!raw || typeof raw !== 'object') return null;
+  const pctRaw = String(raw.percentile ?? 'p75').toLowerCase().replace(/^p/, '');
+  const percentile = Math.min(100, Math.max(1, Number(pctRaw) || 75));
+  const num = (o: unknown): Record<string, number> => {
+    const out: Record<string, number> = {};
+    if (o && typeof o === 'object') {
+      for (const [k, v] of Object.entries(o as Record<string, unknown>)) {
+        const n = Number(v);
+        if (Number.isFinite(n) && n > 0) out[k] = n;
+      }
+    }
+    return out;
+  };
+  const units: Record<string, Record<string, number>> = {};
+  if (raw.units && typeof raw.units === 'object') {
+    for (const [u, o] of Object.entries(raw.units as Record<string, unknown>)) units[u] = num(o);
+  }
+  return { percentile, defaults: num(raw.defaults), units };
+}
+
+/**
+ * Nearest-rank percentile (ceil), the standard "≥pXX of samples meet the budget"
+ * reading: p75 of [a…] is the value at ceil(0.75·n) in the sorted list. One
+ * sample → that sample. Deterministic, no interpolation.
+ */
+export function percentileOf(p: number, values: number[]): number {
+  if (values.length === 0) return 0;
+  const sorted = [...values].sort((a, b) => a - b);
+  const rank = Math.min(sorted.length, Math.max(1, Math.ceil((p / 100) * sorted.length)));
+  return sorted[rank - 1];
+}
+
+/** Budget for a metric on a unit: per-unit override, else defaults, else none. */
+export function budgetFor(config: PerfConfig, unit: string, metric: string): number | undefined {
+  return config.units[unit]?.[metric] ?? config.defaults[metric];
+}
+
+/**
+ * The scenario_ms verdict for one unit's run. `durations` = per-test wall-clock ms
+ * (a @cases scenario contributes one sample per row-test — each is a real run).
+ */
+export function perfVerdict(
+  config: PerfConfig,
+  unit: string,
+  samples: Array<{ title: string; ms: number }>,
+): PerfVerdict | null {
+  const budgetMs = budgetFor(config, unit, 'scenario_ms');
+  if (budgetMs === undefined || samples.length === 0) return null;
+  const measuredMs = percentileOf(config.percentile, samples.map((s) => s.ms));
+  const pass = measuredMs <= budgetMs;
+  const slowest = pass ? [] : [...samples].sort((a, b) => b.ms - a.ms).slice(0, 3);
+  return { unit, metric: 'scenario_ms', percentile: config.percentile, budgetMs, measuredMs, samples: samples.length, pass, slowest };
+}

package/src/harness/sensors.ts

@@ -33,10 +33,22 @@ const BUCKET_ORDER: Array<[string, string[]]> = [
 ];
 const BUCKETS: Record<string, string[]> = Object.fromEntries(BUCKET_ORDER);
 
+// Flow journey-phase categories (FL-HP-001, FL-ER-002 …). Matched on exact SEGMENTS,
+// never by containment — 'SHOP'.includes('HP') is true, which is exactly the kind of
+// false hit substring matching would produce for two-letter phase tokens. (#569)
+const PHASE_BUCKETS: Record<string, string> = {
+  HP: 'business-core',          // happy path = the business goal itself
+  ER: 'validation-security',    // error recovery (validation must not trap the journey)
+  EH: 'validation-security',    // guards & leakage (direct access, back, refresh)
+};
+
 /** Classify a VP category into a balance bucket by keyword containment + precedence (H1). */
 export function bucketForCategory(category: string | undefined): string {
   const cat = (category || '').toUpperCase();
   if (!cat) return 'other';
+  for (const seg of cat.split('-')) {
+    if (PHASE_BUCKETS[seg]) return PHASE_BUCKETS[seg];
+  }
   for (const [bucket, kws] of BUCKET_ORDER) {
     if (kws.some((k) => cat.includes(k))) return bucket;
   }
@@ -351,7 +363,7 @@ export function flowRegressionDepth(scenarios: ScenarioInfo[]): FlowDepthResult
   // 1. Count/quantity proof — a row count or item quantity, not just presence of a row.
   const countProof = any(/\b(quantity|qty|two (?:rows|lines|cart)|row count|count column|number of items|one[_ ]row|two[_ ]rows|qty[_ ])/i);
   // 2. Teardown — removes the item and verifies the empty/zero state (the inverse operation).
-  const teardown = any(/\b(remove|delete|clear)\b/i) && any(/\b(empty|no items|zero|removed|0 items)\b/i);
+  const teardown = any(/\b(remove|delete|clear)(?:s|d|ed|ing)?\b/i) && any(/\b(empty|emptied|no items|zero|removed|cleared|0 items)\b/i);
   // 3. Multi-source — the cart is fed from >1 source (the main list AND a recommended/related rail).
   const multiSource = any(/\b(recommended|related|you may also|suggest)\b/i) && addsToCart;
 

package/src/harness/spec-coverage.ts

@@ -66,21 +66,43 @@ export function parseSpecClauses(specPath: string): { frs: FrClause[]; valRows:
   if (!fs.existsSync(specPath)) return { frs: [], valRows: [] };
   const lines = readTextFile(specPath).split('\n');
 
+  // Requirement ids follow the PROJECT's scheme, not ours (#572): `**FR-1**:` is one
+  // convention among many — a real spec declared ~30 MUST clauses as `` `REQ-SRCH-001`: ``
+  // and the FR-locked pattern returned zero, so the MUST-coverage gate never ran and the
+  // specFR axis was excluded "for lack of evidence" that was sitting right there. Same
+  // silent-failure class as the CRLF parsers, same id-scheme-tolerance lesson as delivery.
+  //
+  // A declaration is: line-leading (optionally bulleted / bold / backticked) `<ID>:` where
+  // the id ends in a number. Table rows are EXCLUDED — traceability tables cite requirement
+  // ids without declaring them — and so are prefixes that are never requirements
+  // (test cases, viewpoints, known-defect records, data-factory checks, flows, delivery items).
+  const NON_REQUIREMENT_PREFIX = /^(TC|VP|KD|CHK|FL|DI)-/i;
   const frs: FrClause[] = [];
+  const seen = new Set<string>();
   for (const line of lines) {
-    const m = line.match(/\*\*FR-(\d+)\*\*\s*:\s*(.+)$/);
-    if (m) frs.push({ id: `FR-${m[1]}`, text: m[2].replace(/\*\*/g, '').trim(), modality: modalityOf(m[2]) });
+    if (/^\s*\|/.test(line)) continue;   // table row = citation, not declaration
+    const m = line.match(/^\s*(?:[-*+]\s+)?[*_`]*([A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-\d+[a-zA-Z]?)[*_`]*\s*:\s*(.+)$/);
+    if (!m || NON_REQUIREMENT_PREFIX.test(m[1])) continue;
+    const id = m[1].toUpperCase();
+    if (seen.has(id)) continue;          // first declaration wins
+    seen.add(id);
+    frs.push({ id, text: m[2].replace(/\*\*/g, '').trim(), modality: modalityOf(m[2]) });
   }
 
   // Validation Rules table: a row carries a Constraint, a Trigger cell, and (often) a code.
+  // A "Trigger" column alone is NOT enough to claim the table (#578): a screen-STATES table
+  // ("State ID | Trigger | URL/heading oracle | …") uses Trigger for the user action that
+  // enters the state, and reading it as validation rows invented three gate-relevant
+  // TRIGGER-UNCOVERED gaps on a real spec. The table must also name a Constraint/Rule/
+  // Validation column — the thing a validation row is ABOUT.
   const valRows: ValRow[] = [];
   let cTrigger = -1, cConstraint = -1, cCode = -1, inTable = false;
   for (const raw of lines) {
     const line = raw.trim();
-    if (line.startsWith('|') && /\btrigger\b/i.test(line) && cTrigger < 0) {
+    if (line.startsWith('|') && /\btrigger\b/i.test(line) && /\b(constraint|rule|validation)\b/i.test(line) && cTrigger < 0) {
       const cells = line.split('|').map((c) => c.trim());
       cTrigger = cells.findIndex((c) => /^trigger$/i.test(c));
-      cConstraint = cells.findIndex((c) => /constraint/i.test(c));
+      cConstraint = cells.findIndex((c) => /constraint|rule|validation/i.test(c));
       cCode = cells.findIndex((c) => /code/i.test(c));
       inTable = cTrigger >= 0;
       continue;
@@ -104,12 +126,40 @@ function scenarioBlocks(featureText: string): string[] {
   return featureText.split(/\n\s*\n/).filter((b) => /\bScenario:/.test(b)).map((b) => b.toLowerCase());
 }
 
+/**
+ * Requirement ids CITED anywhere in the feature (tags, comments, prose) — with the
+ * compressed notations authors naturally write expanded (#578 follow-up, 3rd recurrence):
+ * `REQ-CART-001..005` (range), `REQ-QTY-001/003` (enumeration). A plain substring check
+ * missed exactly the ids inside the shorthand, so a deferral comment that HONESTLY listed
+ * its flow-owned requirements still left them reported as uncovered.
+ */
+export function citedIds(featureText: string): Set<string> {
+  const t = featureText.toUpperCase();
+  const out = new Set<string>();
+  for (const m of t.matchAll(/\b([A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-\d+[A-Z]?)\b/g)) out.add(m[1]);
+  // Range: PREFIX-001..005 (also – — ~ as the dash). Width follows the FIRST number.
+  for (const m of t.matchAll(/\b([A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-)(\d+)\s*(?:\.\.|–|—|~)\s*(\d+)/g)) {
+    const w = m[2].length;
+    for (let i = parseInt(m[2], 10); i <= parseInt(m[3], 10) && i - parseInt(m[2], 10) < 200; i++) {
+      out.add(m[1] + String(i).padStart(w, '0'));
+    }
+  }
+  // Enumeration: PREFIX-001/003/007 — every slash part is an id under the same prefix.
+  for (const m of t.matchAll(/\b([A-Z][A-Z0-9]*(?:-[A-Z0-9]+)*-)(\d+)((?:\/\d+)+)/g)) {
+    const w = m[2].length;
+    out.add(m[1] + m[2]);
+    for (const part of m[3].split('/').filter(Boolean)) out.add(m[1] + part.padStart(w, '0'));
+  }
+  return out;
+}
+
 export function specCoverage(specPath: string, scenarios: ScenarioInfo[], featureText: string): SpecCoverageResult {
   const { frs, valRows } = parseSpecClauses(specPath);
   if (!fs.existsSync(specPath) || (frs.length === 0 && valRows.length === 0)) {
     return { hasSpec: fs.existsSync(specPath), frTotal: 0, frCovered: 0, uncoveredMust: [], inferredOnly: [], triggerGaps: [], verdict: 'pass' };
   }
   const featLower = featureText.toLowerCase();
+  const cites = citedIds(featureText);
 
   // FR coverage: explicit @spec:FR / literal FR-id citation, else keyword fallback.
   const uncoveredMust: { id: string; text: string }[] = [];
@@ -117,7 +167,7 @@ export function specCoverage(specPath: string, scenarios: ScenarioInfo[], featur
   let frCovered = 0;
   for (const fr of frs) {
     const idLower = fr.id.toLowerCase();
-    const cited = featLower.includes(idLower);
+    const cited = featLower.includes(idLower) || cites.has(fr.id.toUpperCase());
     const words = [...new Set((fr.text.toLowerCase().match(/[a-z][a-z-]{4,}/g) || []))]
       .filter((w) => !/must|should|system|screen|users?|value|input|field/.test(w));
     const kwHit = words.length > 0 && scenarios.some((s) => words.filter((w) => s.haystack.includes(w)).length >= Math.min(2, words.length));

package/src/orchestrator/templates/ai-src/commands/add-flow.md

@@ -86,15 +86,62 @@ qa/flows/${input:flow}/
     └── ui/                        # Screenshots, mockups
 ```
 
-### 1a. Identify the screens in the flow
+### 1a. Define the flow's BOUNDARY, then its screens
 
-Ask the user: "Which screens does this flow visit, in order? (e.g., login → dashboard → award-form → confirmation)"
+> QA teams often call this level **System Test** — same thing: one fully-integrated business
+> journey verified against the spec. Use whichever name the team knows; the boundary rules
+> below are the ISTQB system-test design rules.
+
+
+A flow is the **smallest complete business action chain**: one clear trigger ending in ONE
+observable, valuable outcome. Before asking for screens, walk this checklist with the user —
+if 1, 3 or 8 fails, propose SPLITTING into separate flows:
+
+1. Exactly **one business goal**? (cart correctness + category filtering = two flows)
+2. A clear **trigger** and precondition?
+3. **One observable final outcome**? (a final assertion you can write in one sentence)
+4. Is that outcome **valuable to the actor**? (an order placed, a password reset — not "a page rendered")
+5. Is **every step necessary** for that outcome?
+6. Are all steps at the **same business abstraction**?
+7. Are optional/error branches **phases of this goal** (ER/EH), not new goals?
+8. Does **no segment** form an independently valuable flow on its own?
+9. Can you write **a single clear final assertion**?
+10. Can you name it "**Verb + outcome**"? (`place-order`, `reset-password` — not `cart-and-filter`)
+
+Then ask: "Which screens does this flow visit, in order? (e.g., login → dashboard → award-form → confirmation)"
 
 Record the screen list — you will need it for:
 - Filling `spec.md` (Step 3)
 - Suggesting `[Screen:Element]` namespace prefixes
 - Capturing visuals per screen (Step 2)
 
+### 1b. Author the Flow Contract (`requirements/flow-contract.yaml`)
+
+Write the answers down as the flow's contract — `sungen audit` scores the flow **against it**
+(the `flowCoverage` axis: HP/ER/EH journey phases; `FLOW-OUTCOME-UNPROVEN` when no automated
+scenario asserts data on the outcome screen; `FLOW-SCOPE-CREEP` when scenarios never touch it):
+
+```yaml
+goal: "Place an order for a product added from home"   # Verb + outcome
+actor: user
+trigger: "Add a product to the cart from the home featured list"
+precondition: "A registered account; an empty cart"
+outcome:
+  screen: checkout            # the [Screen:...] namespace carrying the final proof
+  assertion: "The confirmation shows the order number and the paid total"
+value: "The customer has paid; the shop has a new order"
+phases: [HP, ER, EH]          # journey phases (default); add UI only if the flow owns UI states
+stateful: cart                # the mutated collection, if any — enables regression-depth dims
+golden: true                  # optional — release-critical: Final Inspection expects @golden scenarios here
+external:                     # optional — legs owned by another team/vendor (System INTEGRATION Testing)
+  - name: payment-gateway
+    owner: vendor-x
+    screens: [payment]        # the flow namespaces that leg passes through
+```
+
+**A filled contract is an INPUT to generation — never an output.** Like `test-viewpoint.md`,
+generation must not rewrite it to match what was generated; disagree → propose the diff and ask.
+
 ### 2. Capture visual source
 
 **Mobile path** (`platform: mobile`):
@@ -187,7 +234,8 @@ If user picks `/sungen:create-test`, **you MUST use the Skill tool** to invoke i
 - Test data namespaced by phase: `login.email`, `submission.nominee`
 - `@flow` tag required at feature level
 - `Background:` should only contain the starting navigation — the URL path (web) or the `--reach` nav recipe (mobile)
-- Each scenario = one phase of the journey
+- Each scenario = one phase of the journey; ids are `FL-<PHASE>-NNN` (`HP`/`ER`/`EH`, optional `UI`)
+- One flow = ONE business goal with ONE observable outcome (`requirements/flow-contract.yaml`) — a segment with its own value is its own flow
 {{#cap parallel-subagents}}
 - Mobile flows are tagged `@platform:mobile` and run via `/sungen:run-test <flow>` (WebdriverIO, not Playwright)
 {{/cap}}

package/src/orchestrator/templates/ai-src/commands/create-test.md

@@ -6,6 +6,16 @@ order: 20
 claude-tools: "Read, Grep, Bash, Glob, Write, AskUserQuestion, Skill, mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, mcp__playwright__browser_take_screenshot"
 copilot-tools: "[vscode, execute, read, agent, edit, search, web, browser, todo, 'playwright/*']"
 codex-trigger: "Run when the user asks to CREATE, generate, write, or author test cases / a .feature file for a screen or flow. Step 2 (after add-screen/add-flow, before run-test). Do NOT use for executing, running, or compiling existing tests."
+---
+## ⛔ HARD RULE — the run's LAST action is the next-step hand-back
+
+A create-test run is NOT finished when the files are written or the audit prints. The final
+action of EVERY run — success, partial, or aborted — is the next-step hand-back
+({{#cap parallel-subagents}}an `AskUserQuestion` offering the next actions{{/cap}}{{^cap parallel-subagents}}a numbered list of next-action choices{{/cap}};
+see "Finish — always hand the next step back" at the end of this file). Ending with a prose
+summary and no choices is a broken run: the operator is left guessing. This holds no matter
+how long the generation/repair loop ran.
+
 ---
 {{#cap parallel-subagents}}
 ## ⛔ HARD RULE — No Figma MCP when PAT data exists

package/src/orchestrator/templates/ai-src/commands/run-test.md

@@ -7,6 +7,29 @@ claude-tools: "Read, Grep, Bash, Glob, Edit, Write, AskUserQuestion, mcp__playwr
 copilot-tools: "[read, execute, edit, vscode/askQuestions, playwright/*, appium/*]"
 codex-trigger: "Run when the user asks to RUN, execute, or compile tests, generate selectors.yaml, or run tests. Step 4. Do NOT use for authoring/creating new test cases."
 ---
+## ⛔ HARD RULE — the transition INTO this run is a tool call, never prose
+
+A QA field report: the user picked "Run test" from create-test's hand-back, and the session
+answered with a BRIEFING — missing selector, expected reds, "run under Node 22" — written as
+"Before you do…", then stopped. Correct facts, wrong role: those are conditions YOU handle
+inside the run, not reasons to stop and hand the work back.
+
+- The first thing this command produces is a **tool call** (platform detection, preflight,
+  compile — whatever comes first). Never open with a plan and end the turn.
+- A **missing selector** goes to the selector-generation/fix step — that is what this command
+  is FOR.
+- **Expected-red scenarios** (@known-defect asserting a live defect) stay red; note them in
+  the results summary, never "fix" them and never stop for them.
+- **Runtime selection is yours**: check `node -v` first. If the major version is ≥ 23 and
+  Playwright browser runs are known-broken on it, select Node 22 yourself when available —
+  `export PATH="$HOME/.nvm/versions/node/$(ls $HOME/.nvm/versions/node | grep '^v22' | tail -1)/bin:$PATH"`
+  — and say so in one line. Only if NO compatible Node exists do you stop, with the exact
+  install command as the hand-back.
+- Ending this run follows the same law as create-test: the LAST action is the next-step
+  hand-back (the AskUserQuestion in "After showing results"), no matter how the run went.
+
+---
+
 ## Role
 
 You are a **Senior Developer**.

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

@@ -603,24 +603,67 @@ error:
 
 ## Flow Test Generation
 
+> **Terminology**: many QA teams call this level **System Test** (ISTQB: verify the fully
+> integrated system against its specified requirements, designed around business
+> processes/use cases). In sungen a *flow* is that system-test suite run through the real UI;
+> its automation then serves as the regression suite on later runs. The names are
+> interchangeable in conversation; the artifacts stay `qa/flows/<name>/`.
+
+**Representative, not exhaustive (ISTQB system-test design rule).** A flow case takes ONE
+representative input per branch — one valid value for the main flow, one error value that
+triggers the exception branch and proves the journey recovers. The full equivalence/boundary
+matrix belongs to the OWNING SCREEN (as `@cases` there), never re-run inside the flow: if the
+screen already proved "the field rejects negatives", the flow only proves "the journey survives
+one rejected input". `sungen audit` reports `FLOW-EXHAUSTIVE-INPUTS` when ≥3 same-shape flow
+scenarios differ only in data. **Mocked dependencies**: a flow scenario using `@mock` is
+delivered as *Pass (Mocked)* — verified handling logic, not the real dependency; the delivery's
+External Dependency Tracking table lists it until re-verified real.
+
+**Release selection & external legs**: when the contract declares `golden: true`, tag the
+happy-path scenario(s) that prove the outcome with **`@golden`** — that is the set
+`sungen inspect` (Final Inspection, Go/No-Go) runs before a release; `GOLDEN-MISSING` fires
+until it exists, and a @golden scenario that passes only against mocks BLOCKS the release.
+When the contract declares `external:` legs (another team/vendor's system), scenarios touching
+those namespaces are the **System INTEGRATION** group — keep their oracles about the boundary
+(contract/format/handoff), and expect `SIT-MOCK-ONLY` until they are re-verified real.
+
+
 > **Auto-detect**: if path is `qa/flows/<name>/` → use this section. Skip Steps 1–4 above.
 
+**Read `requirements/flow-contract.yaml` FIRST — it is the flow's boundary and the yardstick
+`sungen audit` scores the flow against** (`flowCoverage` axis = journey phases HP/ER/EH automated;
+`FLOW-OUTCOME-UNPROVEN`; `FLOW-SCOPE-CREEP`). No contract yet → author it with the user via the
+boundary checklist in `add-flow` (one business goal · clear trigger · ONE observable outcome
+valuable to the actor · name = "Verb + outcome"), THEN generate. **A filled contract is an INPUT —
+never rewrite it to match your output** (same rule as `test-viewpoint.md`).
+
 | Aspect | Screen | Flow |
 |---|---|---|
-| Section focus | UI patterns per section | Journey phases across screens |
+| Section focus | UI patterns per section | Journey phases toward ONE declared outcome |
 | Selector format | `[Element]` | `[Screen:Element]` (namespaced) |
 | Test data keys | `{{variable}}` | `{{phase.variable}}` |
 | Feature tag | `@auto` / `@smoke` etc. | `@flow` (required) |
-| Viewpoints | VP-UI/VAL/LOGIC/SEC per section | VP-LOGIC (transitions), VP-SEC (auth persistence), VP-VAL (cross-screen data) |
+| Scenario ids | `VP-<CATEGORY>-NNN` | `FL-<PHASE>-NNN` — phases: `HP` (happy path), `ER` (error recovery), `EH` (guards), `UI` (journey UI states, optional) |
 
-**Scenarios to generate:**
+**Scenarios to generate — every phase demanded by the contract, automated:**
 
-| Category | What to test |
-|---|---|
-| Happy path | Complete flow end-to-end with valid data |
-| Auth persistence | Auth state maintained across screen transitions |
-| Error recovery | Invalid input mid-flow → fix → continue |
-| Cross-screen data | Data entered on screen A visible on screen B |
+| Phase | What to test | Scoring |
+|---|---|---|
+| `FL-HP` happy path | The complete journey ending in the contract's `outcome.assertion` — an AUTOMATED **data** assertion on `outcome.screen` (an order number, a summed total — not just "page visible"). This scenario is WHY the flow exists: it is the regression proof after a lib/framework upgrade. | uncovered → `flowCoverage` drops + `FLOW-OUTCOME-UNPROVEN` |
+| `FL-ER` error recovery | Invalid input mid-flow → error shown → fix → the journey still completes. Validation must not trap the journey. | uncovered → `flowCoverage` drops |
+| `FL-EH` guards | Direct URL access without the precondition · browser back · refresh · expired context — each ends in a safe observable state. | uncovered → `flowCoverage` drops |
+| Cross-screen handoff | After every screen transition, assert the CARRIED state on the new screen (the added product's name in the cart, the email echoed on the sent screen). | blind tails cap `businessDepth` (`FLOW-HANDOFF-SHALLOW`) |
+| Stateful regression (when `stateful:` declared) | Count/quantity proof · teardown (remove → empty) · multi-source add. | missing dims cap `businessDepth` (`FLOW-DEPTH`) |
+
+**Boundary discipline while generating:** every scenario must serve the contract's goal. A scenario
+that never touches `outcome.screen` and is not a guard (`EH`) or error-recovery (`ER`) belongs in a
+DIFFERENT flow — propose the split instead of writing it here (`FLOW-SCOPE-CREEP` will flag it).
+Auth persistence across transitions is part of `EH` unless the project declares it its own phase.
+
+**Manual in flows**: always `@manual:Mx` with the reason code — bare `@manual` is flagged
+(`MANUAL-CODE-MISSING`) because the capability planner cannot route it. Typical flow deferrals:
+inbox/mail oracle → `M5`, network-request count → `M3`, context expiry control → `M7`. A
+cross-screen scenario inside the flow's own goal is NOT manual — automate it here.
 
 ```gherkin
 @flow @auth:user
@@ -630,19 +673,20 @@ Feature: Award Submission Flow
     Given User is on [Login] page
 
   @high
-  Scenario: User logs in successfully
+  Scenario: FL-HP-001 A signed-in user's nomination is submitted and confirmed
     When User fill [Login:Email] field with {{login.email}}
     And User fill [Login:Password] field with {{login.password}}
     And User click [Login:Submit] button
     Then User see [Dashboard] page
-
-  @high
-  Scenario: User submits nomination
     When User click [Dashboard:Awards] link
-    Then User see [Awards] page
-    When User fill [Awards:Nominee] field with {{submission.nominee}}
+    And User fill [Awards:Nominee] field with {{submission.nominee}}
     And User click [Awards:Submit] button
-    Then User see {{success_message}} message
+    Then User see [Awards:Success Message] text with {{success_message}}
+
+  @high
+  Scenario: FL-EH-001 Direct access to the award form without login redirects to login
+    When User go to [Awards] page
+    Then User see [Login] page
 ```
 
 ```yaml

package/src/orchestrator/templates/qa-context.md

@@ -45,8 +45,21 @@ Example:
 
 ## Testing Strategy
 
+Machine-readable intent — `sungen audit` reads these keys (Intent Profile). Values here are
+live even when the surrounding text changes; an invalid value silently falls back to the default.
+
+focus: functional
+<!-- focus: functional | e-commerce | security | smoke — drives the audit's depth threshold -->
+
+risk_tier: normal
+<!-- risk_tier: high | normal | low -->
+
+To silence driver suggestions in audit findings, add a line: capability_suggestions with value off.
+
 **Focus areas** — what to cover thoroughly:
-<!-- List from: functional, security, ui, accessibility, performance -->
+<!-- Prose for humans; the parseable value is the `focus:` key above.
+     Response-time budgets are NOT a focus value — declare them in qa/perf.yaml
+     (percentile + scenario_ms budgets; reported by `sungen delivery`). -->
 <!-- Example: functional, security -->
 
 **Mandatory coverage:**