@sylphx/flow 2.9.0 → 2.11.0

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

@@ -0,0 +1,50 @@
+---
+name: review-operability
+description: Review operability - async workflows, DLQ, retries, drift detection
+agent: coder
+---
+
+# Operability Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of operability 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 operational risks and reliability improvements.
+
+## Tech Stack
+
+* **Workflows**: Upstash Workflows + QStash
+* **Cache**: Upstash Redis
+* **Platform**: Vercel
+
+## Review Scope
+
+### 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
+
+### 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
+
+### Release Safety
+
+* 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?

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

@@ -0,0 +1,47 @@
+---
+name: review-performance
+description: Review performance - budgets, Core Web Vitals, caching
+agent: coder
+---
+
+# Performance Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of performance 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 bottlenecks and optimization opportunities.
+
+## Tech Stack
+
+* **Framework**: Next.js (SSR/ISR/Static)
+* **Platform**: Vercel
+* **Tooling**: Bun
+
+## Review Scope
+
+### Performance Requirements
+
+* 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
+
+### Core Web Vitals Targets
+
+* LCP (Largest Contentful Paint) < 2.5s
+* FID (First Input Delay) < 100ms
+* CLS (Cumulative Layout Shift) < 0.1
+* INP (Interaction to Next Paint) < 200ms
+
+## Key Areas to Explore
+
+* 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?

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

@@ -0,0 +1,45 @@
+---
+name: review-pricing
+description: Review pricing - pricing governance, grandfathering, migrations
+agent: coder
+---
+
+# Pricing Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of pricing governance 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.
+
+## Tech Stack
+
+* **Payments**: Stripe
+
+## Review Scope
+
+### Stripe 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.
+
+### Pricing Admin Requirements
+
+* 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.
+
+## Key Areas to Explore
+
+* 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?

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

@@ -0,0 +1,56 @@
+---
+name: review-privacy
+description: Review privacy - consent, PII handling, data lifecycle, GDPR
+agent: coder
+---
+
+# Privacy Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of privacy controls 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 compliance gaps and privacy improvements.
+
+## Tech Stack
+
+* **Analytics**: PostHog
+* **Email**: Resend
+* **Tag Management**: GTM (marketing only)
+* **Observability**: Sentry
+
+## Review Scope
+
+### Consent Governance (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.
+
+### PII and Sensitive Data Controls (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
+* 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?

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

@@ -0,0 +1,43 @@
+---
+name: review-pwa
+description: Review PWA - manifest, service worker, caching, push notifications
+agent: coder
+---
+
+# PWA Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of PWA implementation 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 engagement opportunities and offline capabilities.
+
+## Tech Stack
+
+* **Framework**: Next.js
+* **Platform**: Vercel
+
+## Review Scope
+
+### PWA Requirements
+
+* Manifest file complete and valid
+* Service worker with explicit cache correctness
+* Push notifications using VAPID where applicable
+
+### Service Worker Caching Boundary (Mandatory)
+
+* 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
+
+## Key Areas to Explore
+
+* 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?

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

@@ -0,0 +1,50 @@
+---
+name: review-referral
+description: Review referral - attribution, anti-fraud, rewards, clawback
+agent: coder
+---
+
+# Referral Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of the referral system 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 growth opportunities and fraud prevention improvements.
+
+## Tech Stack
+
+* **Analytics**: PostHog
+* **Database**: Neon (Postgres)
+
+## Review Scope
+
+### Referral (Anti-Abuse Baseline Required)
+
+* 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
+
+### Referral Anti-Fraud Minimum Baseline (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
+  * Auditable manual review/appeal posture where applicable
+
+## Key Areas to Explore
+
+* 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?

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

@@ -0,0 +1,54 @@
+---
+name: review-security
+description: Review security - OWASP, CSP/HSTS, CSRF, anti-bot, rate limiting
+agent: coder
+---
+
+# Security Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of security controls 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 vulnerabilities and hardening opportunities.
+
+## Tech Stack
+
+* **Rate Limiting**: Upstash Redis
+* **Framework**: Next.js
+* **Platform**: Vercel
+
+## Review Scope
+
+### Security Baseline
+
+* 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
+
+### Configuration and Secrets Governance
+
+* Required configuration must fail-fast at build/startup
+* Strict environment isolation (dev/stage/prod)
+* Rotation and incident remediation posture must be auditable and exercisable
+
+## Key Areas to Explore
+
+* What OWASP Top 10 vulnerabilities exist in the current implementation?
+* How comprehensive are the security headers (CSP, HSTS, etc.)?
+* Where is rate limiting missing or insufficient?
+* How are secrets managed and what is the rotation strategy?
+* What attack vectors exist for the authentication flows?
+* How does the system detect and respond to security incidents?

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

