@sun-asterisk/sungen 3.2.25 → 3.2.26

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

@@ -718,7 +718,7 @@ flows:
     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."
+    reason: "The guard lives in SCREEN_A_001's spec, which this project does not hold."
 ```
 
 Four statuses, and **silence is not one of them**: `covered` · `deferred` · `pending-clarification`
@@ -728,6 +728,36 @@ missing flow. `sungen audit` then measures `flowCoverage` per DECLARED FLOW and
 `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`.
 
+**Enumerate every branch the spec declares — do not rely on reading carefully.** Before writing
+scenarios, list each mutually-exclusive branch the spec makes explicit, one line per arm:
+
+- every `### Exception Flow X` / `### Alternative Flow X` heading;
+- every row of a decision table (`DEC-*`, `BR-*`, any table of conditions → outcomes);
+- every arm of an if/elif/else cascade in pseudocode;
+- every state transition a state machine declares.
+
+Each arm needs its OWN scenario, or a written exclusion. **Covering a sibling arm proves nothing
+about this one** — and two scenarios that assert the same thing under different names are one test
+counted twice, which is worse than a gap because the coverage sheet reports it as two.
+`sungen audit` reports `SPEC-BRANCH-UNCOVERED` and `BRANCH-OVERCLAIMED`. This rule existed as
+prose before and was missed three times in three flows; it is enumerated now for that reason.
+
+**Two viewpoints per UI region, not one.** A region that has both conditional rendering (`DEC-*`)
+and an acceptance scenario describing a click needs a case for EACH: "render — DEC-xxx" and
+"interaction — click → destination". Finishing the render half is the easy half, and stopping there
+is the common failure. Every navigation target the spec names needs a click-through case
+(`NAV-TARGET-ABSENT`), even when this flow does not consume the destination — a context param
+handed to another screen is that screen's input, and the handoff is where it goes wrong.
+
+**A deny case needs its allow case.** "permission denied → content hidden" passes just as happily
+when the content is hidden for everyone. Pair it with "permission granted → content shown", the
+way a boundary needs `min-1 / min / max / max+1` (`PERMISSION-PAIR-MISSING`).
+
+**State that ARRIVES with the data is a different case from state the test creates.** A
+discriminator field you can only observe at load (an item already favourited before the page
+opens) is a different oracle timing from the same field set by an action inside the test. Both are
+needed; the first is usually `@manual:M1` or a data-factory fixture.
+
 **One id per atomic CLAIM in the viewpoint.** The flow id groups; the viewpoint id identifies.
 Writing `FL-BF-001` on four different claims makes the ledger count four items while traceability
 sees one, so the coverage arithmetic and "which test proves this?" are both wrong and neither