@sun-asterisk/sungen 3.2.12-beta.2 → 3.2.12-beta.4

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

@@ -90,6 +90,10 @@ Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data lint --screen
 
 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 **merges** the standardized field data in — it **replaces only the field keys it owns and preserves every other key** (create-test's data, flow-namespaced keys, `@cases` datasets, overrides). It asks before merging (in ALL mode after they confirmed, add `--yes`; `--force` skips the prompt). The output is standardized `valid/boundary/invalid` values with `CHK-*` traceability.
 
+### 5.5 Validate semantic correctness
+
+Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data validate --screen <name> || npx sungen data validate --screen <name>`. This is stronger than lint (coverage): it checks every generated value is **semantically** correct — each `valid`/`boundary` value actually satisfies the constraints, and each synthesized `invalid` value actually violates them (a value in the `valid` set that breaks `maxLength`, or a "below min" case that landed inside the range, is a `VALUE_NOT_VALID` error). Fix any `error`; `INVALID_LOOKS_VALID` warns are a prompt to confirm the value is invalid for a non-length reason (charset/format). Each generated value also carries an `expected: valid|invalid` field in the test-data for 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.

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

@@ -85,12 +85,15 @@ This is the core discipline: *common is never enough; when blind, think and ask
 ## 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.
+deep-merged over the common (**later-wins**, keyed by `type` + data-point `id`) via three explicit
+operations: **EXTEND** (a new `id` appends), **REPLACE** (same `id` wins; `constraints` merge
+key-by-key), **DISABLE** (list ids under `disable:` to drop shipped cases that don't apply — a stale
+target id warns). You can also override `security:` banks and `techniques:` the same way. `sungen
+update` refreshes `common/` but never touches your overlay; a stale entry **warns you to prune it** —
+it never edits your file. Nothing is silently overwritten: **`sungen data provenance`** (and a
+`⟲ .overwrite →` line at `data gen`) shows exactly what your overlay changed, and each overlaid value
+is tagged `via: .overwrite` in the test-data. Prefer a targeted `errorMap`/`constraints` in the
+field-map for per-screen tweaks; use `.overwrite` only for rules that apply project-wide.
 
 ## Bulk-import fixtures (CSV)
 
@@ -109,6 +112,14 @@ Then `sungen data gen` writes the standardized `test-data/<name>.yaml`. Do not h
 generated values — change the field-map or `.overwrite` and re-run (determinism: same input → same
 data).
 
+Then run **`sungen data validate`** — the semantic check beyond coverage. It verifies each generated
+value is *correct*, not just *present*: every `valid`/`boundary` value actually satisfies the
+constraints and every synthesized `invalid` value actually violates them. A boundary is expanded to
+**one case per point** (`min / min+1` → two cases; `< min` → min-1, below the minimum), each stamped
+`expected: valid|invalid` in the output. Any `VALUE_NOT_VALID` error means a value labeled valid breaks
+a constraint — fix the field-map/constraints and re-run. This is what stops the "structurally right but
+semantically wrong" data (e.g. a "below minimum length" case that is actually long enough to pass).
+
 ## Weaving into scenarios
 
 When a `.feature` exists, express invalid/boundary sets as data-driven `Scenario Outline` + `Examples`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sun-asterisk/sungen",
-  "version": "3.2.12-beta.2",
+  "version": "3.2.12-beta.4",
   "description": "Deterministic E2E Test Compiler - Gherkin + Selectors → Playwright tests",
   "main": "src/index.ts",
   "types": "src/index.ts",
@@ -39,8 +39,8 @@
     "@babel/types": "^7.28.5",
     "@cucumber/gherkin": "^37.0.0",
     "@cucumber/messages": "^31.0.0",
-    "@sungen/driver-data-factory": "3.2.12-beta.2",
-    "@sungen/driver-ui": "3.2.12-beta.2",
+    "@sungen/driver-data-factory": "3.2.12-beta.4",
+    "@sungen/driver-ui": "3.2.12-beta.4",
     "chalk": "^5.6.2",
     "commander": "^14.0.2",
     "dotenv": "^17.2.3",

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

@@ -90,6 +90,10 @@ Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data lint --screen
 
 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 **merges** the standardized field data in — it **replaces only the field keys it owns and preserves every other key** (create-test's data, flow-namespaced keys, `@cases` datasets, overrides). It asks before merging (in ALL mode after they confirmed, add `--yes`; `--force` skips the prompt). The output is standardized `valid/boundary/invalid` values with `CHK-*` traceability.
 
+### 5.5 Validate semantic correctness
+
+Run (local-first): `[ -x ./bin/sungen.js ] && ./bin/sungen.js data validate --screen <name> || npx sungen data validate --screen <name>`. This is stronger than lint (coverage): it checks every generated value is **semantically** correct — each `valid`/`boundary` value actually satisfies the constraints, and each synthesized `invalid` value actually violates them (a value in the `valid` set that breaks `maxLength`, or a "below min" case that landed inside the range, is a `VALUE_NOT_VALID` error). Fix any `error`; `INVALID_LOOKS_VALID` warns are a prompt to confirm the value is invalid for a non-length reason (charset/format). Each generated value also carries an `expected: valid|invalid` field in the test-data for 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.

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

@@ -85,12 +85,15 @@ This is the core discipline: *common is never enough; when blind, think and ask
 ## 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.
+deep-merged over the common (**later-wins**, keyed by `type` + data-point `id`) via three explicit
+operations: **EXTEND** (a new `id` appends), **REPLACE** (same `id` wins; `constraints` merge
+key-by-key), **DISABLE** (list ids under `disable:` to drop shipped cases that don't apply — a stale
+target id warns). You can also override `security:` banks and `techniques:` the same way. `sungen
+update` refreshes `common/` but never touches your overlay; a stale entry **warns you to prune it** —
+it never edits your file. Nothing is silently overwritten: **`sungen data provenance`** (and a
+`⟲ .overwrite →` line at `data gen`) shows exactly what your overlay changed, and each overlaid value
+is tagged `via: .overwrite` in the test-data. Prefer a targeted `errorMap`/`constraints` in the
+field-map for per-screen tweaks; use `.overwrite` only for rules that apply project-wide.
 
 ## Bulk-import fixtures (CSV)
 
@@ -109,6 +112,14 @@ Then `sungen data gen` writes the standardized `test-data/<name>.yaml`. Do not h
 generated values — change the field-map or `.overwrite` and re-run (determinism: same input → same
 data).
 
+Then run **`sungen data validate`** — the semantic check beyond coverage. It verifies each generated
+value is *correct*, not just *present*: every `valid`/`boundary` value actually satisfies the
+constraints and every synthesized `invalid` value actually violates them. A boundary is expanded to
+**one case per point** (`min / min+1` → two cases; `< min` → min-1, below the minimum), each stamped
+`expected: valid|invalid` in the output. Any `VALUE_NOT_VALID` error means a value labeled valid breaks
+a constraint — fix the field-map/constraints and re-run. This is what stops the "structurally right but
+semantically wrong" data (e.g. a "below minimum length" case that is actually long enough to pass).
+
 ## Weaving into scenarios
 
 When a `.feature` exists, express invalid/boundary sets as data-driven `Scenario Outline` + `Examples`