@sylphx/flow 2.10.0 → 2.12.0

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

@@ -1,6 +1,6 @@
 ---
 name: review-discovery
-description: Review discovery - competitive research, features, pricing opportunities
+description: Review discovery - competitive research, opportunities, market positioning
 agent: coder
 ---
 
@@ -8,42 +8,31 @@ agent: coder
 
 ## Mandate
 
-* Perform a **deep, thorough review** to discover opportunities in this codebase.
+* Perform a **deep, thorough review** to discover opportunities for this product.
 * **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.
+* **This review IS exploration** — think broadly and creatively about what could be.
 
-## Review Scope
+## Tech Stack
 
-### Review Requirements: Explore Beyond the Spec
+* Research across the product's full stack as needed
 
-* **Feature design review**: define success criteria, journeys, state model, auth/entitlements, instrumentation; propose competitiveness improvements within constraints.
-* **Pricing/monetization review**: packaging/entitlements, lifecycle semantics, legal/tax/invoice implications; propose conversion/churn improvements within constraints.
-* **Competitive research**: features, extensibility, guidance patterns, pricing/packaging norms; convert insights into testable acceptance criteria.
+## Non-Negotiables
 
-### Discovery Areas
+* None — this is pure exploration
 
-* What features are competitors offering that we lack?
-* What pricing models are common in the market?
-* What UX patterns are users expecting?
-* What integrations would add value?
-* What automation opportunities exist?
-* What self-service capabilities are missing?
+## Context
 
-### Analysis Framework
+Discovery is about finding what's missing, what's possible, and what would make the product significantly more competitive. It's not about fixing bugs — it's about identifying opportunities that don't yet exist.
 
-* Market positioning
-* Feature gap analysis
-* Pricing benchmarking
-* User journey optimization
-* Technical debt opportunities
-* Scalability considerations
+Look at competitors, market trends, user expectations, and technological possibilities. What would make users choose this product over alternatives? What capabilities would unlock new business models?
 
-## Verification Checklist
+## Driving Questions
 
-- [ ] Competitor analysis completed
-- [ ] Feature gaps identified
-- [ ] Pricing reviewed
-- [ ] UX patterns researched
-- [ ] Integration opportunities listed
-- [ ] Recommendations prioritized
+* What are competitors doing that we're not?
+* What do users expect based on industry standards that we lack?
+* What integrations would add significant value?
+* What pricing models are common in the market and how do we compare?
+* What technical capabilities could enable new business models?
+* What would make this product a category leader rather than a follower?

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,51 +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 that don't yet exist.
 
-## Review Scope
+## Tech Stack
 
-### Growth System (Onboarding, Share/Viral, Retention)
+* **Analytics**: PostHog
+* **Framework**: Next.js
 
-* The review must produce a coherent, measurable growth system for activation, sharing/virality, and retention, aligned with compliance and anti-abuse constraints.
+## Non-Negotiables
 
-### Onboarding
+* Sharing/virality mechanics must be consent-aware
+* Growth instrumentation must not violate privacy constraints
 
-* Onboarding must be:
-  * Outcome-oriented
-  * Localized
-  * Accessible
-  * Instrumented
+## Context
 
-### Sharing/Virality
+Growth isn't about tricks — it's about removing friction from value delivery. Users who quickly experience value stay; users who don't, leave.
 
-* Sharing/virality must be:
-  * Consent-aware
-  * Abuse-resistant
-  * Measurable end-to-end
+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.
 
-### Retention
+## Driving Questions
 
-* Retention must be:
-  * Intentionally engineered
-  * Monitored
-  * Protected against regressions
-
-### Growth Best Practices
-
-* Clear value proposition on landing
-* Frictionless signup
-* Time-to-value optimization
-* Activation milestones defined
-* Re-engagement campaigns
-* Churn prediction/prevention
-* NPS/satisfaction tracking
-
-## Verification Checklist
-
-- [ ] Onboarding flow exists
-- [ ] Onboarding instrumented
-- [ ] Sharing mechanisms work
-- [ ] Sharing is consent-aware
-- [ ] Retention metrics tracked
-- [ ] Re-engagement exists
-- [ ] Growth metrics dashboarded
+* 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,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 what would make the product feel native to each locale.
 
