Every public declaration in this module is intended to be visible only
to the rest of the SDK (`:purchases`, `:ui:revenuecatui`, hybrid
bridges), not to app developers, so put the opt-in gate in place from
day one instead of bolting it on later.

Sibling annotation, not the existing one
----------------------------------------

`@InternalRevenueCatAPI` lives in `:purchases` and we deliberately
keep `:rules-engine` standalone (no dependency on `:purchases`), so
this defines a parallel `@InternalRulesEngineAPI` in
`com.revenuecat.purchases.rules` with identical
`@RequiresOptIn(level=ERROR)` semantics. Two annotations doing the
same job is mildly redundant but unambiguous in the IDE and avoids
coupling the two modules just for an annotation.

Changes
-------

- New `InternalRulesEngineAPI.kt` mirroring the shape of
  `:purchases`'s `InternalRevenueCatAPI`.
- `RulesEngine` object annotated with `@InternalRulesEngineAPI`.
- Test class opts in with `@OptIn(InternalRulesEngineAPI::class)`.
- Metalava configured (per-module) to add
  `com.revenuecat.purchases.rules.InternalRulesEngineAPI` to the
  hidden-annotations list, on top of the
  `com.revenuecat.purchases.InternalRevenueCatAPI` entry already added
  by the `revenuecat-public-library` convention plugin.
- `api.txt` regenerated: `RulesEngine` is now hidden; the annotation
  itself remains public so consumers can opt in.

Verified
--------

- `./gradlew :rules-engine:testDefaultsDebugUnitTest` ✔
- `./gradlew :rules-engine:metalavaCheckCompatibilityDefaultsRelease` ✔
- `./gradlew detektAll` ✔

Co-authored-by: Cursor <cursoragent@cursor.com>

Drop the explainer comment above the `mavenPublishing.configure(...)`
override in `rules-engine/build.gradle.kts` and the doc on
`InternalRulesEngineAPI`. The behavior is self-evident from the code
and the annotation already carries a `@RequiresOptIn` message.

Co-authored-by: Cursor <cursoragent@cursor.com>

…public API

Adds scripts/check-rules-engine-internal-only.sh which regenerates rules-engine/api.txt and asserts it contains only the @InternalRulesEngineAPI annotation declaration. Unlike a baseline diff, this check is intrinsic and cannot be silenced by regenerating api.txt.

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: Cursor <cursoragent@cursor.com>

…ine-enforce-internal-api

…merge)

Co-authored-by: Cursor <cursoragent@cursor.com>

…github.com/RevenueCat/purchases-android into pallares/rules-engine-enforce-internal-api

First slice of the JSON Logic rules engine in the new `:rules-engine`
module (built on top of the module skeleton from
`pallares/rules-engine-skeleton`). Pure Kotlin, no exported API
surface — every new declaration is module-`internal` so the engine can
land incrementally without changing `rules-engine/api.txt` or pulling
anything into the SDK's metalava signature.

What's in:

- `Logger.kt` — internal `RulesEngineLogger` interface + default
  `PrintlnLogger` (stderr) + test `CapturingLogger`. Kept internal so a
  future host-supplied logger can be adapted to the same interface
  without API churn.
- `Value.kt` — typed `Value` sealed class (`Null` / `BoolValue` /
  `IntValue` / `FloatValue` / `StringValue` / `ArrayValue` /
  `ObjectValue`), JSON Logic truthiness + loose (`==`) / strict (`===`)
  equality with type coercion.
- `RuleError.kt` — `RuleError` sealed `RuntimeException` (`Parse`,
  `TypeMismatch`, `UnsupportedOperator`).
- `Evaluator.kt` — top-level dispatcher; takes a typed `Value`
  predicate (no JSON parsing in the engine) and returns `Boolean`.
- `operators/` — MVP set: `var` (strict dot-path), `missing`, `==`,
  `!=`, `===`, `!==`, `!`, `!!`, `and`, `or`, `if`.
- Test source set adds a `helpers/ValueJsonHelper.kt` (`org.json` +
  `BigDecimal` scale check to preserve int-vs-decimal intent) so test
  predicates can be expressed as JSON literals — production callers
  will construct `Value` trees from the host SDK's own JSON parser.

Key decisions:

- **JSON parsing lives outside the engine.** The engine accepts a typed
  `Value` tree (the JSON-shaped sealed class is what cross-language
  bridges can express across the boundary). The `org.json`-backed JSON
  helper is gated to the test source set only via a new
  `testImplementation(libs.json)` dep.
- **Missing variables** resolve to `Null` and emit a warning, per JSON
  Logic spec. No `MissingVariable` subclass in v1; reserved for a
  future strict mode.
