@sun-asterisk/sungen 3.2.20-beta.1 → 3.2.20-beta.2

package/src/harness/flow-plan.ts

@@ -71,6 +71,9 @@ export interface FlowPlan {
   legs: LegPlan[];
   byReason: Record<string, number>;
   capabilityManual: number;
+  /** @manual whose reason is "cross-screen → automate via flow" (class XS) — inside a flow this
+   *  usually means the scenario should simply BE automated here. (#569) */
+  crossScreenManual: number;
   judgmentManual: number;
   contracts: Contract[];
   readiness: 'ready' | 'not-ready';
@@ -87,14 +90,18 @@ export function buildFlowPlan(cwd: string, flow: string): FlowPlan {
   // Legs = distinct screen namespaces.
   const legMap = new Map<string, { scenarios: Set<string>; refs: Set<string>; automated: boolean }>();
   const byReason: Record<string, number> = {};
-  let capabilityManual = 0, judgmentManual = 0;
+  let capabilityManual = 0, judgmentManual = 0, crossScreenManual = 0;
 
   for (const sc of scenarios) {
     if (sc.manual) {
       const { code } = inferReasonCode(sc.tags, sc.reason);
       byReason[code] = (byReason[code] || 0) + 1;
       const cls = MANUAL_REASONS[code]?.cls;
-      if (cls === 'capability') capabilityManual++; else if (cls === 'keep') judgmentManual++;
+      // XS ("cross-screen → automate via flow") is a THIRD class; it used to be silently
+      // dropped from both counters, understating the plan's manual load. (#569)
+      if (cls === 'capability') capabilityManual++;
+      else if (cls === 'keep') judgmentManual++;
+      else if (cls === 'flow') crossScreenManual++;
     }
     for (const r of sc.refs) {
       const leg = r.screen.toLowerCase();
@@ -133,5 +140,5 @@ export function buildFlowPlan(cwd: string, flow: string): FlowPlan {
   }
   if (readiness === 'ready') plan.unshift('Selectors present for every automated leg — ready to compile + run.');
 
-  return { flow, total: scenarios.length, legs, byReason, capabilityManual, judgmentManual, contracts, readiness, missingLegs, plan };
+  return { flow, total: scenarios.length, legs, byReason, capabilityManual, judgmentManual, crossScreenManual, contracts, readiness, missingLegs, plan };
 }

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/orchestrator/templates/ai-src/commands/add-flow.md

@@ -86,15 +86,52 @@ 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)"
+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
+```
+
+**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 +224,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/skills/sungen-tc-generation/SKILL.md

@@ -605,22 +605,40 @@ error:
 
 > **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 +648,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:**