@sylphx/flow 2.10.0 → 2.12.0

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

@@ -1,6 +1,6 @@
 ---
 name: review-pwa
-description: Review PWA - manifest, service worker, caching, push notifications
+description: Review PWA - offline experience, installation, engagement
 agent: coder
 ---
 
@@ -12,40 +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 what would make the web experience feel native.
 
-## Review Scope
+## Tech Stack
 
-### PWA Requirements
+* **Framework**: Next.js
+* **Platform**: Vercel
 
-* Manifest file complete and valid
-* Service worker with explicit cache correctness
-* Push notifications using VAPID where applicable
-
-### Service Worker Caching Boundary (Mandatory)
+## Non-Negotiables
 
 * 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
-
-### PWA Best Practices
-
-* Installable (meets PWA criteria)
-* Offline fallback page
-* App icons (all sizes)
-* Splash screen configured
-* Theme color defined
-* Start URL configured
-* Display mode appropriate
-* Cache versioning strategy
-* Cache invalidation on deploy
-
-## Verification Checklist
-
-- [ ] Valid manifest.json
-- [ ] Service worker registered
-- [ ] SW doesn't cache auth content
-- [ ] Cache-control headers correct
-- [ ] Push notifications work (if applicable)
-- [ ] Installable on mobile
-- [ ] Offline fallback exists
-- [ ] Cache invalidation tested
+* Cache invalidation on deploy must be correct (no stale content)
+
+## Context
+
+A PWA is an opportunity to deliver native-like experience without an app store. But a bad PWA is worse than no PWA — stale content, broken offline states, and confusing installation prompts erode trust.
+
+Consider: what would make users want to install this? What should work offline? How do we handle the transition between online and offline gracefully?
+
+## Driving Questions
+
+* Would users actually want to install this as an app? Why or why not?
+* What should the offline experience be, and what is it today?
+* What happens when users go offline in the middle of something important?
+* How do we handle cache invalidation without breaking the experience?
+* What push notification opportunities exist that we're not using?
+* What would make the installed experience better than the browser experience?

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

@@ -1,6 +1,6 @@
 ---
 name: review-referral
-description: Review referral - attribution, anti-fraud, rewards, clawback
+description: Review referral - attribution, rewards, fraud prevention
 agent: coder
 ---
 
@@ -12,43 +12,30 @@ agent: coder
 * **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
 * Deliverables must be stated as **findings, gaps, and actionable recommendations**.
 * **Single-pass delivery**: no deferrals; deliver a complete assessment.
+* **Explore beyond the spec**: identify growth opportunities and fraud vectors.
 
-## 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
-
-### Referral Best Practices
-
-* Clear attribution window
-* Reward triggers well-defined
-* Double-sided rewards (referrer + referee)
-* Fraud detection signals
-* Admin visibility into referral chains
-* Automated clawback on refund/chargeback
-
-## Verification Checklist
-
-- [ ] Attribution tracking works
-- [ ] Reward lifecycle defined
-- [ ] Velocity controls implemented
-- [ ] Device/account linkage checked
-- [ ] Clawback on fraud/refund
-- [ ] Admin can review referrals
-- [ ] Localized referral messaging
+## Tech Stack
+
+* **Analytics**: PostHog
+* **Database**: Neon (Postgres)
+
+## Non-Negotiables
+
+* Referral rewards must have clawback capability for fraud
+* Attribution must be auditable (who referred whom, when, reward status)
+* Velocity controls must exist to prevent abuse
+
+## Context
+
+Referral programs can drive explosive growth — or become fraud magnets. The best referral programs make sharing natural and rewarding. The worst become liability when abusers exploit them.
+
+Consider both sides: what makes users want to share? And what prevents bad actors from gaming the system? A referral program that's easy to abuse is worse than no referral program.
+
+## Driving Questions
+
+* Why would a user share this product with someone they know?
+* How easy is it for a bad actor to generate fake referrals?
+* What fraud patterns exist that we haven't addressed?
+* What is the actual ROI of the referral program?
+* Where do users drop off in the referral/share flow?
+* If we redesigned referrals from scratch, what would be different?

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