- **`var` lookup** uses strict dot-path navigation. Flat-key fallback
  considered and deferred — pure addition if we need it later.

Verification:

- `./gradlew :rules-engine:test` — 63 tests, 0 failures.
- `./gradlew :rules-engine:check` — `lint` + `metalavaCheckCompatibility`
  pass; `api.txt` unchanged because every new declaration is
  `internal`.
- `./gradlew detektAll` — clean.

Co-authored-by: Cursor <cursoragent@cursor.com>

…(do not merge)"

This reverts commit b7bbd5e.

…rge)"

This reverts commit 6e38341.

Extends the JSON Logic operator set with arithmetic so predicates can
express counter and sum conditions before the comparison and string
operators land.

What's new:

- `+`, `-`, `*`, `/`, `%` per the JSON Logic spec, including variadic
  `+` and `*`, the 1-arg numeric-cast form of `+`, and unary negation
  via `-`. All arithmetic returns `Value.FloatValue(Double)` for
  consistency with the JS reference (which `parseFloat`s every
  operand). `looseEq` and `strictEq` already bridge `IntValue(n) ↔
  FloatValue(n.0)`, so existing comparisons keep working.
- Non-numeric operands (`ObjectValue`, `ArrayValue`, unparseable
  strings) coerce to `Double.NaN` and propagate through arithmetic —
  the result is `FloatValue(NaN)`, falsy under `isTruthy`.