@@ -0,0 +1,51 @@
+---
+name: review-seo
+description: Review SEO - metadata, Open Graph, canonical, hreflang, sitemap
+agent: coder
+---
+
+# SEO Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of SEO 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 improvements for discoverability and search rankings.
+
+## Tech Stack
+
+* **Framework**: Next.js (SSR-first for indexable/discovery)
+
+## Review Scope
+
+### SEO Requirements
+
+* SEO-first + SSR-first for indexable/discovery
+* Required elements:
+  * Metadata (title, description)
+  * Open Graph tags
+  * Favicon (all sizes)
+  * Canonical URLs
+  * hreflang + x-default
+  * schema.org structured data
+  * sitemap.xml
+  * robots.txt
+
+### SEO/i18n/Canonicalization Verification
+
+* `/en/*` non-existence (must redirect)
+* hreflang/x-default correct
+* Sitemap containing only true variants
+* UGC canonical redirects
+* Locale routing invariants
+
+## Key Areas to Explore
+
+* How does the site perform in search engine results currently?
+* What pages are missing proper metadata or structured data?
+* How does the sitemap handle dynamic content and pagination?
+* Are there duplicate content issues or canonicalization problems?
+* What opportunities exist for featured snippets or rich results?
+* How does page load performance affect SEO rankings?

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

@@ -0,0 +1,38 @@
+---
+name: review-storage
+description: Review storage - Vercel Blob upload governance, intent-based uploads
+agent: coder
+---
+
+# Storage Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of file storage and uploads 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 improvements for security, reliability, and cost efficiency.
+
+## Tech Stack
+
+* **Storage**: Vercel Blob
+* **Platform**: Vercel
+
+## Review Scope
+
+### 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.
+
+## Key Areas to Explore
+
+* How are uploads currently implemented and do they follow intent-based pattern?
+* What security vulnerabilities exist in the upload flow?
+* How are abandoned/orphaned uploads handled?
+* What is the cost implication of current storage patterns?
+* How does the system handle large files and upload failures?
+* What content validation (type, size, malware) exists?

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

@@ -0,0 +1,43 @@
+---
+name: review-support
+description: Review support - contact, communications, newsletter
+agent: coder
+---
+
+# Support Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of support and communications 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 user satisfaction improvements and support efficiency gains.
+
+## Tech Stack
+
+* **Email**: Resend
+* **Framework**: Next.js
+
+## Review Scope
+
+### Support and Communications
+
+* Support/Contact surface must be:
+  * Discoverable
+  * Localized
+  * WCAG AA compliant
+  * SEO-complete
+  * Privacy-safe
+  * Auditable where relevant
+* Newsletter subscription/preferences must be consent-aware
+* Unsubscribe enforcement must be reliable
+
+## Key Areas to Explore
+
+* How do users find help when they need it?
+* What self-service support options exist (FAQ, help center)?
+* How are support requests tracked and resolved?
+* What is the email deliverability and engagement rate?
+* How does the newsletter system handle bounces and complaints?
+* What support tools do agents have for helping users?

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

