@sylphx/flow 2.6.0 → 2.7.0

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # @sylphx/flow
 
+## 2.7.0 (2025-12-17)
+
+### ✨ Features
+
+- **commands:** split saas-review into domain-specific commands ([bef500f](https://github.com/SylphxAI/flow/commit/bef500f1eeb450ee6790084354ff015ad6179f7d))
+
 ## 2.6.0 (2025-12-17)
 
 ### ✨ Features

package/assets/slash-commands/saas-auth.md

@@ -0,0 +1,78 @@
+---
+name: saas-auth
+description: SaaS identity review - SSO, passkeys, verification, account security
+agent: coder
+---
+
+# Identity & Account Security Review
+
+## Scope
+
+Review identity systems: authentication methods, SSO providers, passkeys/WebAuthn, verification flows, session management, and account security surfaces.
+
+## Specification
+
+### Identity Providers (SSO)
+
+* SSO providers (minimum): **Google, Apple, Facebook, Microsoft, GitHub** (prioritize by audience).
+* If provider env/secrets are missing, **hide** the login option (no broken/disabled UI).
+* Allow linking multiple providers and safe unlinking; server-enforced and abuse-protected.
+
+### Passkeys (WebAuthn)
+
+* Passkeys are first-class with secure enrollment/usage/recovery.
+* Must support cross-device authentication where platform allows.
+
+### Verification
+
+* **Email verification is mandatory** baseline for high-impact capabilities.
+* **Phone verification is optional** and used as risk-based step-up (anti-abuse, higher-trust flows, recovery); consent-aware and data-minimizing.
+
+### Membership and Entitlements
+
+* Membership is entitlement-driven and server-enforced.
+* All authorization/entitlements are **server-enforced**; no client-trust.
+
+### Account Security Surface
+
+* Provide a dedicated **Account Security** surface.
+* **Minimum acceptance criteria**:
+  * Session/device visibility and revocation
+  * MFA/passkey management
+  * Linked identity provider management
+  * Key security event visibility (and export where applicable)
+* All server-enforced and auditable.
+
+### Session Management
+
+* Session/device visibility + revocation available to user.
+* Security event visibility with clear audit trail.
+* Recovery governance (including support-assisted recovery) with strict audit logging.
+* Step-up authentication for sensitive actions.
+
+### Password Security
+
+* Password UX: masked + temporary reveal option.
+* No plaintext passwords in logs/returns/storage/telemetry.
+* MFA required for Admin/SUPER_ADMIN; step-up for high-risk actions.
+
+## Domain Discovery
+
+After reviewing compliance with spec, explore improvements:
+
+* **Onboarding friction**: Is sign-up flow optimized? Too many steps? Missing social providers for target market?
+* **Security vs UX balance**: Are step-up challenges appropriate? Too frequent? Too rare?
+* **Recovery flows**: Is account recovery secure yet accessible? Support burden from lockouts?
+* **Modern auth**: Are passkeys properly promoted? Is passwordless an option?
+* **Trust signals**: Are verified badges shown? Does verification unlock features appropriately?
+
+## Domain Gates
+
+* [ ] All SSO providers working (or hidden if unconfigured)
+* [ ] Passkey enrollment/usage/recovery tested
+* [ ] Email verification enforced for high-impact actions
+* [ ] Account security surface complete (sessions, MFA, providers, events)
+* [ ] Session revocation works correctly
+* [ ] No client-trust for authorization decisions
+* [ ] Step-up auth for sensitive actions
+* [ ] No plaintext passwords anywhere

package/assets/slash-commands/saas-billing.md

@@ -0,0 +1,68 @@
+---
+name: saas-billing
+description: SaaS billing review - Stripe, webhooks, pricing governance, ledger
+agent: coder
+---
+
+# Billing & Payments Review
+
+## Scope
+
+Review all payment and billing systems: Stripe integration, webhook handling, pricing governance, subscription state machine, and financial-grade ledger (if applicable).
+
+## Specification
+
+### Billing State Machine (Hard Requirement)
+
+* **Billing and access state machine is mandatory**: define and validate the mapping **Stripe state → internal subscription state → entitlements**, including trial, past_due, unpaid, canceled, refund, and dispute outcomes.
+* UI must only present interpretable, non-ambiguous states derived from server-truth.
+* **No dual-write (hard requirement)**: subscription/payment truth must be derived from Stripe-driven events; internal systems must not directly rewrite billing truth or authorize entitlements based on non-Stripe truth, except for explicitly defined admin remediation flows that are fully server-enforced and fully audited.
+
+### Stripe Integration
+
+* Support subscriptions and one-time payments as product needs require.
+* Tax/invoicing and refund/dispute handling must be behaviorally consistent with product UX and entitlement state.
+
+### Webhook Handling (Hard Requirement)
+
+* Webhooks must be idempotent, retry-safe, out-of-order safe, auditable; billing UI reflects server-truth state without ambiguity.
+* **Webhook trust is mandatory (high-risk)**: webhook origin must be verified (signature verification and replay resistance). The Stripe **event id** must be used as the idempotency and audit correlation key; unverifiable events must be rejected and must trigger alerting.
+* **Out-of-order behavior must be explicit**: all webhook handlers must define and enforce a clear out-of-order strategy (event ordering is not guaranteed even for the same subscription), and must define final-state decision rules.
+
+### Pricing Governance (Stripe-first, not Dashboard-first)
+
+* 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.
+* An operational-grade **Pricing Admin** must exist to manage creation of new Stripe Prices, activation/deactivation of sellable prices, and (optionally) controlled bulk subscription migrations; 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.
+
+### Financial-Grade Balance System (Only if "balance/credits/wallet" exists)
+
+* 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.
+
+### Auditability
+
+* **Auditability chain is mandatory** for any high-value mutation: who/when/why, before/after state, and correlation to the triggering request/job/webhook must be recorded and queryable.
+
+## Domain Discovery
+
+After reviewing compliance with spec, explore improvements:
+
+* **Conversion optimization**: Are there friction points in the checkout flow? Missing payment methods for target markets?
+* **Churn reduction**: Is dunning (failed payment retry) properly configured? Are there win-back opportunities?
+* **Pricing opportunities**: Are tiers properly differentiated? Is there usage-based pricing potential?
+* **Trial optimization**: Is trial-to-paid conversion measured and optimized?
+* **Upgrade/downgrade UX**: Is plan switching seamless? Prorated correctly?
+
+## Domain Gates
+
+* [ ] Stripe state machine fully mapped and documented
+* [ ] Webhook handlers are idempotent and out-of-order safe
+* [ ] Signature verification implemented and tested
+* [ ] Pricing admin exists with RBAC and audit
+* [ ] No dual-write violations
+* [ ] Ledger is append-only (if balance exists)
+* [ ] Billing UI reflects server-truth only

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

@@ -0,0 +1,135 @@
+---
+name: saas-discovery
+description: SaaS strategic discovery - features, pricing, competitive research
+agent: coder
+---
+
+# Strategic Discovery & Opportunities
+
+## Scope
+
+Cross-domain strategic exploration: identify new feature opportunities, optimize pricing/packaging, and conduct competitive research. This is NOT compliance checking — it's creative/strategic work to improve the product.
+
+## Mandate
+
+* **Exploration required**: identify improvements for competitiveness, completeness, usability, reliability, and monetization within fixed constraints.
+* Think beyond current implementation — what's missing? What would make users love this product?
+* Convert insights into **testable acceptance criteria**, not vague suggestions.
+
+## Feature Discovery
+
+### Process
+
+1. **Audit current capabilities**: What does the product do today?
+2. **Identify gaps**: What's missing that users expect?
+3. **Prioritize by impact**: What would move the needle most?
+4. **Define success criteria**: How would we know the feature works?
+
+### Areas to Explore
+
+* **User workflows**: Are there manual steps that could be automated?
+* **Integrations**: What third-party services should we connect to?
+* **Data/insights**: What data do we have that users would value seeing?
+* **Collaboration**: Are there multi-user/team features missing?
+* **Mobile**: Is the mobile experience feature-complete or degraded?
+* **API/Developer**: Should there be a public API? Webhooks for users?
+* **AI/Automation**: Where could AI add value without being gimmicky?
+
+### Output Format
+
+For each feature opportunity:
+```markdown
+**Feature**: [Name]
+**Problem**: [What user problem does this solve?]
+**Impact**: [High/Medium/Low] — [Why?]
+**Effort**: [High/Medium/Low] — [Why?]
+**Success Criteria**: [How do we measure success?]
+**Acceptance Criteria**:
+- [ ] [Specific, testable requirement]
+- [ ] [Another requirement]
+```
+
+## Pricing & Monetization Discovery
+
+### Process
+
+1. **Audit current pricing**: Tiers, features per tier, price points
+2. **Analyze value alignment**: Does pricing match perceived value?
+3. **Identify friction**: Where do users hesitate to pay?
+4. **Explore models**: Subscription, usage-based, hybrid, freemium
+
+### Areas to Explore
+
+* **Tier differentiation**: Are tiers clearly differentiated? Is there a "trapped middle"?
+* **Feature gating**: Are the right features gated? Too much in free? Too little?
+* **Price anchoring**: Is there a decoy tier? Is the recommended tier obvious?
+* **Trial optimization**: Is trial length optimal? What converts?
+* **Upgrade triggers**: What signals readiness to upgrade? Are we acting on them?
+* **Annual discounts**: Is annual pricing compelling enough?
+* **Add-ons**: Are there features that should be add-ons rather than tier-gated?
+* **Usage-based**: Would pay-per-use work for any features?
+
+### Output Format
+
+For each pricing opportunity:
+```markdown
+**Change**: [What to change]
+**Rationale**: [Why this improves monetization]
+**Expected Impact**: [Conversion? ARPU? Retention?]
+**Risk**: [What could go wrong?]
+**Test Plan**: [How to validate before full rollout]
+```
+
+## Competitive Research
+
+### Process
+
+1. **Identify competitors**: Direct and indirect (alternative solutions)
+2. **Analyze features**: What do they have that we don't?
+3. **Analyze pricing**: How do they package and price?
+4. **Analyze UX**: What do they do better? Worse?
+5. **Synthesize insights**: What should we adopt? Avoid? Differentiate on?
+
+### Areas to Explore
+
+* **Feature parity**: What table-stakes features are we missing?
+* **Differentiation**: What do we do uniquely well? How to amplify?
+* **Pricing position**: Are we premium, mid-market, or budget? Is that intentional?
+* **UX patterns**: What onboarding/guidance patterns work well elsewhere?
+* **Growth tactics**: How do competitors acquire and retain users?
+* **Market gaps**: What's everyone missing that we could own?
+
+### Output Format
+
+For each competitive insight:
+```markdown
+**Competitor**: [Name]
+**Observation**: [What we learned]
+**Implication**: [What this means for us]
+**Action**: [Specific recommendation]
+**Priority**: [High/Medium/Low]
+```
+
+## Synthesis
+
+After exploring all areas, produce a prioritized roadmap:
+
+### Immediate Wins (Do Now)
+High impact + Low effort opportunities
+
+### Strategic Investments (Plan Carefully)
+High impact + High effort opportunities
+
+### Quick Wins (When Available)
+Low impact + Low effort opportunities
+
+### Deprioritized (Defer/Skip)
+Low impact + High effort — document why not pursuing
+
+## Exit Criteria
+
+* [ ] Feature gaps identified with acceptance criteria
+* [ ] Pricing optimization opportunities documented
+* [ ] Competitive landscape analyzed
+* [ ] Prioritized roadmap produced
+* [ ] All recommendations have testable success criteria

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

@@ -0,0 +1,94 @@
+---
+name: saas-growth
+description: SaaS growth review - onboarding, referral, retention, guidance
+agent: coder
+---
+
+# Growth Systems Review
+
+## Scope
+
+Review growth systems: onboarding flows, referral program, retention mechanics, viral/sharing features, and user guidance.
+
+## Specification
+
+### Growth System Foundation
+
+* The system must produce a coherent, measurable growth system for activation, sharing/virality, and retention, aligned with compliance and anti-abuse constraints.
+
+### Onboarding
+
+* Onboarding must be **outcome-oriented** (guide to first value, not just feature tour).
+* Localized for all supported locales.
+* Accessible (WCAG AA).
+* Instrumented (track completion, drop-off points).
+* Progressive disclosure — don't overwhelm new users.
+
+### Sharing/Virality
+
+* Sharing must be **consent-aware** (no spam, no dark patterns).
+* Abuse-resistant with rate limiting and detection.
+* Measurable end-to-end (share → click → signup → conversion).
+* Platform-appropriate sharing (native share sheet on mobile, copy link on desktop).
+
+### Retention
+
+* Retention must be **intentionally engineered**, not accidental.
+* Monitored with cohort analysis.
+* Protected against regressions (alert on retention drops).
+* Re-engagement flows (email, push) must be consent-governed.
+
+### Referral Program (Anti-Abuse Baseline Required)
+
+* Referral must be measurable, abuse-resistant, and governed:
+  * Clear attribution semantics (who referred whom, when)
+  * Reward lifecycle governance (pending → approved → paid, including revocation/clawbacks)
+  * Anti-fraud measures
+  * Admin reporting and audit capabilities
+  * Localized and instrumented
+
+* **Referral anti-fraud minimum baseline is mandatory**:
+  * Define minimum set of risk signals and enforcement measures
+  * Velocity controls (rate limiting referrals)
+  * Account/device linkage posture (detect self-referral)
+  * Risk-tiered enforcement (high-risk delays, low-risk instant)
+  * Reward delay/hold/freeze capabilities
+  * Clawback conditions clearly defined
+  * Auditable manual review/appeal posture where applicable
+
+### Support and Communications
+
+* Support/Contact surface must be discoverable, localized, WCAG AA, SEO-complete, privacy-safe, and auditable where relevant.
+* Newsletter subscription/preferences must be consent-aware; unsubscribe enforcement must be reliable and immediate.
+
+### Admin Platform (Growth-Related)
+
+* **Admin analytics and reporting are mandatory**:
+  * Comprehensive dashboards/reports for business, growth, billing, referral, support, and security/abuse signals
+  * Governed by RBAC
+  * Reporting must be consistent with system-of-record truth and auditable
+
+## Domain Discovery
+
+After reviewing compliance with spec, explore improvements:
+
+* **Activation optimization**: What's the "aha moment"? How fast do users reach it? What's blocking them?
+* **Viral loops**: Are there natural sharing moments? Can product usage generate invites?
+* **Retention hooks**: What brings users back? Email? Push? In-app value?
+* **Referral improvements**: Is the reward compelling? Is sharing frictionless? What's the k-factor?
+* **Churn analysis**: Why do users leave? Exit surveys? Behavioral patterns before churn?
+* **Expansion revenue**: Are there upsell opportunities? Usage-based triggers?
+
+## Domain Gates
+
+* [ ] Onboarding tracks completion and drop-off
+* [ ] Onboarding is localized and accessible
+* [ ] Sharing respects consent and has rate limits
+* [ ] Sharing is measurable end-to-end
+* [ ] Retention cohorts are tracked
+* [ ] Retention regression alerts exist
+* [ ] Referral attribution is accurate
+* [ ] Referral has anti-fraud controls
+* [ ] Reward lifecycle is auditable
+* [ ] Support surface is discoverable and localized
+* [ ] Newsletter unsubscribe works immediately

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

@@ -0,0 +1,66 @@
+---
+name: saas-i18n
+description: SaaS internationalization review - locales, routing, canonicalization, hreflang
+agent: coder
+---
+
+# Internationalization & Routing Review
+
+## Scope
+
+Review internationalization systems: locale support, URL routing strategy, canonicalization, hreflang implementation, and UGC handling across languages.
+
+## Specification
+
+### 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
+
+* Use Intl APIs for formatting (dates, numbers, currencies).
+* Explicit fallback rules for missing translations.
+* **Missing translation keys must fail build** — no silent fallbacks in production.
+* No hardcoded user-facing strings outside localization system.
+
+### UGC Canonicalization
+
+* 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.
+
+### SEO Requirements
+
+* `hreflang` tags with `x-default` pointing to non-prefixed (English) version.
+* `sitemap.xml` containing only true localized variants.
+* Canonical URLs properly set per page.
+* No duplicate content across locale paths.
+
+## Domain Discovery
+
+After reviewing compliance with spec, explore improvements:
+
+* **Market expansion**: Are high-value markets missing? (e.g., Arabic RTL, Hindi)
+* **Translation quality**: Are translations professional or machine-generated? User complaints?
+* **Locale detection**: Is auto-detection helpful or annoying? Is manual switching easy?
+* **Regional pricing**: Does i18n support regional pricing display? Currency localization?
+* **Legal localization**: Are terms/privacy properly localized per jurisdiction?
+* **Date/time handling**: Timezone-aware displays? User preference respected?
+
+## Domain Gates
+
+* [ ] All supported locales have complete translations
+* [ ] `/en/*` returns 301 redirect to non-prefixed
+* [ ] Missing translation keys fail build
+* [ ] hreflang tags present and correct
+* [ ] x-default points to non-prefixed version
+* [ ] Sitemap contains only true localized pages
+* [ ] UGC has single canonical URL per content
+* [ ] No hardcoded strings in components

package/assets/slash-commands/saas-platform.md

@@ -0,0 +1,87 @@
+---
+name: saas-platform
+description: SaaS frontend review - design system, SEO, PWA, performance, accessibility
+agent: coder
+---
+
+# Frontend & Platform Review
+
+## Scope
+
+Review frontend systems: design system, SEO implementation, PWA capabilities, performance optimization, and accessibility compliance.
+
+## Specification
+
+### Design System & UX
+
+* Design-system driven UI (tokens for colors, spacing, typography).
+* Dark/light theme support with user preference persistence.
+* **WCAG AA** accessibility compliance.
+* CLS-safe (no layout shift).
+* **Mobile-first** responsive design; desktop-second.
+* Iconify for icons; no emoji in UI content.
+
+### SEO Requirements
+
+* **SEO-first + SSR-first** for indexable/discovery pages.
+* Required metadata:
+  * Title and description (unique per page)
+  * Open Graph tags (og:title, og:description, og:image)
+  * Favicon (multiple sizes)
+  * Canonical URL
+  * robots meta tag
+* `schema.org` structured data where applicable.
+* `sitemap.xml` (auto-generated, up-to-date).
+* `robots.txt` properly configured.
+
+### PWA Capabilities
+
+* Web app manifest with proper icons and theme colors.
+* Service worker with explicit cache correctness.
+* Push notifications using VAPID where applicable.
+* **Service Worker caching boundary is mandatory**: service worker must not cache personalized/sensitive/authorized content.
+* Authenticated and entitlement-sensitive routes must have explicit cache-control and SW rules.
+* SW caching boundaries must be validated by tests to prevent stale or unauthorized state exposure.
+
+### Performance
+
+* 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
+* Target metrics:
+  * LCP < 2.5s
+  * FID < 100ms
+  * CLS < 0.1
+  * TTFB < 600ms
+
+### Guidance System
+
+* Guidance is mandatory for all user-facing features and monetization flows.
+* Must be: discoverable, clear, dismissible with re-entry option.
+* Localized and measurable (track engagement).
+* Governed by eligibility and frequency controls.
+
+## Domain Discovery
+
+After reviewing compliance with spec, explore improvements:
+
+* **Performance wins**: Are there obvious bundle size reductions? Lazy loading opportunities? Image optimization?
+* **SEO gaps**: Missing structured data? Pages not indexed? Slow crawl rate?
+* **PWA enhancement**: Is offline experience meaningful? Are push notifications valuable?
+* **Accessibility**: Beyond AA compliance, are there UX improvements for assistive tech?
+* **Design consistency**: Are there inconsistencies in the design system usage? Rogue styles?
+* **Mobile experience**: Is mobile-first truly implemented? Touch targets adequate?
+
+## Domain Gates
+
+* [ ] Design tokens used consistently (no hardcoded values)
+* [ ] Dark/light theme works correctly
+* [ ] WCAG AA compliance verified
+* [ ] All pages have unique title/description/OG tags
+* [ ] Sitemap.xml exists and is current
+* [ ] Schema.org markup present
+* [ ] Service worker doesn't cache authenticated content
+* [ ] Core Web Vitals within targets
+* [ ] Performance budgets defined and enforced
+* [ ] Guidance system implemented for key flows

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

@@ -1,275 +1,178 @@
 ---
 name: saas-review
-description: Full-stack SaaS product review - architecture, billing, security, compliance, growth
+description: Full-stack SaaS product review - master orchestrator
 agent: coder
 ---
 
-# Global Subscription Web Product — Master Specification and Review Mandate
+# SaaS Product Review — Master Orchestration
 
-## 1) Mandate and Work Model
+## Mandate
 
-* Perform a complete end-to-end review across product, engineering, security, compliance, growth, operations, and UX.
+* Perform a **complete end-to-end review** across product, engineering, security, compliance, growth, operations, and UX.
 * **Delegate work to multiple workers; you act as the final gate to improve quality.**
-* Deliverables must be stated as **standards, constraints, and acceptance criteria**; avoid low-level implementation prescriptions unless required for correctness or compliance.
-* **Single-pass delivery**: no roadmap, no phasing, no deferrals; deliver an integrated outcome that satisfies all requirements simultaneously.
-* **Exploration required**: the review must not be limited to this document; identify additional improvements for competitiveness, completeness, usability, reliability, and monetization within fixed constraints.
+* Deliverables must be stated as **standards, constraints, and acceptance criteria**.
+* **Single-pass delivery**: no roadmap, no phasing, no deferrals; deliver an integrated outcome.
 
-## 2) Non-Negotiable Engineering Principles
+## Non-Negotiable Engineering Principles
 
 * No workarounds, hacks, or TODOs.
 * Feature-first with clean architecture; designed for easy extension; no "god files".
 * Type-first, strict end-to-end correctness (**DB → API → UI**).
-* Serverless-first and server-first; edge-compatible where feasible without sacrificing correctness, security, or observability.
+* Serverless-first; edge-compatible where feasible without sacrificing correctness, security, or observability.
 * Mobile-first responsive design; desktop-second.
 * Precise naming; remove dead/unused code.
 * Upgrade all packages to latest stable; avoid deprecated patterns.
 
-## 3) Fixed Platform, Stack, and Tooling (Locked)
+## Fixed Platform & Stack (Locked)
 
-* Platform: **Vercel**
-* Framework: **Next.js** (SSR-first for indexable/discovery)
-* API: **tRPC** for all internal application APIs
-* i18n: **next-intl**
-* DB: **Neon (Postgres)**
-* ORM: **Drizzle**
-* Auth: **better-auth**
-* Payments: **Stripe**
-* Email: **Resend**
-* Observability: **Sentry**
-* Analytics: **PostHog**
-* Cache / rate limiting / workflows: **Upstash Redis + Upstash Workflows + QStash**
-* Tooling baseline: **Bun**, **Biome**, **Bun test**
-* Tag management: **GTM (marketing tags only)**
+| Layer | Technology |
+|-------|------------|
+| Platform | Vercel |
+| Framework | Next.js (SSR-first) |
+| API | tRPC |
+| i18n | next-intl |
+| Database | Neon (Postgres) |
+| ORM | Drizzle |
+| Auth | better-auth |
+| Payments | Stripe |
+| Email | Resend |
+| Observability | Sentry |
+| Analytics | PostHog |
+| Cache/Workflows | Upstash Redis + Workflows + QStash |
+| Storage | Vercel Blob |
+| Tooling | Bun, Biome, Bun test |
+| Tag Management | GTM (marketing only) |
 
-## 4) Architecture and Data Foundations
+## Review Execution
 
-### 4.1 Boundaries, Server Enforcement, and Consistency Model (Hard Requirement)
+### Phase 1: Domain Reviews (Parallel)
 
-* Define clear boundaries: domain rules, use-cases, integrations, UI.
-* All authorization/entitlements are **server-enforced**; no client-trust.
-* Runtime constraints (serverless/edge) must be explicit and validated.
-* **Consistency model is mandatory for high-value state**: for billing, entitlements, ledger, admin privilege grants, and security posture, the system must define and enforce an explicit consistency model (source-of-truth, allowed delay windows, retry/out-of-order handling, and acceptable eventual consistency bounds).
-* **Billing and access state machine is mandatory**: define and validate the mapping **Stripe state → internal subscription state → entitlements**, including trial, past_due, unpaid, canceled, refund, and dispute outcomes. UI must only present interpretable, non-ambiguous states derived from server-truth.
-* **No dual-write (hard requirement)**: subscription/payment truth must be derived from Stripe-driven events; internal systems must not directly rewrite billing truth or authorize entitlements based on non-Stripe truth, except for explicitly defined admin remediation flows that are fully server-enforced and fully audited.
-* **Server-truth is authoritative**: UI state must never contradict server-truth. Where asynchronous confirmation exists, UI must represent that state unambiguously and remain explainable.
-* **Auditability chain is mandatory** for any high-value mutation: who/when/why, before/after state, and correlation to the triggering request/job/webhook must be recorded and queryable.
-
-### 4.2 Drizzle Migrations (Non-Negotiable)
-
-* Migration files must exist, be complete, and be committed.
-* Deterministic, reproducible, environment-safe; linear/auditable history; no drift.
-* CI must fail if schema changes are not represented by migrations.
-
-### 4.3 Financial-Grade Balance System (Only if "balance/credits/wallet" exists)
-
-* 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.
-
-### 4.4 Vercel Blob Upload Governance (Hard Requirement)
-
-* All uploads must be **intent-based and server-verified**.
-* The client must upload to Vercel Blob first using short-lived, server-issued authorization (e.g., signed upload URL / token), then call a server finalize endpoint to persist the resulting Blob URL/key.
-* The server must validate the Blob URL/key ownership and namespace, and must match it against the originating upload intent (who/what/where/expiry/constraints) before attaching it to any resource.
-* The system must support safe retries and idempotent finalize; expired/abandoned intents must be cleanable and auditable.
-
-## 5) Internationalization, Routing, and Canonicalization (Keep Precise)
-
-### 5.1 Supported Locales
-
-`en`, `zh-Hans`, `zh-Hant`, `es`, `ja`, `ko`, `de`, `fr`, `pt-BR`, `it`, `nl`, `pl`, `tr`, `id`, `th`, `vi`
-
-### 5.2 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>/...`.
-
-### 5.3 Globalization Rules
-
-* Intl formatting; explicit fallback rules.
-* Missing translation keys must fail build.
-* No hardcoded user-facing strings outside localization.
-
-### 5.4 UGC Canonicalization
-
-* 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.
-
-## 6) Product Systems (Capabilities + Governance)
-
-### 6.1 Membership and Account Security
-
-* Membership is entitlement-driven and server-enforced.
-* Provide a dedicated **Account Security** surface.
-* **Account Security minimum acceptance**: session/device visibility and revocation; MFA/passkey management; linked identity provider management; key security event visibility (and export where applicable). All server-enforced and auditable.
-
-### 6.2 Identity, Verification, and Sign-in
-
-* SSO providers (minimum): **Google, Apple, Facebook, Microsoft, GitHub** (prioritize by audience).
-* If provider env/secrets are missing, **hide** the login option (no broken/disabled UI).
-* Allow linking multiple providers and safe unlinking; server-enforced and abuse-protected.
-* Passkeys (WebAuthn) are first-class with secure enrollment/usage/recovery.
-* Verification:
+Delegate each domain to a worker agent. Workers should review compliance with spec AND identify domain-specific improvement opportunities.
 
-  * **Email verification is mandatory** baseline for high-impact capabilities.
-  * **Phone verification is optional** and used as risk-based step-up (anti-abuse, higher-trust flows, recovery); consent-aware and data-minimizing.
+| Worker | Command | Focus |
+|--------|---------|-------|
+| Billing | `/saas-billing` | Stripe, webhooks, pricing governance, ledger |
+| Auth | `/saas-auth` | SSO, passkeys, verification, sessions, account security |
+| i18n | `/saas-i18n` | Locales, routing, canonicalization, hreflang |
+| Platform | `/saas-platform` | Design system, SEO, PWA, performance, a11y |
+| Security | `/saas-security` | OWASP, privacy, consent, observability, operability |
+| Growth | `/saas-growth` | Onboarding, referral, retention, guidance |
 
-### 6.3 Billing and Payments (Stripe)
+### Phase 2: Strategic Discovery
 
-* Support subscriptions and one-time payments as product needs require.
-* **Billing state machine follows §4.1 mapping requirements**; UI must only surface explainable, non-ambiguous states aligned to server-truth.
-* Webhooks must be idempotent, retry-safe, out-of-order safe, auditable; billing UI reflects server-truth state without ambiguity.
-* **Webhook trust is mandatory (high-risk)**: webhook origin must be verified (signature verification and replay resistance). The Stripe **event id** must be used as the idempotency and audit correlation key; unverifiable events must be rejected and must trigger alerting.
-* **Out-of-order behavior must be explicit**: all webhook handlers must define and enforce a clear out-of-order strategy (event ordering is not guaranteed even for the same subscription), and must use the §4.1 consistency model to define final-state decision rules.
-* Tax/invoicing and refund/dispute handling must be behaviorally consistent with product UX and entitlement state.
-* **Stripe pricing governance is mandatory (Stripe-first, not Dashboard-first)**:
+After domain reviews complete, run cross-domain strategic analysis:
 
-  * 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.
-  * An operational-grade Pricing Admin must exist to manage creation of new Stripe Prices, activation/deactivation of sellable prices, and (optionally) controlled bulk subscription migrations; 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.
+| Worker | Command | Focus |
+|--------|---------|-------|
+| Discovery | `/saas-discovery` | Feature opportunities, pricing optimization, competitive research |
 
-### 6.4 Admin Platform (Operational-Grade)
+### Phase 3: Final Gate (You)
 
-* Baseline: RBAC (least privilege), audit logs, feature flags governance, optional impersonation with safeguards and auditing.
-* Admin bootstrap must not rely on file seeding:
+Synthesize all domain findings and discovery insights:
 
-  * Use a secure, auditable **first-login allowlist** for the initial SUPER_ADMIN.
-  * Permanently disable bootstrap after completion.
-  * All privilege grants must be server-enforced and recorded in the audit log.
-  * The allowlist must be managed via secure configuration (environment/secret store), not code or DB seeding.
-* **Configuration management is mandatory**:
+1. **Aggregate findings** from all workers
+2. **Resolve conflicts** between domains
+3. **Verify delivery gates** (below)
+4. **Produce integrated report** with prioritized actions
 
-  * All **non-secret** product-level configuration must be manageable via admin (server-enforced), with validation and change history.
-  * Secrets/credentials are environment-managed only; admin may expose safe readiness/health visibility, not raw secrets.
-* **Admin analytics and reporting are mandatory**:
+## Architecture Foundations (All Domains)
 
-  * Provide comprehensive dashboards/reports for business, growth, billing, referral, support, and security/abuse signals, governed by RBAC.
-  * Reporting must be consistent with system-of-record truth (billing/webhooks, ledger, entitlements) and auditable when derived from privileged actions.
-* **Admin operational management is mandatory**:
+These principles apply across all domain reviews:
 
-  * Tools for user/account management, entitlements/access management, lifecycle actions, and issue resolution workflows.
-  * Actions affecting access, money/credits, or security posture require appropriate step-up controls and must be fully auditable; reversibility must follow domain rules.
+### Server Enforcement
 
-### 6.5 Support and Communications
-
-* Support/Contact surface must be discoverable, localized, WCAG AA, SEO-complete, privacy-safe, and auditable where relevant.
-* Newsletter subscription/preferences must be consent-aware; unsubscribe enforcement must be reliable.
-
-### 6.6 Referral (Anti-Abuse Baseline Required)
-
-* Referral must be measurable, abuse-resistant, and governed:
-
-  * attribution semantics, reward lifecycle governance (including revocation/clawbacks), anti-fraud, admin reporting/audit,
-  * localized and instrumented.
-* **Referral anti-fraud minimum baseline is mandatory**:
-
-  * 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, and an auditable manual review/appeal posture where applicable.
-
-## 7) UX, Design System, and Guidance
-
-* Design-system driven UI (tokens), dark/light theme, WCAG AA, CLS-safe, responsive.
-* Iconify; no emoji in UI content.
-* Guidance is mandatory for all user-facing features and monetization flows: discoverable, clear, dismissible with re-entry, localized and measurable, governed by eligibility and frequency controls.
-
-## 8) Web Platform: SEO, PWA, Performance
-
-* SEO-first + SSR-first for indexable/discovery.
-* Required: metadata + Open Graph + favicon; canonical; hreflang + x-default; schema.org; sitemap.xml; robots.txt.
-* PWA: manifest, service worker with explicit cache correctness; push notifications using VAPID where applicable.
-* **Service Worker caching boundary is mandatory**: service worker must not cache personalized/sensitive/authorized content. Authenticated and entitlement-sensitive routes must have explicit cache-control and SW rules, and must be validated by tests to prevent stale or unauthorized state exposure.
-* 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.
-
-## 9) Growth System (Onboarding, Share/Viral, Retention)
-
-* The review must produce a coherent, measurable growth system for activation, sharing/virality, and retention, aligned with compliance and anti-abuse constraints.
-* Onboarding must be outcome-oriented, localized, accessible, and instrumented.
-* Sharing/virality must be consent-aware, abuse-resistant, and measurable end-to-end.
-* Retention must be intentionally engineered, monitored, and protected against regressions.
-
-## 10) Trust, Safety, Security, Privacy, Compliance, and Operability
-
-* **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.
-* **Consent governance is mandatory (release-blocking)**:
-
-  * 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.
-* **Marketing attribution and conversions are governed (hard requirement)**:
-
-  * GTM may be used **only** for marketing tags and attribution; it must not become the primary product analytics system (PostHog remains the product analytics source).
-  * Conversions representing monetary value or entitlement changes must be **server-truth aligned**, **idempotent**, and **deduplicated**; client-side tags may exist for attribution but must not become the authoritative source of billing/entitlement truth.
-* **PII and sensitive data controls apply everywhere (hard requirement)**:
-
-  * 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.
-* Data lifecycle must be explicit and enforceable:
-
-  * define deletion/deactivation semantics, deletion propagation, 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), and ensure external disclosures match behavior.
-* Abuse/fraud posture (especially referral/UGC/support): define prevention and enforcement measures; risk signals trigger protective actions and step-up verification where appropriate.
-* Account/session security management: session/device visibility + revocation, security event visibility, recovery governance (including support-assisted recovery) with strict audit logging; step-up for sensitive actions.
-* **Async/workflows are governed (hard requirement)**:
-
-  * 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.
-* Release safety: define safe rollout posture with backward compatibility and rollback expectations for billing/ledger/auth changes.
-* **Observability and alerting are mandatory (hard requirement)**:
-
-  * 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, and drift detection.
-* **Configuration and secrets governance is mandatory**:
-
-  * required configuration must fail-fast at build/startup,
-  * strict environment isolation (dev/stage/prod),
-  * rotation and incident remediation posture must be auditable and exercisable.
-* **Drift detection must be remediable (hard requirement)**:
-
-  * drift alerts must have a defined remediation playbook (automated fix or operator workflow),
-  * each remediation must be auditable and support post-incident traceability.
-* Security baseline:
+* All authorization/entitlements are **server-enforced**; no client-trust.
+* **Server-truth is authoritative**: UI state must never contradict server-truth.
 
-  * OWASP Top 10:2025 taxonomy; OWASP ASVS (L2/L3) verification baseline.
-  * Password UX masked + temporary reveal; no plaintext passwords in logs/returns/storage/telemetry.
-  * MFA for Admin/SUPER_ADMIN; step-up for high-risk.
-  * Risk-based anti-bot for auth and high-cost endpoints; integrate rate limits + consent gating.
-  * Baseline controls: CSP/HSTS/headers, CSRF where applicable, Upstash-backed rate limiting, PII scrubbing, supply-chain hygiene, measurable security.
-  * **Security controls must be verifiable**: CSP/HSTS/security headers and CSRF (where applicable) must be covered by automated checks or security tests and included in release gates.
+### Consistency Model
 
-## 11) Review Requirements: Explore Beyond the Spec
+* For billing, entitlements, ledger, admin privileges, and security posture: define explicit consistency model (source-of-truth, delay windows, retry handling).
 
-* 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.
+### Drizzle Migrations
 
-## 12) Delivery Gates and Completion
+* Migration files must exist, be complete, and be committed.
+* Deterministic, reproducible, environment-safe; linear/auditable history; no drift.
+* CI must fail if schema changes are not represented by migrations.
 
-* CI must block merges/deploys when failing:
+### Vercel Blob Upload Governance
 
-  * Biome lint/format, strict TS typecheck, unit + E2E (**Bun test**), build,
-  * migration integrity checks,
-  * i18n missing-key checks,
-  * **SEO/i18n/canonicalization verification** covering `/en/*` non-existence, hreflang/x-default, sitemap containing only true variants, UGC canonical redirects, and locale routing invariants,
-  * **performance budget verification** for key journeys (including Core Web Vitals-related thresholds) with release-blocking regression detection,
-  * **security verification** for CSP/HSTS/security headers and CSRF (where applicable),
-  * **consent gating verification** for analytics/marketing tags/newsletter eligibility and firing rules.
-* **All gates above must be enforced by automated tests or mechanized checks (non-manual); manual verification does not satisfy release gates.**
-* Build/startup must fail-fast when required configuration/secrets are missing or invalid for the target environment.
-* Operability gates must be met for release:
-
-  * observability and alerting are configured for critical anomalies,
-  * workflow dead-letter handling is operable, visible, and supports controlled replay.
-* Complete only when all sections are satisfied without deferral, system is integrated/buildable/testable/deployable, and there are no TODOs/hacks/workarounds/dead/unused code.
+* All uploads must be **intent-based and server-verified**.
+* Client uploads via short-lived, server-issued authorization, then calls server finalize endpoint.
+* Server validates Blob URL/key ownership and matches against originating intent before attaching to any resource.
+* Support safe retries and idempotent finalize; expired/abandoned intents must be cleanable and auditable.
+
+### Auditability
+
+* For any high-value mutation: who/when/why, before/after state, and correlation to triggering request/job/webhook must be recorded and queryable.
+
+## Delivery Gates (Release-Blocking)
+
+CI must block merges/deploys when failing:
+
+### Code Quality
+- [ ] Biome lint/format passes
+- [ ] Strict TypeScript typecheck passes
+- [ ] Unit + E2E tests pass (Bun test)
+- [ ] Build succeeds
+
+### Data Integrity
+- [ ] Migration integrity checks pass
+- [ ] No schema drift
+
+### Internationalization
+- [ ] Missing translation keys fail build
+- [ ] `/en/*` returns 301 redirect
+- [ ] hreflang/x-default correct
+- [ ] Sitemap contains only true localized pages
+
+### Performance
+- [ ] Performance budgets enforced
+- [ ] Core Web Vitals within targets
+- [ ] Regression detection active
+
+### Security
+- [ ] CSP/HSTS/security headers verified
+- [ ] CSRF protection tested
+- [ ] Consent gates analytics/marketing
+
+### Operability
+- [ ] Observability configured for critical paths
+- [ ] Alerting defined for anomalies
+- [ ] DLQ is operable with safe replay
+
+### Release Criteria
+- [ ] Required configuration fails fast if missing
+- [ ] All domain gates pass
+- [ ] No TODOs/hacks/workarounds/dead code
+
+## Output Format
+
+### Executive Summary
+- Overall health assessment
+- Critical blockers (must fix before release)
+- High-priority improvements
+
+### Domain Reports
+For each domain, summarize:
+- Compliance status (pass/fail with details)
+- Improvement opportunities discovered
+- Recommended actions with priority
+
+### Strategic Opportunities
+From discovery phase:
+- Feature roadmap (prioritized)
+- Pricing optimizations
+- Competitive positioning
+
+### Delivery Gate Status
+Checklist with pass/fail for each gate
+
+## Completion Criteria
+
+Complete only when:
+- [ ] All domain reviews finished
+- [ ] Discovery phase completed
+- [ ] All findings synthesized
+- [ ] Delivery gates verified
+- [ ] Integrated report produced
+- [ ] No deferrals — everything addressed in single pass

package/assets/slash-commands/saas-security.md

@@ -0,0 +1,108 @@
+---
+name: saas-security
+description: SaaS security review - OWASP, privacy, consent, observability, operability
+agent: coder
+---
+
+# Security, Privacy & Compliance Review
+
+## Scope
+
+Review security posture, privacy compliance, consent governance, observability systems, and operational readiness.
+
+## Specification
+
+### Security Baseline
+
+* **OWASP Top 10:2025** taxonomy awareness and mitigation.
+* **OWASP ASVS** (L2/L3) verification baseline.
+* Baseline controls:
+  * CSP (Content Security Policy) properly configured
+  * HSTS with appropriate max-age
+  * Security headers (X-Frame-Options, X-Content-Type-Options, etc.)
+  * CSRF protection where applicable
+  * Upstash-backed rate limiting
+  * Supply-chain hygiene (dependency audits)
+* **Security controls must be verifiable**: CSP/HSTS/security headers and CSRF must be covered by automated checks or security tests and included in release gates.
+* Risk-based anti-bot for auth and high-cost endpoints; integrate rate limits + consent gating.
+
+### Consent Governance (Release-Blocking)
+
+* **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.
+* 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 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.
+
+### Marketing Attribution (Hard Requirement)
+
+* GTM may be used **only** for marketing tags and attribution; it must not become the primary product analytics system (PostHog remains the product analytics source).
+* Conversions representing monetary value or entitlement changes must be **server-truth aligned**, **idempotent**, and **deduplicated**; client-side tags may exist for attribution but must not become the authoritative source of billing/entitlement truth.
+
+### PII and Sensitive Data (Hard Requirement)
+
+* 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.
+
+### Data Lifecycle
+
+* Define deletion/deactivation semantics and deletion propagation.
+* Export capability 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).
+* External disclosures must match actual behavior.
+
+### Async/Workflows Governance (Hard Requirement)
+
+* 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.
+
+### Observability and Alerting (Hard Requirement)
+
+* 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, and drift detection.
+
+### Configuration and Secrets
+
+* Required configuration must fail-fast at build/startup.
+* Strict environment isolation (dev/stage/prod).
+* Rotation and incident remediation posture must be auditable and exercisable.
+
+### Drift Detection (Hard Requirement)
+
+* Drift alerts must have a defined remediation playbook (automated fix or operator workflow).
+* Each remediation must be auditable and support post-incident traceability.
+
+### Abuse/Fraud Posture
+
+* Define prevention and enforcement measures for referral/UGC/support abuse.
+* Risk signals trigger protective actions and step-up verification where appropriate.
+
+## Domain Discovery
+
+After reviewing compliance with spec, explore improvements:
+
+* **Attack surface reduction**: Are there unused endpoints? Overly permissive APIs?
+* **Monitoring gaps**: What security events aren't being tracked? Alert fatigue issues?
+* **Compliance readiness**: Is SOC2/GDPR/CCPA posture documented? Audit-ready?
+* **Incident response**: Is there a playbook? Has it been tested?
+* **Third-party risk**: Are vendor dependencies assessed? Data processing agreements in place?
+* **Security UX**: Are security features discoverable? Do they create unnecessary friction?
+
+## Domain Gates
+
+* [ ] CSP/HSTS/security headers configured and tested
+* [ ] CSRF protection implemented where needed
+* [ ] Rate limiting active on sensitive endpoints
+* [ ] Consent governs all analytics/marketing
+* [ ] PII scrubbing verified (logs, Sentry, PostHog)
+* [ ] Data deletion propagates to third parties
+* [ ] DLQ exists and is operable
+* [ ] Correlation IDs present end-to-end
+* [ ] Critical alerts defined and tested
+* [ ] Config fails fast on missing required values
+* [ ] Drift detection has remediation playbook

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@sylphx/flow",
-	"version": "2.6.0",
+	"version": "2.7.0",
 	"description": "One CLI to rule them all. Unified orchestration layer for Claude Code, OpenCode, Cursor and all AI development tools. Auto-detection, auto-installation, auto-upgrade.",
 	"type": "module",
 	"bin": {