@sylphx/flow 2.8.0 → 2.10.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +32 -0
- package/assets/slash-commands/review-account-security.md +51 -0
- package/assets/slash-commands/review-admin.md +54 -0
- package/assets/slash-commands/review-auth.md +47 -0
- package/assets/slash-commands/review-billing.md +47 -0
- package/assets/slash-commands/review-code-quality.md +63 -0
- package/assets/slash-commands/review-data-architecture.md +36 -0
- package/assets/slash-commands/review-database.md +40 -0
- package/assets/slash-commands/review-delivery.md +71 -0
- package/assets/slash-commands/review-discovery.md +49 -0
- package/assets/slash-commands/review-growth.md +62 -0
- package/assets/slash-commands/review-i18n.md +50 -0
- package/assets/slash-commands/review-ledger.md +40 -0
- package/assets/slash-commands/review-observability.md +55 -0
- package/assets/slash-commands/review-operability.md +54 -0
- package/assets/slash-commands/review-performance.md +56 -0
- package/assets/slash-commands/review-pricing.md +48 -0
- package/assets/slash-commands/review-privacy.md +50 -0
- package/assets/slash-commands/review-pwa.md +51 -0
- package/assets/slash-commands/review-referral.md +54 -0
- package/assets/slash-commands/review-security.md +53 -0
- package/assets/slash-commands/review-seo.md +60 -0
- package/assets/slash-commands/review-storage.md +41 -0
- package/assets/slash-commands/review-support.md +55 -0
- package/assets/slash-commands/review-uiux.md +56 -0
- package/package.json +1 -1
- package/assets/slash-commands/saas-admin.md +0 -123
- package/assets/slash-commands/saas-auth.md +0 -78
- package/assets/slash-commands/saas-billing.md +0 -68
- package/assets/slash-commands/saas-discovery.md +0 -135
- package/assets/slash-commands/saas-growth.md +0 -94
- package/assets/slash-commands/saas-i18n.md +0 -66
- package/assets/slash-commands/saas-platform.md +0 -87
- package/assets/slash-commands/saas-review.md +0 -179
- package/assets/slash-commands/saas-security.md +0 -108
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-observability
|
|
3
|
+
description: Review observability - logs, Sentry, correlation IDs, alerting
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Observability Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of observability in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Observability and Alerting (Mandatory)
|
|
19
|
+
|
|
20
|
+
* Structured logs and correlation IDs must exist end-to-end (request/job/webhook) with consistent traceability
|
|
21
|
+
* Define critical-path SLO/SLI posture
|
|
22
|
+
* Define actionable alerts for:
|
|
23
|
+
* Webhook failures
|
|
24
|
+
* Ledger/entitlement drift
|
|
25
|
+
* Authentication attacks
|
|
26
|
+
* Abuse spikes
|
|
27
|
+
* Drift detection
|
|
28
|
+
|
|
29
|
+
### Logging Best Practices
|
|
30
|
+
|
|
31
|
+
* Structured JSON logs
|
|
32
|
+
* Correlation ID in all logs
|
|
33
|
+
* Request ID propagation
|
|
34
|
+
* User context (anonymized where needed)
|
|
35
|
+
* Error stack traces
|
|
36
|
+
* Performance timing
|
|
37
|
+
* No PII in logs
|
|
38
|
+
|
|
39
|
+
### Monitoring
|
|
40
|
+
|
|
41
|
+
* Sentry for error tracking
|
|
42
|
+
* PostHog for product analytics
|
|
43
|
+
* Server metrics (latency, throughput, errors)
|
|
44
|
+
* Database query performance
|
|
45
|
+
* External service health
|
|
46
|
+
|
|
47
|
+
## Verification Checklist
|
|
48
|
+
|
|
49
|
+
- [ ] Structured logging implemented
|
|
50
|
+
- [ ] Correlation IDs propagate
|
|
51
|
+
- [ ] Sentry configured
|
|
52
|
+
- [ ] SLO/SLI defined
|
|
53
|
+
- [ ] Alerts for critical failures
|
|
54
|
+
- [ ] No PII in logs
|
|
55
|
+
- [ ] Dashboards for key metrics
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-operability
|
|
3
|
+
description: Review operability - async workflows, DLQ, retries, drift detection
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Operability Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of operability in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Async/Workflows Governance (Hard Requirement)
|
|
19
|
+
|
|
20
|
+
* Define idempotency and deduplication posture
|
|
21
|
+
* Define controlled retries/backoff
|
|
22
|
+
* **Dead-letter handling must exist and be observable and operable**
|
|
23
|
+
* **Safe replay must be supported**
|
|
24
|
+
* 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
|
|
25
|
+
|
|
26
|
+
### Drift Detection (Hard Requirement)
|
|
27
|
+
|
|
28
|
+
* Drift alerts must have a defined remediation playbook (automated fix or operator workflow)
|
|
29
|
+
* Each remediation must be auditable and support post-incident traceability
|
|
30
|
+
|
|
31
|
+
### Release Safety
|
|
32
|
+
|
|
33
|
+
* Define safe rollout posture with backward compatibility
|
|
34
|
+
* Rollback expectations for billing/ledger/auth changes
|
|
35
|
+
|
|
36
|
+
### Operability Best Practices
|
|
37
|
+
|
|
38
|
+
* Health check endpoints
|
|
39
|
+
* Graceful shutdown
|
|
40
|
+
* Circuit breakers for external services
|
|
41
|
+
* Timeout configuration
|
|
42
|
+
* Retry with exponential backoff
|
|
43
|
+
* Bulk operation controls
|
|
44
|
+
* Maintenance mode capability
|
|
45
|
+
|
|
46
|
+
## Verification Checklist
|
|
47
|
+
|
|
48
|
+
- [ ] Async jobs idempotent
|
|
49
|
+
- [ ] DLQ exists and observable
|
|
50
|
+
- [ ] Safe replay supported
|
|
51
|
+
- [ ] Drift detection implemented
|
|
52
|
+
- [ ] Remediation playbooks exist
|
|
53
|
+
- [ ] Rollback strategy defined
|
|
54
|
+
- [ ] Health checks present
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-performance
|
|
3
|
+
description: Review performance - budgets, Core Web Vitals, caching
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Performance Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of performance in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Performance Requirements
|
|
19
|
+
|
|
20
|
+
* Performance must be **measurable and regression-resistant**:
|
|
21
|
+
* Define and enforce performance budgets for key journeys
|
|
22
|
+
* Define caching boundaries and correctness requirements across SSR/ISR/static and service worker behavior
|
|
23
|
+
* Monitor Core Web Vitals and server latency
|
|
24
|
+
* Alert on regressions
|
|
25
|
+
|
|
26
|
+
### Performance Budget Verification
|
|
27
|
+
|
|
28
|
+
* **Performance budget verification** for key journeys (including Core Web Vitals-related thresholds) with release-blocking regression detection
|
|
29
|
+
|
|
30
|
+
### Core Web Vitals
|
|
31
|
+
|
|
32
|
+
* LCP (Largest Contentful Paint) < 2.5s
|
|
33
|
+
* FID (First Input Delay) < 100ms
|
|
34
|
+
* CLS (Cumulative Layout Shift) < 0.1
|
|
35
|
+
* INP (Interaction to Next Paint) < 200ms
|
|
36
|
+
|
|
37
|
+
### Performance Best Practices
|
|
38
|
+
|
|
39
|
+
* Image optimization (WebP, lazy loading)
|
|
40
|
+
* Code splitting
|
|
41
|
+
* Tree shaking
|
|
42
|
+
* Bundle size monitoring
|
|
43
|
+
* Font optimization
|
|
44
|
+
* Critical CSS
|
|
45
|
+
* Preloading key resources
|
|
46
|
+
* Server response time < 200ms
|
|
47
|
+
|
|
48
|
+
## Verification Checklist
|
|
49
|
+
|
|
50
|
+
- [ ] Performance budgets defined
|
|
51
|
+
- [ ] Core Web Vitals within targets
|
|
52
|
+
- [ ] Regression detection active
|
|
53
|
+
- [ ] Caching boundaries defined
|
|
54
|
+
- [ ] Images optimized
|
|
55
|
+
- [ ] Bundle size acceptable
|
|
56
|
+
- [ ] No render-blocking resources
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-pricing
|
|
3
|
+
description: Review pricing - pricing governance, grandfathering, migrations
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Pricing Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of pricing governance in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Stripe Pricing Governance (Stripe-first, not Dashboard-first)
|
|
19
|
+
|
|
20
|
+
* Stripe is the system-of-record for products, prices, subscriptions, invoices, and disputes; internal systems must not contradict Stripe truth.
|
|
21
|
+
* 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.
|
|
22
|
+
* Default pricing change policy is **grandfathering**: existing subscribers keep their current price; new customers use the currently active sellable price.
|
|
23
|
+
|
|
24
|
+
### Pricing Admin Requirements
|
|
25
|
+
|
|
26
|
+
* An operational-grade Pricing Admin must exist to manage:
|
|
27
|
+
* Creation of new Stripe Prices
|
|
28
|
+
* Activation/deactivation of sellable prices
|
|
29
|
+
* Controlled bulk subscription migrations (optional)
|
|
30
|
+
* All actions must be governed by RBAC, step-up controls, and audit logs.
|
|
31
|
+
* Stripe Dashboard is treated as monitoring/emergency access; non-admin Stripe changes must be detectable (drift), alertable, and remediable.
|
|
32
|
+
|
|
33
|
+
### Pricing Strategy
|
|
34
|
+
|
|
35
|
+
* Clear tier differentiation
|
|
36
|
+
* Feature gating by plan
|
|
37
|
+
* Upgrade/downgrade paths defined
|
|
38
|
+
* Proration handling
|
|
39
|
+
* Trial-to-paid conversion flow
|
|
40
|
+
|
|
41
|
+
## Verification Checklist
|
|
42
|
+
|
|
43
|
+
- [ ] Stripe is system-of-record
|
|
44
|
+
- [ ] New prices don't mutate existing
|
|
45
|
+
- [ ] Grandfathering policy implemented
|
|
46
|
+
- [ ] Pricing admin exists with RBAC
|
|
47
|
+
- [ ] Stripe Dashboard drift detectable
|
|
48
|
+
- [ ] Upgrade/downgrade paths work
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-privacy
|
|
3
|
+
description: Review privacy - consent, PII handling, data lifecycle, GDPR
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Privacy Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of privacy controls in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Consent Governance (Release-Blocking)
|
|
19
|
+
|
|
20
|
+
* Analytics (PostHog) and marketing/newsletter communications (Resend) must be governed by consent and user preferences.
|
|
21
|
+
* Marketing tags (including GTM and Google Ads) must not load or fire without the appropriate consent.
|
|
22
|
+
* Without consent, tracking and marketing sends must not occur, except for strictly necessary service communications.
|
|
23
|
+
* Event schemas and attributes must follow data minimization, with explicit PII classification and handling rules.
|
|
24
|
+
|
|
25
|
+
### PII and Sensitive Data Controls (Hard Requirement)
|
|
26
|
+
|
|
27
|
+
* PII rules apply to logs, Sentry, PostHog, support tooling, email systems, and marketing tags/conversion payloads.
|
|
28
|
+
* A consistent scrubbing/redaction standard must exist, and must be covered by automated tests to prevent leakage to third parties.
|
|
29
|
+
|
|
30
|
+
### Data Lifecycle
|
|
31
|
+
|
|
32
|
+
* Define deletion/deactivation semantics
|
|
33
|
+
* Deletion propagation to third parties
|
|
34
|
+
* Export where applicable
|
|
35
|
+
* DR/backup posture aligned with retention
|
|
36
|
+
* **Define data classification, retention periods, deletion propagation to third-party processors, and explicit exceptions** (legal/tax/anti-fraud)
|
|
37
|
+
* Ensure external disclosures match behavior
|
|
38
|
+
|
|
39
|
+
### Behavioral Consistency
|
|
40
|
+
|
|
41
|
+
* **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.
|
|
42
|
+
|
|
43
|
+
## Verification Checklist
|
|
44
|
+
|
|
45
|
+
- [ ] Consent gates analytics/marketing
|
|
46
|
+
- [ ] No tracking without consent
|
|
47
|
+
- [ ] PII scrubbed from logs/Sentry/PostHog
|
|
48
|
+
- [ ] Data deletion flow works
|
|
49
|
+
- [ ] Deletion propagates to third parties
|
|
50
|
+
- [ ] Privacy policy matches actual behavior
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-pwa
|
|
3
|
+
description: Review PWA - manifest, service worker, caching, push notifications
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# PWA Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of PWA implementation in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### PWA Requirements
|
|
19
|
+
|
|
20
|
+
* Manifest file complete and valid
|
|
21
|
+
* Service worker with explicit cache correctness
|
|
22
|
+
* Push notifications using VAPID where applicable
|
|
23
|
+
|
|
24
|
+
### Service Worker Caching Boundary (Mandatory)
|
|
25
|
+
|
|
26
|
+
* Service worker must not cache personalized/sensitive/authorized content
|
|
27
|
+
* Authenticated and entitlement-sensitive routes must have explicit cache-control and SW rules
|
|
28
|
+
* Must be validated by tests to prevent stale or unauthorized state exposure
|
|
29
|
+
|
|
30
|
+
### PWA Best Practices
|
|
31
|
+
|
|
32
|
+
* Installable (meets PWA criteria)
|
|
33
|
+
* Offline fallback page
|
|
34
|
+
* App icons (all sizes)
|
|
35
|
+
* Splash screen configured
|
|
36
|
+
* Theme color defined
|
|
37
|
+
* Start URL configured
|
|
38
|
+
* Display mode appropriate
|
|
39
|
+
* Cache versioning strategy
|
|
40
|
+
* Cache invalidation on deploy
|
|
41
|
+
|
|
42
|
+
## Verification Checklist
|
|
43
|
+
|
|
44
|
+
- [ ] Valid manifest.json
|
|
45
|
+
- [ ] Service worker registered
|
|
46
|
+
- [ ] SW doesn't cache auth content
|
|
47
|
+
- [ ] Cache-control headers correct
|
|
48
|
+
- [ ] Push notifications work (if applicable)
|
|
49
|
+
- [ ] Installable on mobile
|
|
50
|
+
- [ ] Offline fallback exists
|
|
51
|
+
- [ ] Cache invalidation tested
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-referral
|
|
3
|
+
description: Review referral - attribution, anti-fraud, rewards, clawback
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Referral Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of the referral system in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Referral (Anti-Abuse Baseline Required)
|
|
19
|
+
|
|
20
|
+
* Referral must be measurable, abuse-resistant, and governed:
|
|
21
|
+
* Attribution semantics
|
|
22
|
+
* Reward lifecycle governance (including revocation/clawbacks)
|
|
23
|
+
* Anti-fraud measures
|
|
24
|
+
* Admin reporting/audit
|
|
25
|
+
* Localized and instrumented
|
|
26
|
+
|
|
27
|
+
### Referral Anti-Fraud Minimum Baseline (Mandatory)
|
|
28
|
+
|
|
29
|
+
* Define a minimum set of risk signals and enforcement measures, including:
|
|
30
|
+
* Velocity controls
|
|
31
|
+
* Account/device linkage posture
|
|
32
|
+
* Risk-tiered enforcement
|
|
33
|
+
* Reward delay/hold/freeze
|
|
34
|
+
* Clawback conditions
|
|
35
|
+
* Auditable manual review/appeal posture where applicable
|
|
36
|
+
|
|
37
|
+
### Referral Best Practices
|
|
38
|
+
|
|
39
|
+
* Clear attribution window
|
|
40
|
+
* Reward triggers well-defined
|
|
41
|
+
* Double-sided rewards (referrer + referee)
|
|
42
|
+
* Fraud detection signals
|
|
43
|
+
* Admin visibility into referral chains
|
|
44
|
+
* Automated clawback on refund/chargeback
|
|
45
|
+
|
|
46
|
+
## Verification Checklist
|
|
47
|
+
|
|
48
|
+
- [ ] Attribution tracking works
|
|
49
|
+
- [ ] Reward lifecycle defined
|
|
50
|
+
- [ ] Velocity controls implemented
|
|
51
|
+
- [ ] Device/account linkage checked
|
|
52
|
+
- [ ] Clawback on fraud/refund
|
|
53
|
+
- [ ] Admin can review referrals
|
|
54
|
+
- [ ] Localized referral messaging
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-security
|
|
3
|
+
description: Review security - OWASP, CSP/HSTS, CSRF, anti-bot, rate limiting
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Security Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of security controls in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Security Baseline
|
|
19
|
+
|
|
20
|
+
* OWASP Top 10:2025 taxonomy; OWASP ASVS (L2/L3) verification baseline.
|
|
21
|
+
* Password UX masked + temporary reveal; no plaintext passwords in logs/returns/storage/telemetry.
|
|
22
|
+
* MFA for Admin/SUPER_ADMIN; step-up for high-risk.
|
|
23
|
+
* Risk-based anti-bot for auth and high-cost endpoints; integrate rate limits + consent gating.
|
|
24
|
+
|
|
25
|
+
### Baseline Controls
|
|
26
|
+
|
|
27
|
+
* CSP/HSTS/headers
|
|
28
|
+
* CSRF where applicable
|
|
29
|
+
* Upstash-backed rate limiting
|
|
30
|
+
* PII scrubbing
|
|
31
|
+
* Supply-chain hygiene
|
|
32
|
+
* Measurable security
|
|
33
|
+
|
|
34
|
+
### Verification Requirements
|
|
35
|
+
|
|
36
|
+
* **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.
|
|
37
|
+
|
|
38
|
+
### Configuration and Secrets Governance
|
|
39
|
+
|
|
40
|
+
* Required configuration must fail-fast at build/startup
|
|
41
|
+
* Strict environment isolation (dev/stage/prod)
|
|
42
|
+
* Rotation and incident remediation posture must be auditable and exercisable
|
|
43
|
+
|
|
44
|
+
## Verification Checklist
|
|
45
|
+
|
|
46
|
+
- [ ] OWASP Top 10:2025 addressed
|
|
47
|
+
- [ ] CSP headers configured
|
|
48
|
+
- [ ] HSTS enabled
|
|
49
|
+
- [ ] CSRF protection where needed
|
|
50
|
+
- [ ] Rate limiting implemented
|
|
51
|
+
- [ ] No plaintext passwords anywhere
|
|
52
|
+
- [ ] MFA for admin roles
|
|
53
|
+
- [ ] Security headers tested in CI
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-seo
|
|
3
|
+
description: Review SEO - metadata, Open Graph, canonical, hreflang, sitemap
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# SEO Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of SEO in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### SEO Requirements
|
|
19
|
+
|
|
20
|
+
* SEO-first + SSR-first for indexable/discovery
|
|
21
|
+
* Required elements:
|
|
22
|
+
* Metadata (title, description)
|
|
23
|
+
* Open Graph tags
|
|
24
|
+
* Favicon (all sizes)
|
|
25
|
+
* Canonical URLs
|
|
26
|
+
* hreflang + x-default
|
|
27
|
+
* schema.org structured data
|
|
28
|
+
* sitemap.xml
|
|
29
|
+
* robots.txt
|
|
30
|
+
|
|
31
|
+
### SEO/i18n/Canonicalization Verification
|
|
32
|
+
|
|
33
|
+
* `/en/*` non-existence (must redirect)
|
|
34
|
+
* hreflang/x-default correct
|
|
35
|
+
* Sitemap containing only true variants
|
|
36
|
+
* UGC canonical redirects
|
|
37
|
+
* Locale routing invariants
|
|
38
|
+
|
|
39
|
+
### SEO Best Practices
|
|
40
|
+
|
|
41
|
+
* Unique titles per page
|
|
42
|
+
* Meta descriptions present
|
|
43
|
+
* Heading hierarchy (single H1)
|
|
44
|
+
* Image alt text
|
|
45
|
+
* Internal linking structure
|
|
46
|
+
* Page speed optimization
|
|
47
|
+
* Mobile-friendly
|
|
48
|
+
* No duplicate content
|
|
49
|
+
|
|
50
|
+
## Verification Checklist
|
|
51
|
+
|
|
52
|
+
- [ ] All pages have unique titles
|
|
53
|
+
- [ ] Meta descriptions present
|
|
54
|
+
- [ ] Open Graph tags complete
|
|
55
|
+
- [ ] Canonical URLs correct
|
|
56
|
+
- [ ] hreflang implemented
|
|
57
|
+
- [ ] sitemap.xml exists and valid
|
|
58
|
+
- [ ] robots.txt configured
|
|
59
|
+
- [ ] schema.org markup present
|
|
60
|
+
- [ ] SSR for indexable content
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-storage
|
|
3
|
+
description: Review storage - Vercel Blob upload governance, intent-based uploads
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Storage Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of file storage and uploads in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Vercel Blob Upload Governance (Hard Requirement)
|
|
19
|
+
|
|
20
|
+
* All uploads must be **intent-based and server-verified**.
|
|
21
|
+
* 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.
|
|
22
|
+
* 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.
|
|
23
|
+
* The system must support safe retries and idempotent finalize; expired/abandoned intents must be cleanable and auditable.
|
|
24
|
+
|
|
25
|
+
### Storage Best Practices
|
|
26
|
+
|
|
27
|
+
* No direct client-to-storage writes without server authorization
|
|
28
|
+
* Upload size limits enforced server-side
|
|
29
|
+
* File type validation (not just extension, actual content)
|
|
30
|
+
* Malware scanning if applicable
|
|
31
|
+
* Cleanup of orphaned/abandoned uploads
|
|
32
|
+
* CDN caching strategy defined
|
|
33
|
+
|
|
34
|
+
## Verification Checklist
|
|
35
|
+
|
|
36
|
+
- [ ] Intent-based upload flow implemented
|
|
37
|
+
- [ ] Server-issued short-lived authorization
|
|
38
|
+
- [ ] Server validates blob ownership before attach
|
|
39
|
+
- [ ] Idempotent finalize endpoint
|
|
40
|
+
- [ ] Abandoned uploads cleanable
|
|
41
|
+
- [ ] File type/size validation server-side
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-support
|
|
3
|
+
description: Review support - contact, communications, newsletter
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Support Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of support and communications in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### Support and Communications
|
|
19
|
+
|
|
20
|
+
* Support/Contact surface must be:
|
|
21
|
+
* Discoverable
|
|
22
|
+
* Localized
|
|
23
|
+
* WCAG AA compliant
|
|
24
|
+
* SEO-complete
|
|
25
|
+
* Privacy-safe
|
|
26
|
+
* Auditable where relevant
|
|
27
|
+
* Newsletter subscription/preferences must be consent-aware
|
|
28
|
+
* Unsubscribe enforcement must be reliable
|
|
29
|
+
|
|
30
|
+
### Support Best Practices
|
|
31
|
+
|
|
32
|
+
* Clear contact methods
|
|
33
|
+
* Response time expectations
|
|
34
|
+
* Help center / FAQ
|
|
35
|
+
* Ticket tracking
|
|
36
|
+
* Escalation paths
|
|
37
|
+
* Support-assisted account recovery (with audit)
|
|
38
|
+
|
|
39
|
+
### Communications
|
|
40
|
+
|
|
41
|
+
* Transactional emails (Resend)
|
|
42
|
+
* Marketing emails (consent-gated)
|
|
43
|
+
* In-app notifications
|
|
44
|
+
* Push notifications (consent-gated)
|
|
45
|
+
* Email templates localized
|
|
46
|
+
|
|
47
|
+
## Verification Checklist
|
|
48
|
+
|
|
49
|
+
- [ ] Contact page discoverable
|
|
50
|
+
- [ ] Contact page localized
|
|
51
|
+
- [ ] WCAG AA compliant
|
|
52
|
+
- [ ] Newsletter consent-aware
|
|
53
|
+
- [ ] Unsubscribe works reliably
|
|
54
|
+
- [ ] Transactional emails work
|
|
55
|
+
- [ ] Support recovery audited
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-uiux
|
|
3
|
+
description: Review UI/UX - design system, tokens, accessibility, guidance
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# UI/UX Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of UI/UX in this codebase.
|
|
12
|
+
* **Delegate to multiple workers** to research different aspects in parallel; you act as the **final gate** to synthesize and verify quality.
|
|
13
|
+
* Deliverables must be stated as **findings, gaps, and actionable recommendations**.
|
|
14
|
+
* **Single-pass delivery**: no deferrals; deliver a complete assessment.
|
|
15
|
+
|
|
16
|
+
## Review Scope
|
|
17
|
+
|
|
18
|
+
### UX, Design System, and Guidance
|
|
19
|
+
|
|
20
|
+
* Design-system driven UI (tokens)
|
|
21
|
+
* Dark/light theme support
|
|
22
|
+
* WCAG AA compliance
|
|
23
|
+
* CLS-safe (no layout shifts)
|
|
24
|
+
* Responsive design (mobile-first, desktop-second)
|
|
25
|
+
* Iconify for icons; no emoji in UI content
|
|
26
|
+
|
|
27
|
+
### Guidance Requirements
|
|
28
|
+
|
|
29
|
+
* Guidance is mandatory for all user-facing features and monetization flows:
|
|
30
|
+
* Discoverable
|
|
31
|
+
* Clear
|
|
32
|
+
* Dismissible with re-entry
|
|
33
|
+
* Localized and measurable
|
|
34
|
+
* Governed by eligibility and frequency controls
|
|
35
|
+
|
|
36
|
+
### Design System Best Practices
|
|
37
|
+
|
|
38
|
+
* Consistent spacing scale
|
|
39
|
+
* Typography scale defined
|
|
40
|
+
* Color tokens (semantic, not hardcoded)
|
|
41
|
+
* Component library documented
|
|
42
|
+
* Motion/animation guidelines
|
|
43
|
+
* Error state patterns
|
|
44
|
+
* Loading state patterns
|
|
45
|
+
* Empty state patterns
|
|
46
|
+
|
|
47
|
+
## Verification Checklist
|
|
48
|
+
|
|
49
|
+
- [ ] Design tokens used consistently
|
|
50
|
+
- [ ] Dark/light theme works
|
|
51
|
+
- [ ] WCAG AA verified
|
|
52
|
+
- [ ] No CLS issues
|
|
53
|
+
- [ ] Mobile-first responsive
|
|
54
|
+
- [ ] No emoji in UI
|
|
55
|
+
- [ ] Guidance present on key flows
|
|
56
|
+
- [ ] Guidance is dismissible + re-entrable
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@sylphx/flow",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.10.0",
|
|
4
4
|
"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.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|