fix(feature-model): cross-tree constraints silently pass by avrabe · Pull Request #156 · pulseengine/rivet

avrabe · 2026-04-21T17:16:04Z

HIGH severity: silent false-positive PASS

Before this PR, rivet variant check reported PASS on variants that explicitly violated cross-tree constraints like `(implies X (not Y))`. The entire constraint surface was effectively decorative for any constraint whose consequent wasn't a bare feature name — only `excludes` had a real post-propagation check.

Root cause

`Expr::Implies` was used only to forward-propagate feature selection: "if antecedent is selected and consequent is a bare feature name, select it too." When the consequent was anything more complex (`not`, `and`, `or`, link predicate, regex), `extract_feature_name` returned `None`, the propagation loop fell through, and `solve` returned `Ok(...)`. No validation ever ran.

Fix

`rivet-core/src/feature_model.rs::solve` now runs a generic `eval_constraint` pass after propagation:

`Implies(a,b)` = `!a || b` (proper material implication)
`Excludes(a,b)` = `!(a && b)` (kept its dedicated diagnostic for backwards compat)
`And`/`Or`/`Not`/`BoolLit` proper semantics
Feature-name leaf via `extract_feature_name`
Artifact-predicate leaves default to `true` to avoid spurious violations

Evidence

Before: failing test reproduced — `(implies feature-x (not feature-y))` with both selected got `Ok`.
After: 3 regression tests pass, all 560 rivet-core lib tests still green, clippy clean.

Test plan

3 new regression tests in `feature_model::tests`
Full `cargo test -p rivet-core --lib` green
`cargo clippy --all-targets -- -D warnings` clean
CI green

🤖 Generated with Claude Code

…ions Before this change, `rivet variant check` silently reported PASS on variants that explicitly violated `(implies X (not Y))` and other cross-tree constraints where forward propagation could not auto-select a feature to satisfy the consequent. The solver only used `Expr::Implies` to schedule consequent features for selection; when the consequent was a negation, a compound, or any non-feature-name shape, no check ever fired against the propagated selection — a false-positive PASS on a safety-critical validation surface. Fix: add a `eval_constraint` pass after propagation that treats every top-level constraint as a boolean assertion over the effective feature set, with standard propositional semantics for `and`/`or`/`not`/ `implies`/`excludes`. `excludes` keeps its dedicated diagnostic string to preserve existing error messages; other shapes report through a new `describe_constraint` helper. Unknown artifact-oriented predicates (link queries, regex matches) default to true so unrelated constraint flavours do not trigger spurious violations. Regression tests cover the reported shape `(implies X (not Y))` with both X and Y selected (now FAIL), the companion case with only X selected (still PASS), and ensure forward propagation of `(implies X Y)` still works. Fixes: REQ-044

github-actions

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Rivet Criterion Benchmarks'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: `62ccd34`	Previous: `aa706fc`	Ratio
`traceability_matrix/1000`	`58483` ns/iter (`± 635`)	`45738` ns/iter (`± 588`)	`1.28`
`query/10000`	`108855` ns/iter (`± 1336`)	`90574` ns/iter (`± 529`)	`1.20`

This comment was automatically generated by workflow using github-action-benchmark.

thin-vec 0.2.14 has a Double-Free / UAF in IntoIter::drop and ThinVec::clear. Pulled in transitively via salsa 0.26.0. Rivet does not directly construct or iterate thin_vec::ThinVec — the exposure is through salsa's internal data structures. Ignore in both cargo-deny and cargo-audit until either salsa bumps its thin-vec dependency or thin-vec 0.2.15 lands upstream. Trace: skip

codecov · 2026-04-21T18:14:22Z

Codecov Report

❌ Patch coverage is 82.14286% with 20 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
rivet-core/src/feature_model.rs	82.14%	20 Missing ⚠️

📢 Thoughts on this report? Let us know!

