@sylphx/flow 2.28.3 → 2.28.5
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 +16 -0
- package/assets/slash-commands/continue.md +150 -9
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,21 @@
|
|
|
1
1
|
# @sylphx/flow
|
|
2
2
|
|
|
3
|
+
## 2.28.5 (2026-01-04)
|
|
4
|
+
|
|
5
|
+
Enhance continue command with Radix UI everywhere, bootstrap super admin, and platform-led integrations
|
|
6
|
+
|
|
7
|
+
### 📚 Documentation
|
|
8
|
+
|
|
9
|
+
- **commands:** enhance continue with Radix UI, bootstrap, platform-led integrations ([bd09618](https://github.com/SylphxAI/flow/commit/bd09618e384f638e57535d51814696e0e2b9235e))
|
|
10
|
+
|
|
11
|
+
## 2.28.4 (2026-01-04)
|
|
12
|
+
|
|
13
|
+
Rewrite continue command with SSOT principles and comprehensive system correctness guidelines
|
|
14
|
+
|
|
15
|
+
### 📚 Documentation
|
|
16
|
+
|
|
17
|
+
- **commands:** rewrite continue command with SSOT principles ([b3ca5e0](https://github.com/SylphxAI/flow/commit/b3ca5e048b7580ed2f723936297b015a03964932))
|
|
18
|
+
|
|
3
19
|
## 2.28.3 (2025-12-19)
|
|
4
20
|
|
|
5
21
|
### 🐛 Bug Fixes
|
|
@@ -5,17 +5,158 @@ description: Trigger autonomous product iteration - think, improve, ship
|
|
|
5
5
|
|
|
6
6
|
# Continue
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Continuously commit.
|
|
9
9
|
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
- What would beat competitors?
|
|
10
|
+
The entire system — not limited to data — must strictly obey a Single Source of Truth (SSOT) principle.
|
|
11
|
+
Every state, behavior, flow, permission, architecture decision, UI behavior, and side effect
|
|
12
|
+
must have exactly one authoritative source, one interpretation, and one correct path.
|
|
14
13
|
|
|
15
|
-
|
|
14
|
+
The system must be fully reason-able end to end.
|
|
15
|
+
There must be no implicit behavior, hidden assumptions, magic defaults, or silent fallbacks.
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
Continuously and repeatedly review, validate, and correct the entire system:
|
|
18
|
+
- Membership and identity correctness and completeness
|
|
19
|
+
- Consistency across state, permissions, flows, and lifecycle
|
|
20
|
+
- Architectural boundaries, modularity, and separation of responsibilities
|
|
21
|
+
- UI behavior matching system intent, state, and permissions
|
|
22
|
+
- Alignment with modern industry standards and best practices
|
|
18
23
|
|
|
19
|
-
|
|
24
|
+
No workarounds.
|
|
25
|
+
No hacks.
|
|
26
|
+
No temporary solutions.
|
|
27
|
+
No backward compatibility.
|
|
28
|
+
No deprecated logic.
|
|
29
|
+
No TODOs.
|
|
30
|
+
No dead code.
|
|
31
|
+
No unused code.
|
|
32
|
+
No incorrect or misleading code.
|
|
20
33
|
|
|
21
|
-
|
|
34
|
+
Every feature must be built intent-first:
|
|
35
|
+
- The correct model must exist before implementation
|
|
36
|
+
- No duplicated concepts, parallel truths, or shadow logic
|
|
37
|
+
- Any feature must be removable or refactorable without destabilizing the system
|
|
38
|
+
|
|
39
|
+
Continuously perform:
|
|
40
|
+
- Deduplication
|
|
41
|
+
- Refactoring
|
|
42
|
+
- Polishing
|
|
43
|
+
- Modularity enforcement
|
|
44
|
+
- Responsibility separation
|
|
45
|
+
- Architectural correction
|
|
46
|
+
|
|
47
|
+
The system must remain:
|
|
48
|
+
- Stateless
|
|
49
|
+
- Serverless-friendly
|
|
50
|
+
- Scalable
|
|
51
|
+
- Reasonable
|
|
52
|
+
- Testable
|
|
53
|
+
- Observable
|
|
54
|
+
|
|
55
|
+
## UI: Radix UI Everywhere
|
|
56
|
+
|
|
57
|
+
Use Radix UI comprehensively. If Radix has a primitive for it, use it.
|
|
58
|
+
No custom implementations of solved problems.
|
|
59
|
+
No alternative component libraries for what Radix already provides.
|
|
60
|
+
|
|
61
|
+
Radix primitives are the SSOT for:
|
|
62
|
+
- Dialogs, modals, sheets
|
|
63
|
+
- Dropdowns, menus, context menus
|
|
64
|
+
- Popovers, tooltips, hover cards
|
|
65
|
+
- Tabs, accordions, collapsibles
|
|
66
|
+
- Select, combobox, radio, checkbox, switch
|
|
67
|
+
- Sliders, progress, scroll areas
|
|
68
|
+
- Navigation, breadcrumbs
|
|
69
|
+
- Toasts, alerts
|
|
70
|
+
- Avatar, aspect ratio, separator
|
|
71
|
+
|
|
72
|
+
When similar UI problems arise across the system,
|
|
73
|
+
solve them once with Radix, then reuse everywhere.
|
|
74
|
+
|
|
75
|
+
## Bootstrap: Super Admin
|
|
76
|
+
|
|
77
|
+
Simplest possible approach:
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
INITIAL_SUPERADMIN_EMAIL=your@email.com
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
Flow:
|
|
84
|
+
1. Set env variable
|
|
85
|
+
2. Register with that email
|
|
86
|
+
3. Automatically elevated to super_admin
|
|
87
|
+
4. Done
|
|
88
|
+
|
|
89
|
+
Why singular:
|
|
90
|
+
- Only one initial super_admin needed
|
|
91
|
+
- They promote others via admin UI
|
|
92
|
+
- Simple = fewer bugs
|
|
93
|
+
|
|
94
|
+
The bootstrap must:
|
|
95
|
+
- Execute exactly once
|
|
96
|
+
- Be non-reentrant
|
|
97
|
+
- Not be bypassable
|
|
98
|
+
- Not become permanent logic dependency
|
|
99
|
+
|
|
100
|
+
## Third-Party Integrations: Platform-Led
|
|
101
|
+
|
|
102
|
+
The platform is the source of truth. Third-party services sync FROM the platform, not TO it.
|
|
103
|
+
|
|
104
|
+
**Stripe:**
|
|
105
|
+
- Platform defines products, prices, features
|
|
106
|
+
- Stripe is synced to match platform state
|
|
107
|
+
- No manual Stripe dashboard configuration
|
|
108
|
+
- Platform state → Stripe sync (never reverse)
|
|
109
|
+
|
|
110
|
+
**All integrations:**
|
|
111
|
+
- Design in platform first
|
|
112
|
+
- Third-party services are implementation details
|
|
113
|
+
- No dependency on third-party UI/configuration
|
|
114
|
+
- Platform can switch providers without architectural change
|
|
115
|
+
|
|
116
|
+
## Technologies
|
|
117
|
+
|
|
118
|
+
All must be used correctly, consistently, and idiomatically:
|
|
119
|
+
tRPC, Next.js, Radix UI, next-intl, Drizzle,
|
|
120
|
+
Better Auth, Stripe, Upstash, Neon, Vercel,
|
|
121
|
+
Resend (email), Vercel Blob (storage),
|
|
122
|
+
AI SDK with OpenRouter provider,
|
|
123
|
+
Iconify, Bun, Biome, Bun test,
|
|
124
|
+
Responsive Web Design.
|
|
125
|
+
|
|
126
|
+
## Re-authentication Flow
|
|
127
|
+
|
|
128
|
+
All sensitive operations require explicit re-authentication:
|
|
129
|
+
|
|
130
|
+
```
|
|
131
|
+
Sensitive action triggered
|
|
132
|
+
↓
|
|
133
|
+
Check verified session
|
|
134
|
+
↓
|
|
135
|
+
Does the user have a password?
|
|
136
|
+
├─ Yes → Verify password
|
|
137
|
+
└─ No → Send email OTP (6 digits, 10-minute expiry)
|
|
138
|
+
↓
|
|
139
|
+
Verification succeeds
|
|
140
|
+
↓
|
|
141
|
+
Mark session as verified
|
|
142
|
+
↓
|
|
143
|
+
Allow scoped, time-bound sensitive actions
|
|
144
|
+
(2FA setup, email change, account deletion, etc.)
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
The verified state must:
|
|
148
|
+
- Have explicit scope
|
|
149
|
+
- Have explicit expiration
|
|
150
|
+
- Never be implicitly reused
|
|
151
|
+
- Never be shared across sessions or contexts
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
Any ambiguity, inconsistency, incompleteness, or undefined behavior
|
|
156
|
+
must be treated as a bug, not a feature.
|
|
157
|
+
|
|
158
|
+
The system must withstand repeated review, rejection, refactor, and redesign,
|
|
159
|
+
and after every correction,
|
|
160
|
+
become simpler, more consistent, and closer to the correct model.
|
|
161
|
+
|
|
162
|
+
Ultrathink.
|
package/package.json
CHANGED