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

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

@@ -690,6 +690,42 @@ core, AF→behaviour, EF→validation/security) and traces them to the viewpoint
 `FL-EF` priority rows. Declare `phases: [BF, AF, EF]` in the contract; the FIRST phase is the
 Basic Flow and is the one that must reach `outcome`.
 
+**Declare the flow INVENTORY, not just the phases.** `phases: [BF, AF, EF]` says which
+vocabulary the suite uses; it cannot say how many flows the use case has — a phase counts as
+covered the moment ONE scenario carries it, so a fifteen-flow use case with three scenarios
+reported full phase coverage while a reviewer counting flows read it as a third done. List every
+flow in the contract, and give each one a status:
+
+```yaml
+flows:
+  - id: BF
+    outcome: "The successGuarantee — verified, recorded, signed in"
+    status: covered
+  - id: AF02
+    branchFrom: "BF step 4, before submitting"
+    outcome: "Re-enters BF at step 4 with the buffer restored"
+    status: covered
+  - id: EF08
+    branchFrom: "BF step 1, the control tapped twice"
+    outcome: "One request, one record"
+    status: pending-clarification      # the spec is silent — ASK, never assume a guard
+    reason: "The guard lives in ST_AUTH_001's spec, which this project does not hold."
+```
+
+Four statuses, and **silence is not one of them**: `covered` · `deferred` · `pending-clarification`
+(the behaviour is not agreed yet, so no scenario can be right) · `out-of-scope` (another suite owns
+it). Anything but `covered` needs a `reason:` — a deferral nobody can audit is the same as a
+missing flow. `sungen audit` then measures `flowCoverage` per DECLARED FLOW and reports
+`FLOW-UNCOVERED` (declared, nobody wrote it), `FLOW-UNDECLARED` (a scenario claiming a flow id the
+inventory never declares), `FLOW-STATUS-UNREASONED` and `FLOW-INVENTORY-MISSING`.
+
+**One flow, one id — a viewpoint is not a flow.** Several scenarios may prove one flow: give them
+the same flow id and different sequence numbers (`VP-VAL-EF01-001`, `VP-VAL-EF01-002`), never a
+fresh flow id per assertion. Two shapes the audit reports as `FLOW-PHASE-MISFILED`: an `EF` that
+reaches the outcome with nothing failing (that is a success-path postcondition, so it belongs to
+the BF), and an `AF` with no branch point (it walks the basic path asserting extra content — also
+the BF's). Both inflate the flow count while adding no branch coverage.
+
 **Declare once, then declare only the differences.** Actor · Trigger · Goal · Precondition ·
 `successGuarantee` · `minimalGuarantee` are use-case-level: they live in `flow-contract.yaml`
 and are never repeated per flow. Each flow in `test-viewpoint.md` then states only three things: