@sylphx/flow 2.11.0 → 2.12.0

package/assets/slash-commands/review-growth.md

@@ -1,6 +1,6 @@
 ---
 name: review-growth
-description: Review growth - onboarding, viral mechanics, retention
+description: Review growth - activation, retention, virality
 agent: coder
 ---
 
@@ -12,46 +12,29 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify growth opportunities and conversion improvements.
+* **Explore beyond the spec**: identify growth opportunities that don't yet exist.
 
 ## Tech Stack
 
 * **Analytics**: PostHog
 * **Framework**: Next.js
 
-## Review Scope
+## Non-Negotiables
 
-### Growth System (Onboarding, Share/Viral, Retention)
+* Sharing/virality mechanics must be consent-aware
+* Growth instrumentation must not violate privacy constraints
 
-* The review must produce a coherent, measurable growth system for activation, sharing/virality, and retention, aligned with compliance and anti-abuse constraints.
+## Context
 
-### Onboarding
+Growth isn't about tricks — it's about removing friction from value delivery. Users who quickly experience value stay; users who don't, leave.
 
-* Onboarding must be:
-  * Outcome-oriented
-  * Localized
-  * Accessible
-  * Instrumented
+The review should consider: what's preventing users from reaching their "aha moment" faster? What would make them want to share? What brings them back? These aren't features to add — they're fundamental product questions.
 
-### Sharing/Virality
+## Driving Questions
 
-* Sharing/virality must be:
-  * Consent-aware
-  * Abuse-resistant
-  * Measurable end-to-end
-
-### Retention
-
-* Retention must be:
-  * Intentionally engineered
-  * Monitored
-  * Protected against regressions
-
-## Key Areas to Explore
-
-* What is the current activation rate and where do users drop off?
-* How can time-to-value be reduced for new users?
-* What viral mechanics exist and how effective are they?
-* What retention patterns exist and what predicts churn?
-* How does the product re-engage dormant users?
-* What experiments could drive meaningful growth improvements?
+* Where do users drop off before experiencing value?
+* What would cut time-to-value in half?
+* Why would a user tell someone else about this product?
+* What brings users back after their first session?
+* What signals predict churn before it happens?
+* What would a 10x better onboarding look like?

package/assets/slash-commands/review-i18n.md

@@ -1,6 +1,6 @@
 ---
 name: review-i18n
-description: Review i18n - locales, routing, canonicalization, UGC
+description: Review i18n - localization, routing, translation quality
 agent: coder
 ---
 
@@ -12,43 +12,30 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for coverage, quality, and user experience.
+* **Explore beyond the spec**: identify what would make the product feel native to each locale.
 
 ## Tech Stack
 
 * **i18n**: next-intl
 * **Framework**: Next.js
 
-## Review Scope
+## Non-Negotiables
 
-### Supported Locales
-
-`en`, `zh-Hans`, `zh-Hant`, `es`, `ja`, `ko`, `de`, `fr`, `pt-BR`, `it`, `nl`, `pl`, `tr`, `id`, `th`, `vi`
-
-### URL Strategy: Prefix Except Default
-
-* English is default and non-prefixed.
-* `/en/*` must not exist; permanently redirect to non-prefixed equivalent.
-* All non-default locales are `/<locale>/...`.
-
-### Globalization Rules
-
-* Intl formatting for dates, numbers, currency
-* Explicit fallback rules
+* `/en/*` must not exist (permanently redirect to non-prefixed)
 * Missing translation keys must fail build
 * No hardcoded user-facing strings outside localization
 
-### UGC Canonicalization
+## Context
+
+Internationalization isn't just translation — it's making the product feel native to each market. Bad i18n is obvious to users and signals that they're second-class citizens. Good i18n is invisible.
 
-* Separate UI language from content language.
-* Exactly one canonical URL per UGC resource determined by content language.
-* No indexable locale-prefixed duplicates unless primary content is truly localized; otherwise redirect to canonical.
-* Canonical/hreflang/sitemap must reflect only true localized variants.
+Consider: dates, numbers, currency, pluralization, text direction, cultural norms. Does the product feel like it was built for each locale, or does it feel like a translation of an English product?
 
-## Key Areas to Explore
+## Driving Questions
 
-* How complete and consistent are the translations across all locales?
-* What user-facing strings are hardcoded and missing from localization?
-* How does the routing handle edge cases (unknown locales, malformed URLs)?
-* What is the translation workflow and how can it be improved?
-* How does the system handle RTL languages if needed in the future?
+* What would make the product feel native to a non-English user?
+* Where do translations feel awkward or machine-generated?
+* What cultural assumptions are baked into the UX that don't translate?
+* How painful is the translation workflow for adding new strings?
+* What locales are we missing that represent real market opportunity?
+* Where do we fall back to English in ways users would notice?

package/assets/slash-commands/review-ledger.md

@@ -1,6 +1,6 @@
 ---
 name: review-ledger
-description: Review ledger - financial-grade balance system, immutable ledger
+description: Review ledger - balance systems, financial integrity, reconciliation
 agent: coder
 ---
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify improvements for accuracy, auditability, and reconciliation.
+* **Explore beyond the spec**: identify financial integrity risks before they become real problems.
 
 ## Tech Stack
 
@@ -20,19 +20,24 @@ agent: coder
 * **Database**: Neon (Postgres)
 * **ORM**: Drizzle
 
-## Review Scope
+## Non-Negotiables
 
-### Financial-Grade Balance System (Only if "balance/credits/wallet" exists)
+* Balances must be immutable ledger (append-only), not mutable fields
+* No floating-point for money (use deterministic precision)
+* All financial mutations must be idempotent
+* Monetary flows must be reconcilable with Stripe
 
-* Any balance concept must be implemented as an **immutable ledger** (append-only source of truth), not a mutable balance field.
-* Deterministic precision (no floats), idempotent posting, concurrency safety, transactional integrity, and auditability are required.
-* Monetary flows must be currency-based and reconcilable with Stripe; credits (if used) must be governed as non-cash entitlements.
+## Context
 
-## Key Areas to Explore
+Financial systems are unforgiving. A bug that creates or destroys money — even briefly — is a serious incident. Users trust us with their money; that trust is easily lost and hard to regain.
 
-* Is there a balance/credits system and how is it implemented?
-* If mutable balances exist, what are the risks and how to migrate to immutable ledger?
-* How does the system handle concurrent transactions?
-* What is the reconciliation process with Stripe?
-* How are edge cases handled (refunds, disputes, partial payments)?
-* What audit trail exists for financial mutations?
+If balance/credits/wallet exists, it must be bulletproof. If it doesn't exist yet, consider whether the current design would support adding it correctly. Retrofitting financial integrity is painful.
+
+## Driving Questions
+
+* Does a balance/credits system exist, and is it implemented correctly?
+* Where could money be created or destroyed by a bug?
+* What happens during concurrent transactions?
+* How would we detect if balances drifted from reality?
+* Can we prove every balance by replaying the ledger?
+* What financial edge cases (refunds, disputes, chargebacks) aren't handled?

package/assets/slash-commands/review-observability.md

@@ -1,6 +1,6 @@
 ---
 name: review-observability
-description: Review observability - logs, Sentry, correlation IDs, alerting
+description: Review observability - logging, tracing, alerting, debugging
 agent: coder
 ---
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify blind spots and debugging improvements.
+* **Explore beyond the spec**: identify the production issues we can't debug today.
 
 ## Tech Stack
 
@@ -20,24 +20,22 @@ agent: coder
 * **Analytics**: PostHog
 * **Platform**: Vercel
 
-## Review Scope
+## Non-Negotiables
 
-### Observability and Alerting (Mandatory)
+* Correlation IDs must exist end-to-end (request → job → webhook)
+* Alerts must exist for critical failures (webhook failures, auth attacks, drift)
 
-* Structured logs and correlation IDs must exist end-to-end (request/job/webhook) with consistent traceability
-* Define critical-path SLO/SLI posture
-* Define actionable alerts for:
-  * Webhook failures
-  * Ledger/entitlement drift
-  * Authentication attacks
-  * Abuse spikes
-  * Drift detection
+## Context
 
