@sun-asterisk/sungen 3.2.10-beta.5 → 3.2.10

package/src/orchestrator/templates/specs-test-data.ts

@@ -48,27 +48,9 @@ export class TestDataLoader {
     if (value === undefined || value === null) {
       throw new Error(`Test data key not found: ${key}`);
     }
-    // A projected array (e.g. `{{q.rows[*].name}}`) serializes as a JSON list so the full
-    // ordered set is preserved for the assert-compare — String([...]) would flatten it to a
-    // lossy comma-join that can't be distinguished from a scalar containing commas.
-    if (Array.isArray(value)) return this.interpolate(JSON.stringify(value));
     return this.interpolate(String(value));
   }
 
-  /**
-   * Resolve a key to its RAW, uncoerced value (array/object/number kept as-is) — for binding
-   * DB query parameters, where type-strict stores (MySQL numeric columns, MongoDB) require the
-   * native type. get() stringifies for Gherkin text; raw() must not. Throws on missing, mirroring
-   * get()'s guard.
-   */
-  raw(key: string): any {
-    const value = this.resolve(key);
-    if (value === undefined || value === null) {
-      throw new Error(`Test data key not found: ${key}`);
-    }
-    return value;
-  }
-
   /**
    * Substitute embedded `{{ref}}` cross-references inside a resolved string value.
    * Each ref is looked up via resolve() (flat key, @cases row column, or dotted path),
@@ -96,7 +78,6 @@ export class TestDataLoader {
    *      `q.count` / `q.length`  → number of rows
    *      `q.first.col` / `q.last.col` / `q[2].col` → a specific row's column
    *      `q.col`                → shorthand for the first row's column
-   *      `q.rows[*].col`        → the `col` of EVERY row, projected to an ordered array
    */
   private resolve(key: string): any {
     // 1. Exact flat key — captured vars (set()) live under a literal, possibly dotted, key.
@@ -107,26 +88,9 @@ export class TestDataLoader {
       return this.data[key];
     }
     // 2. Structured path: head from the row (cases) or shared data, then walk segments.
-    //    `[n]` → `.n` (numeric index); `[*]` → `.*` (project the rest of the path over each element).
-    const tokens = String(key).replace(/\[(\d+)\]/g, '.$1').replace(/\[\*\]/g, '.*').split('.');
-    const cur: any = (this.row && tokens[0] in this.row) ? this.row[tokens[0]] : this.data[tokens[0]];
-    return TestDataLoader.walk(cur, tokens, 1);
-  }
-
-  /**
-   * Walk the remaining path tokens from `i`. A `*` token on an array projects: the rest of the
-   * path is mapped over every element and the collected array returned (recurses for nested `[*]`).
-   * Non-`*` tokens use the linear single-step navigation, so numeric/first/last/object access is
-   * unchanged.
-   */
-  private static walk(cur: any, tokens: string[], i: number): any {
-    for (; i < tokens.length && cur != null; i++) {
-      if (tokens[i] === '*' && Array.isArray(cur)) {
-        const rest = tokens.slice(i + 1);
-        return cur.map((el) => TestDataLoader.walk(el, rest, 0));
-      }
-      cur = TestDataLoader.step(cur, tokens[i]);
-    }
+    const tokens = String(key).replace(/\[(\d+)\]/g, '.$1').split('.');
+    let cur: any = (this.row && tokens[0] in this.row) ? this.row[tokens[0]] : this.data[tokens[0]];
+    for (let i = 1; i < tokens.length && cur != null; i++) cur = TestDataLoader.step(cur, tokens[i]);
     return cur;
   }
 

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

