@sun-asterisk/sungen 3.2.34-beta.1 → 3.3.0-alpha.1

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

@@ -7,22 +7,7 @@ claude-tools: "Read, Grep, Bash, Glob, Write, AskUserQuestion, Skill, mcp__playw
 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 run is NOT finished when its files are written or its output prints. The final action of EVERY
-run — success, partial, or aborted — is the next-step hand-back.
-
-**Ask `sungen next <unit>` rather than deciding from memory.** It derives the answer from what the
-project actually holds (artifacts on disk, the audit report, the accepted viewpoint baseline, the
-compiled spec, the run results), so the hand-back stays correct even when the run ended somewhere
-unexpected — a failed install, a driver that turned out not to support this unit kind, an aborted
-repair loop. Every `sungen` command also prints `Next: sungen next …` as its own last line.
-
-This matters most exactly where it used to break. A run that ended on a command with no footer of
-its own — `sungen capability add`, a dead-end install — left the session with nothing to follow and
-it stopped mid-workflow. If a step turns out to be impossible, that is still a hand-back: say what
-blocked it, run `sungen next <unit>`, and offer what remains. Ending with a prose summary and no
-choices is a broken run.
+<!-- include: hand-back-rule -->
 
 ---
 {{#cap parallel-subagents}}
@@ -64,8 +49,7 @@ restated from screen specs the project does not hold, say so: the audit reports
 `SPEC-RESTATED-UNVERIFIED` because `specFR 100%` over a hand-copied list certifies the copy, not
 the source.
 
-**A viewpoint you draft (mode 2, step 3) carries BOTH classification axes** — on a QA-written one
-(mode 1) a missing axis or guarantee line is a row in `viewpoint-review.md`, not an edit. `VP-LOGIC / VP-VAL / VP-SEC / VP-NAV` classify
+**The viewpoint carries BOTH classification axes.** `VP-LOGIC / VP-VAL / VP-SEC / VP-NAV` classify
 by TECHNICAL RISK; `BF / AF / EF` classify by BUSINESS BRANCH. They answer different questions and
 neither replaces the other — a reviewer needs to see both, so use the compound id
 (`VP-SEC-EF02-001`) and give the viewpoint a section per flow as well as its priority table by
@@ -82,8 +66,8 @@ questions and only one of them is a yardstick:
 | `flow-contract.yaml` | the USE CASE — actor · trigger · goal · precondition · both guarantees · the flow inventory | `flowCoverage` |
 | `test-viewpoint.md` | the CLAIMS the suite must prove — cross-screen concerns, edge cases, design decisions, open questions, priorities | `atomicLedger` · `traceability` |
 
-If `requirements/test-viewpoint.md` is missing or still the scaffold, **draft it before generating**
-(mode 2, step 3 — `add-flow` scaffolds the template; a run that deletes or replaces it has removed the yardstick). Without it two scored
+If `requirements/test-viewpoint.md` is missing, **write it before generating** (`add-flow` scaffolds
+a template; a run that deletes or replaces it has removed the yardstick). Without it two scored
 axes are excluded and four sensors cannot run at all — the atomic ledger, the
 declaration-integrity checks, the browser-gesture check and the two-way continuity check — so the
 audit reports `VIEWPOINT-MISSING` and the result is *unmeasured*, not passing. And the reason the
@@ -96,8 +80,8 @@ ordering choice: a yardstick derived from the scenarios reads 100% by constructi
 dropped along the way stops being missing from anything. `sungen audit` now reports
 `VIEWPOINT-ADOPTED-POST-HOC` on the first sighting of a viewpoint alongside an existing suite and
 holds `atomicLedger` + `traceability` as unverified until a human accepts it — so the honest move
-is to write the claims from `spec.md` and the contract, mark the file `drafted-by: ai` (its first
-line), and let the QA revise before `--accept-viewpoint`. **You never run `--accept-viewpoint` yourself** — `sungen next` lists it as a `⚖ decide` step for exactly this reason: an agent accepting the yardstick it wrote in the same session makes `atomicLedger` and `traceability` read 100% against its own checklist, and the Exception Flow it forgot stops being missing from anything. Present the acceptance to the QA in the hand-back (`AskUserQuestion`) with what the file declares — never as a question mid-run.
+is to write the claims from `spec.md` and the contract, mark plainly that they are a draft for QA
+review, and let the QA revise before `--accept-viewpoint`. **You never run `--accept-viewpoint` yourself** — `sungen next` lists it as a `⚖ decide` step for exactly this reason: an agent accepting the yardstick it wrote in the same session makes `atomicLedger` and `traceability` read 100% against its own checklist, and the Exception Flow it forgot stops being missing from anything. Present the acceptance to the QA (`AskUserQuestion`) with what the file declares, and stop.
 
 **When you give a claim an id, a scenario must carry that id.** The id is the contract: a claim
 whose id no scenario carries is reported MISSING, and word overlap will not rescue it. Several
@@ -111,12 +95,24 @@ narrow the claim to what is actually proven.
 
 **Priority comes from the declaration.** A scenario tagged `@high` under a viewpoint row that says
 `Low` is `PRIORITY-CONTRADICTED` — a smoke run selects on the tag, so it picks up work the QA
-deliberately deprioritised. Inherit the declared priority; if the tag is right, the declaration is
-what is wrong — fix it in your own draft (mode 2), or report it in `viewpoint-review.md` for the QA
-(mode 1). Never leave both on record silently.
+deliberately deprioritised. Inherit the declared priority; if the tag is right, fix the
+declaration instead of leaving both on record.
 
 ---
 
+## ⛔ HARD RULE — approvals and waivers are a human's, on a terminal
+
+`sungen contract approve`, `sungen journey --waive` and `sungen journey --decide` record a QA
+decision and ask for a typed confirmation on a real terminal (TTY). Never run them, never fake the
+terminal (`script`, `expect`, a pty wrapper), and never edit `contracts.lock.yaml` or
+`qa/**/decisions/` by hand. When one is due, show the exact command and stop for the human.
+
+**Hand-written free tests (`@free` / `@impl:code`).** When the unit has free tests with recorded
+traces, write their Gherkin with `sungen contract derive --screen <name>` — deterministic, it writes
+`features/<name>.free.feature` with every scenario tagged `@free @proposed`. Do not author those
+steps yourself; you may name the scenarios and suggest VP-ids. A `@proposed` scenario is not
+counted by the audit until a QA approves it (`sungen contract approve --screen <name>`).
+
 ## Platform detection (do this FIRST)
 
 Read `qa/capabilities.yaml` and check the `platform` field — **and the verification scope** (`verification:` if set, else derived from `enabled`: `ui` always; `api`/`db` only if that driver is on). This is the project's recorded **test type**: an **E2E/UI-only** project (no `api`/`db`) must NOT get `@api`/`@query`/`@requires:api|db` verification unless the test-viewpoint explicitly asks for it — keep oracles UI-observable, and cap any in-scope API/DB-in-E2E verification at the **≤20% band** (see `sungen-tc-generation` → "Respect the project's verification scope"). `sungen audit` flags `VERIFICATION-OUT-OF-SCOPE`.
@@ -207,11 +203,22 @@ If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the d
    **Screen requirements** — check `<base>/${input:name}/requirements/`:
 {{/cap}}
    - If `spec.md` exists → read it as PRIMARY source (sections, fields, validation rules, business rules, states).
-   - `test-viewpoint.md` → **Viewpoint — review or draft** below, once every source is read. No question here.
 {{#cap parallel-subagents}}
+   - If `test-viewpoint.md` exists → read it. If it only contains HTML comments (scaffold template), use `AskUserQuestion` to ask:
+     - **Fill test-viewpoint.md first** — I'll help you identify edge cases, known issues, and design decisions for this screen before generating tests
+     - **Continue without it** — generate tests from spec and other sources only
+
+   **A filled `test-viewpoint.md` is an INPUT — never an output.** Do NOT rewrite, re-order, or replace its viewpoint declarations as part of generating tests. It is the yardstick two scored axes measure the suite against (`traceability`, `atomicLedger`): rewrite it to match what you just generated and both read 100% by construction, while any viewpoint you quietly dropped stops being missing from anything. If the declared taxonomy genuinely does not fit the screen, **report the mismatch and ask** — propose the diff (ids added / removed and why) and let the QA decide. `sungen audit` reports `VIEWPOINT-BASELINE-CHANGED` and stops scoring both axes when this file moves, so an unannounced rewrite lowers the score rather than raising it.
 
    **Context discovery (prefer an isolated agent).** Reading all sources here can flood this context. **Claude Code:** spawn the **`sungen-discovery`** sub-agent (Task tool, `subagent_type: sungen-discovery`) to read spec/figma/ui/live in isolation and return a **compact discovery report** (sources, completeness, conflicts, recommended route, key facts); use that report instead of pasting raw sources. **Copilot / no sub-agents:** do the reading inline as below.
 {{/cap}}
+{{^cap parallel-subagents}}
+   - If `test-viewpoint.md` exists → read it. If it only contains HTML comments (scaffold template), ask:
+     - **1) Fill test-viewpoint.md first** — identify edge cases, known issues, and design decisions before generating tests
+     - **2) Continue without it** — generate tests from spec and other sources only
+
+   **A filled `test-viewpoint.md` is an INPUT — never an output.** Do NOT rewrite, re-order, or replace its viewpoint declarations while generating tests. It is the yardstick two scored axes measure the suite against (`traceability`, `atomicLedger`): rewrite it to match what you just generated and both read 100% by construction, while any viewpoint you quietly dropped stops being missing from anything. If the declared taxonomy genuinely does not fit the screen, **report the mismatch and ask** — propose the diff (ids added / removed and why) and let the QA decide. `sungen audit` reports `VIEWPOINT-BASELINE-CHANGED` and stops scoring both axes when this file moves.
+{{/cap}}
 
    **Auto-detect visual source** — do NOT ask the user to pick a source. Instead, check what already exists and use it:
    1. If `spec_figma.md` exists → read it as Figma supplement (PAT flow already completed during `add-screen`). Do NOT call any `mcp__figma__*` tool.
@@ -235,18 +242,6 @@ If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the d
 
    **Cross-check + Design Inventory**: when the unit holds any design source (`ui/` images, `ui/figma-meta.md`, `spec_figma.md`), follow `sungen-tc-generation` § **Design Inventory** (reading order, one `UI-NNN` row per item, `spec+design` / `design-only` / `conflict`) and **write `requirements/ui-inventory.md`** before generating — from the discovery report's UI INVENTORY block when a sub-agent read the sources. Every `design-only` / `conflict` item must then be covered (`@ui:UI-NNN`) or deferred with a reason (`# UI-DEFERRED: UI-NNN — <reason>`) in the `.feature`; `sungen audit` reports `UI-ITEM-UNCOVERED` otherwise. Show the user the conflicts and design-only items — they are decisions, not details.
 
-   **Viewpoint — review or draft (no question asked).** Run `sungen viewpoint scan --screen <name> --json` (a flow: `--flow <name>`). It reads ids and item numbers only. Its `mode` (1 or 2) and `modeReason` name the row below — follow them; the table explains them:
-
-   | `requirements/test-viewpoint.md` | Mode | You |
-   |---|---|---|
-   | missing; nothing but the scaffold (headings, `<…>` placeholders, empty tables); or ONE OR MORE VP rows and every one of them lacks a `Kỳ vọng` | **2 — draft** | Write it from `sungen-viewpoint/viewpoint-template.md`, first line `drafted-by: ai`, keeping any row already there. Each row answers "test CÁI GÌ" and "kỳ vọng ra sao"; where the spec states the expected result, write it; only what the spec leaves open becomes a closed question in mục 5, never an invented expectation; every accepted-input class the spec names (whitelist, value list, conversion) gets an "accepted, no error" row, citing the list by name; a VP that needs a real device, account or time is `# MANUAL/ENV`. Then scan again. |
-   | first line `drafted-by: ai` | **2 — re-review** | Your draft, not yet accepted: you may revise it, from the spec and the review. |
-   | anything else — QA-written, with or without VP ids (a scaffold from an older sungen reads as this row too: delete the file to have it drafted) | **1 — review only** | Never edit it. Generate from it as written; a gap is reported, not filled. |
-
-   Then review it with `sungen-viewpoint/review-checklist.md` and the scan JSON (mode 2: fix your draft until only QA decisions remain) and write `requirements/viewpoint-review.md`, overwritten each run. Mode 2 also runs `sungen audit --screen <name> --no-baseline` before generating. Keep the review's row count for the hand-back.
-
-   **A filled `test-viewpoint.md` is an INPUT — never an output.** Do NOT rewrite, re-order, or replace its viewpoint declarations as part of generating tests — your own draft included: a draft is revised from the spec, never from the scenarios. It is the yardstick two scored axes measure the suite against (`traceability`, `atomicLedger`): rewrite it to match what you just generated and both read 100% by construction, while any viewpoint you quietly dropped stops being missing from anything. If the declared taxonomy genuinely does not fit the screen, **report the mismatch in `viewpoint-review.md`** — the diff (ids added / removed and why) — and let the QA decide. `sungen audit` reports `VIEWPOINT-BASELINE-CHANGED` and stops scoring both axes when this file moves, so an unannounced rewrite lowers the score rather than raising it.
-
    Summarize what you found in requirements and present to the user.
 
 {{#cap parallel-subagents}}
@@ -287,7 +282,6 @@ If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the d
      - **BALANCE** → stop expanding secondary viewpoints; add business-core scenarios first.
      - **TRACE** → align `VP-` ids with the viewpoint-overview.
    - Stop when the gate PASSes and findings clear, **or** the budget is exhausted → report residual gaps honestly (never fake a pass).
-   - **Repair never edits a QA-written viewpoint (mode 1).** A finding whose fix is an edit to `test-viewpoint.md` becomes a row in `viewpoint-review.md` for the QA when it cites one of the file's VP ids (the checklist's audit rule; anything else goes in the hand-back); in a mode-2 draft, fix the draft.
 
 5.6. **Record (reuse + observability).** Build the manifest and report usage:
    - `sungen manifest --screen <name>` — fingerprints for next-run change detection. On a **re-run**, start the whole command by `sungen manifest --screen <name> --diff` and only regenerate scenarios whose spec section changed (keep/regenerate/retire).
@@ -301,7 +295,7 @@ If the unit is **api-first** (`qa/api/<name>/` or `qa/api/flows/<name>/`), the d
    > **No parallel fan-out here.** Copilot has no sub-agents, so generation is sequential (the Claude Code variant fans out one `sungen-generator` per viewpoint group and merges). Same output, no speedup.
 5.3. **Standardize field test-data — Data Factory (when the unit has input fields).** For each input field, author the field-map `qa/data-factory/<name>.fields.yaml` (field → catalog `type` + real `constraints` + `errorMap`), then run `sungen data lint --screen ${input:name}` and `sungen data gen --screen ${input:name}` per the **`sungen-data-factory`** skill. `data gen` **MERGES** into `test-data.yaml` (replaces only its field keys, preserves the rest), so it is safe here. Weave the standardized boundary/invalid sets into `@cases` with `CHK-*` trace. Then `… data validate` (values correct) + `… data crosscheck` (testcase↔data agree); for a stateful precondition, `… data state --scaffold <name>` to auto-draft → fill entities + confirm with QA → `… data state`, weave the `@manual:data-setup` `Background` (works spec+viewpoint only). **Same standard as `/sungen:create-data-test`, applied inline — do NOT run that command separately afterwards.** No input fields (navigation/list) → skip.
 5.4. **Depth self-check (deterministic — BEFORE the audit).** Run `sungen depth-lint --screen ${input:name}`. It splits every shallow business-critical scenario into **DEEPEN IN PLACE** (add a real value assertion — the printed `template` is a theme-keyed hint, apply judgment to the actual claim; never fake one onto a visibility/behavior scenario) and **CROSS-SCREEN** (route to a flow / tag `@manual:Mx` + reason — removes it from the depth denominator honestly). Act on both, re-run until `deepen` is empty (or only honest over-counts remain), THEN gate. Lifts first-pass `businessDepth` mechanically instead of via 2–3 repair rounds.
-5.5. **Quality gate & repair (harness — always run).** Per `sungen-harness-audit`: run `sungen audit --screen ${input:name}` (structural), THEN do an **independent semantic review inline** using the `sungen-reviewer` criteria (does each scenario's steps PROVE its title/viewpoint? observable Thens? business-critical assertion depth?). Merge both sets of issues; if gate FAILs / findings exist, repair (budget 3) and re-audit — GATE missing theme → generate it (cross-screen → **automate it in the flow** via `/sungen:add-flow`, NOT a full `@manual` screen duplicate — `sungen audit` flags an automatable `@manual` as `MANUAL-AUTOMATABLE`; reserve `@manual:Mx` for true judgment/missing-capability); DEPTH → add data assertions; BALANCE → add business-core first; TRACE → align VP ids. Never fake a pass. Repair never edits a QA-written viewpoint (mode 1): a finding whose fix is an edit to `test-viewpoint.md` and cites one of its VP ids becomes a row in `viewpoint-review.md`; in a mode-2 draft, fix the draft.
+5.5. **Quality gate & repair (harness — always run).** Per `sungen-harness-audit`: run `sungen audit --screen ${input:name}` (structural), THEN do an **independent semantic review inline** using the `sungen-reviewer` criteria (does each scenario's steps PROVE its title/viewpoint? observable Thens? business-critical assertion depth?). Merge both sets of issues; if gate FAILs / findings exist, repair (budget 3) and re-audit — GATE missing theme → generate it (cross-screen → **automate it in the flow** via `/sungen:add-flow`, NOT a full `@manual` screen duplicate — `sungen audit` flags an automatable `@manual` as `MANUAL-AUTOMATABLE`; reserve `@manual:Mx` for true judgment/missing-capability); DEPTH → add data assertions; BALANCE → add business-core first; TRACE → align VP ids. Never fake a pass.
 5.6. **Record.** `sungen manifest --screen ${input:name}`. Ledger **each phase** (not just repair) — pick one `runId` at the start and pass it so `trace`/`ledger report` show THIS run, not a mix: `sungen ledger record --screen ${input:name} --run <runId> --step <discovery|viewpoint|gherkin|audit|repair:N> --ms <elapsed>`. On re-run, start with `sungen manifest --screen ${input:name} --diff` and only regenerate changed sections.
 6. **Converge — show the trace.** Run `sungen trace --screen ${input:name}` and present: process map (phases + repair rounds), bottlenecks, **HUMAN-LOOP FOCUS** (@manual to verify), audit score + gate + residual gaps. Then offer next steps based on which tier was just generated:
 {{/cap}}
@@ -367,13 +361,9 @@ Do not stop after writing the files. Close every run with, in this order:
 1. **The traceability check below** — an untagged requirement becomes an uncovered gap at delivery.
 2. **The harness result in one line** — score, gate verdict, and the axis the `SCORE-CAPPED` finding
    names (that finding is the single answer to "how do I raise the score").
-3. **The viewpoint review in one line** — `Viewpoint review: N điểm cần QA xem` (N = the `[ ]` rows
-   of `requirements/viewpoint-review.md`).
-4. **`AskUserQuestion` with the next actions** — never end with prose alone. Offer
+3. **`AskUserQuestion` with the next actions** — never end with prose alone. Offer
    `/sungen:run-test <name>` (recommended once the tiers are written), re-running `create-test` to
-   extend, "Mở viewpoint-review.md" when N > 0, and "Done for now". After a mode-2 draft also list
-   the decision `sungen audit --screen <name> --accept-viewpoint` — for the QA to run once the draft
-   is reviewed; you never run it yourself. A run that ends without this leaves the operator guessing.
+   extend, and "Done for now". A run that ends without this leaves the operator guessing.
 
 ### Requirement traceability
 

package/dist/orchestrator/templates/ai-src/commands/dashboard.md

@@ -7,6 +7,8 @@ claude-tools: "Bash, Read, AskUserQuestion"
 copilot-tools: "[read, execute, edit, vscode/askQuestions]"
 codex-trigger: "Run when the user asks to OPEN or view the sungen results dashboard."
 ---
+<!-- include: hand-back-rule -->
+
 ## Role
 
 You are a **QA Reporting Engineer**. Your job is to invoke the deterministic `sungen dashboard` CLI which builds a self-contained HTML report. The HTML is shareable as-is (open via `file://`, no server required).

package/dist/orchestrator/templates/ai-src/commands/delivery.md

@@ -7,6 +7,8 @@ claude-tools: "Bash, Read, Write, AskUserQuestion"
 copilot-tools: "[read, execute, edit, vscode/askQuestions]"
 codex-trigger: "Run when the user asks to EXPORT or deliver test cases for QA hand-off. Final step. Do NOT use for creating or running tests."
 ---
+<!-- include: hand-back-rule -->
+
 ## Role
 
 You are a **QA Test Delivery Engineer**. The deterministic `sungen delivery` CLI does all parsing,

package/dist/orchestrator/templates/ai-src/commands/design.md

@@ -7,6 +7,8 @@ claude-tools: "Read, Grep, Bash, Glob, Write, AskUserQuestion, Skill, mcp__playw
 copilot-tools: "[vscode, execute, read, agent, edit, search, web, browser, todo, 'playwright/*']"
 codex-trigger: "Run when the user asks to capture DESIGN/visual context (Figma, live page scan, mockups) for a screen. Used before create-test. Do NOT use for writing or running tests."
 ---
+<!-- include: hand-back-rule -->
+
 {{#cap parallel-subagents}}
 ## `/sungen:design` is an alias of `/sungen:create-test`
 {{/cap}}

package/dist/orchestrator/templates/ai-src/commands/feedback.md

@@ -7,6 +7,8 @@ claude-tools: "Read, Grep, Bash, Glob"
 copilot-tools: "[vscode, execute, read, search]"
 codex-trigger: "Run when the user wants to send FEEDBACK about sungen itself."
 ---
+<!-- include: hand-back-rule -->
+
 ## Role
 {{#cap parallel-subagents}}
 

package/dist/orchestrator/templates/ai-src/commands/locale.md

@@ -6,6 +6,8 @@ claude-tools: "Read, Grep, Bash, Glob, Edit, Write, AskUserQuestion, mcp__playwr
 copilot-tools: "[read, execute, edit, vscode/askQuestions, playwright/*]"
 codex-trigger: "Run when the user asks to bootstrap i18n/localization for a screen. Runs before run-test --env <locale>."
 ---
+<!-- include: hand-back-rule -->
+
 ## Role
 
 You are a **Senior QA Localization Engineer**. Use the `sungen-locale` skill — it contains the full phased strategy. Your job in this command is parameter parsing, context detection, and final hand-off.

package/dist/orchestrator/templates/ai-src/commands/review.md

@@ -7,6 +7,8 @@ claude-tools: "Read, Grep, Glob, Bash, Edit, Write, AskUserQuestion"
 copilot-tools: "[vscode, execute, read, edit, search, todo]"
 codex-trigger: "Run when the user asks to REVIEW or score the quality of already-generated test cases. Step 3 (between create-test and run-test). Do NOT use for creating or running tests."
 ---
+<!-- include: hand-back-rule -->
+
 {{^cap parallel-subagents}}
 **Input**: Screen or flow name (e.g., `/sungen-review admin-users`).
 

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

@@ -7,6 +7,8 @@ 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."
 ---
+<!-- include: hand-back-rule -->
+
 ## ⛔ 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
@@ -25,14 +27,6 @@ inside the run, not reasons to stop and hand the work back.
   `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.
-  **Ask `sungen next <unit>` rather than deciding from memory** — it derives the answer from what
-  the project now holds, so the hand-back stays correct even when the run ended somewhere
-  unexpected (a failed install, a driver that does not support this unit kind, an aborted repair
-  loop). Every `sungen` command also prints `Next: sungen next …` as its own last line. A step
-  that turns out to be impossible is still a hand-back: say what blocked it, run
-  `sungen next <unit>`, and offer what remains.
 
 ---
 
@@ -273,6 +267,10 @@ question already.
 6. **Phase 2 — Priority Wave**: Run all `@high` scenarios. Fix only failures from this wave. Max 2 attempts. Shared selectors fixed here cascade to later phases.
 7. **Phase 3 — Full Run**: Run all tests. Fix only **new** failures (elements unique to `@normal`/`@low`). Max 1 attempt. Don't loop on low-priority failures.
 8. **Phase 4 — Regression**: One final full run. No more fix loops. Then run `sungen triage --screen <name>` and render its table as the results summary: every red or flaky scenario already sits in one class (`product-candidate`, `unclassified`, `test-defect`, `environment`, `blocked-capability`, `known-defect`, `flaky`) with the rule and one evidence line. You may move an `unclassified` row into a class only with a written evidence line of your own. You may never turn a `product-candidate` into a `test-defect` by editing the `.feature` or the expected value — the Gherkin is frozen; report it as a candidate bug. For each `product-candidate` you judge to be a product bug, run `sungen defect draft --screen <name> --scenario "<title>"`, fill the record's Summary, check its Expected against `spec.md`, then add `@known-defect:DEF-NNN` to that scenario's tag line (the tag-only exception above). The severity in the draft is `proposed` — confirm it with QA (`AskUserQuestion`) before the hand-back and set `severity_source: qa`. A row you judge is not a product bug stays in the summary with your reason, and gets no record. A `bare-timeout` row (`unclassified`) is never re-run inside this command — Phase 4 was the final run; offer the re-run in Next steps.
+8a. **Test Contract — every unit with a lock.** When `qa/<screens|flows|api>/<name>/contracts.lock.yaml` exists, check the suite still does what QA approved:
+   - **`@free` / `@impl:code` scenarios** (hand-written specs, not compiled): in the Phase 4 final run, run their specs with `--trace on` (`npx playwright test <their spec> --trace on`) — their trace is the only proof. The project's config needs the sungen run-record reporter; if it is missing, no trace is admissible: tell the QA, do not edit the config yourself. Then `sungen contract check --screen <name> --trace`.
+   - **No free tests**: `sungen contract check --screen <name>`.
+   - **Exit 2 (hard)** — `oracle-weakened`, `target-changed`, `assertion-lost`, `lock-uncommitted`, `unproven` → report each finding to the QA in the results summary, with its rule. **Never** edit the `.feature`, an expected value, the lock or a decision to turn it green, and **never** run `sungen contract approve` — approving is a QA's decision, on a terminal. **Exit 0 with `review`** → list it for the QA: review blocks `sungen delivery` until QA re-approves. **Exit 1** → report the error. No lock → skip: every scenario is `proposed`, which never blocks.
 9. **Phase 8 — Serial-cascade risk check** (#414): If any scenario has many steps, a skipped test may cause downstream steps to be incorrectly skipped due to the serial-cascade sensor detecting false "not reached" conditions. When you see "test skipped" messages during Phase 3–4 runs, check if the skipped scenario is a **blockers-exist** dependency in the test ledger (`sungen ledger query --screen <name>`). If the scenario had high step count and cascade fired, offer: *"Scenarios with deep steps can trigger serial-cascade skipping. Consider parallelizing this spec with `@concurrent` tags or breaking into smaller scenarios."* Let the user decide whether to refactor (do not auto-apply parallelization).
 {{#cap parallel-subagents}}
 9. **Integrity check & trace (always run after the final run).**

package/dist/orchestrator/templates/ai-src/config/claude.md

@@ -12,32 +12,45 @@ You generate 3 files for sungen — a Gherkin compiler that produces Playwright
 | `sungen-tc-generation` | Test case generation strategy, output format |
 | `sungen-test-design-techniques` | EP, BVA, Decision Table, State Transition — systematic scenario generation |
 | `sungen-tc-review` | Review scoring, quality rules, checklist |
-| `sungen-viewpoint` | 17 UI patterns x 4 viewpoints — coverage checklists |
+| `sungen-viewpoint` | 32 UI patterns (17 web + 15 mobile-native) x 4 viewpoints — coverage checklists |
 | `sungen-selector-keys` | YAML key generation from `[Reference]` names, suffixes, lookup priority |
 | `sungen-selector-fix` | Selector generation from live page, auto-fix strategy |
-| `sungen-delivery` | Export Gherkin + Playwright results → CSV test case deliverable |
+| `sungen-delivery` | Export the Test Case & Coverage Matrix (or the legacy per-scenario CSV) from Gherkin + Playwright results |
 | `sungen-capture` | Acquire visual/design context — one skill, 4 modes: figma-mcp (Dev Mode MCP), figma-pat (URL → spec_figma.md), live (Playwright MCP scan), local (images in `requirements/ui/`) |
 | `sungen-locale` | Bootstrap i18n — audit selectors, detect locale switch mechanism, generate test-data overlay |
 | `sungen-data-factory` | Standardized test-data — field-type/security catalog, 4-source method, `.overwrite`, blind-spot prompts |
+| `sungen-harness-audit` | How to read `sungen audit` output and repair test-design findings (the create-test quality loop) |
+| `sungen-capture-mobile` | Capture a live mobile screen via Appium MCP — locator tree + screenshot (`@platform:mobile/android/ios`) |
+| `sungen-mobile-gestures` | Mobile gesture patterns (swipe, long-press, scroll-to, pinch, pull-to-refresh) — Gherkin + Appium MCP mapping |
+| `sungen-selector-fix-mobile` | Mobile selector fixing — Appium MCP exploration, accessibility-id-first strategy, run via wdio |
+| `sungen-api-design` | API-first design loop for an api unit — catalog, API viewpoints, `@api`/`@cases`/flow scenarios, audit gate + repair |
+| `sungen-api-coverage-model` | Per-endpoint API coverage model — tiered case set expanded from the catalog's `fields:` metadata |
+| `sungen-ingest-legacy` | Import a legacy manual test-case suite (Google Sheets or local file) via `sungen ingest` |
+| `sungen-dashboard` | Single-file HTML dashboard of test cases + results (`sungen dashboard`) |
 
-## Workflow (8 AI commands)
+## Workflow (12 AI commands)
 
 | Command | What it does |
 |---|---|
 | `/sungen:add-screen <name> <path>` | Scaffold `qa/screens/<name>/` directories |
 | `/sungen:add-flow <name> [--path <url>]` | Scaffold `qa/flows/<name>/` directories for E2E cross-screen testing |
-| `/sungen:create-test <name>` | Generate `.feature` + `test-data.yaml` (auto-detects screen or flow) |
+| `/sungen:add-api <name> [--base-url <url>] [--flow <name>] [--import <spec>]` | Scaffold an API area (`qa/api/<name>/`), or an ordered `@api` chain with `--flow` (`qa/api/flows/<name>/`); `--base-url` is needed only until the project has an API datasource; `--import` an OpenAPI/CSV spec to populate the endpoint catalog |
+| `/sungen:create-test <name>` | Generate `.feature` + `test-data.yaml`, then run the quality harness (auto-detects screen / flow / API) |
+| `/sungen:design <name>` | Alias of `create-test` |
 | `/sungen:create-data-test <name>` | Generate standardized test-data (valid/boundary/invalid + CHK trace) from the Data Factory catalog; no name = all units (asks to confirm) |
 | `/sungen:review <name>` | Score syntax, coverage, viewpoint quality (auto-detects screen or flow) |
-| `/sungen:run-test <name>` | Generate `selectors.yaml`, compile, run, auto-fix (auto-detects screen or flow) |
-| `/sungen:delivery [name...]` | Export the Test Case & Coverage Matrix (review/manual/customer deliverable; `--legacy` = classic CSV; all screens if no arg) |
+| `/sungen:run-test <name>` | Generate `selectors.yaml`, compile, run, auto-fix (auto-detects screen / flow / API) |
+| `/sungen:delivery [name...]` | Export the Test Case & Coverage Matrix (review/manual/customer deliverable; `--legacy` = classic CSV; all units if no arg) |
+| `/sungen:dashboard [name...]` | Build the single-file HTML dashboard (`qa/dashboard/index.html`) — results, trends, run compare, CSV/XLSX export |
 | `/sungen:locale <name> <locale>` | Bootstrap i18n for a screen — audit selectors, detect locale switch, generate overlay (run before `/sungen:run-test --env <locale>`) |
+| `/sungen:feedback [message]` | Record QA feedback locally (`.sungen/feedback/`) with context attached |
 
 **Screen path:** add-screen → create-test → review → run-test → delivery.
 **Flow path:** add-flow → create-test → review → run-test → delivery.
+**API path:** add-api (`--import <openapi|csv>` for accuracy) → create-test → run-test → delivery. API units carry no selectors and no visual capture; create-test runs the audit + reviewer loop itself.
 **i18n path:** (after run-test passes for base locale) → locale → run-test --env <locale> → delivery --env <locale>.
 
-`create-test`, `review`, and `run-test` auto-detect context: if `qa/flows/<name>/` exists → flow mode, else `qa/screens/<name>/` → screen mode.
+`create-test` and `run-test` auto-detect context: if `qa/api/<name>/` (or `qa/api/flows/<name>/`) exists → API mode, else if `qa/flows/<name>/` → flow mode, else `qa/screens/<name>/` → screen mode. `review` covers screen and flow units.
 
 After each command completes, use `AskUserQuestion` to present the next actions as selectable options. Never just print text — always give clickable choices so the user can continue the workflow seamlessly.
 

package/dist/orchestrator/templates/ai-src/config/copilot.md

@@ -12,32 +12,45 @@ You generate 3 files for sungen — a Gherkin compiler that produces Playwright
 | `sungen-tc-generation` | Test case generation strategy, output format |
 | `sungen-test-design-techniques` | EP, BVA, Decision Table, State Transition — systematic scenario generation |
 | `sungen-tc-review` | Review scoring, quality rules, checklist |
-| `sungen-viewpoint` | 17 UI patterns x 4 viewpoints — coverage checklists |
+| `sungen-viewpoint` | 32 UI patterns (17 web + 15 mobile-native) x 4 viewpoints — coverage checklists |
 | `sungen-selector-keys` | YAML key generation from `[Reference]` names, suffixes, lookup priority |
 | `sungen-selector-fix` | Selector generation from live page, auto-fix strategy |
-| `sungen-delivery` | Export Gherkin + Playwright results → CSV test case deliverable |
+| `sungen-delivery` | Export the Test Case & Coverage Matrix (or the legacy per-scenario CSV) from Gherkin + Playwright results |
 | `sungen-capture` | Acquire visual/design context — one skill, 4 modes: figma-mcp (Dev Mode MCP), figma-pat (URL → spec_figma.md), live (Playwright MCP scan), local (images in `requirements/ui/`) |
 | `sungen-locale` | Bootstrap i18n — audit selectors, detect locale switch mechanism, generate test-data overlay |
 | `sungen-data-factory` | Standardized test-data — field-type/security catalog, 4-source method, `.overwrite`, blind-spot prompts |
+| `sungen-harness-audit` | How to read `sungen audit` output and repair test-design findings (the create-test quality loop) |
+| `sungen-capture-mobile` | Capture a live mobile screen via Appium MCP — locator tree + screenshot (`@platform:mobile/android/ios`) |
+| `sungen-mobile-gestures` | Mobile gesture patterns (swipe, long-press, scroll-to, pinch, pull-to-refresh) — Gherkin + Appium MCP mapping |
+| `sungen-selector-fix-mobile` | Mobile selector fixing — Appium MCP exploration, accessibility-id-first strategy, run via wdio |
+| `sungen-api-design` | API-first design loop for an api unit — catalog, API viewpoints, `@api`/`@cases`/flow scenarios, audit gate + repair |
+| `sungen-api-coverage-model` | Per-endpoint API coverage model — tiered case set expanded from the catalog's `fields:` metadata |
+| `sungen-ingest-legacy` | Import a legacy manual test-case suite (Google Sheets or local file) via `sungen ingest` |
+| `sungen-dashboard` | Single-file HTML dashboard of test cases + results (`sungen dashboard`) |
 
-## Workflow (8 AI commands)
+## Workflow (12 AI commands)
 
 | Command | What it does |
 |---|---|
 | `/sungen-add-screen <name> <path>` | Scaffold `qa/screens/<name>/` directories |
 | `/sungen-add-flow <name> [--path <url>]` | Scaffold `qa/flows/<name>/` directories for E2E cross-screen testing |
-| `/sungen-create-test <name>` | Generate `.feature` + `test-data.yaml` (auto-detects screen or flow) |
+| `/sungen-add-api <name> [--base-url <url>] [--flow <name>] [--import <spec>]` | Scaffold an API area (`qa/api/<name>/`), or an ordered `@api` chain with `--flow` (`qa/api/flows/<name>/`); `--base-url` is needed only until the project has an API datasource; `--import` an OpenAPI/CSV spec to populate the endpoint catalog |
+| `/sungen-create-test <name>` | Generate `.feature` + `test-data.yaml`, then run the quality harness (auto-detects screen / flow / API) |
+| `/sungen-design <name>` | Alias of `create-test` |
 | `/sungen-create-data-test <name>` | Generate standardized test-data (valid/boundary/invalid + CHK trace) from the Data Factory catalog; no name = all units (asks to confirm) |
 | `/sungen-review <name>` | Score syntax, coverage, viewpoint quality (auto-detects screen or flow) |
-| `/sungen-run-test <name>` | Generate `selectors.yaml`, compile, run, auto-fix (auto-detects screen or flow) |
-| `/sungen-delivery [name...]` | Export the Test Case & Coverage Matrix (review/manual/customer deliverable; `--legacy` = classic CSV; all screens if no arg) |
+| `/sungen-run-test <name>` | Generate `selectors.yaml`, compile, run, auto-fix (auto-detects screen / flow / API) |
+| `/sungen-delivery [name...]` | Export the Test Case & Coverage Matrix (review/manual/customer deliverable; `--legacy` = classic CSV; all units if no arg) |
+| `/sungen-dashboard [name...]` | Build the single-file HTML dashboard (`qa/dashboard/index.html`) — results, trends, run compare, CSV/XLSX export |
 | `/sungen-locale <name> <locale>` | Bootstrap i18n for a screen — audit selectors, detect locale switch, generate overlay (run before `/sungen-run-test --env <locale>`) |
+| `/sungen-feedback [message]` | Record QA feedback locally (`.sungen/feedback/`) with context attached |
 
 **Screen path:** add-screen → create-test → review → run-test → delivery.
 **Flow path:** add-flow → create-test → review → run-test → delivery.
+**API path:** add-api (`--import <openapi|csv>` for accuracy) → create-test → run-test → delivery. API units carry no selectors and no visual capture; create-test runs the audit + reviewer loop itself.
 **i18n path:** (after run-test passes for base locale) → locale → run-test --env <locale> → delivery --env <locale>.
 
-`create-test`, `review`, and `run-test` auto-detect context: if `qa/flows/<name>/` exists → flow mode, else `qa/screens/<name>/` → screen mode.
+`create-test` and `run-test` auto-detect context: if `qa/api/<name>/` (or `qa/api/flows/<name>/`) exists → API mode, else if `qa/flows/<name>/` → flow mode, else `qa/screens/<name>/` → screen mode. `review` covers screen and flow units.
 
 After each command completes, present the next actions as selectable options. Never just print text — always give clickable choices so the user can continue the workflow seamlessly.
 

package/dist/orchestrator/templates/ai-src/partials/hand-back-rule.claude.md

@@ -0,0 +1,20 @@
+<!-- sungen:hand-back-rule v1 -->
+## ⛔ HARD RULE — the run's LAST action is the next-step hand-back
+
+A run is NOT finished when its files are written or its output prints. The final action of EVERY
+run — success, partial, failed, or aborted — is the next-step hand-back.
+
+**Ask `sungen next {{unitArg}}` rather than deciding from memory.** It derives the answer from what
+the project actually holds (artifacts on disk, the audit report, the accepted viewpoint baseline,
+the compiled spec, the run results and how many of them failed), so the hand-back stays correct
+even when the run ended somewhere unexpected — a failed install, a driver that turned out not to
+support this unit kind, an aborted repair loop. Every `sungen` command also prints
+`Next: sungen next …` as its own last line, on stderr when the command failed.
+
+**Hand back with `AskUserQuestion`** — one option per step `sungen next` lists. A `decide` step is
+a QA decision: offer it, never run it yourself. Ending with a prose summary and no choices is a
+broken run.
+
+If a step turns out to be impossible, that is still a hand-back: say what blocked it, run
+`sungen next {{unitArg}}`, and offer what remains.
+<!-- /sungen:hand-back-rule -->

package/dist/orchestrator/templates/ai-src/partials/hand-back-rule.codex.md

@@ -0,0 +1,20 @@
+<!-- sungen:hand-back-rule v1 -->
+## ⛔ HARD RULE — the run's LAST action is the next-step hand-back
+
+A run is NOT finished when its files are written or its output prints. The final action of EVERY
+run — success, partial, failed, or aborted — is the next-step hand-back.
+
+**Ask `sungen next {{unitArg}}` rather than deciding from memory.** It derives the answer from what
+the project actually holds (artifacts on disk, the audit report, the accepted viewpoint baseline,
+the compiled spec, the run results and how many of them failed), so the hand-back stays correct
+even when the run ended somewhere unexpected — a failed install, a driver that turned out not to
+support this unit kind, an aborted repair loop. Every `sungen` command also prints
+`Next: sungen next …` as its own last line, on stderr when the command failed.
+
+**Hand back as a numbered list and stop** — one item per step `sungen next` lists, then end your
+turn and wait for the user's pick. A `decide` step is a QA decision: list it, never run it
+yourself. Ending with a prose summary and no numbered choices is a broken run.
+
+If a step turns out to be impossible, that is still a hand-back: say what blocked it, run
+`sungen next {{unitArg}}`, and list what remains.
+<!-- /sungen:hand-back-rule -->

package/dist/orchestrator/templates/ai-src/partials/hand-back-rule.copilot.md

@@ -0,0 +1,20 @@
+<!-- sungen:hand-back-rule v1 -->
+## ⛔ HARD RULE — the run's LAST action is the next-step hand-back
+
+A run is NOT finished when its files are written or its output prints. The final action of EVERY
+run — success, partial, failed, or aborted — is the next-step hand-back.
+
+**Ask `sungen next {{unitArg}}` rather than deciding from memory.** It derives the answer from what
+the project actually holds (artifacts on disk, the audit report, the accepted viewpoint baseline,
+the compiled spec, the run results and how many of them failed), so the hand-back stays correct
+even when the run ended somewhere unexpected — a failed install, a driver that turned out not to
+support this unit kind, an aborted repair loop. Every `sungen` command also prints
+`Next: sungen next …` as its own last line, on stderr when the command failed.
+
+**Hand back as a numbered list and stop** — one item per step `sungen next` lists, then end your
+turn and wait for the user's pick. A `decide` step is a QA decision: list it, never run it
+yourself. Ending with a prose summary and no numbered choices is a broken run.
+
+If a step turns out to be impossible, that is still a hand-back: say what blocked it, run
+`sungen next {{unitArg}}`, and list what remains.
+<!-- /sungen:hand-back-rule -->

package/dist/orchestrator/templates/ai-src/skills/sungen-api-coverage-model/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sungen-api-coverage-model
-description: The per-endpoint API coverage model — the systematic case set to enumerate for each endpoint (read / mutating / flow), keyed to the catalog's fields: metadata, tiered so a first pass is complete (not "happy path + 1 error"). Load this in API unit mode alongside sungen-api-design; it turns endpoints × field constraints into a concrete case list, mechanically, instead of guessing.
+description: 'The per-endpoint API coverage model — the systematic case set to enumerate for each endpoint (read / mutating / flow), keyed to the catalog''s fields: metadata, tiered so a first pass is complete (not "happy path + 1 error"). Load this in API unit mode alongside sungen-api-design; it turns endpoints × field constraints into a concrete case list, mechanically, instead of guessing.'
 ---
 
 # API coverage model (what to test per endpoint)

package/dist/orchestrator/templates/ai-src/skills/sungen-capture-mobile/SKILL.md

@@ -6,7 +6,7 @@ user-invocable: false
 
 ## Purpose
 
-Launch a mobile app on a device/emulator, capture **one locator tree** (`generate_locators`) and **one screenshot**, and save them as visual context for test generation. The mobile analogue of `sungen-capture-live` — same job, Appium MCP instead of Playwright MCP.
+Launch a mobile app on a device/emulator, capture **one locator tree** (`generate_locators`) and **one screenshot**, and save them as visual context for test generation. The mobile analogue of `sungen-capture` mode `live` — same job, Appium MCP instead of Playwright MCP.
 
 Use when the target is a native/Flutter/React-Native app (`@platform:android` or `@platform:ios`) running on a connected device or emulator.
 
@@ -188,8 +188,8 @@ Flutter/RN expose the same Semantics on each, so one exploration covers most of
 
 ## Relationship to other capture skills
 
-- `sungen-capture-figma` / `sungen-capture-local` — design/image sources (platform-agnostic)
-- `sungen-capture-live` — web (Playwright MCP)
+- `sungen-capture` (modes `figma-mcp` / `figma-pat` / `local`) — design/image sources (platform-agnostic)
+- `sungen-capture` (mode `live`) — web (Playwright MCP)
 - `sungen-capture-mobile` — this skill, mobile (Appium MCP)
 
 All write to `requirements/ui/` and report back to the caller.

package/dist/orchestrator/templates/ai-src/skills/sungen-data-factory/SKILL.md

@@ -69,6 +69,15 @@ Rules:
   catalog defaults).
 - Map every `errorRef` placeholder (`M13`, `M39`, …) to the spec's real code via `errorMap`. Leave
   one unmapped **only** if the spec has none — the lint flags it as an open point to confirm.
+- Some catalog constraints are only placeholders (string `minLength: 1` / `maxLength: 255`, phone
+  `8..15`, …). A field that does not set its own value is warned **`PLACEHOLDER_CONSTRAINT`** — the
+  boundary cases are built from that number, so take it from the spec.
+- An **empty value** is judged by `required`, not by `minLength`: `required: false` → `""` is valid
+  (no "below minimum" case for it); `required: true` **or unset** → `""` is invalid. `minLength: 0`
+  has no min-1 case. So an optional field must say `required: false`.
+- To drop **one** generated case for **one** field, list its id under the field's **`disable:`**
+  (e.g. `disable: [CHK-STR-I2]` drops min-1 and keeps max+1 `CHK-STR-I2a`). It is reported as
+  not applicable. The overwrite's `disable:` drops a case for every field of the type.
 - **Complex forms:** a **group** field takes nested **`fields:`** (recursive; no `type` on the group → renders a nested object like `address.city`). A field whose rule depends on another takes **`dependsOn: { field, value }`** — recorded as a `_depends_on` note (the generator doesn't resolve the runtime condition; weave it into the scenario/`@cases`).
 - Set **`unique: true`** on a field that must be fresh every run (register email/username, anything
   that would clash with a record a previous run left behind). Its valid value then carries a runtime

package/dist/orchestrator/templates/ai-src/skills/sungen-harness-audit/SKILL.md

@@ -38,8 +38,6 @@ user-invocable: false
 | **DEFECT-REF-MISSING** | a `@known-defect:DEF-NNN` tag names no file in `qa/defects/` | Draft the record (`sungen defect draft --screen <name> --scenario "<title>"`) or correct the id. Never drop the tag to silence it — the scenario still asserts a live defect. |
 | **DEFECT-ORPHAN** (info) | an open defect record names a scenario this unit no longer has | Update the record's `scenarios:` to the renamed title, or close the record if the scenario was removed on purpose. Nothing in the suite to repair. |
 | **UNIVERSAL** | a universal theme (error/empty-state, accessibility) is absent | Low priority — add if in scope; otherwise note as out-of-scope with reason. |
-| **VIEWPOINT-DRAFT-UNREVIEWED** | `test-viewpoint.md` carries `drafted-by: ai`: no baseline, `atomicLedger` + `traceability` held | A QA action, not a repair. Keep generating; list the decision `sungen audit --screen <name> --accept-viewpoint` in the hand-back for the QA to run after reviewing the draft. Never run it, never delete the line yourself. |
-| **VIEWPOINT-REVIEW-OPEN** (info) | `requirements/viewpoint-review.md` still has `[ ]` rows | A QA action. Report the count in the hand-back with the option to open the file; never tick rows or edit a QA-written viewpoint to clear it. Not scored. |
 
 ## P5 steps for deep cross-screen / list coverage
 
@@ -68,7 +66,7 @@ Use these when repairing GATE/DEPTH findings for the hard viewpoints (cart/detai
 ## Repair loop rules
 
 1. **Budget = 3 rounds.** Re-run `sungen audit` after each repair; track score delta.
-2. **Stop when** `gateStatus == PASS` AND `findings` empty — or budget exhausted. QA-action findings (`VIEWPOINT-DRAFT-UNREVIEWED`, `VIEWPOINT-REVIEW-OPEN`) do not count: no repair clears them.
+2. **Stop when** `gateStatus == PASS` AND `findings` empty — or budget exhausted.
 3. **Never fake a pass.** A shallow `see [Cart] page` does not satisfy `cart-correctness`. If a gap is genuinely cross-screen or needs capabilities the DSL lacks (e.g. capture an element value to compare elsewhere), **report it as a residual gap / flow item** instead of forcing a green gate.
 4. **EP/data families are OK.** A `duplicates` cluster with `sameDataLikely=false` is an intentional equivalence-partition family (e.g. many invalid-email cases) — keep it; only collapse `sameDataLikely=true` exact duplicates.
 5. **Advisory findings — surface, don't gate.** `MANUAL-REASON-MISMATCH` → fix the scenario's `@manual:Mx` code (so the planner recommends the right driver) during repair. `CAPABILITY-SUGGESTION` → **present it to the user as a next-step option** (e.g. "N @manual could be automated — `sungen capability add api db`?"), **recommend-only — never auto-install**. `VERIFICATION-OUT-OF-SCOPE (api|db)` → the unit uses `@api`/`@query`/`@requires:api|db` verification the project's recorded **test type** never opted into (E2E/UI-only per `capabilities.yaml`, and the viewpoint doesn't ask for it). During repair: **rewrite the oracle to be UI-observable** (or downgrade the deep check to an `(optional deep check: …)` note); only keep the API/DB verification if the project genuinely tests that layer — then record it (`verification: [ui, api]` / `sungen capability add`). Keep API/DB-in-E2E to the ≤20% band. Neither of these fails the gate.

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

@@ -385,7 +385,7 @@ Security:         [S1 – admin only]
    - **`--accept-viewpoint` is the QA's command, not yours.** `sungen next` shows it as a `⚖ decide`
      step. Present the declared-id diff and stop; a yardstick accepted by the process it measures
      reads 100% by construction.
-   - **Match the scenarios to the file — never the file to the scenarios.** A filled `test-viewpoint.md` is an input; do not rewrite its declarations to fit what you generated. That is not compliance, it is moving the yardstick: `traceability` + `atomicLedger` then read 100% by construction and a dropped viewpoint stops being missing from anything. Disagree with the taxonomy → report the diff (ids added / removed and why) in `requirements/viewpoint-review.md`; the QA decides — no mid-run question. `sungen audit` reports `VIEWPOINT-BASELINE-CHANGED` and excludes both axes until a human accepts the change (`sungen audit --screen <name> --accept-viewpoint`).
+   - **Match the scenarios to the file — never the file to the scenarios.** A filled `test-viewpoint.md` is an input; do not rewrite its declarations to fit what you generated. That is not compliance, it is moving the yardstick: `traceability` + `atomicLedger` then read 100% by construction and a dropped viewpoint stops being missing from anything. Disagree with the taxonomy → propose the diff and ask. `sungen audit` reports `VIEWPOINT-BASELINE-CHANGED` and excludes both axes until a human accepts the change (`sungen audit --screen <name> --accept-viewpoint`).
 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.

package/dist/orchestrator/templates/ai-src/skills/sungen-viewpoint/SKILL.md

@@ -15,24 +15,6 @@ This skill is a **router**. The detailed checklists live in 6 group files — lo
 
 > All checklist items are written in English. Render scenario names, step text, and test IDs in English.
 
-## Authoring (mode 2) — drafting `test-viewpoint.md`
-
-Draft `requirements/test-viewpoint.md` only when the file is missing, is an untouched scaffold
-(headings, `<…>` placeholders, empty tables), or has one or more VP rows and every one lacks a
-`Kỳ vọng` — a file with no VP ids that is not the scaffold is QA-written (mode 1). Draft it from
-`viewpoint-template.md` in this folder (the QA's sections, in Vietnamese): the file's first line is
-`drafted-by: ai`; every VP row has a non-empty `Kỳ vọng`; whatever the spec leaves open becomes a
-closed question in mục 5, never an invented expectation. Fill sections 1 and 3 and the Coverage
-table from the patterns and Shared Checks below. A viewpoint without `drafted-by: ai` is QA-owned:
-read it, never edit it.
-
-## Review (both modes) — `review-checklist.md`
-
-create-test reviews every viewpoint with `review-checklist.md` in this folder, fed by
-`sungen viewpoint scan --json`, and writes `requirements/viewpoint-review.md`. On a QA-owned file
-that review file is the only output, limited to the checks its `Mode 1` column allows; on your own
-draft, run every check and fix the draft first.
-
 ## Routing table
 
 | UI element on the screen | Pattern | Read file |