-## Key Areas to Explore
+Observability is about answering questions when things go wrong. It's 3am, something is broken, users are complaining — can you figure out what happened? How fast?
 
-* How easy is it to debug a production issue end-to-end?
+Good observability makes debugging easy. Bad observability means you're guessing, adding log lines, redeploying, and hoping. Consider: what questions would you need to answer during an incident, and can you answer them today?
+
+## Driving Questions
+
+* If something breaks in production right now, how would we find out?
 * What blind spots exist where errors go unnoticed?
-* How effective are the current alerts (signal vs noise)?
-* What SLOs/SLIs are defined and are they meaningful?
-* How does log correlation work across async boundaries?
-* What dashboards exist and do they answer the right questions?
+* How long would it take to trace a user's request through the entire system?
+* What alerts exist, and do they fire for the right things?
+* Where do we have noise that's training people to ignore alerts?
+* What production issue in the last month was hard to debug, and why?

package/assets/slash-commands/review-operability.md

@@ -1,6 +1,6 @@
 ---
 name: review-operability
-description: Review operability - async workflows, DLQ, retries, drift detection
+description: Review operability - workflows, retries, DLQ, incident response
 agent: coder
 ---
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify operational risks and reliability improvements.
+* **Explore beyond the spec**: identify what will break at 3am and how we'd fix it.
 
 ## Tech Stack
 
@@ -20,31 +20,23 @@ agent: coder
 * **Cache**: Upstash Redis
 * **Platform**: Vercel
 
-## Review Scope
+## Non-Negotiables
 
-### Async/Workflows Governance (Hard Requirement)
+* Dead-letter handling must exist and be operable (visible, replayable)
+* Side-effects (email, billing, ledger) must be idempotent or safely re-entrant
+* Drift alerts must have remediation playbooks
 
-* Define idempotency and deduplication posture
-* Define controlled retries/backoff
-* **Dead-letter handling must exist and be observable and operable**
-* **Safe replay must be supported**
-* Side-effects (email/billing/ledger/entitlements) must be governed such that they are either proven effectively-once or safely re-entrant
+## Context
 
-### Drift Detection (Hard Requirement)
+Operability is about running the system in production — not just building it. Systems fail. Jobs get stuck. State drifts. The question is: when something goes wrong, can an operator fix it without deploying code?
 
-* Drift alerts must have a defined remediation playbook (automated fix or operator workflow)
-* Each remediation must be auditable and support post-incident traceability
+Consider the operator experience during an incident. What tools do they have? What runbooks exist? Can they safely retry failed jobs? Can they detect and fix drift?
 
-### Release Safety
+## Driving Questions
 
-* Define safe rollout posture with backward compatibility
-* Rollback expectations for billing/ledger/auth changes
-
-## Key Areas to Explore
-
-* How does the system handle job failures and retries?
-* What happens to messages that fail permanently (DLQ)?
-* How are operators notified of and able to resolve stuck workflows?
-* What drift can occur between systems and how is it detected?
-* How safe is the deployment process for critical paths?
-* What runbooks exist for common operational issues?
+* What happens when a job fails permanently?
+* How would an operator know something is stuck?
+* Can failed workflows be safely replayed without duplicating side-effects?
+* What drift can occur between systems, and how would we detect it?
+* What's the rollback plan if a deploy breaks something critical?
+* What runbooks exist, and what runbooks should exist but don't?

package/assets/slash-commands/review-performance.md

@@ -1,6 +1,6 @@
 ---
 name: review-performance
-description: Review performance - budgets, Core Web Vitals, caching
+description: Review performance - speed, Core Web Vitals, bottlenecks
 agent: coder
 ---
 
@@ -12,7 +12,7 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify bottlenecks and optimization opportunities.
+* **Explore beyond the spec**: identify what's making the product feel slow.
 
 ## Tech Stack
 
@@ -20,28 +20,22 @@ agent: coder
 * **Platform**: Vercel
 * **Tooling**: Bun
 