- Division and modulo by zero return `Value.Null` (deliberate
  deviation from JS's `Infinity` / `NaN` — friendlier for rule
  authors and matches the engine's "missing value" convention).
  Documented in the type's KDoc.

Tests:

- `ArithmeticOperatorsTest` covers each operator (basic, variadic,
  coercion, NaN propagation, divide/mod by zero, arity errors).
- `EvaluatorTest` adds two integration tests through dispatch:
  `var * 2 == 6` and the divide-by-zero → null → falsy flow.

Co-authored-by: Cursor <cursoragent@cursor.com>

Extends the JSON Logic operator set with the comparison operators rule
authors need to express numeric thresholds and ranges.

What's new:

- `<`, `<=`, `>`, `>=` per the JSON Logic spec.
- `<` and `<=` accept the 3-arg between form (`{"<=": [1, x, 10]}`
  reads as `1 <= x <= 10`). `>` and `>=` are binary only, matching
  the JS reference.
- All operators coerce operands through `Value.toNumberOrNull` and
  compare as `Double`. Non-numeric operands (`ObjectValue`,
  `ArrayValue`, unparseable strings) become `Double.NaN`; per
  IEEE 754 every comparison against NaN is `false`, so a malformed
  operand makes the predicate fail closed.

String semantics deviate from the JS reference (which compares two
strings lexicographically, e.g. `"10" < "9"` is true). We always
coerce numerically — `"10" < "9"` is false. Documented in the type's
KDoc.

Tests:

- `ComparisonOperatorsTest` covers each operator (basic, between
  form, coercion, NaN propagation, no-between for `>` / `>=`, arity
  errors).
- `EvaluatorTest` adds two integration tests through dispatch:
  `var >= 3` and the 3-arg `1 <= var <= 10` between form.

Co-authored-by: Cursor <cursoragent@cursor.com>

Implements `in`, `cat`, `substr`, `merge`, and `missing_some` so v1
targeting predicates can express string-content, array-membership, and
"any N of these fields populated" checks.

What's new:

- New `StringArrayOperators` covers `in`, `cat`, `substr`, and
  `merge`.
- `opMissingSome` lives next to `opMissing` in `AccessorOperators` —
  it reuses the same dot-path lookup, so co-locating beats spawning a
  parallel module.
- `Operators` dispatch table extended with all five operators.

Behavior notes (deviations from the JSON Logic JS reference, both
documented in type-level KDocs and unit-tested):

- **`in` array membership uses `looseEq` instead of strict `===`.**
  Rule authors regularly write integer literals against
  backend-supplied string lists (`{"in": [{"var": "tier_id"},
  ["1", "2", "3"]]}` etc.); strict equality would silently fail
  those, loose equality matches the rest of our equality story.
- **`substr` slices by Unicode code points**, not UTF-16 code units.
  Matches Kotlin's `String.codePointCount` semantics and gives the
  intuitive answer for multibyte strings. Differs from JS only for
  surrogate-pair characters, which are vanishingly rare in real
  rule data.

A few smaller decisions that follow JS:

- `cat` stringifies via a JS-style `String(value)` helper (`null` →
  `"null"`, arrays → comma-joined, objects → `"[object Object]"`).
- `substr` with negative `length` mirrors the JS reference's
  two-step impl (drop from the right of the substring-from-start).
- `missing_some` falls back to `0` for non-numeric `min_required`,
  matching our other operators' lenient numeric coercion.

Tests:

- `StringArrayOperatorsTest` covers each of the four operators.
- `AccessorOperatorsTest` extended with `missing_some` cases
  (threshold met, below threshold, zero required, dot-paths, arity
  errors).
- `EvaluatorTest` adds two integration tests through dispatch: a
  `country in [...]` membership check, and a `missing_some` gate
  inside an `if`.

Co-authored-by: Cursor <cursoragent@cursor.com>

- Gate the `mavenPublishing { ... }` configuration on the
  `com.vanniktech.maven.publish` plugin actually being applied.
  `ConfigureConditionalPublishing` in the convention plugin skips the
  publish plugin when `ANDROID_VARIANT_TO_PUBLISH` contains
  `customEntitlementComputation` (which `:rules-engine` doesn't have),
  so the unconditional block was breaking
  `./gradlew :purchases:publish -PANDROID_VARIANT_TO_PUBLISH=customEntitlementComputationBc8Release`
  — i.e. the "Deploying Custom Entitlements Computation version"
  fastlane step — with `Unresolved reference: mavenPublishing` while
  configuring `:rules-engine`.

- Suppress `:rules-engine` from `dokkaHtmlMultiModule`. The existing
  `HideInternalRevenueCatAPIPlugin` is hardcoded to
  `com.revenuecat.purchases.InternalRevenueCatAPI` and only applied to
  `:purchases`, so without this `RulesEngine` and `InternalRulesEngineAPI`
  would leak into the published docs at `docs/{version}/`. Every public
  symbol in this module is gated by `@InternalRulesEngineAPI`, so a
  dedicated docs page would be empty anyway — suppressing the module
  is simpler than generalizing the hide-plugin.

- Add `:rules-engine:metalavaGenerateSignatureDefaultsRelease` to
  `scripts/api-dump.sh`. The script previously only invoked the
  `Bc8`/`Bc7`/`customEntitlement` task names, so `:rules-engine`
  (single-flavor, no `billingclient` dimension) was never regenerated,
  meaning the committed `rules-engine/api.txt` couldn't act as a
  tripwire via `scripts/api-check.sh`. With this change a leaked
  non-internal API would show up as a diff in CI.

Verified:
- `:purchases:publish --dry-run -PANDROID_VARIANT_TO_PUBLISH=customEntitlementComputationBc8Release` now only fails on the unrelated `mavenCentralUsername`/`Password` credentials error.
- `:rules-engine:dokkaHtmlPartial` reports `Exiting Generation: Nothing to document`.
- `scripts/api-dump.sh` runs the rules-engine task and `api.txt` round-trips clean.
- `:rules-engine:testDefaultsReleaseUnitTest`, `:rules-engine:metalavaCheckCompatibilityDefaultsRelease`, and `detektAll` all pass.

Co-authored-by: Cursor <cursoragent@cursor.com>

# Conflicts:
#	scripts/api-dump.sh

The module is currently a skeleton with no functionality and no
consumers, so publishing `purchases-rules-engine` would ship an empty
artifact whose Maven Central version we'd then be on the hook to keep
publishing forever. Defer the publishing wiring until the JSON Logic
engine lands.

- Short-circuit `:rules-engine` in `ConfigureConditionalPublishing` so
  `com.vanniktech.maven.publish` is never applied to it. The module
  still compiles, gets detekt'd, runs tests, and is dokka-suppressed on
  every PR — there's just no AAR pushed to Sonatype.
- Drop the `mavenPublishing { configure(AndroidSingleVariantLibrary(…)) }`
  block (and its imports) from `rules-engine/build.gradle.kts`. With the
  publish plugin no longer applied, it's unreachable.
- Remove `api(project(":rules-engine"))` from `:bom` so consumers
  exploring the BoM don't see a real-looking `purchases-rules-engine`
  they could pull in and get nothing.
- Drop the `:rules-engine:metalavaGenerateSignatureDefaultsRelease`
  entry from `scripts/api-dump.sh`. It will be re-added in the same
  follow-up PR that flips publishing back on, to keep all the "publish
  wiring" in one switch-flip.

Follow-up PR (alongside the first real consumer of `RulesEngine`):
revert the `:rules-engine` short-circuit, restore the
`mavenPublishing { … }` block (gated with `plugins.withId(...)` so it
doesn't break CE deploys), restore the `:bom` entry, and re-add the
api-dump invocation.

Verified:
- `:purchases:publish --dry-run -PANDROID_VARIANT_TO_PUBLISH=customEntitlementComputationBc8Release` only fails on the unrelated `mavenCentralUsername`/`Password` credentials error — `:rules-engine` configures cleanly.
- `:rules-engine:tasks --all` lists no Maven publish tasks (only the unrelated `prepareLintJarForPublish` Android Lint internal).
- `:bom:tasks` resolves without `:rules-engine`.
- `:rules-engine:testDefaultsReleaseUnitTest`, `:rules-engine:metalavaCheckCompatibilityDefaultsRelease`, `:rules-engine:dokkaHtmlPartial`, and `detektAll` all pass.
- `scripts/api-dump.sh` leaves all `api*.txt` files unchanged.

Co-authored-by: Cursor <cursoragent@cursor.com>

Keep this PR minimal: an internal kotlin android library that
compiles, tests, and gets detekt'd. Everything that's only relevant
when the module ships an artifact lives in a separate draft PR:

- Drop the module-level `metalava { … }` block (and the committed
  `api.txt` baseline). Without a CI step regenerating it, the file
  was just static; we'll re-add both — and wire them into
  `scripts/api-dump.sh` — once publishing flips on.
- Drop the `dokkaHtmlPartial` suppression. The module would only show
  up in `dokkaHtmlMultiModule` output once it's published, so there's
  nothing to hide today.

Replace the two trailing comments with a single short pointer to the
follow-up PR and the `ConfigureConditionalPublishing` short-circuit.

Co-authored-by: Cursor <cursoragent@cursor.com>

…into pallares/rules-engine-enforce-internal-api

The `metalava { hiddenAnnotations.add(…) }` block lives in this branch
(rather than the skeleton) because the
`scripts/check-rules-engine-internal-only.sh` guardrail is the only
thing that depends on it: it asserts that, once
`@InternalRulesEngineAPI`-annotated declarations are hidden, the
generated `api.txt` contains nothing but the annotation interface
itself. Anything else is a leaked non-internal public API.

Without this block, the skeleton would have nothing exercising metalava
on `:rules-engine` (publishing wiring also lives in a separate draft
PR), so we keep it co-located with the check that needs it.

Co-authored-by: Cursor <cursoragent@cursor.com>

`metalava { hiddenAnnotations.add(InternalRulesEngineAPI) }` + a
committed `api.txt` are standard hygiene for every module that uses
`revenuecat.public.library`. The CocoaPods/Maven publishing wiring is
the only thing that's truly "exists but unwired" in this PR and that
already moved to its own draft.

Keeping the metalava config here also avoids a duplicate `metalava {}`
block landing in both the distribution PR (which adds the
`api-dump.sh` entry to enforce drift) and the enforce-internal-api PR
(which uses metalava to verify nothing leaks outside
`@InternalRulesEngineAPI`).

The `api.txt` file is not yet regenerated by CI in this PR — that
follow-up lives in the distribution draft PR.

Co-authored-by: Cursor <cursoragent@cursor.com>

…into pallares/rules-engine-enforce-internal-api

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: Cursor <cursoragent@cursor.com>

Resolve conflicts: keep arithmetic operators and extended ToNumber
coercion from this branch, take main's RulesEngine.setLogger API and
evaluator visibility, and merge TypeMismatch with UnsupportedOperator.

Co-authored-by: Cursor <cursoragent@cursor.com>

The internal module opts out of Metalava; drop the accidental api.txt
and revert the unrelated api-dump.sh comment so this PR stays focused
on arithmetic operators only.

Co-authored-by: Cursor <cursoragent@cursor.com>

…/json-logic-comparison-operators

Resolve conflicts: keep comparison operators with arithmetic from main and
align rules-engine-internal logger and evaluator APIs with main.

Co-authored-by: Cursor <cursoragent@cursor.com>

Match json-logic-js: after ToPrimitive (number hint), lex compare only when
both sides are strings; compound-vs-string uses jsString, not numeric coercion.

Co-authored-by: Cursor <cursoragent@cursor.com>

Use a when expression instead of multiple return statements.

Co-authored-by: Cursor <cursoragent@cursor.com>

Use Array.prototype.join semantics for cat null operands and jsToNumber
for missing_some threshold comparisons so NaN and unparseable need
counts never satisfy per json-logic-js.

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: Cursor <cursoragent@cursor.com>

Reject empty-string haystacks before substring search per json-logic-js,
and add tests for null substr length, object cat operands, and empty
haystack membership.

Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: Cursor <cursoragent@cursor.com>

…github.com/RevenueCat/purchases-android into pallares/json-logic-string-array-operators

Suppress ReturnCount on clampedInt, name substr operand counts, and
avoid String.codePoints (API 24) for minSdk 23 compatibility.

Co-authored-by: Cursor <cursoragent@cursor.com>