…ry vs implied) Pain point: `rivet variant solve` output mixed user-picked features with ones the solver added via mandatory-group propagation or constraint implication. A flat list like `base, auth, oauth, token-cache, metrics` didn't tell the user which features were their intent and which were downstream effects. Minimum-impact change per scope-limits brief (risk of conflict with PR #156 cross-tree constraint work): - Extend `ResolvedVariant` with a per-feature `origins: BTreeMap<String, FeatureOrigin>` where FeatureOrigin is UserSelected / Mandatory / ImpliedBy(name) / AllowedButUnbound. - Populate origins alongside the existing selected-set fixpoint loop — no algorithmic changes. First-reason-wins on insertion so user selection beats later mandatory/implied discoveries. - Text output of `rivet variant solve` prints one feature per line, prefixed with `+`, labeled (mandatory) / (selected) / (implied by X). - JSON output is strictly additive: `effective_features` + `feature_count` preserved, new `origins` object keyed by feature name. Tests: - 4 new unit tests in rivet-core/src/feature_model.rs covering each origin variant. - 2 new integration tests in rivet-cli/tests/variant_solve_origins.rs asserting text prefixes/labels and JSON backwards compatibility. - All 15 pre-existing feature_model unit tests still pass; all 6 proptest_feature_model properties still hold. Implements: REQ-043, REQ-046 Refs: REQ-052 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs+feat(variant): feature-model schema reference + init scaffolder Pain point: users reverse-engineer the feature-model YAML schema because `rivet variant --help` has no field reference and `selects:` vs `selected:` / group types / s-expression constraint syntax / bindings file shape are undocumented. Changes: - Add docs/feature-model-schema.md: top-level reference for feature model YAML (root, features, group types, constraint syntax) with a worked example. - Add docs/feature-model-bindings.md: dedicated binding file reference. - Link both from docs/getting-started.md. - Variant subcommand doc-comment now points at the schema reference so `rivet variant --help` surfaces it. - Add `rivet variant init <name>` scaffolder that writes a starter feature-model.yaml + bindings/<name>.yaml with comments documenting every field. Tests: 3 new integration tests in rivet-cli/tests/variant_init.rs covering scaffolded file contents, overwrite protection, and that the scaffolded template parses clean via `rivet variant list`. Implements: REQ-042, REQ-043, REQ-044 Refs: REQ-046 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(hooks): pre-commit hook walks up to find rivet.yaml (marker discovery) Pain point: `rivet init --hooks` emitted a pre-commit hook that ran `rivet validate` at the git root. If the rivet project is relocated inside the working tree (e.g. moved to subdir/), the hook either silently validates the wrong directory or fails to find rivet.yaml. Fix: the installed pre-commit hook now walks up from $PWD until it finds a directory containing rivet.yaml, then cd's there before invoking `rivet validate`. If no rivet.yaml exists in the ancestor chain, the hook exits 0 silently so it does not block commits in unrelated repositories. Tests: rivet-cli/tests/hooks_install.rs adds 2 integration tests — one verifies the hook body does not embed a hard-coded -p/--project flag and uses the walk-up pattern; one stages a fresh project, moves rivet.yaml into a subdirectory, and confirms the hook still discovers it when run from a nested path. Fixes: REQ-051 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(variant): check-all + optional --variant on validate (API ergonomics) Pain point: variant-scoped validation required --model, --variant, and --binding to be passed together — there was no way to validate just model/binding consistency, and no single-invocation way to assert a whole batch of variants is valid. Changes: - `rivet validate --model X --binding Y` (no --variant) now parses the model, parses the binding, and checks that every feature referenced in the binding exists in the model. Reports a clear diagnostic on unknown feature names instead of the old "must all be provided together" error. The full --model + --variant + --binding mode is unchanged. - `rivet variant check-all --model M --binding B` iterates every variant declared under `variants:` in the binding file, prints a PASS/FAIL line per variant, and exits non-zero if any fail. - `FeatureBinding` in rivet-core grows an optional `variants:` field (default empty) so the same file can carry bindings and declared variants without schema churn. Tests: 5 new integration tests in rivet-cli/tests/variant_scoped_api.rs cover the no-variant validate mode, the unknown-feature diagnostic, check-all exit codes for mixed/all-pass fixtures, and JSON output shape. Existing feature_model unit tests still pass (binding YAML is backward-compatible — `variants:` defaults to empty). Implements: REQ-044, REQ-045, REQ-046 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(sexpr): semantic notes on filter parse errors Pain point: `[FilterError { offset: 14, message: "unexpected atom at top level" }]` exposed parser internals. Users writing `A and B`, `and A B`, or `(bogus A B)` got a positional offset with no hint that they were using the wrong syntax. Fix: extend `FilterError` with an optional `note` field, populated by a classifier that inspects the source before parsing. Three common shapes get a semantic nudge: - bare infix (`A and B`) → suggest `(and A B)`. - missing outer parens (`and A B`) → suggest wrapping it. - unknown head (`(bogus …)`) → reference the supported form list. `FilterError::Display` renders the positional detail followed by the note on a new line. Feature-model constraint errors now format via Display instead of Debug, so the note bubbles out through `rivet variant check` / `rivet validate --model` paths. Tests: 4 new unit tests in sexpr_eval covering the three error shapes plus a success case that must carry no note. All pre-existing tests unchanged. Fixes: REQ-043 Implements: REQ-042 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(variant-solve): per-feature origin tracking (selected vs mandatory vs implied) Pain point: `rivet variant solve` output mixed user-picked features with ones the solver added via mandatory-group propagation or constraint implication. A flat list like `base, auth, oauth, token-cache, metrics` didn't tell the user which features were their intent and which were downstream effects. Minimum-impact change per scope-limits brief (risk of conflict with PR #156 cross-tree constraint work): - Extend `ResolvedVariant` with a per-feature `origins: BTreeMap<String, FeatureOrigin>` where FeatureOrigin is UserSelected / Mandatory / ImpliedBy(name) / AllowedButUnbound. - Populate origins alongside the existing selected-set fixpoint loop — no algorithmic changes. First-reason-wins on insertion so user selection beats later mandatory/implied discoveries. - Text output of `rivet variant solve` prints one feature per line, prefixed with `+`, labeled (mandatory) / (selected) / (implied by X). - JSON output is strictly additive: `effective_features` + `feature_count` preserved, new `origins` object keyed by feature name. Tests: - 4 new unit tests in rivet-core/src/feature_model.rs covering each origin variant. - 2 new integration tests in rivet-cli/tests/variant_solve_origins.rs asserting text prefixes/labels and JSON backwards compatibility. - All 15 pre-existing feature_model unit tests still pass; all 6 proptest_feature_model properties still hold. Implements: REQ-043, REQ-046 Refs: REQ-052 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