-## Review Scope
+## Non-Negotiables
 
-### Performance Requirements
+* Core Web Vitals must meet thresholds (LCP < 2.5s, CLS < 0.1, INP < 200ms)
+* Performance regressions must be detectable
 
-* Performance must be **measurable and regression-resistant**:
-  * Define and enforce performance budgets for key journeys
-  * Define caching boundaries and correctness requirements across SSR/ISR/static and service worker behavior
-  * Monitor Core Web Vitals and server latency
-  * Alert on regressions
+## Context
 
-### Core Web Vitals Targets
+Performance is a feature. Slow products feel broken, even when they're correct. Users don't read loading spinners — they leave. Every 100ms of latency costs engagement.
 
-* LCP (Largest Contentful Paint) < 2.5s
-* FID (First Input Delay) < 100ms
-* CLS (Cumulative Layout Shift) < 0.1
-* INP (Interaction to Next Paint) < 200ms
+Don't just measure — understand. Where does time go? What's blocking the critical path? What would make the product feel instant? Sometimes small architectural changes have bigger impact than optimization.
 
-## Key Areas to Explore
+## Driving Questions
 
-* What are the current Core Web Vitals scores and where do they fall short?
-* Which pages or components are the biggest performance bottlenecks?
-* How effective is the current caching strategy?
-* What opportunities exist for code splitting and lazy loading?
-* How does the bundle size compare to industry benchmarks?
-* What database queries are slow and how can they be optimized?
+* What makes the product feel slow to users?
+* Where are the biggest bottlenecks in the critical user journeys?
+* What's in the critical rendering path that shouldn't be?
+* How large is the JavaScript bundle, and what's bloating it?
+* What database queries are slow, and why?
+* If we could make one thing 10x faster, what would have the most impact?

package/assets/slash-commands/review-pricing.md

@@ -1,6 +1,6 @@
 ---
 name: review-pricing
-description: Review pricing - pricing governance, grandfathering, migrations
+description: Review pricing - strategy, packaging, monetization
 agent: coder
 ---
 
@@ -8,38 +8,33 @@ agent: coder
 
 ## Mandate
 
-* Perform a **deep, thorough review** of pricing governance in this codebase.
+* Perform a **deep, thorough review** of pricing in this codebase.
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify monetization opportunities and pricing strategy improvements.
+* **Explore beyond the spec**: identify monetization opportunities and pricing friction.
 
 ## Tech Stack
 
 * **Payments**: Stripe
 
-## Review Scope
+## Non-Negotiables
 
-### Stripe Pricing Governance (Stripe-first, not Dashboard-first)
+* Stripe is system-of-record; internal systems must not contradict Stripe truth
+* Pricing changes must create new Stripe Prices (historical prices immutable)
+* Non-admin Stripe Dashboard changes must be detectable (drift)
 
-* Stripe is the system-of-record for products, prices, subscriptions, invoices, and disputes; internal systems must not contradict Stripe truth.
-* Pricing changes must be performed by creating new Stripe Prices and updating the "active sellable price" policy; historical prices must remain immutable for existing subscriptions unless an approved migration is executed.
-* Default pricing change policy is **grandfathering**: existing subscribers keep their current price; new customers use the currently active sellable price.
+## Context
 
-### Pricing Admin Requirements
+Pricing is strategy, not just configuration. The right pricing captures value, reduces friction, and aligns incentives. The wrong pricing leaves money on the table or drives users away.
 
-* An operational-grade Pricing Admin must exist to manage:
-  * Creation of new Stripe Prices
-  * Activation/deactivation of sellable prices
-  * Controlled bulk subscription migrations (optional)
-* All actions must be governed by RBAC, step-up controls, and audit logs.
-* Stripe Dashboard is treated as monitoring/emergency access; non-admin Stripe changes must be detectable (drift), alertable, and remediable.
+Consider the entire monetization journey: how users discover value, how they decide to pay, how they upgrade/downgrade. Where is there friction? Where are we undercharging? Where are we losing conversions?
 
-## Key Areas to Explore
+## Driving Questions
 