@@ -0,0 +1,49 @@
+---
+name: review-uiux
+description: Review UI/UX - design system, tokens, accessibility, guidance
+agent: coder
+---
+
+# UI/UX Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of UI/UX 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 usability improvements and design inconsistencies.
+
+## Tech Stack
+
+* **Framework**: Next.js
+* **Icons**: Iconify
+
+## Review Scope
+
+### UX, Design System, and Guidance
+
+* Design-system driven UI (tokens)
+* Dark/light theme support
+* WCAG AA compliance
+* CLS-safe (no layout shifts)
+* Responsive design (mobile-first, desktop-second)
+* Iconify for icons; no emoji in UI content
+
+### Guidance Requirements
+
+* 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
+
+## Key Areas to Explore
+
+* How consistent is the design system across the application?
+* What accessibility issues exist and affect real users?
+* Where do users get confused or drop off in key flows?
+* How does the mobile experience compare to desktop?
+* What guidance/onboarding is missing for complex features?
+* How does the dark/light theme implementation handle edge cases?

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@sylphx/flow",
-	"version": "2.9.0",
+	"version": "2.11.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": {

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

@@ -1,123 +0,0 @@
----
-name: saas-admin
-description: SaaS admin platform review - RBAC, bootstrap, config, feature flags, ops
-agent: coder
----
-
-# Admin Platform Review
-
-## Scope
-
-Review admin systems: RBAC, bootstrap flow, configuration management, feature flags governance, operational tooling, and impersonation.
-
-## Specification
-
-### Access Control (RBAC)
-
-* **Least privilege principle**: Users get minimum permissions needed.
-* Role hierarchy with clear inheritance.
-* Permission granularity (resource-level, action-level).
-* All authorization is **server-enforced**; no client-trust.
-* Role changes require appropriate privilege level and are audited.
-
-### Admin Bootstrap (Hard Requirement)
-
-* Admin bootstrap must **not rely on file seeding**.
-* Use a secure, auditable **first-login allowlist** for the initial SUPER_ADMIN.
-* **Permanently disable bootstrap** after completion — no re-entry.
-* 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
-
-* All **non-secret** product-level configuration must be manageable via admin (server-enforced).
-* Configuration changes require **validation and change history**.
-* Secrets/credentials are **environment-managed only**; admin may expose safe readiness/health visibility, not raw secrets.
-* Support for environment-specific overrides (dev/staging/prod).
-* Rollback capability for configuration changes.
-
-### Feature Flags Governance
-
-* Gradual rollout support (percentage-based, user segment-based).
-* A/B testing integration where applicable.
-* **Audit trail** for all flag changes (who/when/why).
-* Emergency **kill switches** for rapid disable.
-* Flag lifecycle management (created → active → deprecated → removed).
-* Server-enforced evaluation; no client-side flag source-of-truth.
-
-### Operational Management
-
-* **User/account management tools**:
-  * Search, view, edit user profiles
-  * Account status management (active, suspended, banned)
-  * Manual verification/unverification
-
-* **Entitlements/access management**:
-  * View and modify user entitlements
-  * Grant/revoke access with audit trail
-  * Bulk operations with safeguards
-
-* **Lifecycle actions**:
-  * Account suspension/reactivation
-  * Data export (for user requests)
-  * Account deletion with proper cascade
-
-* **Issue resolution workflows**:
-  * Support ticket integration
-  * Action history per user
-  * Notes and annotations
-
-* **Step-up controls** for sensitive actions:
-  * Actions affecting money/credits require MFA
-  * Actions affecting security posture require MFA
-  * Destructive actions require confirmation + reason
-
-### Impersonation
-
-* Impersonation allowed **with explicit safeguards**:
-  * Requires elevated privilege level
-  * Time-limited sessions (auto-expire)
-  * Full audit logging (start, actions, end)
-  * Clear indicator in UI during impersonation
-  * Cannot impersonate higher-privilege users
-* All actions during impersonation attributed to both impersonator and target.
-* Optional: Visible indicator to impersonated user that session was accessed.
-
-### Admin Audit Logging
-
-* **All admin actions must be auditable**:
-  * Who performed the action
-  * When (timestamp with timezone)
-  * What action was taken
-  * Why (required reason for sensitive actions)
-  * Before/after state for mutations
-  * Correlation to session/request
-* Audit logs must be:
-  * Immutable (append-only)
-  * Queryable and filterable
-  * Exportable for compliance
-  * Retained per data retention policy
-
-## Domain Discovery
-
-After reviewing compliance with spec, explore improvements:
-
-* **Admin UX**: Is the admin panel efficient for common tasks? Keyboard shortcuts? Bulk actions?
-* **Self-service vs admin**: What admin actions could be self-service for users?
-* **Automation**: What repetitive admin tasks could be automated? Scheduled jobs?
-* **Alerting**: Should certain admin actions trigger alerts? (e.g., mass deletions)
-* **Delegation**: Can some admin tasks be delegated to lower roles safely?
-* **Mobile admin**: Is there a need for mobile admin access? How to secure?
-
-## Domain Gates
-
-* [ ] RBAC implemented with least privilege
-* [ ] Bootstrap flow is secure and one-time only
-* [ ] Config changes are validated and audited
-* [ ] Feature flags have full audit trail
-* [ ] Sensitive actions require step-up (MFA)
-* [ ] Impersonation is time-limited and fully logged
-* [ ] All admin actions are auditable
-* [ ] Audit logs are immutable and queryable
-* [ ] No hardcoded admin credentials anywhere
-* [ ] Admin endpoints are rate-limited