@sylphx/flow 2.9.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 +19 -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 -178
- package/assets/slash-commands/saas-security.md +0 -108
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,24 @@
|
|
|
1
1
|
# @sylphx/flow
|
|
2
2
|
|
|
3
|
+
## 2.10.0 (2025-12-17)
|
|
4
|
+
|
|
5
|
+
Replace saas-* commands with 24 focused /review-* commands.
|
|
6
|
+
|
|
7
|
+
Each domain now has a dedicated review command with mandate to delegate to multiple workers for parallel research.
|
|
8
|
+
|
|
9
|
+
Categories:
|
|
10
|
+
- Core Architecture (4): data-architecture, database, ledger, storage
|
|
11
|
+
- Identity & Security (4): auth, account-security, security, privacy
|
|
12
|
+
- Billing & Commerce (3): billing, pricing, referral
|
|
13
|
+
- Frontend & Experience (5): uiux, i18n, seo, pwa, performance
|
|
14
|
+
- Operations & Management (4): admin, observability, operability, support
|
|
15
|
+
- Growth & Research (2): growth, discovery
|
|
16
|
+
- Quality & Delivery (2): code-quality, delivery
|
|
17
|
+
|
|
18
|
+
### ✨ Features
|
|
19
|
+
|
|
20
|
+
- **commands:** replace saas-* with 24 focused /review-* commands ([c2f9eb9](https://github.com/SylphxAI/flow/commit/c2f9eb9bad695714be08645163480b46b9286b99))
|
|
21
|
+
|
|
3
22
|
## 2.9.0 (2025-12-17)
|
|
4
23
|
|
|
5
24
|
Add comprehensive SaaS review command suite with parallel worker delegation.
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-account-security
|
|
3
|
+
description: Review account security - sessions, devices, MFA, security events
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Account Security Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of account security 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
|
+
### Membership and Account Security
|
|
19
|
+
|
|
20
|
+
* Membership is entitlement-driven and server-enforced.
|
|
21
|
+
* Provide a dedicated **Account Security** surface.
|
|
22
|
+
* **Account Security minimum acceptance**:
|
|
23
|
+
* Session/device visibility and revocation
|
|
24
|
+
* MFA/passkey management
|
|
25
|
+
* Linked identity provider management
|
|
26
|
+
* Key security event visibility (and export where applicable)
|
|
27
|
+
* All server-enforced and auditable
|
|
28
|
+
|
|
29
|
+
### Security Event Management
|
|
30
|
+
|
|
31
|
+
* Login attempts (success/failure) logged
|
|
32
|
+
* Password changes logged
|
|
33
|
+
* MFA enrollment/removal logged
|
|
34
|
+
* Session creation/revocation logged
|
|
35
|
+
* Suspicious activity detection
|
|
36
|
+
* Security event notifications
|
|
37
|
+
|
|
38
|
+
### Recovery Governance
|
|
39
|
+
|
|
40
|
+
* Account recovery flow secure
|
|
41
|
+
* Support-assisted recovery with strict audit logging
|
|
42
|
+
* Step-up verification for sensitive actions
|
|
43
|
+
|
|
44
|
+
## Verification Checklist
|
|
45
|
+
|
|
46
|
+
- [ ] Session/device visibility exists
|
|
47
|
+
- [ ] Session revocation works
|
|
48
|
+
- [ ] MFA management available
|
|
49
|
+
- [ ] Identity provider linking visible
|
|
50
|
+
- [ ] Security events logged and visible
|
|
51
|
+
- [ ] Recovery flow is secure and audited
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-admin
|
|
3
|
+
description: Review admin - RBAC, bootstrap, config management, feature flags
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Admin Platform Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of the admin platform 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
|
+
### Admin Platform (Operational-Grade)
|
|
19
|
+
|
|
20
|
+
* Baseline: RBAC (least privilege), audit logs, feature flags governance, optional impersonation with safeguards and auditing.
|
|
21
|
+
|
|
22
|
+
### Admin Bootstrap (Critical)
|
|
23
|
+
|
|
24
|
+
* Admin bootstrap must not rely on file seeding:
|
|
25
|
+
* Use a secure, auditable **first-login allowlist** for the initial SUPER_ADMIN.
|
|
26
|
+
* Permanently disable bootstrap after completion.
|
|
27
|
+
* All privilege grants must be server-enforced and recorded in the audit log.
|
|
28
|
+
* The allowlist must be managed via secure configuration (environment/secret store), not code or DB seeding.
|
|
29
|
+
|
|
30
|
+
### Configuration Management (Mandatory)
|
|
31
|
+
|
|
32
|
+
* All **non-secret** product-level configuration must be manageable via admin (server-enforced), with validation and change history.
|
|
33
|
+
* Secrets/credentials are environment-managed only; admin may expose safe readiness/health visibility, not raw secrets.
|
|
34
|
+
|
|
35
|
+
### Admin Analytics and Reporting (Mandatory)
|
|
36
|
+
|
|
37
|
+
* Provide comprehensive dashboards/reports for business, growth, billing, referral, support, and security/abuse signals, governed by RBAC.
|
|
38
|
+
* Reporting must be consistent with system-of-record truth and auditable when derived from privileged actions.
|
|
39
|
+
|
|
40
|
+
### Admin Operational Management (Mandatory)
|
|
41
|
+
|
|
42
|
+
* Tools for user/account management, entitlements/access management, lifecycle actions, and issue resolution workflows.
|
|
43
|
+
* Actions affecting access, money/credits, or security posture require appropriate step-up controls and must be fully auditable; reversibility must follow domain rules.
|
|
44
|
+
|
|
45
|
+
## Verification Checklist
|
|
46
|
+
|
|
47
|
+
- [ ] RBAC implemented (least privilege)
|
|
48
|
+
- [ ] Admin bootstrap secure (not file seeding)
|
|
49
|
+
- [ ] Bootstrap disables after completion
|
|
50
|
+
- [ ] Config management with history
|
|
51
|
+
- [ ] Feature flags governed
|
|
52
|
+
- [ ] Admin dashboards exist
|
|
53
|
+
- [ ] Impersonation has safeguards
|
|
54
|
+
- [ ] All admin actions audited
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-auth
|
|
3
|
+
description: Review authentication - SSO providers, passkeys, verification, sign-in
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Authentication Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of authentication 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
|
+
### Identity, Verification, and Sign-in
|
|
19
|
+
|
|
20
|
+
* SSO providers (minimum): **Google, Apple, Facebook, Microsoft, GitHub** (prioritize by audience).
|
|
21
|
+
* If provider env/secrets are missing, **hide** the login option (no broken/disabled UI).
|
|
22
|
+
* Allow linking multiple providers and safe unlinking; server-enforced and abuse-protected.
|
|
23
|
+
* Passkeys (WebAuthn) are first-class with secure enrollment/usage/recovery.
|
|
24
|
+
|
|
25
|
+
### Verification Requirements
|
|
26
|
+
|
|
27
|
+
* **Email verification is mandatory** baseline for high-impact capabilities.
|
|
28
|
+
* **Phone verification is optional** and used as risk-based step-up (anti-abuse, higher-trust flows, recovery); consent-aware and data-minimizing.
|
|
29
|
+
|
|
30
|
+
### Authentication Best Practices
|
|
31
|
+
|
|
32
|
+
* Secure session management
|
|
33
|
+
* Token rotation and expiry
|
|
34
|
+
* Brute force protection
|
|
35
|
+
* Account enumeration prevention
|
|
36
|
+
* Secure password reset flow
|
|
37
|
+
* Remember me functionality (secure)
|
|
38
|
+
|
|
39
|
+
## Verification Checklist
|
|
40
|
+
|
|
41
|
+
- [ ] All SSO providers implemented
|
|
42
|
+
- [ ] Missing provider secrets hide UI option
|
|
43
|
+
- [ ] Multi-provider linking works safely
|
|
44
|
+
- [ ] Passkeys (WebAuthn) supported
|
|
45
|
+
- [ ] Email verification enforced
|
|
46
|
+
- [ ] Phone verification optional/step-up
|
|
47
|
+
- [ ] Session management secure
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-billing
|
|
3
|
+
description: Review billing - Stripe integration, webhooks, state machine
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Billing Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of billing and payments 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
|
+
### Billing and Payments (Stripe)
|
|
19
|
+
|
|
20
|
+
* Support subscriptions and one-time payments as product needs require.
|
|
21
|
+
* **Billing state machine follows mapping requirements**; UI must only surface explainable, non-ambiguous states aligned to server-truth.
|
|
22
|
+
* Tax/invoicing and refund/dispute handling must be behaviorally consistent with product UX and entitlement state.
|
|
23
|
+
|
|
24
|
+
### Webhook Requirements (High-Risk)
|
|
25
|
+
|
|
26
|
+
* Webhooks must be idempotent, retry-safe, out-of-order safe, auditable
|
|
27
|
+
* Billing UI reflects server-truth state without ambiguity
|
|
28
|
+
* **Webhook trust is mandatory**: webhook origin must be verified (signature verification and replay resistance)
|
|
29
|
+
* The Stripe **event id** must be used as the idempotency and audit correlation key
|
|
30
|
+
* Unverifiable events must be rejected and must trigger alerting
|
|
31
|
+
* **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)
|
|
32
|
+
|
|
33
|
+
### State Machine
|
|
34
|
+
|
|
35
|
+
* Define mapping: **Stripe state → internal subscription state → entitlements**
|
|
36
|
+
* Handle: trial, past_due, unpaid, canceled, refund, dispute
|
|
37
|
+
* UI only shows interpretable, non-ambiguous states
|
|
38
|
+
|
|
39
|
+
## Verification Checklist
|
|
40
|
+
|
|
41
|
+
- [ ] Billing state machine defined
|
|
42
|
+
- [ ] Webhook signature verification
|
|
43
|
+
- [ ] Idempotent webhook handling (event id)
|
|
44
|
+
- [ ] Out-of-order handling defined
|
|
45
|
+
- [ ] All Stripe states mapped
|
|
46
|
+
- [ ] UI reflects server-truth only
|
|
47
|
+
- [ ] Refund/dispute handling works
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-code-quality
|
|
3
|
+
description: Review code quality - linting, TypeScript, testing, CI
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Code Quality Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of code quality 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
|
+
### Non-Negotiable Engineering Principles
|
|
19
|
+
|
|
20
|
+
* No workarounds, hacks, or TODOs.
|
|
21
|
+
* Feature-first with clean architecture; designed for easy extension; no "god files".
|
|
22
|
+
* Type-first, strict end-to-end correctness (**DB → API → UI**).
|
|
23
|
+
* Serverless-first and server-first; edge-compatible where feasible without sacrificing correctness, security, or observability.
|
|
24
|
+
* Mobile-first responsive design; desktop-second.
|
|
25
|
+
* Precise naming; remove dead/unused code.
|
|
26
|
+
* Upgrade all packages to latest stable; avoid deprecated patterns.
|
|
27
|
+
|
|
28
|
+
### Tooling Baseline
|
|
29
|
+
|
|
30
|
+
* **Bun** for runtime
|
|
31
|
+
* **Biome** for linting/formatting
|
|
32
|
+
* **Bun test** for testing
|
|
33
|
+
* Strict TypeScript
|
|
34
|
+
|
|
35
|
+
### CI Requirements
|
|
36
|
+
|
|
37
|
+
* Biome lint/format passes
|
|
38
|
+
* Strict TS typecheck passes
|
|
39
|
+
* Unit + E2E tests pass
|
|
40
|
+
* Build succeeds
|
|
41
|
+
|
|
42
|
+
### Code Quality Best Practices
|
|
43
|
+
|
|
44
|
+
* Consistent code style
|
|
45
|
+
* Meaningful variable/function names
|
|
46
|
+
* Single responsibility principle
|
|
47
|
+
* DRY (Don't Repeat Yourself)
|
|
48
|
+
* SOLID principles
|
|
49
|
+
* No circular dependencies
|
|
50
|
+
* Reasonable file sizes
|
|
51
|
+
* Clear module boundaries
|
|
52
|
+
|
|
53
|
+
## Verification Checklist
|
|
54
|
+
|
|
55
|
+
- [ ] Biome lint passes
|
|
56
|
+
- [ ] Biome format passes
|
|
57
|
+
- [ ] TypeScript strict mode
|
|
58
|
+
- [ ] No type errors
|
|
59
|
+
- [ ] Tests exist and pass
|
|
60
|
+
- [ ] Build succeeds
|
|
61
|
+
- [ ] No TODOs/hacks
|
|
62
|
+
- [ ] No dead code
|
|
63
|
+
- [ ] Packages up to date
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-data-architecture
|
|
3
|
+
description: Review data architecture - boundaries, consistency model, server enforcement
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Data Architecture Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of data architecture 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
|
+
### Boundaries, Server Enforcement, and Consistency Model (Hard Requirement)
|
|
19
|
+
|
|
20
|
+
* Define clear boundaries: domain rules, use-cases, integrations, UI.
|
|
21
|
+
* All authorization/entitlements are **server-enforced**; no client-trust.
|
|
22
|
+
* Runtime constraints (serverless/edge) must be explicit and validated.
|
|
23
|
+
* **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).
|
|
24
|
+
* **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.
|
|
25
|
+
* **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.
|
|
26
|
+
* **Server-truth is authoritative**: UI state must never contradict server-truth. Where asynchronous confirmation exists, UI must represent that state unambiguously and remain explainable.
|
|
27
|
+
* **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.
|
|
28
|
+
|
|
29
|
+
## Verification Checklist
|
|
30
|
+
|
|
31
|
+
- [ ] Clear domain boundaries defined
|
|
32
|
+
- [ ] Server enforcement for all authorization
|
|
33
|
+
- [ ] Explicit consistency model documented
|
|
34
|
+
- [ ] State machine for billing/entitlements exists
|
|
35
|
+
- [ ] No dual-write violations
|
|
36
|
+
- [ ] Auditability chain implemented
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-database
|
|
3
|
+
description: Review database - Drizzle migrations, schema drift, CI gates
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Database Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of database architecture 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
|
+
### Drizzle Migrations (Non-Negotiable)
|
|
19
|
+
|
|
20
|
+
* Migration files must exist, be complete, and be committed.
|
|
21
|
+
* Deterministic, reproducible, environment-safe; linear/auditable history; no drift.
|
|
22
|
+
* CI must fail if schema changes are not represented by migrations.
|
|
23
|
+
|
|
24
|
+
### Database Best Practices
|
|
25
|
+
|
|
26
|
+
* Schema design follows normalization principles where appropriate
|
|
27
|
+
* Indexes exist for commonly queried columns
|
|
28
|
+
* Foreign key constraints are properly defined
|
|
29
|
+
* No orphaned tables or columns
|
|
30
|
+
* Proper use of data types (no stringly-typed data)
|
|
31
|
+
* Timestamps use consistent timezone handling
|
|
32
|
+
|
|
33
|
+
## Verification Checklist
|
|
34
|
+
|
|
35
|
+
- [ ] All migrations committed and complete
|
|
36
|
+
- [ ] No schema drift detected
|
|
37
|
+
- [ ] CI blocks on migration integrity
|
|
38
|
+
- [ ] Indexes cover common queries
|
|
39
|
+
- [ ] Foreign keys properly defined
|
|
40
|
+
- [ ] Data types appropriate
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-delivery
|
|
3
|
+
description: Review delivery gates - release blocking checks, verification
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Delivery Gates Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of delivery gates 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
|
+
### Delivery Gates and Completion
|
|
19
|
+
|
|
20
|
+
CI must block merges/deploys when failing:
|
|
21
|
+
|
|
22
|
+
#### Code Quality Gates
|
|
23
|
+
- [ ] Biome lint/format passes
|
|
24
|
+
- [ ] Strict TS typecheck passes
|
|
25
|
+
- [ ] Unit + E2E tests pass (Bun test)
|
|
26
|
+
- [ ] Build succeeds
|
|
27
|
+
|
|
28
|
+
#### Data Integrity Gates
|
|
29
|
+
- [ ] Migration integrity checks pass
|
|
30
|
+
- [ ] No schema drift
|
|
31
|
+
|
|
32
|
+
#### i18n Gates
|
|
33
|
+
- [ ] Missing translation keys fail build
|
|
34
|
+
- [ ] `/en/*` returns 301 redirect
|
|
35
|
+
- [ ] hreflang/x-default correct
|
|
36
|
+
- [ ] Sitemap contains only true variants
|
|
37
|
+
|
|
38
|
+
#### Performance Gates
|
|
39
|
+
- [ ] Performance budget verification for key journeys
|
|
40
|
+
- [ ] Core Web Vitals within thresholds
|
|
41
|
+
- [ ] Release-blocking regression detection
|
|
42
|
+
|
|
43
|
+
#### Security Gates
|
|
44
|
+
- [ ] CSP/HSTS/security headers verified
|
|
45
|
+
- [ ] CSRF protection tested
|
|
46
|
+
|
|
47
|
+
#### Consent Gates
|
|
48
|
+
- [ ] Analytics/marketing consent gating verified
|
|
49
|
+
- [ ] Newsletter eligibility and firing rules tested
|
|
50
|
+
|
|
51
|
+
### Automation Requirement
|
|
52
|
+
|
|
53
|
+
**All gates above must be enforced by automated tests or mechanized checks (non-manual); manual verification does not satisfy release gates.**
|
|
54
|
+
|
|
55
|
+
### Configuration Gates
|
|
56
|
+
|
|
57
|
+
* Build/startup must fail-fast when required configuration/secrets are missing or invalid for the target environment.
|
|
58
|
+
|
|
59
|
+
### Operability Gates
|
|
60
|
+
|
|
61
|
+
* Observability and alerting configured for critical anomalies
|
|
62
|
+
* Workflow dead-letter handling is operable, visible, and supports controlled replay
|
|
63
|
+
|
|
64
|
+
## Verification Checklist
|
|
65
|
+
|
|
66
|
+
- [ ] All gates automated (no manual)
|
|
67
|
+
- [ ] CI blocks on failures
|
|
68
|
+
- [ ] Config fail-fast works
|
|
69
|
+
- [ ] Operability gates met
|
|
70
|
+
- [ ] No TODOs/hacks/workarounds
|
|
71
|
+
- [ ] No dead/unused code
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-discovery
|
|
3
|
+
description: Review discovery - competitive research, features, pricing opportunities
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Discovery Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** to discover opportunities 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
|
+
### Review Requirements: Explore Beyond the Spec
|
|
19
|
+
|
|
20
|
+
* **Feature design review**: define success criteria, journeys, state model, auth/entitlements, instrumentation; propose competitiveness improvements within constraints.
|
|
21
|
+
* **Pricing/monetization review**: packaging/entitlements, lifecycle semantics, legal/tax/invoice implications; propose conversion/churn improvements within constraints.
|
|
22
|
+
* **Competitive research**: features, extensibility, guidance patterns, pricing/packaging norms; convert insights into testable acceptance criteria.
|
|
23
|
+
|
|
24
|
+
### Discovery Areas
|
|
25
|
+
|
|
26
|
+
* What features are competitors offering that we lack?
|
|
27
|
+
* What pricing models are common in the market?
|
|
28
|
+
* What UX patterns are users expecting?
|
|
29
|
+
* What integrations would add value?
|
|
30
|
+
* What automation opportunities exist?
|
|
31
|
+
* What self-service capabilities are missing?
|
|
32
|
+
|
|
33
|
+
### Analysis Framework
|
|
34
|
+
|
|
35
|
+
* Market positioning
|
|
36
|
+
* Feature gap analysis
|
|
37
|
+
* Pricing benchmarking
|
|
38
|
+
* User journey optimization
|
|
39
|
+
* Technical debt opportunities
|
|
40
|
+
* Scalability considerations
|
|
41
|
+
|
|
42
|
+
## Verification Checklist
|
|
43
|
+
|
|
44
|
+
- [ ] Competitor analysis completed
|
|
45
|
+
- [ ] Feature gaps identified
|
|
46
|
+
- [ ] Pricing reviewed
|
|
47
|
+
- [ ] UX patterns researched
|
|
48
|
+
- [ ] Integration opportunities listed
|
|
49
|
+
- [ ] Recommendations prioritized
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-growth
|
|
3
|
+
description: Review growth - onboarding, viral mechanics, retention
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Growth Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of growth systems 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
|
+
### Growth System (Onboarding, Share/Viral, Retention)
|
|
19
|
+
|
|
20
|
+
* The review must produce a coherent, measurable growth system for activation, sharing/virality, and retention, aligned with compliance and anti-abuse constraints.
|
|
21
|
+
|
|
22
|
+
### Onboarding
|
|
23
|
+
|
|
24
|
+
* Onboarding must be:
|
|
25
|
+
* Outcome-oriented
|
|
26
|
+
* Localized
|
|
27
|
+
* Accessible
|
|
28
|
+
* Instrumented
|
|
29
|
+
|
|
30
|
+
### Sharing/Virality
|
|
31
|
+
|
|
32
|
+
* Sharing/virality must be:
|
|
33
|
+
* Consent-aware
|
|
34
|
+
* Abuse-resistant
|
|
35
|
+
* Measurable end-to-end
|
|
36
|
+
|
|
37
|
+
### Retention
|
|
38
|
+
|
|
39
|
+
* Retention must be:
|
|
40
|
+
* Intentionally engineered
|
|
41
|
+
* Monitored
|
|
42
|
+
* Protected against regressions
|
|
43
|
+
|
|
44
|
+
### Growth Best Practices
|
|
45
|
+
|
|
46
|
+
* Clear value proposition on landing
|
|
47
|
+
* Frictionless signup
|
|
48
|
+
* Time-to-value optimization
|
|
49
|
+
* Activation milestones defined
|
|
50
|
+
* Re-engagement campaigns
|
|
51
|
+
* Churn prediction/prevention
|
|
52
|
+
* NPS/satisfaction tracking
|
|
53
|
+
|
|
54
|
+
## Verification Checklist
|
|
55
|
+
|
|
56
|
+
- [ ] Onboarding flow exists
|
|
57
|
+
- [ ] Onboarding instrumented
|
|
58
|
+
- [ ] Sharing mechanisms work
|
|
59
|
+
- [ ] Sharing is consent-aware
|
|
60
|
+
- [ ] Retention metrics tracked
|
|
61
|
+
- [ ] Re-engagement exists
|
|
62
|
+
- [ ] Growth metrics dashboarded
|
|
@@ -0,0 +1,50 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-i18n
|
|
3
|
+
description: Review i18n - locales, routing, canonicalization, UGC
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Internationalization Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of internationalization 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
|
+
### Supported Locales
|
|
19
|
+
|
|
20
|
+
`en`, `zh-Hans`, `zh-Hant`, `es`, `ja`, `ko`, `de`, `fr`, `pt-BR`, `it`, `nl`, `pl`, `tr`, `id`, `th`, `vi`
|
|
21
|
+
|
|
22
|
+
### URL Strategy: Prefix Except Default
|
|
23
|
+
|
|
24
|
+
* English is default and non-prefixed.
|
|
25
|
+
* `/en/*` must not exist; permanently redirect to non-prefixed equivalent.
|
|
26
|
+
* All non-default locales are `/<locale>/...`.
|
|
27
|
+
|
|
28
|
+
### Globalization Rules
|
|
29
|
+
|
|
30
|
+
* Intl formatting for dates, numbers, currency
|
|
31
|
+
* Explicit fallback rules
|
|
32
|
+
* Missing translation keys must fail build
|
|
33
|
+
* No hardcoded user-facing strings outside localization
|
|
34
|
+
|
|
35
|
+
### UGC Canonicalization
|
|
36
|
+
|
|
37
|
+
* Separate UI language from content language.
|
|
38
|
+
* Exactly one canonical URL per UGC resource determined by content language.
|
|
39
|
+
* No indexable locale-prefixed duplicates unless primary content is truly localized; otherwise redirect to canonical.
|
|
40
|
+
* Canonical/hreflang/sitemap must reflect only true localized variants.
|
|
41
|
+
|
|
42
|
+
## Verification Checklist
|
|
43
|
+
|
|
44
|
+
- [ ] All locales supported
|
|
45
|
+
- [ ] `/en/*` returns 301 redirect
|
|
46
|
+
- [ ] Missing keys fail build
|
|
47
|
+
- [ ] No hardcoded strings
|
|
48
|
+
- [ ] Intl formatting used
|
|
49
|
+
- [ ] UGC has single canonical URL
|
|
50
|
+
- [ ] hreflang tags correct
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review-ledger
|
|
3
|
+
description: Review ledger - financial-grade balance system, immutable ledger
|
|
4
|
+
agent: coder
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Ledger Review
|
|
8
|
+
|
|
9
|
+
## Mandate
|
|
10
|
+
|
|
11
|
+
* Perform a **deep, thorough review** of any balance/credits/wallet 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
|
+
### Financial-Grade Balance System (Only if "balance/credits/wallet" exists)
|
|
19
|
+
|
|
20
|
+
* Any balance concept must be implemented as an **immutable ledger** (append-only source of truth), not a mutable balance field.
|
|
21
|
+
* Deterministic precision (no floats), idempotent posting, concurrency safety, transactional integrity, and auditability are required.
|
|
22
|
+
* Monetary flows must be currency-based and reconcilable with Stripe; credits (if used) must be governed as non-cash entitlements.
|
|
23
|
+
|
|
24
|
+
### Ledger Requirements
|
|
25
|
+
|
|
26
|
+
* Append-only transaction log
|
|
27
|
+
* Double-entry bookkeeping where applicable
|
|
28
|
+
* Idempotent transaction posting (idempotency keys)
|
|
29
|
+
* Concurrency-safe balance calculations
|
|
30
|
+
* Audit trail for all mutations
|
|
31
|
+
* Reconciliation with external systems (Stripe)
|
|
32
|
+
|
|
33
|
+
## Verification Checklist
|
|
34
|
+
|
|
35
|
+
- [ ] Immutable ledger pattern used (not mutable balance)
|
|
36
|
+
- [ ] No floating point for money
|
|
37
|
+
- [ ] Idempotent posting implemented
|
|
38
|
+
- [ ] Concurrency safety verified
|
|
39
|
+
- [ ] Full audit trail exists
|
|
40
|
+
- [ ] Reconciliation with Stripe possible
|