@@ -1,6 +1,6 @@
 ---
 name: review-security
-description: Review security - OWASP, CSP/HSTS, CSRF, anti-bot, rate limiting
+description: Review security - OWASP, headers, authentication, secrets
 agent: coder
 ---
 
@@ -8,46 +8,39 @@ agent: coder
 
 ## Mandate
 
-* Perform a **deep, thorough review** of security controls in this codebase.
+* Perform a **deep, thorough review** of security 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 not listed here.
 
-## Review Scope
+## Tech Stack
 
-### Security Baseline
+* **Rate Limiting**: Upstash Redis
+* **Framework**: Next.js
+* **Platform**: Vercel
 
-* 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.
+## Non-Negotiables
 
-### Baseline Controls
+* OWASP Top 10:2025 vulnerabilities must be addressed
+* CSP, HSTS, X-Frame-Options, X-Content-Type-Options headers must be present
+* CSRF protection on state-changing requests
+* No plaintext passwords in logs, returns, storage, or telemetry
+* MFA required for Admin/SUPER_ADMIN roles
+* Required configuration must fail-fast at build/startup if missing
+* Secrets must not be hardcoded or committed
 
-* CSP/HSTS/headers
-* CSRF where applicable
-* Upstash-backed rate limiting
-* PII scrubbing
-* Supply-chain hygiene
-* Measurable security
+## Context
 
-### Verification Requirements
+Security isn't a feature — it's a foundational property. A single vulnerability can compromise everything else. The review should think like an attacker: where are the weak points? What would I exploit?
 
-* **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.
+Beyond fixing vulnerabilities, consider the security architecture holistically. Is defense-in-depth implemented? Are there single points of failure? Would you trust this system with your own data?
 
-### Configuration and Secrets Governance
+## Driving Questions
 
-* Required configuration must fail-fast at build/startup
-* Strict environment isolation (dev/stage/prod)
-* Rotation and incident remediation posture must be auditable and exercisable
-
-## Verification Checklist
-
-- [ ] OWASP Top 10:2025 addressed
-- [ ] CSP headers configured
-- [ ] HSTS enabled
-- [ ] CSRF protection where needed
-- [ ] Rate limiting implemented
-- [ ] No plaintext passwords anywhere
-- [ ] MFA for admin roles
-- [ ] Security headers tested in CI
+* What would an attacker target first?
+* Where is rate limiting missing or insufficient?
+* What attack vectors exist in authentication flows?
+* How are secrets managed and what's the rotation strategy?
+* What happens when a secret is compromised — is incident response exercisable?
+* Where does "security by obscurity" substitute for real controls?

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

@@ -1,6 +1,6 @@
 ---
 name: review-seo
-description: Review SEO - metadata, Open Graph, canonical, hreflang, sitemap
+description: Review SEO - discoverability, metadata, search rankings
 agent: coder
 ---
 
@@ -12,49 +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 what would make this product dominate search results.
 