-* How does the pricing model compare to competitors?
-* What friction exists in the upgrade/downgrade paths?
-* How is grandfathering implemented and communicated?
-* What tools exist for pricing experimentation (A/B tests)?
-* How are pricing changes rolled out safely?
-* What analytics exist for pricing optimization decisions?
+* How does our pricing compare to competitors?
+* Where do users abandon the upgrade flow?
+* What would make upgrading feel like an obvious decision?
+* How do we communicate value at each pricing tier?
+* What pricing experiments would teach us the most?
+* If we could change one thing about pricing, what would have the biggest impact?

package/assets/slash-commands/review-privacy.md

@@ -1,6 +1,6 @@
 ---
 name: review-privacy
-description: Review privacy - consent, PII handling, data lifecycle, GDPR
+description: Review privacy - consent, PII, data lifecycle, compliance
 agent: coder
 ---
 
@@ -21,36 +21,25 @@ agent: coder
 * **Tag Management**: GTM (marketing only)
 * **Observability**: Sentry
 
-## Review Scope
+## Non-Negotiables
 
-### Consent Governance (Release-Blocking)
+* Analytics and marketing must not fire before user consent
+* PII must not leak into logs, Sentry, PostHog, or third-party services
+* Account deletion must propagate to all third-party processors
+* Marketing tags (GTM, Google Ads) must not load without consent
+* Conversion tracking must be server-truth aligned, idempotent, and deduplicated
 
-* Analytics (PostHog) and marketing/newsletter communications (Resend) must be governed by consent and user preferences.
-* Marketing tags (including GTM and Google Ads) must not load or fire without the appropriate consent.
-* Without consent, tracking and marketing sends must not occur, except for strictly necessary service communications.
-* Event schemas and attributes must follow data minimization, with explicit PII classification and handling rules.
+## Context
 
-### PII and Sensitive Data Controls (Hard Requirement)
+Privacy isn't just compliance — it's trust. Users share data expecting it to be handled responsibly. Every log line, every analytics event, every third-party integration is a potential privacy leak.
 
-* PII rules apply to logs, Sentry, PostHog, support tooling, email systems, and marketing tags/conversion payloads.
-* A consistent scrubbing/redaction standard must exist, and must be covered by automated tests to prevent leakage to third parties.
+The review should verify that actual behavior matches stated policy. If the privacy policy says "we don't track without consent," does the code actually enforce that? Mismatches are not just bugs — they're trust violations.
 
-### Data Lifecycle
+## Driving Questions
 
-* Define deletion/deactivation semantics
-* Deletion propagation to third parties
-* Export where applicable
-* **Define data classification, retention periods, deletion propagation to third-party processors, and explicit exceptions** (legal/tax/anti-fraud)
-
-### Behavioral Consistency
-
-* **Behavioral consistency is required**: policy and disclosures must match actual behavior across UI, data handling, logging/observability, analytics, support operations, and marketing tags; mismatches are release-blocking.
-
-## Key Areas to Explore
-
-* Does the consent implementation actually block tracking before consent?
-* Where does PII leak into logs, analytics, or error tracking?
-* How does account deletion propagate to all third-party services?
-* Does the privacy policy accurately reflect actual data practices?
-* What data retention policies exist and are they enforced?
-* How would the system handle a GDPR data subject access request?
+* Does the consent implementation actually block tracking, or just record preference?
+* Where does PII leak that we haven't noticed?
+* If a user requests data deletion, what actually gets deleted vs. retained?
+* Does the privacy policy accurately reflect what the code actually does?
+* How would we handle a GDPR data subject access request today?
+* What data are we collecting that we don't actually need?

package/assets/slash-commands/review-pwa.md

@@ -1,6 +1,6 @@
 ---
 name: review-pwa
-description: Review PWA - manifest, service worker, caching, push notifications
+description: Review PWA - offline experience, installation, engagement
 agent: coder
 ---
 
@@ -12,32 +12,29 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify engagement opportunities and offline capabilities.
+* **Explore beyond the spec**: identify what would make the web experience feel native.
 
 ## Tech Stack
 
 * **Framework**: Next.js
 * **Platform**: Vercel
 
