The configurator

Pick a product line, select features with live variability validation, and walk away with the exact splent commands that build your product.

---

Table of contents

1. The flow
2. What the page enforces
3. The command block
4. Scope of the validation

---

The flow

1. Choose a product line. The chooser lists every SPL in the marketplace index that carries a parsed UVL model.
2. Select features. The configuration page renders the model as mandatory features, optional features and alternative groups.
3. Validate live. Every change re-validates the selection against the variability model and updates the result — valid or not, and why.
4. Copy the commands. A valid selection produces a copyable block of splent commands that create and derive the product.

What the page enforces

Rule	Behaviour
Mandatory features	Pre-selected and locked — they are part of every product of the line and cannot be deselected.
Requires-constraints (a => b)	Applied transitively: selecting a auto-adds b (and whatever b implies). Auto-added features are marked with an amber badge so you always see what the model added for you, and why your product is bigger than your click count.
Alternative groups	At most one member may be selected (e.g. one session backend). A group whose members are mandatory must have exactly one selection — leaving it empty is a violation.

Violations are structured and explained in plain language next to the selection — an unknown feature, two members of an alternative group, or a required group left empty — so fixing the configuration never requires reading UVL.

The command block

A valid configuration ends in the exact command sequence, ready to copy:

splent product:create my_app --spl marketplace_spl
splent product:select my_app
splent feature:add splent-io/splent_feature_theme
splent feature:add splent-io/splent_feature_auth
...
splent product:resolve
splent product:derive --dev

Nothing is executed on your behalf and no account is involved — the configurator’s only output is commands you run in your own workspace.

Scope of the validation

The configurator validates with its own logic over the index’s parsed model — mandatory presence, the transitive closure of a => b constraints, and alternative group rules. It deliberately does not embed a SAT solver: flamapy-based analysis stays in the CLI (product:validate, spl:* commands) and in UVLHub, where the full .uvl files live.

This keeps the web app dependency-free and instant, at the cost of known limits:

• Only simple implications (a => b) are understood; arbitrary cross-tree formulas in the UVL are not evaluated here.
• No cardinality or numeric constraints.
• The model it sees is the index’s parsed snapshot, not the live .uvl.

The generated command sequence ends in product:resolve / product:derive, which re-validate the configuration against the real UVL model — so the CLI remains the final authority.