-## 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
-
-### SEO Best Practices
-
-* Unique titles per page
-* Meta descriptions present
-* Heading hierarchy (single H1)
-* Image alt text
-* Internal linking structure
-* Page speed optimization
-* Mobile-friendly
-* No duplicate content
-
-## Verification Checklist
-
-- [ ] All pages have unique titles
-- [ ] Meta descriptions present
-- [ ] Open Graph tags complete
-- [ ] Canonical URLs correct
-- [ ] hreflang implemented
-- [ ] sitemap.xml exists and valid
-- [ ] robots.txt configured
-- [ ] schema.org markup present
-- [ ] SSR for indexable content
+## Tech Stack
+
+* **Framework**: Next.js (SSR-first for indexable/discovery)
+
+## Non-Negotiables
+
+* All pages must have metadata (title, description)
+* Canonical URLs must be correct (no duplicate content)
+* sitemap.xml and robots.txt must exist and be correct
+
+## Context
+
+SEO is about being found when people are looking for what you offer. Good SEO isn't tricks — it's making content genuinely useful and technically accessible to search engines.
+
+Consider: what queries should this product rank for? What content would genuinely serve those searchers? Is the technical foundation (metadata, structure, performance) supporting or hindering discoverability?
+
+## Driving Questions
+
+* What queries should this product rank #1 for?
+* What content gaps exist that competitors are filling?
+* Where are we losing rankings due to technical issues?
+* What structured data opportunities are we missing?
+* How does Core Web Vitals performance affect our search rankings?
+* What would make Google consider this site authoritative in our domain?

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

@@ -1,6 +1,6 @@
 ---
 name: review-storage
-description: Review storage - Vercel Blob upload governance, intent-based uploads
+description: Review storage - uploads, file handling, security
 agent: coder
 ---
 
@@ -12,30 +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 security risks and cost optimization opportunities.
 
-## Review Scope
+## Tech Stack
 
-### Vercel Blob Upload Governance (Hard Requirement)
+* **Storage**: Vercel Blob
+* **Platform**: Vercel
 
-* 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.
+## Non-Negotiables
 
-### Storage Best Practices
+* Uploads must be intent-based and server-verified (no direct client uploads to permanent storage)
+* Server must validate blob ownership before attaching to resources
+* Abandoned uploads must be cleanable
 
-* No direct client-to-storage writes without server authorization
-* Upload size limits enforced server-side
-* File type validation (not just extension, actual content)
-* Malware scanning if applicable
-* Cleanup of orphaned/abandoned uploads
-* CDN caching strategy defined
+## Context
 
-## Verification Checklist
+File uploads are a common attack vector. Users upload things you don't expect. Files live longer than you plan. Storage costs accumulate quietly. A well-designed upload system is secure, efficient, and maintainable.
 
-- [ ] Intent-based upload flow implemented
-- [ ] Server-issued short-lived authorization
-- [ ] Server validates blob ownership before attach
-- [ ] Idempotent finalize endpoint
-- [ ] Abandoned uploads cleanable
-- [ ] File type/size validation server-side
+Consider: what could a malicious user upload? What happens to files when the referencing entity is deleted? How does storage cost scale with usage?
+
+## Driving Questions
+
+* What could a malicious user do through the upload flow?
+* What happens to orphaned files when entities are deleted?
+* How much are we spending on storage, and is it efficient?
+* What file types do we accept, and should we?
+* How do we handle upload failures gracefully?
+* What content validation exists (type, size, safety)?

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

@@ -1,6 +1,6 @@
 ---
 name: review-support
-description: Review support - contact, communications, newsletter
+description: Review support - help experience, communications, user satisfaction
 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 what would make users feel genuinely supported.
 
-## 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
-
-### Support Best Practices
-
-* Clear contact methods
-* Response time expectations
-* Help center / FAQ
-* Ticket tracking
-* Escalation paths
-* Support-assisted account recovery (with audit)
-
-### Communications
-
-* Transactional emails (Resend)
-* Marketing emails (consent-gated)
-* In-app notifications
-* Push notifications (consent-gated)
-* Email templates localized
-
-## Verification Checklist
-
-- [ ] Contact page discoverable
-- [ ] Contact page localized
-- [ ] WCAG AA compliant
-- [ ] Newsletter consent-aware
-- [ ] Unsubscribe works reliably
-- [ ] Transactional emails work
-- [ ] Support recovery audited
+## Tech Stack
+
+* **Email**: Resend
+* **Framework**: Next.js
+
+## Non-Negotiables
+
+* Unsubscribe must work reliably
+* Support contact must be discoverable
+* Newsletter/marketing must respect consent preferences
+
+## Context
+
+Support is where user trust is won or lost. When something goes wrong, how easy is it to get help? When help arrives, does it actually solve the problem? Great support turns frustrated users into loyal advocates.
+
+Consider the entire help-seeking journey: finding help, explaining the problem, getting resolution. Where is there friction? Where do users give up? What would make users feel genuinely cared for?
+
+## Driving Questions
+
+* When users need help, can they find it easily?
+* What problems do users have that they can't solve themselves?
+* How long does it take to resolve a typical support request?
+* What would reduce support volume without reducing user satisfaction?
+* Where do users get stuck and give up on getting help?
+* What would make the support experience genuinely delightful?

