Agent rules and change review
Review skill boundaries, duplicate-payment prevention, cache/identity preservation and durable consumable fulfillment.
A skill guides work; it does not guarantee generated code correctness. Review against the actual resolved release and platform tests. If versions differ from baseline, the agent must report differences instead of assuming future/older APIs.
Prohibited integration shortcuts
- Don't turn public API migration into unrelated changes to purchases, cache namespaces, retries, recovery scheduling or persisted schemas.
- Don't clear storage, pending journals or inventory, or create another customer, to fix network failure.
- Don't infer definitive failure from network errors, null lookups, empty sync or unrelated events and launch a second payment.
- Don't expose predecessor customer results or another app/store's attempt to the new session.
- Don't confirm before inventory commit, confirm inside a registered handler, or create competing grant owners.
- Don't assume RevenueCat/host wrapper methods are official Inappify APIs merely from similar names.
- Don't bypass Web bridge limits through another JS client, MethodChannels, src classes or handcrafted HTTP.
- Don't publish SDKs, deploy services, migrate production or generate real OTP/payments without explicit authorization.
Check platform boundaries
The capability matrix is contractual. This iOS release has no StoreKit/Android history; Flutter Web lacks some JS methods/policy forwarding. iOS local attempt keys don't promise Direct server deduplication. Don't hide these differences behind universal assumptions.
Fulfillment and verification evidence
Grant consumables transactionally with uniqueness scoped to app/customer/source/deliveryId. Restart/failed-confirm tests must preserve exactly-once inventory. Reconcile post-payment timeout using the same checkout/attempt. Subscription access comes from active CustomerInfo, not a local flag or bank message.
Report analyzer/unit verification and what remains untested on devices/stores. Build success proves neither a live payment nor backend deployment. Don't expose secrets as verification evidence.
Maintain the skill
Source lives in the Flutter repository. For SDK releases, recheck baseline, facade signatures, actual backends and purchase payloads; type-check examples again. New guidance must not fabricate a new contract for older apps.