avrabe mentioned this pull request Apr 21, 2026

docs: CLI gaps + severity backlog (real-world 3400-artifact project) #161

Merged

github-actions Bot reviewed Apr 21, 2026

View reviewed changes

avrabe merged commit 56087b8 into main Apr 21, 2026
18 of 23 checks passed

avrabe deleted the fix/variant-cross-tree-constraints branch April 21, 2026 18:52

avrabe mentioned this pull request Apr 22, 2026

fix(v0.4.1): 5 user-reported pain points (#3, #4, #6, #7, #8) #174

Merged

8 tasks

avrabe mentioned this pull request Apr 22, 2026

S-expression query language + product line engineering (variant management) #128

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(feature-model): cross-tree constraints silently pass#156

fix(feature-model): cross-tree constraints silently pass#156
avrabe merged 2 commits intomainfrom
fix/variant-cross-tree-constraints

avrabe commented Apr 21, 2026

Uh oh!

github-actions Bot left a comment •

edited

Loading

Uh oh!

codecov Bot commented Apr 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

avrabe commented Apr 21, 2026

HIGH severity: silent false-positive PASS

Root cause

Fix

Evidence

Test plan

Uh oh!

github-actions Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

⚠️ Performance Alert ⚠️

Uh oh!

codecov Bot commented Apr 21, 2026

Codecov Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

github-actions Bot left a comment •

edited

Loading