-## Review Scope
+## Tech Stack
 
-### Supported Locales
+* **i18n**: next-intl
+* **Framework**: Next.js
 
-`en`, `zh-Hans`, `zh-Hant`, `es`, `ja`, `ko`, `de`, `fr`, `pt-BR`, `it`, `nl`, `pl`, `tr`, `id`, `th`, `vi`
+## Non-Negotiables
 
-### 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?
 
-## Verification Checklist
+## Driving Questions
 
-- [ ] All locales supported
-- [ ] `/en/*` returns 301 redirect
-- [ ] Missing keys fail build
-- [ ] No hardcoded strings
-- [ ] Intl formatting used
-- [ ] UGC has single canonical URL
-- [ ] hreflang tags correct
+* 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,29 +12,32 @@ 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 financial integrity risks before they become real problems.
 
-## Review Scope
+## Tech Stack
 
-### Financial-Grade Balance System (Only if "balance/credits/wallet" exists)
+* **Payments**: Stripe
+* **Database**: Neon (Postgres)
+* **ORM**: Drizzle
 
-* 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.
+## Non-Negotiables
 
-### Ledger Requirements
+* 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
 
-* Append-only transaction log
-* Double-entry bookkeeping where applicable
-* Idempotent transaction posting (idempotency keys)
-* Concurrency-safe balance calculations
-* Audit trail for all mutations
-* Reconciliation with external systems (Stripe)
+## Context
 
-## Verification Checklist
+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.
 
-- [ ] Immutable ledger pattern used (not mutable balance)
-- [ ] No floating point for money
-- [ ] Idempotent posting implemented
-- [ ] Concurrency safety verified
-- [ ] Full audit trail exists
-- [ ] Reconciliation with Stripe possible
+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,44 +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 the production issues we can't debug today.
 
-## Review Scope
-
-### Observability and Alerting (Mandatory)
-
-* 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
-
-### Logging Best Practices
-
-* Structured JSON logs
-* Correlation ID in all logs
-* Request ID propagation
-* User context (anonymized where needed)
-* Error stack traces
-* Performance timing
-* No PII in logs
-
-### Monitoring
-
-* Sentry for error tracking
-* PostHog for product analytics
-* Server metrics (latency, throughput, errors)
-* Database query performance
-* External service health
-
-## Verification Checklist
-
-- [ ] Structured logging implemented
-- [ ] Correlation IDs propagate
-- [ ] Sentry configured
-- [ ] SLO/SLI defined
-- [ ] Alerts for critical failures
-- [ ] No PII in logs
-- [ ] Dashboards for key metrics
+## Tech Stack
+
+* **Error Tracking**: Sentry
+* **Analytics**: PostHog
+* **Platform**: Vercel
+
+## Non-Negotiables
+
+* Correlation IDs must exist end-to-end (request → job → webhook)
+* Alerts must exist for critical failures (webhook failures, auth attacks, drift)
+
+## Context
+
+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?
+
+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 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,43 +12,31 @@ 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 what will break at 3am and how we'd fix it.
 
-## Review Scope
+## Tech Stack
 
-### Async/Workflows Governance (Hard Requirement)
+* **Workflows**: Upstash Workflows + QStash
+* **Cache**: Upstash Redis
+* **Platform**: Vercel
 
-* 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 without duplicated economic/security consequences
+## Non-Negotiables
 
-### Drift Detection (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
 
-* Drift alerts must have a defined remediation playbook (automated fix or operator workflow)
-* Each remediation must be auditable and support post-incident traceability
+## Context
 
-### Release Safety
+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?
 
-* Define safe rollout posture with backward compatibility
-* Rollback expectations for billing/ledger/auth changes
+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?
 
