@lexq/cli 0.3.1 → 1.0.0

package/skills/lexq-recipes/SKILL.md

@@ -20,7 +20,11 @@ lexq versions create --group-id <gid> --json '{"commitMessage": "Initial tiered
 
 # 3. Register facts (skip if already exist)
 lexq facts create --key paymentAmount --name "Payment Amount" --type NUMBER --required
-lexq facts create --key customerTier --name "Customer Tier" --type STRING
+lexq facts create --key customerTier --name "Customer Tier" --type STRING \
+  --allowed-values "VIP, GOLD, SILVER"
+# A value domain says which values the fact accepts. It refuses a rule literal that could
+# never match (a typo like "PLATNUM"), and the Console offers a dropdown instead of a text box.
+# Leave it off when the set is open — a country code, an account id, a free-text label.
 
 # 4. Add rules — creation order becomes priority order (first created = priority 1 = highest)
 lexq rules create --group-id <gid> --version-id <vid> --json '{

package/skills/lexq-shared/SKILL.md

@@ -47,6 +47,7 @@ This is the typical lifecycle. **Always follow this order:**
 1. lexq groups create          → Create a policy group
 2. lexq versions create        → Create a DRAFT version inside it
 3. lexq facts create           → Register input variables (if not already defined)
+                               → --allowed-values / --min / --max constrain what callers may send
 4. lexq rules create           → Add rules with conditions + actions
 5. lexq analytics dry-run      → Test with sample facts (validate before publish)
 6. lexq deploy publish         → DRAFT → ACTIVE (locks the version)

package/skills/lexq-simulation/SKILL.md

@@ -186,12 +186,18 @@ rule you expect never appears in `decisionTraces`, check the version's `effectiv
 - **empty** — the condition was evaluated and did not match
 - **`Evaluation error: <code>`** — the condition could not be evaluated at all
 
-| Code                    | Meaning                                                            |
-|-------------------------|--------------------------------------------------------------------|
-| `FACT_NOT_PROVIDED`     | The rule references a fact absent from the request                 |
-| `FACT_TYPE_MISMATCH`    | The fact's runtime type does not match the condition               |
-| `UNSUPPORTED_FACT_TYPE` | Operator not valid for the fact's type (e.g. `CONTAINS` on a list) |
-| `MALFORMED_RULE`        | The stored rule is structurally invalid                            |
+Each code says **who fixes it**.
+
+| Code                           | Who fixes it | Meaning                                                    |
+|--------------------------------|--------------|------------------------------------------------------------|
+| `FACT_NOT_PROVIDED`            | the caller   | The rule reads a fact the request did not include          |
+| `FACT_TYPE_MISMATCH`           | the caller   | The value sent has the wrong type for the condition        |
+| `CONDITION_VALUE_TYPE_INVALID` | the author   | The literal stored in the rule is wrong for its operator   |
+| `MALFORMED_RULE`               | nobody       | The stored rule is structurally invalid. Report it         |
+
+`CONDITION_VALUE_TYPE_INVALID` is worth escalating. The right-hand side of a condition belongs
+to the rule, not to your request, so changing the payload will not help — the rule fails the
+same way for every caller. It also got past the check that is supposed to reject it on save.
 
 A rule from another group referencing facts you did not send yields `FACT_NOT_PROVIDED` — this
 is normal, not an error.