nextlevelbuilder/ui-ux-pro-max-skill · error · ValueError
unknown decision-rule condition: {}
Error message
unknown decision-rule condition: {} What it means
Each top-level key must be a condition in ALLOWED_CONDITIONS, which is exactly {"must_have"} plus the 36 if_* signal conditions defined in CONDITION_SIGNALS (if_booking, if_mobile, if_ux_focused, ...). Any other key — a typo, a renamed condition, or free-form text — raises this ValueError naming the offending condition.
Source
Thrown at src/ui-ux-pro-max/scripts/reasoning_contract.py:77
result = {}
for key, value in pairs:
if key in result:
raise ValueError("duplicate decision-rule key: {}".format(key))
result[key] = value
return result
def parse_decision_rules(raw):
"""Parse the canonical condition -> action-array representation."""
try:
rules = json.loads(raw or "{}", object_pairs_hook=_object_without_duplicates)
except json.JSONDecodeError as error:
raise ValueError("invalid decision-rule JSON: {}".format(error)) from error
if not isinstance(rules, dict):
raise ValueError("decision rules must be a JSON object")
for condition, actions in rules.items():
if condition not in ALLOWED_CONDITIONS:
raise ValueError("unknown decision-rule condition: {}".format(condition))
if not isinstance(actions, list) or not actions:
raise ValueError("{} must map to a non-empty action array".format(condition))
for action in actions:
_validate_action(action)
if len(actions) != len(set(actions)):
raise ValueError("{} contains duplicate actions".format(condition))
return rules
def _validate_action(action):
if not isinstance(action, str) or ":" not in action:
raise ValueError("action must use a known prefix: {}".format(action))
prefix, value = action.split(":", 1)
if prefix not in ACTION_PREFIXES:
raise ValueError("unknown decision-rule action: {}".format(action))
if prefix in TOKEN_ACTION_PREFIXES and not TOKEN_RE.fullmatch(value):
raise ValueError("invalid {} action value: {}".format(prefix, value))
if prefix == "pattern" and not value.strip():View on GitHub (pinned to a38d04c3d5)
Solutions
- Check the failing key against the allowed list in the message's source file: ALLOWED_CONDITIONS in src/ui-ux-pro-max/scripts/reasoning_contract.py:45.
- Fix typos and casing: conditions are lowercase snake_case starting with if_ (or exactly "must_have").
- If a new condition is genuinely needed, add its signal words to CONDITION_SIGNALS in the same file — the allowed set is derived from it — and update tests.
- Remove conditions that no longer exist in the vocabulary instead of keeping them for forward-compatibility; the grammar is closed by design.
Example fix
// before
{"if-Mobile": ["mode:dark"], "always": ["style:minimal"]}
// after
{"if_mobile": ["mode:dark"], "must_have": ["style:minimal"]} Defensive patterns
Strategy: validation
Validate before calling
from src.ui_ux_pro_max.scripts.reasoning_contract import ALLOWED_CONDITIONS
unknown = set(json.loads(raw)) - ALLOWED_CONDITIONS
if unknown:
raise ValueError(f"unknown conditions {sorted(unknown)}; allowed: {sorted(ALLOWED_CONDITIONS)}") Type guard
def is_known_condition(key: str) -> bool:
return key in ALLOWED_CONDITIONS # {"must_have", *CONDITION_SIGNALS} Try / catch
try:
rules = rc.parse_decision_rules(raw)
except ValueError as exc:
if 'unknown decision-rule condition' in str(exc):
bad = str(exc).rsplit(":", 1)[-1].strip()
raw = json.dumps({k: v for k, v in json.loads(raw).items() if k in rc.ALLOWED_CONDITIONS})
# dropped condition logged; re-parse remaining rules
rules = rc.parse_decision_rules(raw) Prevention
- Generate rule payloads from ALLOWED_CONDITIONS at runtime instead of hardcoding key names.
- Re-run the contract tests in scripts/tests after any change to CONDITION_SIGNALS so stale payloads fail in CI, not production.
- Note the vocabulary is versioned with the toolkit: re-validate stored rule blobs after upgrades.
When it happens
Trigger: parse_decision_rules with keys like "if-Mobile" (hyphen/case mismatch), "if_mobile_ui" (suffix typo), "always" (not in the closed set), or a condition added to CONDITION_SIGNALS only in a newer version while the payload was authored against an older (or newer) vocabulary.
Common situations: Hand-authoring rules against the README's condition list and mistyping one; upgrading the toolkit so the condition vocabulary changed while stale rule payloads remain in data files.
Related errors
- unknown decision-rule action: {}
- duplicate decision-rule key: {}
- decision rules must be a JSON object
- {} must map to a non-empty action array
- {} contains duplicate actions
AI-assisted analysis of nextlevelbuilder/ui-ux-pro-max-skill@a38d04c3d5 (2026-08-14).
Data as JSON: /api/errors/e138702641504ab1.
Report an issue: GitHub.