package/assets/slash-commands/review-trust-safety.md

@@ -0,0 +1,42 @@
+---
+name: review-trust-safety
+description: Review trust & safety - abuse prevention, moderation, user protection
+agent: coder
+---
+
+# Trust & Safety Review
+
+## Mandate
+
+* Perform a **deep, thorough review** of trust and safety 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 abuse vectors before bad actors find them.
+
+## Tech Stack
+
+* **Analytics**: PostHog
+* **Database**: Neon (Postgres)
+* **Workflows**: Upstash Workflows + QStash
+
+## Non-Negotiables
+
+* All enforcement actions must be auditable (who/when/why)
+* Appeals process must exist for affected users
+* Graduated response levels must be defined (warn → restrict → suspend → ban)
+
+## Context
+
+Trust & safety is about protecting users — from each other and from malicious actors. Every platform eventually attracts abuse. The question is whether you're prepared for it or scrambling to react.
+
+Consider: what would a bad actor try to do? How would we detect it? How would we respond? What about the false positives — innocent users caught by automated systems? A good T&S system is effective against abuse AND fair to legitimate users.
+
+## Driving Questions
+
+* What would a motivated bad actor try to do on this platform?
+* How would we detect coordinated abuse or bot networks?
+* What happens when automated moderation gets it wrong?
+* How do affected users appeal decisions, and is it fair?
+* What abuse patterns exist that we haven't addressed?
+* What would make users trust that we're protecting them?

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

@@ -1,6 +1,6 @@
 ---
 name: review-uiux
-description: Review UI/UX - design system, tokens, accessibility, guidance
+description: Review UI/UX - design system, accessibility, user experience
 agent: coder
 ---
 
@@ -12,45 +12,28 @@ 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**: if the current design needs fundamental rethinking, propose it.
 
-## 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
-
-### Design System Best Practices
-
-* Consistent spacing scale
-* Typography scale defined
-* Color tokens (semantic, not hardcoded)
-* Component library documented
-* Motion/animation guidelines
-* Error state patterns
-* Loading state patterns
-* Empty state patterns
-
-## Verification Checklist
-
-- [ ] Design tokens used consistently
-- [ ] Dark/light theme works
-- [ ] WCAG AA verified
-- [ ] No CLS issues
-- [ ] Mobile-first responsive
-- [ ] No emoji in UI
-- [ ] Guidance present on key flows
-- [ ] Guidance is dismissible + re-entrable
+## Tech Stack
+
+* **Framework**: Next.js
+* **Icons**: Iconify
+
+## Non-Negotiables
+
+* WCAG AA accessibility compliance
+
+## Context
+
+UI/UX determines how users perceive and interact with the product. A great UI isn't just "correct" — it's delightful, intuitive, and makes complex tasks feel simple.
+
+The review should consider: does the current design truly serve users well? Or does it need fundamental rethinking? Small tweaks to a flawed design won't make it excellent. If redesign is warranted, propose it.
+
+## Driving Questions
+
+* Where do users get confused, frustrated, or give up?
+* If we were designing this from scratch today, what would be different?
+* What would make this experience genuinely delightful, not just functional?
+* How does the design system enable or constrain good UX?
+* What are competitors doing that users might expect?
+* Where is the UI just "okay" when it could be exceptional?

package/package.json

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