-## Review Scope
+## Non-Negotiables
 
-### PWA Requirements
+* Service worker must not cache personalized/sensitive/authorized content
+* Cache invalidation on deploy must be correct (no stale content)
 
-* Manifest file complete and valid
-* Service worker with explicit cache correctness
-* Push notifications using VAPID where applicable
+## Context
 
-### Service Worker Caching Boundary (Mandatory)
+A PWA is an opportunity to deliver native-like experience without an app store. But a bad PWA is worse than no PWA — stale content, broken offline states, and confusing installation prompts erode trust.
 
-* Service worker must not cache personalized/sensitive/authorized content
-* Authenticated and entitlement-sensitive routes must have explicit cache-control and SW rules
-* Must be validated by tests to prevent stale or unauthorized state exposure
+Consider: what would make users want to install this? What should work offline? How do we handle the transition between online and offline gracefully?
 
-## Key Areas to Explore
+## Driving Questions
 
-* Does the PWA meet installation criteria on all platforms?
-* What is the offline experience and how can it be improved?
-* How does the service worker handle cache invalidation on deploys?
-* What push notification capabilities exist and how are they used?
-* Are there any caching bugs that expose stale or unauthorized content?
-* How does the PWA experience compare to native app expectations?
+* Would users actually want to install this as an app? Why or why not?
+* What should the offline experience be, and what is it today?
+* What happens when users go offline in the middle of something important?
+* How do we handle cache invalidation without breaking the experience?
+* What push notification opportunities exist that we're not using?
+* What would make the installed experience better than the browser experience?

package/assets/slash-commands/review-referral.md

@@ -1,6 +1,6 @@
 ---
 name: review-referral
-description: Review referral - attribution, anti-fraud, rewards, clawback
+description: Review referral - attribution, rewards, fraud prevention
 agent: coder
 ---
 
@@ -12,39 +12,30 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
-* **Explore beyond the spec**: identify growth opportunities and fraud prevention improvements.
+* **Explore beyond the spec**: identify growth opportunities and fraud vectors.
 
 ## Tech Stack
 
 * **Analytics**: PostHog
 * **Database**: Neon (Postgres)
 
-## Review Scope
+## Non-Negotiables
 
-### Referral (Anti-Abuse Baseline Required)
+* Referral rewards must have clawback capability for fraud
+* Attribution must be auditable (who referred whom, when, reward status)
+* Velocity controls must exist to prevent abuse
 
-* Referral must be measurable, abuse-resistant, and governed:
-  * Attribution semantics
-  * Reward lifecycle governance (including revocation/clawbacks)
-  * Anti-fraud measures
-  * Admin reporting/audit
-  * Localized and instrumented
+## Context
 
-### Referral Anti-Fraud Minimum Baseline (Mandatory)
+Referral programs can drive explosive growth — or become fraud magnets. The best referral programs make sharing natural and rewarding. The worst become liability when abusers exploit them.
 
-* Define a minimum set of risk signals and enforcement measures, including:
-  * Velocity controls
-  * Account/device linkage posture
-  * Risk-tiered enforcement
-  * Reward delay/hold/freeze
-  * Clawback conditions
-  * Auditable manual review/appeal posture where applicable
+Consider both sides: what makes users want to share? And what prevents bad actors from gaming the system? A referral program that's easy to abuse is worse than no referral program.
 
-## Key Areas to Explore
+## Driving Questions
 
-* How effective is the current referral program at driving growth?
-* What fraud patterns have been observed and how are they mitigated?
-* How does the attribution model handle edge cases (multiple touches, expired links)?
-* What is the reward fulfillment process and where can it fail?
-* How do users discover and share referral links?
-* What analytics exist to measure referral program ROI?
+* Why would a user share this product with someone they know?
+* How easy is it for a bad actor to generate fake referrals?
+* What fraud patterns exist that we haven't addressed?
+* What is the actual ROI of the referral program?
+* Where do users drop off in the referral/share flow?
+* If we redesigned referrals from scratch, what would be different?