-### Operability Best Practices
+## Driving Questions
 
-* Health check endpoints
-* Graceful shutdown
-* Circuit breakers for external services
-* Timeout configuration
-* Retry with exponential backoff
-* Bulk operation controls
-* Maintenance mode capability
-
-## Verification Checklist
-
-- [ ] Async jobs idempotent
-- [ ] DLQ exists and observable
-- [ ] Safe replay supported
-- [ ] Drift detection implemented
-- [ ] Remediation playbooks exist
-- [ ] Rollback strategy defined
-- [ ] Health checks present
+* 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,45 +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 what's making the product feel slow.
 
-## Review Scope
+## Tech Stack
 
-### Performance Requirements
+* **Framework**: Next.js (SSR/ISR/Static)
+* **Platform**: Vercel
+* **Tooling**: Bun
 
-* 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
+## Non-Negotiables
 
-### Performance Budget Verification
+* Core Web Vitals must meet thresholds (LCP < 2.5s, CLS < 0.1, INP < 200ms)
+* Performance regressions must be detectable
 
-* **Performance budget verification** for key journeys (including Core Web Vitals-related thresholds) with release-blocking regression detection
+## Context
 
-### Core Web Vitals
+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.
 
-### Performance Best Practices
+## Driving Questions
 
-* Image optimization (WebP, lazy loading)
-* Code splitting
-* Tree shaking
-* Bundle size monitoring
-* Font optimization
-* Critical CSS
-* Preloading key resources
-* Server response time < 200ms
-
-## Verification Checklist
-
-- [ ] Performance budgets defined
-- [ ] Core Web Vitals within targets
-- [ ] Regression detection active
-- [ ] Caching boundaries defined
-- [ ] Images optimized
-- [ ] Bundle size acceptable
-- [ ] No render-blocking resources
+* 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,41 +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 friction.
 
-## Review Scope
+## Tech Stack
 
-### Stripe Pricing Governance (Stripe-first, not Dashboard-first)
+* **Payments**: Stripe
 
-* 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.
+## Non-Negotiables
 
-### Pricing Admin Requirements
+* 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)
 
-* 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.
+## Context
 
-### Pricing Strategy
+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.
 
-* Clear tier differentiation
-* Feature gating by plan
-* Upgrade/downgrade paths defined
-* Proration handling
-* Trial-to-paid conversion flow
+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?
 
-## Verification Checklist
+## Driving Questions
 
-- [ ] Stripe is system-of-record
-- [ ] New prices don't mutate existing
-- [ ] Grandfathering policy implemented
-- [ ] Pricing admin exists with RBAC
-- [ ] Stripe Dashboard drift detectable
-- [ ] Upgrade/downgrade paths work
+* 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
 ---
 
@@ -12,39 +12,34 @@ 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 compliance gaps and privacy improvements.
 
-## Review Scope
+## Tech Stack
 
-### Consent Governance (Release-Blocking)
+* **Analytics**: PostHog
+* **Email**: Resend
+* **Tag Management**: GTM (marketing only)
+* **Observability**: Sentry
 
-* 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.
+## Non-Negotiables
 
-### PII and Sensitive Data Controls (Hard Requirement)
+* 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
 
-* 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.
+## Context
 
-### Data Lifecycle
+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.
 
-* Define deletion/deactivation semantics
-* Deletion propagation to third parties
-* Export where applicable
-* DR/backup posture aligned with retention
-* **Define data classification, retention periods, deletion propagation to third-party processors, and explicit exceptions** (legal/tax/anti-fraud)
-* Ensure external disclosures match behavior
+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.
 
-### Behavioral Consistency
+## Driving Questions
 
-* **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.
-
-## Verification Checklist
-
-- [ ] Consent gates analytics/marketing
-- [ ] No tracking without consent
-- [ ] PII scrubbed from logs/Sentry/PostHog
-- [ ] Data deletion flow works
-- [ ] Deletion propagates to third parties
-- [ ] Privacy policy matches actual behavior
+* 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?