feat(targeting): manage rules and guard activation

[joshdholtz]

Why

Expose targeting rules alongside experiments and make JSON config discoverable for agents.

Third PR in the stack: #179 → #180 → #181.

Changes

• Add rc targeting list|show|create|update|delete for legacy rules and checkpoint creation, with API methods in the development overlay.
• Add config_fields to rc schema targeting create|update, including required legacy schedule and placement fields plus condition operators, values, and context.
• Show a readable activation preview and resulting audience; reject audience/condition conflicts before submitting an update.
• Require approval for activation, active-rule updates and reorder, and deletion. Add API, CLI, snapshot, and mock-server coverage.
• Require --force as well as confirmation to delete active or scheduled rules.

Review note

Create, activation, and delete were exercised on a disposable project. The activation preview was checked without approving the write. Reorder still needs a live run; the agent permission layer blocked it during the manual pass.

Verification

go test ./..., go vet ./..., make gen, and make preview passed locally after rebasing onto current main.

---

Note

Medium Risk
Mutations can change which Offering or Flow customers receive; guards reduce accidental live changes but misconfiguration still has production impact.

Overview
Adds rc targeting (list, show, create, update, delete) wired to development v2 /targeting_rules via a new API client service, command-surface docs, CLI coverage, and beta overlay entries.

Create/update support legacy Offering rules (flags or --config) and checkpoint rule creation; rc schema targeting create|update documents schedule, placements, audiences vs conditions, and per-field condition rules. Human output shows audience, placements, schedule, and checkpoints; activation/update previews use readable condition summaries.

Safety: non-inactive creates, activations, changes to active rules (including reorder via position), and deletes require confirmation/--yes; deleting active or scheduled rules also requires --force. Client-side validation blocks conflicting audience_id and conditions. Checkpoint updates are rejected on the update path.

Tests cover API routes, CLI guards, schema content, and new output snapshots; the beta overlay seed script includes targeting paths.

^{Reviewed by Cursor Bugbot for commit 18c26be. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c6da01f. Configure here.}

[cursor]

Targeting responses drop rule position

Medium Severity

TargetingRule has no position field, so list/show --json drop the API's priority and the human views never show it. Reorder writes position, and active rules are first-match-wins, so agents and users cannot see current order before changing it.

Additional Locations (2)

• internal/cli/targeting.go#L46-L54
• internal/cli/targeting_format.go#L76-L155

 

^{Reviewed by Cursor Bugbot for commit c6da01f. Configure here.}

[JZDesign]

We support scheduled offering rules according to the docs… shouldn't we support them here too?

https://www.revenuecat.com/docs/tools/targeting#scheduling-targeting-rules