@@ -1,85 +0,0 @@
----
-name: create-data-test
-description: "Generate standardized test-data for a screen/flow from the Data Factory catalog — valid/boundary/invalid values with CHK-* traceability (no free-form guessing)"
-argument-hint: [screen-or-flow-name]
-order: 25
-claude-tools: "Read, Grep, Bash, Glob, Write, Edit, AskUserQuestion, Skill"
-copilot-tools: "[vscode, execute, read, agent, edit, search, todo]"
-codex-trigger: "Run when the user asks to CREATE, generate, or standardize TEST DATA / test values for a screen or flow (valid/boundary/invalid, boundary values, negative data). Uses the Data Factory driver. Not for generating the .feature scenarios themselves (that is create-test)."
----
-
-**Input**: A screen or flow name (e.g., `/sungen:create-data-test login`), OR **no name** to do every unit (with a confirmation — see ALL mode). Load the `sungen-data-factory` skill for the full method.
-
-## Role
-
-You are a **Senior QA Engineer** producing **test data to a standard**, not by guessing. You do NOT invent values field-by-field. You follow the 4-source method (spec rules → field-type catalog → design technique → DB mapping), driven by the **Data Factory** capability driver. Values come from the catalog (`common/` + the project's `.overwrite`), each tagged with a `CHK-*` id that traces back to the spec. Where the catalog cannot cover a project-specific field, you **ask the QA** — you never fabricate domain data.
-
-## Preconditions
-
-1. **Availability** — Data Factory is **bundled with core** (no `capability add` needed); its CLI (`sungen data …`) is available out of the box. Just continue.
-2. Determine mode from `$ARGUMENTS`:
-   - A **name** given → single-unit mode (that screen/flow only).
-   - **No name** → **ALL mode** (see below — always confirm first).
-
-## ALL mode (no name) — confirm before doing everything
-
-If no name was given, the user wants **all** screens/flows — but this is wide, and a missing name is often a typo (they meant `create-data-test home`). So:
-
-1. List every unit under `qa/screens/*` and `qa/flows/*`, and classify each as **new** (no `test-data/<name>.yaml` yet) vs **would-overwrite**.
-2. Show the list and use `AskUserQuestion` to confirm: *"Generate test-data for ALL N units? (X new · Y would overwrite)"* — default to **No**.
-3. Only proceed when the user confirms. Then run the per-unit flow below for each (the CLI `sungen data gen --all` also enforces this confirm; `--yes` after the user agrees).
-
-## Per-unit flow (single unit, or each unit in ALL mode)
-
-Auto-detect: `qa/flows/<name>/` → flow; else `qa/screens/<name>/` → screen. (API units carry their contract in `apis.yaml` — data there is `@cases` in create-test, not this command.)
-
-### 1. Read the sources (Nguồn 1 + 4)
-
-Read `qa/<screens|flows>/<name>/requirements/spec.md` and `test-viewpoint.md`. For **each input field / parameter**, extract:
-- data **type** (map to a catalog field-type: email · password · phone · string · number-integer · number-float · currency · postcode · katakana …),
-- `required`, format, **min/max** length or value,
-- the real **error/message code** the spec shows when a rule is violated,
-- any **DB mapping** (unique, cross-entity dependency) noted in the spec.
-
-Viewpoint tells you which fields are high-priority → give them the fullest data.
-
-**No input fields → nothing to generate.** If the unit is a pure navigation / listing / capture-compare flow (e.g. a home-shopping browse flow) with **no user-input fields or parameters**, Data Factory has nothing to standardize. Report *"`<name>`: no input fields → nothing to generate"* and stop for this unit — do **not** write an empty `qa/data-factory/<name>.fields.yaml`. (Its scenarios are covered by create-test's data, not by field-level test data.)
-
-### 2. Write the field-map — `qa/data-factory/<name>.fields.yaml`
-
-This is the input the deterministic generator expands. One entry per field:
-
-```yaml
-screen: <name>            # or: flow: <name>
-fields:
-  - name: email
-    type: email
-    required: true
-    constraints: { maxLocal: 64, maxTotal: 254 }   # project's real limits
-    errorMap: { M13: E1042, M02: E1001 }            # catalog placeholder → project's real code
-  - name: password
-    type: password
-    constraints: { minLength: 8, maxLength: 32 }
-```
-
-Map every placeholder error code you can (`errorMap`) to the spec's real code. Leave a code unmapped only if the spec truly has none — the lint will flag it as an open point to confirm with BA/Dev.
-
-### 3. Blind spots — ask, do not invent
-
-If a field's type is **not** in the catalog (a business enum, a cross-entity constraint, a project data model), **stop and ask the QA** with `AskUserQuestion` for: (1) the valid set, (2) invalid / non-existent values, (3) the error code when wrong, (4) dependencies on other fields. Record the answer in `qa/data-factory/project/<entity>.yaml` for reuse. Never fabricate domain values.
-
-### 4. Lint the coverage
-
-Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data lint --screen <name> || npx sungen data lint --screen <name>`. Fix what it reports: add missing boundary values, resolve `UNRESOLVED` items (supply the constraint), map `OPEN_ERRORREF` codes. The bar is the phuong-phap §6 checklist — every required field has valid + boundary + invalid, one invalid per rule.
-
-### 5. Generate the test-data
-
-Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data gen --screen <name> || npx sungen data gen --screen <name>`. If `test-data/<name>.yaml` already exists it **asks before overwriting** — respect the user's choice (in ALL mode after they confirmed, add `--yes`; use `--force` only when the user explicitly wants an unconditional overwrite). The output is standardized `valid/boundary/invalid` values with `CHK-*` traceability.
-
-### 6. Weave into scenarios (if create-test already ran)
-
-If the `.feature` exists, turn the generated invalid/boundary sets into data-driven `Scenario Outline` + `Examples` (`@cases`) referencing the values — following `sungen-gherkin-syntax`. Otherwise leave the standardized `test-data/<name>.yaml` for `/sungen:run-test` to consume.
-
-## After running
-
-Use `AskUserQuestion` to offer the next step: review the generated data, run `/sungen:create-test <name>` (if scenarios don't exist yet), or `/sungen:run-test <name>`.

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

@@ -1,101 +0,0 @@
----
-name: sungen-data-factory
-description: 'Use when create-data-test (or create-test) needs standardized TEST DATA — valid/boundary/invalid values for input fields with CHK-* traceability. Drives the Data Factory catalog + the 4-source method. Invoke after reading spec.md, when authoring the field-map or filling test-data.'
-user-invocable: false
----
-
-## What this skill does
-
-Turn a screen/flow's fields into **standardized test data** — not guessed values. You author a
-**field-map**; the deterministic `sungen data gen` expands it from the Data Factory **catalog**
-(field-type + security + technique library) into valid / boundary / invalid values, each carrying a
-`CHK-*` id that traces to the spec. Your judgment goes into *reading the spec correctly* and
-*answering blind spots* — never into inventing values the catalog or the QA should own.
-
-Data Factory is **bundled with core** (runtime-free) — no `capability add` needed; the `sungen data …`
-CLI is available out of the box.
-
-## The 4-source method (phuong-phap-tao-test-data.md)
-
-Never invent values from memory. Cross-reference four sources — each covers the previous one's gap:
-
-1. **Spec validate rules** — required, format, min/max, business rules, and the **error/message code**
-   per rule. Defines the legal/illegal boundary. (Says the *law*, not every way to *break* it.)
-2. **Field-type catalog** — the accumulated "how this type breaks" knowledge (email/password/phone/
-   number/…). This is the Data Factory `common/` — it fills the "spec doesn't list every break" gap.
-3. **Design technique** — Boundary Value Analysis / Equivalence Partitioning / Decision Table / State
-   Transition — reduces the rule + candidates to a *minimal-but-sufficient* representative set.
-4. **DB mapping** — unique constraints, cross-entity dependency, real backend limits → precondition
-   data, not just a single input value.
-
-Then classify every value into **Valid / Boundary / Invalid** (each invalid tagged with its error
-code) and give it a `CHK-*` id for traceability.
-
-## The field-map — `qa/data-factory/<name>.fields.yaml`
-
-Your main artifact. One entry per input field; the generator expands it:
-
-```yaml
-screen: login                 # or  flow: <name>
-fields:
-  - name: email
-    type: email               # a catalog field-type (see list below)
-    required: true
-    constraints: { maxLocal: 64, maxTotal: 254 }   # the project's REAL limits from spec
-    errorMap: { M13: E1042, M02: E1001 }            # catalog placeholder code → project's real code
-  - name: password
-    type: password
-    constraints: { minLength: 8, maxLength: 32 }
-```
-
-**Catalog field-types** (P1): `email` · `password` · `phone` · `string` · `number-integer` ·
-`number-float` · `currency` · `postcode` · `katakana` (JP). Security payload banks auto-append to a
-field's invalid group via the type's `uses_security` (`sqli`, `xss`, `idor`, `broken-auth`, `upload`,
-`input-validation`).
-
-Rules:
-- Pick the closest `type`; put the project's real numbers in `constraints` (they override the
-  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.
-
-## No input fields → nothing to generate
-
-Data Factory standardizes **field-level input data**. If a unit has no user-input fields or
-parameters — a pure navigation, listing, or capture-compare flow — there is nothing to generate.
-Report *"no input fields → nothing to generate"* and skip it; do **not** write an empty field-map.
-Those scenarios are covered by the data create-test already produced, not by field-level test data.
-(This is a correct outcome, not a gap — don't force a field-map to make the unit "processed".)
-
-## Blind spots — ask, never fabricate
-
-If a field's type is **not** in the catalog — a business enum, a cross-entity constraint, a
-project-specific data model — do **not** guess. Ask the QA (via `AskUserQuestion`) for: (1) the valid
-set, (2) invalid / non-existent values, (3) the error code when wrong, (4) dependencies on other
-fields. Record it in `qa/data-factory/project/<entity>.yaml` so it becomes reusable project catalog.
-This is the core discipline: *common is never enough; when blind, think and ask — don't invent.*
-
-## Customizing the catalog — `.overwrite` (survives `sungen update`)
-
-The shipped `common/` is a floor. Project rules go in `qa/data-factory/common.overwrite.yaml`,
-deep-merged over the common (**later-wins**, keyed by `type` + data-point `id`): same `id` replaces,
-new `id` appends, `constraints` merge key-by-key. `sungen update` refreshes `common/` but never
-touches your overlay. If an update makes an overlay entry stale (references a bank/constraint that no
-longer exists), the loader **warns you to prune it** — it never edits your file. Prefer a targeted
-`errorMap`/`constraints` in the field-map for per-screen tweaks; use `.overwrite` only for rules that
-apply project-wide.
-
-## Verify before done — the phuong-phap §6 checklist
-
-Run `sungen data lint` and clear it: every required field has **≥1 valid**, **boundary present**
-(exact min/max, not only over-boundary) for bounded types, **≥1 invalid per rule** (not one generic
-"wrong" value for many rules), no `UNRESOLVED` values, error codes mapped or explicitly left open.
-Then `sungen data gen` writes the standardized `test-data/<name>.yaml`. Do not hand-edit the
-generated values — change the field-map or `.overwrite` and re-run (determinism: same input → same
-data).
-
-## Weaving into scenarios
-
-When a `.feature` exists, express invalid/boundary sets as data-driven `Scenario Outline` + `Examples`
-(`@cases`) referencing the values — see `sungen-gherkin-syntax`. This keeps one logic + many values
-instead of copy-pasted scenarios, and each row carries its `CHK-*` id for traceability.

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

@@ -1,85 +0,0 @@
----
-name: create-data-test
-description: "Generate standardized test-data for a screen/flow from the Data Factory catalog — valid/boundary/invalid values with CHK-* traceability (no free-form guessing)"
-argument-hint: [screen-or-flow-name]
-order: 25
-claude-tools: "Read, Grep, Bash, Glob, Write, Edit, AskUserQuestion, Skill"
-copilot-tools: "[vscode, execute, read, agent, edit, search, todo]"
-codex-trigger: "Run when the user asks to CREATE, generate, or standardize TEST DATA / test values for a screen or flow (valid/boundary/invalid, boundary values, negative data). Uses the Data Factory driver. Not for generating the .feature scenarios themselves (that is create-test)."
----
-
-**Input**: A screen or flow name (e.g., `/sungen:create-data-test login`), OR **no name** to do every unit (with a confirmation — see ALL mode). Load the `sungen-data-factory` skill for the full method.
-
-## Role
-
-You are a **Senior QA Engineer** producing **test data to a standard**, not by guessing. You do NOT invent values field-by-field. You follow the 4-source method (spec rules → field-type catalog → design technique → DB mapping), driven by the **Data Factory** capability driver. Values come from the catalog (`common/` + the project's `.overwrite`), each tagged with a `CHK-*` id that traces back to the spec. Where the catalog cannot cover a project-specific field, you **ask the QA** — you never fabricate domain data.
-
-## Preconditions
-
-1. **Availability** — Data Factory is **bundled with core** (no `capability add` needed); its CLI (`sungen data …`) is available out of the box. Just continue.
-2. Determine mode from `$ARGUMENTS`:
-   - A **name** given → single-unit mode (that screen/flow only).
-   - **No name** → **ALL mode** (see below — always confirm first).
-
-## ALL mode (no name) — confirm before doing everything
-
-If no name was given, the user wants **all** screens/flows — but this is wide, and a missing name is often a typo (they meant `create-data-test home`). So:
-
-1. List every unit under `qa/screens/*` and `qa/flows/*`, and classify each as **new** (no `test-data/<name>.yaml` yet) vs **would-overwrite**.
-2. Show the list and use `AskUserQuestion` to confirm: *"Generate test-data for ALL N units? (X new · Y would overwrite)"* — default to **No**.
-3. Only proceed when the user confirms. Then run the per-unit flow below for each (the CLI `sungen data gen --all` also enforces this confirm; `--yes` after the user agrees).
-
-## Per-unit flow (single unit, or each unit in ALL mode)
-
-Auto-detect: `qa/flows/<name>/` → flow; else `qa/screens/<name>/` → screen. (API units carry their contract in `apis.yaml` — data there is `@cases` in create-test, not this command.)
-
-### 1. Read the sources (Nguồn 1 + 4)
-
-Read `qa/<screens|flows>/<name>/requirements/spec.md` and `test-viewpoint.md`. For **each input field / parameter**, extract:
-- data **type** (map to a catalog field-type: email · password · phone · string · number-integer · number-float · currency · postcode · katakana …),
-- `required`, format, **min/max** length or value,
-- the real **error/message code** the spec shows when a rule is violated,
-- any **DB mapping** (unique, cross-entity dependency) noted in the spec.
-
-Viewpoint tells you which fields are high-priority → give them the fullest data.
-
-**No input fields → nothing to generate.** If the unit is a pure navigation / listing / capture-compare flow (e.g. a home-shopping browse flow) with **no user-input fields or parameters**, Data Factory has nothing to standardize. Report *"`<name>`: no input fields → nothing to generate"* and stop for this unit — do **not** write an empty `qa/data-factory/<name>.fields.yaml`. (Its scenarios are covered by create-test's data, not by field-level test data.)
-
-### 2. Write the field-map — `qa/data-factory/<name>.fields.yaml`
-
-This is the input the deterministic generator expands. One entry per field:
-
-```yaml
-screen: <name>            # or: flow: <name>
-fields:
-  - name: email
-    type: email
-    required: true
-    constraints: { maxLocal: 64, maxTotal: 254 }   # project's real limits
-    errorMap: { M13: E1042, M02: E1001 }            # catalog placeholder → project's real code
-  - name: password
-    type: password
-    constraints: { minLength: 8, maxLength: 32 }
-```
-
-Map every placeholder error code you can (`errorMap`) to the spec's real code. Leave a code unmapped only if the spec truly has none — the lint will flag it as an open point to confirm with BA/Dev.
-
-### 3. Blind spots — ask, do not invent
-
-If a field's type is **not** in the catalog (a business enum, a cross-entity constraint, a project data model), **stop and ask the QA** with `AskUserQuestion` for: (1) the valid set, (2) invalid / non-existent values, (3) the error code when wrong, (4) dependencies on other fields. Record the answer in `qa/data-factory/project/<entity>.yaml` for reuse. Never fabricate domain values.
-
-### 4. Lint the coverage
-
-Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data lint --screen <name> || npx sungen data lint --screen <name>`. Fix what it reports: add missing boundary values, resolve `UNRESOLVED` items (supply the constraint), map `OPEN_ERRORREF` codes. The bar is the phuong-phap §6 checklist — every required field has valid + boundary + invalid, one invalid per rule.
-
-### 5. Generate the test-data
-
-Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data gen --screen <name> || npx sungen data gen --screen <name>`. If `test-data/<name>.yaml` already exists it **asks before overwriting** — respect the user's choice (in ALL mode after they confirmed, add `--yes`; use `--force` only when the user explicitly wants an unconditional overwrite). The output is standardized `valid/boundary/invalid` values with `CHK-*` traceability.
-
-### 6. Weave into scenarios (if create-test already ran)
-
-If the `.feature` exists, turn the generated invalid/boundary sets into data-driven `Scenario Outline` + `Examples` (`@cases`) referencing the values — following `sungen-gherkin-syntax`. Otherwise leave the standardized `test-data/<name>.yaml` for `/sungen:run-test` to consume.
-
-## After running
-
-Use `AskUserQuestion` to offer the next step: review the generated data, run `/sungen:create-test <name>` (if scenarios don't exist yet), or `/sungen:run-test <name>`.

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

@@ -1,101 +0,0 @@
----
-name: sungen-data-factory
-description: 'Use when create-data-test (or create-test) needs standardized TEST DATA — valid/boundary/invalid values for input fields with CHK-* traceability. Drives the Data Factory catalog + the 4-source method. Invoke after reading spec.md, when authoring the field-map or filling test-data.'
-user-invocable: false
----
-
-## What this skill does
-
-Turn a screen/flow's fields into **standardized test data** — not guessed values. You author a
-**field-map**; the deterministic `sungen data gen` expands it from the Data Factory **catalog**
-(field-type + security + technique library) into valid / boundary / invalid values, each carrying a
-`CHK-*` id that traces to the spec. Your judgment goes into *reading the spec correctly* and
-*answering blind spots* — never into inventing values the catalog or the QA should own.
-
-Data Factory is **bundled with core** (runtime-free) — no `capability add` needed; the `sungen data …`
-CLI is available out of the box.
-
-## The 4-source method (phuong-phap-tao-test-data.md)
-
-Never invent values from memory. Cross-reference four sources — each covers the previous one's gap:
-
-1. **Spec validate rules** — required, format, min/max, business rules, and the **error/message code**
-   per rule. Defines the legal/illegal boundary. (Says the *law*, not every way to *break* it.)
-2. **Field-type catalog** — the accumulated "how this type breaks" knowledge (email/password/phone/
-   number/…). This is the Data Factory `common/` — it fills the "spec doesn't list every break" gap.
-3. **Design technique** — Boundary Value Analysis / Equivalence Partitioning / Decision Table / State
-   Transition — reduces the rule + candidates to a *minimal-but-sufficient* representative set.
-4. **DB mapping** — unique constraints, cross-entity dependency, real backend limits → precondition
-   data, not just a single input value.
-
-Then classify every value into **Valid / Boundary / Invalid** (each invalid tagged with its error
-code) and give it a `CHK-*` id for traceability.
-
-## The field-map — `qa/data-factory/<name>.fields.yaml`
-
-Your main artifact. One entry per input field; the generator expands it:
-
-```yaml
-screen: login                 # or  flow: <name>
-fields:
-  - name: email
-    type: email               # a catalog field-type (see list below)
-    required: true
-    constraints: { maxLocal: 64, maxTotal: 254 }   # the project's REAL limits from spec
-    errorMap: { M13: E1042, M02: E1001 }            # catalog placeholder code → project's real code
-  - name: password
-    type: password
-    constraints: { minLength: 8, maxLength: 32 }
-```
-
-**Catalog field-types** (P1): `email` · `password` · `phone` · `string` · `number-integer` ·
-`number-float` · `currency` · `postcode` · `katakana` (JP). Security payload banks auto-append to a
-field's invalid group via the type's `uses_security` (`sqli`, `xss`, `idor`, `broken-auth`, `upload`,
-`input-validation`).
-
-Rules:
-- Pick the closest `type`; put the project's real numbers in `constraints` (they override the
-  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.
-
-## No input fields → nothing to generate
-
-Data Factory standardizes **field-level input data**. If a unit has no user-input fields or
-parameters — a pure navigation, listing, or capture-compare flow — there is nothing to generate.
-Report *"no input fields → nothing to generate"* and skip it; do **not** write an empty field-map.
-Those scenarios are covered by the data create-test already produced, not by field-level test data.
-(This is a correct outcome, not a gap — don't force a field-map to make the unit "processed".)
-
-## Blind spots — ask, never fabricate
-
-If a field's type is **not** in the catalog — a business enum, a cross-entity constraint, a
-project-specific data model — do **not** guess. Ask the QA (via `AskUserQuestion`) for: (1) the valid
-set, (2) invalid / non-existent values, (3) the error code when wrong, (4) dependencies on other
-fields. Record it in `qa/data-factory/project/<entity>.yaml` so it becomes reusable project catalog.
-This is the core discipline: *common is never enough; when blind, think and ask — don't invent.*
-
-## Customizing the catalog — `.overwrite` (survives `sungen update`)
-
-The shipped `common/` is a floor. Project rules go in `qa/data-factory/common.overwrite.yaml`,
-deep-merged over the common (**later-wins**, keyed by `type` + data-point `id`): same `id` replaces,
-new `id` appends, `constraints` merge key-by-key. `sungen update` refreshes `common/` but never
-touches your overlay. If an update makes an overlay entry stale (references a bank/constraint that no
-longer exists), the loader **warns you to prune it** — it never edits your file. Prefer a targeted
-`errorMap`/`constraints` in the field-map for per-screen tweaks; use `.overwrite` only for rules that
-apply project-wide.
-
-## Verify before done — the phuong-phap §6 checklist
-
-Run `sungen data lint` and clear it: every required field has **≥1 valid**, **boundary present**
-(exact min/max, not only over-boundary) for bounded types, **≥1 invalid per rule** (not one generic
-"wrong" value for many rules), no `UNRESOLVED` values, error codes mapped or explicitly left open.
-Then `sungen data gen` writes the standardized `test-data/<name>.yaml`. Do not hand-edit the
-generated values — change the field-map or `.overwrite` and re-run (determinism: same input → same
-data).
-
-## Weaving into scenarios
-
-When a `.feature` exists, express invalid/boundary sets as data-driven `Scenario Outline` + `Examples`
-(`@cases`) referencing the values — see `sungen-gherkin-syntax`. This keeps one logic + many values
-instead of copy-pasted scenarios, and each row carries its `CHK-*` id for traceability.