anhedral 0.4.2 → 0.6.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/README.md +29 -269
- package/assets/anhedral-cli-init-technical.svg +322 -0
- package/assets/anhedral-cli-init.svg +257 -173
- package/dist/bin.js +28 -191
- package/dist/dependencies.d.ts +7 -57
- package/dist/dependencies.js +96 -308
- package/dist/index.d.ts +2 -7
- package/dist/index.js +1 -4
- package/dist/platforms/desktop.js +401 -0
- package/dist/platforms/extension.js +401 -0
- package/dist/platforms/mobile.js +232 -0
- package/dist/project.d.ts +0 -26
- package/dist/standard-products.d.ts +2 -0
- package/dist/standard-products.js +6 -0
- package/dist/standard.d.ts +18 -0
- package/dist/standard.js +578 -0
- package/dist/version.d.ts +1 -1
- package/dist/version.js +1 -1
- package/docs/application-stack-standard.md +700 -0
- package/package.json +34 -51
- package/CHANGELOG.md +0 -178
- package/CONTRIBUTING.md +0 -77
- package/SECURITY.md +0 -37
- package/SKILL.md +0 -339
- package/assets/images/svg/ably-symbol-color.svg +0 -8
- package/bin/anhedral.js +0 -2
- package/dist/architecture/contributions.d.ts +0 -28
- package/dist/architecture/contributions.js +0 -125
- package/dist/architecture/index.d.ts +0 -12
- package/dist/architecture/index.js +0 -6
- package/dist/architecture/manifest.d.ts +0 -53
- package/dist/architecture/manifest.js +0 -283
- package/dist/architecture/modules.d.ts +0 -41
- package/dist/architecture/modules.js +0 -187
- package/dist/architecture/plan.d.ts +0 -58
- package/dist/architecture/plan.js +0 -145
- package/dist/architecture/templates.d.ts +0 -10
- package/dist/architecture/templates.js +0 -23
- package/dist/cli.d.ts +0 -32
- package/dist/cli.js +0 -281
- package/dist/composers/root.d.ts +0 -6
- package/dist/composers/root.js +0 -35
- package/dist/print.d.ts +0 -8
- package/dist/print.js +0 -48
- package/dist/prompts.d.ts +0 -6
- package/dist/prompts.js +0 -41
- package/dist/scaffold.d.ts +0 -64
- package/dist/scaffold.js +0 -2102
- package/dist/template-source.d.ts +0 -20
- package/dist/template-source.js +0 -180
- package/dist/templates/api.d.ts +0 -2
- package/dist/templates/api.js +0 -3187
- package/dist/templates/assets-private-proxy.d.ts +0 -3
- package/dist/templates/assets-private-proxy.js +0 -277
- package/dist/templates/desktop.js +0 -792
- package/dist/templates/electron-updater.d.ts +0 -3
- package/dist/templates/electron-updater.js +0 -358
- package/dist/templates/extension.js +0 -856
- package/dist/templates/first-run.d.ts +0 -2
- package/dist/templates/first-run.js +0 -167
- package/dist/templates/mobile.js +0 -861
- package/dist/templates/shared.d.ts +0 -2
- package/dist/templates/shared.js +0 -577
- package/dist/templates/web.d.ts +0 -2
- package/dist/templates/web.js +0 -569
- package/dist/toolchain.d.ts +0 -3
- package/dist/toolchain.js +0 -8
- package/dist/ui.d.ts +0 -33
- package/dist/ui.js +0 -199
- package/dist/workspace-config.d.ts +0 -11
- package/dist/workspace-config.js +0 -372
- package/docs/NORTHSTAR.md +0 -114
- package/docs/conventions.md +0 -94
- package/docs/engineering-principles.md +0 -88
- package/docs/master-stack-map.md +0 -199
- package/docs/output-tree-contract.md +0 -493
- package/docs/references/manual-scaffolding.md +0 -421
- package/docs/references/provisioning.md +0 -577
- package/scripts/render-master-stack-map.mjs +0 -510
- package/templates/api-fastify/apps/api/tsconfig.json +0 -20
- package/templates/catalog.json +0 -23
- package/templates/db-drizzle/packages/db/tsconfig.json +0 -14
- package/templates/desktop-electron/apps/desktop/tsconfig.json +0 -37
- package/templates/extension-wxt/apps/extension/tsconfig.json +0 -41
- package/templates/mobile-expo/apps/mobile/expo-env.d.ts +0 -1
- package/templates/web-next/apps/web/next-env.d.ts +0 -6
- /package/dist/{templates → platforms}/desktop.d.ts +0 -0
- /package/dist/{templates → platforms}/extension.d.ts +0 -0
- /package/dist/{templates → platforms}/mobile.d.ts +0 -0
|
@@ -0,0 +1,700 @@
|
|
|
1
|
+
# Anhedral Application Stack & Delivery Standard
|
|
2
|
+
|
|
3
|
+
## 1. Standard
|
|
4
|
+
|
|
5
|
+
Anhedral builds **client-owned, monorepo-first applications** using established frameworks, services, APIs, CLIs, plugins, and agent tooling.
|
|
6
|
+
|
|
7
|
+
The standard is:
|
|
8
|
+
|
|
9
|
+
- **Cloudflare-first** for hosted application infrastructure.
|
|
10
|
+
- **Free-first** where suitable.
|
|
11
|
+
- **OpenAI/Codex-operated** for development and operations.
|
|
12
|
+
- **Computer Use and Control Chrome throughout development.**
|
|
13
|
+
- **GitHub-first** for source control and delivery.
|
|
14
|
+
- **Next.js-first** for web applications.
|
|
15
|
+
- **pnpm + Turborepo** for TypeScript/JavaScript monorepos.
|
|
16
|
+
- **shadcn monorepo initialization for every new project.**
|
|
17
|
+
- **macOS** as the Anhedral development environment.
|
|
18
|
+
- Add applications, packages, providers, and infrastructure only when required.
|
|
19
|
+
- Keep client accounts, source, infrastructure, billing, and recovery client-owned.
|
|
20
|
+
|
|
21
|
+
Human approval is required for paid activation, material spending, architecture exceptions, and production releases.
|
|
22
|
+
|
|
23
|
+
---
|
|
24
|
+
|
|
25
|
+
# 2. Tooling selection chart
|
|
26
|
+
|
|
27
|
+
|Need|Default|Option|When to use|
|
|
28
|
+
|---|---|---|---|
|
|
29
|
+
|**Repository foundation**|**shadcn monorepo initializer + pnpm + Turborepo**|Native language workspaces alongside it|Every new project, including mobile-only, desktop-only, extensions, or projects using another app template.|
|
|
30
|
+
|**Web**|**Next.js + React + TypeScript + Tailwind + shadcn/ui**|Vinext|Next.js by default. Vinext only when its Vite/Workers architecture provides a demonstrated benefit.|
|
|
31
|
+
|**Mobile**|**Expo + React Native Reusables**|—|iOS/Android applications.|
|
|
32
|
+
|**Desktop**|**Electron** + **React** + **TypeScript** + **Tailwind** + **shadcn/ui**|GPUI + Rust|Electron for React/TS reuse. GPUI for deliberately Rust-first applications.|
|
|
33
|
+
|**Extension**|**WXT + Chrome Side Panel API**|—|Browser-integrated products. Side Panel is the primary UI.|
|
|
34
|
+
|**API**|**Hono + OpenAPI on Workers**|Next.js route handlers|Hono for shared/mobile/external APIs. Next.js handlers when only the web application needs them.|
|
|
35
|
+
|**Next.js hosting**|**Cloudflare Workers + OpenNext**|Vercel|Cloudflare by default. Vercel when native Next.js hosting materially simplifies the project and its applicable plan is appropriate.|
|
|
36
|
+
|**General compute**|**Cloudflare Workers**|Containers|Containers for Linux/native dependencies or workloads that do not fit Workers.|
|
|
37
|
+
|**PostgreSQL**|**Neon + Drizzle + Hyperdrive**|—|Relational PostgreSQL persistence.|
|
|
38
|
+
|**Cloudflare SQL**|**D1 + Drizzle**|Neon|D1 when SQLite semantics are sufficient.|
|
|
39
|
+
|**Local data**|**SQLite + filesystem**|—|Offline/device-local applications.|
|
|
40
|
+
|**Authentication**|**Clerk or Better Auth**|No auth|Clerk for managed identity; Better Auth for application-managed auth; no auth when unnecessary.|
|
|
41
|
+
|**Files**|**Private R2 + Worker binding**|Local filesystem|R2 for remote files; filesystem for local files.|
|
|
42
|
+
|**Cache/config**|**KV**|—|Eventually consistent configuration/cache, never authoritative transactional state.|
|
|
43
|
+
|**Realtime**|**Durable Objects + WebSockets**|—|Presence, rooms, collaboration, and stateful realtime coordination.|
|
|
44
|
+
|**Jobs**|**Queues**|—|Deferred/asynchronous processing.|
|
|
45
|
+
|**Scheduled work**|**Cron Triggers**|—|Recurring scheduled work.|
|
|
46
|
+
|**Durable workflows**|**Workflows**|—|Resumable multi-step processes.|
|
|
47
|
+
|**AI**|**OpenAI SDK or AI SDK**|Workers AI|OpenAI SDK for direct OpenAI use; AI SDK for streaming/tools/provider abstraction; Workers AI when Cloudflare inference is advantageous.|
|
|
48
|
+
|**Outbound email**|**Resend**|—|Transactional application email.|
|
|
49
|
+
|**Inbound email**|**Cloudflare Email Routing**|—|Incoming domain-email forwarding.|
|
|
50
|
+
|**Business email**|**Existing provider**|Future Cloudflare offering|Reconsider when Cloudflare's offering is GA/free and preferable.|
|
|
51
|
+
|**Payments**|**Stripe**|RevenueCat + Stripe|Add RevenueCat when web/App Store/Play Store entitlements need unified management.|
|
|
52
|
+
|**Operational telemetry**|**Cloudflare Observability**|Sentry|Add Sentry when additional crash/runtime diagnostics are required.|
|
|
53
|
+
|**Product analytics**|**Basin**|PostHog|PostHog when replay, experiments, funnels, or other required capabilities justify it.|
|
|
54
|
+
|**TS/JS auditing**|**Fallow**|—|Standard static/codebase audit for TypeScript and JavaScript. Use in development and PR checks.|
|
|
55
|
+
|**Source**|**Git + GitHub**|Cloudflare Artifacts|GitHub by default. Artifacts when it provides a concrete advantage and required controls are supported.|
|
|
56
|
+
|**CI/CD**|**GitHub Actions**|Workers Builds|Workers Builds when equivalent controls are available and useful.|
|
|
57
|
+
|**Development agent**|**OpenAI / Codex**|—|Primary implementation, reasoning, testing, and operational agent.|
|
|
58
|
+
|**Interactive development**|**Computer Use + Control Chrome**|—|Used heavily throughout implementation, iteration, setup, automation, and verification.|
|
|
59
|
+
|**Cloudflare operations**|**Cloudflare plugin + `cf` + API/MCP**|Dashboard when useful|Provisioning, deployment, configuration, analytics, observability, and operations.|
|
|
60
|
+
|
|
61
|
+
Do not activate every option simply because it appears in the table.
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
# 3. Repository foundation
|
|
66
|
+
|
|
67
|
+
## Every project starts with shadcn
|
|
68
|
+
|
|
69
|
+
Every new Anhedral project starts from the **shadcn-generated pnpm/Turborepo monorepo**, regardless of initial application type.
|
|
70
|
+
|
|
71
|
+
Initialize:
|
|
72
|
+
|
|
73
|
+
```
|
|
74
|
+
pnpm dlx shadcn@latest init --monorepo --template next
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
This is the **repository bootstrap**, not a requirement that every project remain a Next.js application.
|
|
78
|
+
|
|
79
|
+
After initialization:
|
|
80
|
+
|
|
81
|
+
- Preserve the generated pnpm/Turborepo structure and conventions.
|
|
82
|
+
- Use `apps/*` for applications/services.
|
|
83
|
+
- Use `packages/*` for reusable packages.
|
|
84
|
+
- Keep the generated Next.js app when Next.js is required.
|
|
85
|
+
- Remove or replace the starter app when the project is mobile-only, desktop-only, extension-only, or uses another explicitly selected application template.
|
|
86
|
+
- Never retain an unused Next.js application solely because it initialized the repository.
|
|
87
|
+
- Add application-specific templates inside the established monorepo.
|
|
88
|
+
|
|
89
|
+
Examples:
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
Mobile-only
|
|
93
|
+
|
|
94
|
+
apps/
|
|
95
|
+
└── mobile/
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
```
|
|
99
|
+
Extension-only
|
|
100
|
+
|
|
101
|
+
apps/
|
|
102
|
+
└── extension/
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
```
|
|
106
|
+
Full product
|
|
107
|
+
|
|
108
|
+
apps/
|
|
109
|
+
├── web/
|
|
110
|
+
├── mobile/
|
|
111
|
+
├── desktop/
|
|
112
|
+
├── extension/
|
|
113
|
+
├── api/
|
|
114
|
+
├── jobs/
|
|
115
|
+
└── realtime/
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
## Additional initialization
|
|
119
|
+
|
|
120
|
+
Mobile:
|
|
121
|
+
|
|
122
|
+
```
|
|
123
|
+
pnpm dlx @react-native-reusables/cli@latest init
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
Extension:
|
|
127
|
+
|
|
128
|
+
```
|
|
129
|
+
pnpm dlx wxt@latest init
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
Standard commands where applicable:
|
|
133
|
+
|
|
134
|
+
```
|
|
135
|
+
dev
|
|
136
|
+
build
|
|
137
|
+
lint
|
|
138
|
+
typecheck
|
|
139
|
+
test
|
|
140
|
+
audit
|
|
141
|
+
check
|
|
142
|
+
```
|
|
143
|
+
|
|
144
|
+
Other languages retain their native toolchains. Turborepo coordinates them where useful but does not replace Cargo, Python tooling, Expo tooling, or other native systems.
|
|
145
|
+
|
|
146
|
+
Commit lockfiles and record important toolchain versions.
|
|
147
|
+
|
|
148
|
+
---
|
|
149
|
+
|
|
150
|
+
# 4. Application conventions
|
|
151
|
+
|
|
152
|
+
## Web
|
|
153
|
+
|
|
154
|
+
Default:
|
|
155
|
+
|
|
156
|
+
**Next.js + React + TypeScript + Tailwind CSS + shadcn/ui**
|
|
157
|
+
|
|
158
|
+
Keep the App Router product-driven:
|
|
159
|
+
|
|
160
|
+
```
|
|
161
|
+
app/
|
|
162
|
+
├── page.tsx
|
|
163
|
+
├── dashboard/
|
|
164
|
+
├── projects/
|
|
165
|
+
├── settings/
|
|
166
|
+
└── (admin)/
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
Use route groups such as `(admin)` and `(auth)` when they provide a meaningful layout, authorization, or organizational boundary.
|
|
170
|
+
|
|
171
|
+
### Vinext
|
|
172
|
+
|
|
173
|
+
Vinext is an explicit project choice, not an automatic Next.js replacement.
|
|
174
|
+
|
|
175
|
+
Use it only when its Vite/Workers architecture provides a concrete benefit and the project's dependencies and framework behavior have been verified.
|
|
176
|
+
|
|
177
|
+
## Mobile
|
|
178
|
+
|
|
179
|
+
Use:
|
|
180
|
+
|
|
181
|
+
**Expo + React Native + React Native Reusables + TypeScript**
|
|
182
|
+
|
|
183
|
+
Follow the same general package, styling, naming, and domain conventions as web.
|
|
184
|
+
|
|
185
|
+
Share appropriate business logic, contracts, validation, styling, and utilities.
|
|
186
|
+
|
|
187
|
+
Do not force React and React Native to share rendered components when separate implementations are cleaner.
|
|
188
|
+
|
|
189
|
+
## Desktop
|
|
190
|
+
|
|
191
|
+
Use **Electron** when React/TypeScript reuse is useful.
|
|
192
|
+
|
|
193
|
+
Use **GPUI + Rust** when a deliberately Rust-first architecture, native integration, or performance requirement justifies a separate implementation.
|
|
194
|
+
|
|
195
|
+
## Browser extensions
|
|
196
|
+
|
|
197
|
+
Use:
|
|
198
|
+
|
|
199
|
+
**WXT + Chrome Side Panel API**
|
|
200
|
+
|
|
201
|
+
The Chrome Side Panel is the primary extension interface.
|
|
202
|
+
|
|
203
|
+
Use WXT for:
|
|
204
|
+
|
|
205
|
+
- side panel
|
|
206
|
+
- service worker/background logic
|
|
207
|
+
- content scripts
|
|
208
|
+
- browser messaging
|
|
209
|
+
- permissions
|
|
210
|
+
- packaging
|
|
211
|
+
|
|
212
|
+
Do not default to popup-first extension architecture.
|
|
213
|
+
|
|
214
|
+
---
|
|
215
|
+
|
|
216
|
+
# 5. Shared packages
|
|
217
|
+
|
|
218
|
+
Create packages only when genuine reusable behavior exists.
|
|
219
|
+
|
|
220
|
+
Typical options:
|
|
221
|
+
|
|
222
|
+
```
|
|
223
|
+
packages/
|
|
224
|
+
├── ui/ # React / shadcn
|
|
225
|
+
├── ui-native/ # React Native Reusables
|
|
226
|
+
├── styling/ # colors, typography, spacing, themes
|
|
227
|
+
├── contracts/ # schemas, types, API/event contracts
|
|
228
|
+
├── api-client/
|
|
229
|
+
├── domain/ # portable business logic
|
|
230
|
+
├── server/ # server-only logic
|
|
231
|
+
├── auth/
|
|
232
|
+
├── db/
|
|
233
|
+
├── local-data/
|
|
234
|
+
├── storage/
|
|
235
|
+
├── billing/
|
|
236
|
+
├── email/
|
|
237
|
+
├── ai/
|
|
238
|
+
├── analytics/
|
|
239
|
+
├── observability/
|
|
240
|
+
├── i18n/
|
|
241
|
+
├── eslint-config/
|
|
242
|
+
├── typescript-config/
|
|
243
|
+
└── test-config/
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
Use **`styling`**, not `tokens`, for shared styling definitions.
|
|
247
|
+
|
|
248
|
+
Share:
|
|
249
|
+
|
|
250
|
+
- styling
|
|
251
|
+
- schemas
|
|
252
|
+
- validation
|
|
253
|
+
- contracts
|
|
254
|
+
- API types
|
|
255
|
+
- event definitions
|
|
256
|
+
- portable business logic
|
|
257
|
+
|
|
258
|
+
Keep platform-specific UI separate where appropriate.
|
|
259
|
+
|
|
260
|
+
Keep privileged/server integrations out of client-safe packages.
|
|
261
|
+
|
|
262
|
+
Never expose server credentials through shared client code.
|
|
263
|
+
|
|
264
|
+
---
|
|
265
|
+
|
|
266
|
+
# 6. Cloudflare hosting
|
|
267
|
+
|
|
268
|
+
Cloudflare is the preferred hosted application platform.
|
|
269
|
+
|
|
270
|
+
Typical architecture:
|
|
271
|
+
|
|
272
|
+
```
|
|
273
|
+
Web / Mobile / Desktop / Extension
|
|
274
|
+
│
|
|
275
|
+
▼
|
|
276
|
+
Cloudflare Workers
|
|
277
|
+
Hono / Next.js
|
|
278
|
+
│
|
|
279
|
+
┌──────────┼──────────┐
|
|
280
|
+
▼ ▼ ▼
|
|
281
|
+
Hyperdrive R2 Durable Objects
|
|
282
|
+
│ │
|
|
283
|
+
▼ WebSockets
|
|
284
|
+
Neon
|
|
285
|
+
|
|
286
|
+
Workers
|
|
287
|
+
├── Queues
|
|
288
|
+
├── Cron
|
|
289
|
+
├── Workflows
|
|
290
|
+
├── KV
|
|
291
|
+
├── Observability
|
|
292
|
+
└── Basin
|
|
293
|
+
```
|
|
294
|
+
|
|
295
|
+
Use only required services.
|
|
296
|
+
|
|
297
|
+
## Next.js hosting
|
|
298
|
+
|
|
299
|
+
Default:
|
|
300
|
+
|
|
301
|
+
```
|
|
302
|
+
Next.js
|
|
303
|
+
↓
|
|
304
|
+
OpenNext
|
|
305
|
+
↓
|
|
306
|
+
Cloudflare Workers
|
|
307
|
+
```
|
|
308
|
+
|
|
309
|
+
Alternative:
|
|
310
|
+
|
|
311
|
+
```
|
|
312
|
+
Next.js
|
|
313
|
+
↓
|
|
314
|
+
Vercel
|
|
315
|
+
│
|
|
316
|
+
└─────────────→ Cloudflare infrastructure
|
|
317
|
+
```
|
|
318
|
+
|
|
319
|
+
Vercel may host only the Next.js application while Cloudflare continues to provide:
|
|
320
|
+
|
|
321
|
+
- APIs
|
|
322
|
+
- R2
|
|
323
|
+
- Hyperdrive
|
|
324
|
+
- Durable Objects
|
|
325
|
+
- Queues
|
|
326
|
+
- Workflows
|
|
327
|
+
- analytics
|
|
328
|
+
- other infrastructure
|
|
329
|
+
|
|
330
|
+
Use Vercel when its native Next.js integration, previews, deployment experience, or framework support materially simplifies the project and its applicable plan/cost is appropriate.
|
|
331
|
+
|
|
332
|
+
Cloudflare remains the default.
|
|
333
|
+
|
|
334
|
+
---
|
|
335
|
+
|
|
336
|
+
# 7. APIs
|
|
337
|
+
|
|
338
|
+
Use:
|
|
339
|
+
|
|
340
|
+
**Hono + OpenAPI on Cloudflare Workers**
|
|
341
|
+
|
|
342
|
+
when a shared network API is required by:
|
|
343
|
+
|
|
344
|
+
- mobile
|
|
345
|
+
- desktop
|
|
346
|
+
- extensions
|
|
347
|
+
- integrations
|
|
348
|
+
- external consumers
|
|
349
|
+
- multiple application interfaces
|
|
350
|
+
|
|
351
|
+
Use **Next.js route handlers** when endpoints belong only to the web application and a separate service adds no useful boundary.
|
|
352
|
+
|
|
353
|
+
Do not create `apps/api` automatically.
|
|
354
|
+
|
|
355
|
+
---
|
|
356
|
+
|
|
357
|
+
# 8. Data
|
|
358
|
+
|
|
359
|
+
## PostgreSQL
|
|
360
|
+
|
|
361
|
+
Default:
|
|
362
|
+
|
|
363
|
+
```
|
|
364
|
+
Worker
|
|
365
|
+
↓
|
|
366
|
+
Drizzle
|
|
367
|
+
↓
|
|
368
|
+
Hyperdrive
|
|
369
|
+
↓
|
|
370
|
+
Neon PostgreSQL
|
|
371
|
+
```
|
|
372
|
+
|
|
373
|
+
Use PostgreSQL when relational requirements justify it.
|
|
374
|
+
|
|
375
|
+
Neon remains independently managed.
|
|
376
|
+
|
|
377
|
+
Avoid inappropriate Hyperdrive query caching for correctness-sensitive operations such as:
|
|
378
|
+
|
|
379
|
+
- authentication
|
|
380
|
+
- permissions
|
|
381
|
+
- entitlements
|
|
382
|
+
- balances
|
|
383
|
+
- quotas
|
|
384
|
+
- financial records
|
|
385
|
+
- paid-unit consumption
|
|
386
|
+
|
|
387
|
+
## D1
|
|
388
|
+
|
|
389
|
+
Use:
|
|
390
|
+
|
|
391
|
+
**D1 + Drizzle**
|
|
392
|
+
|
|
393
|
+
when SQLite semantics are sufficient and Cloudflare-native persistence is preferable.
|
|
394
|
+
|
|
395
|
+
D1 is an alternative database choice, not an automatic PostgreSQL replacement.
|
|
396
|
+
|
|
397
|
+
## Local data
|
|
398
|
+
|
|
399
|
+
Use:
|
|
400
|
+
|
|
401
|
+
**SQLite + filesystem**
|
|
402
|
+
|
|
403
|
+
for local/device-resident data.
|
|
404
|
+
|
|
405
|
+
Do not add cloud persistence merely because other applications use it.
|
|
406
|
+
|
|
407
|
+
Offline synchronization requires explicit design for:
|
|
408
|
+
|
|
409
|
+
- identity
|
|
410
|
+
- offline writes
|
|
411
|
+
- conflicts
|
|
412
|
+
- reconciliation
|
|
413
|
+
- authoritative state
|
|
414
|
+
|
|
415
|
+
---
|
|
416
|
+
|
|
417
|
+
# 9. Private files
|
|
418
|
+
|
|
419
|
+
Remote application files use:
|
|
420
|
+
|
|
421
|
+
**private Cloudflare R2 buckets accessed through Worker bindings.**
|
|
422
|
+
|
|
423
|
+
```
|
|
424
|
+
web / mobile / desktop / extension
|
|
425
|
+
↓
|
|
426
|
+
Worker
|
|
427
|
+
↓
|
|
428
|
+
authenticate + authorize
|
|
429
|
+
↓
|
|
430
|
+
private R2 binding
|
|
431
|
+
```
|
|
432
|
+
|
|
433
|
+
Clients never receive R2 credentials.
|
|
434
|
+
|
|
435
|
+
The Worker enforces file-level authorization.
|
|
436
|
+
|
|
437
|
+
Do not make private application buckets public for convenience.
|
|
438
|
+
|
|
439
|
+
Use the local filesystem when files are intentionally device-local.
|
|
440
|
+
|
|
441
|
+
---
|
|
442
|
+
|
|
443
|
+
# 10. Authentication
|
|
444
|
+
|
|
445
|
+
Choose per project.
|
|
446
|
+
|
|
447
|
+
### Clerk
|
|
448
|
+
|
|
449
|
+
Use when managed identity reduces implementation and maintenance.
|
|
450
|
+
|
|
451
|
+
### Better Auth
|
|
452
|
+
|
|
453
|
+
Use when application-managed authentication is preferred.
|
|
454
|
+
|
|
455
|
+
### No authentication
|
|
456
|
+
|
|
457
|
+
Use when accounts are unnecessary.
|
|
458
|
+
|
|
459
|
+
Do not add authentication merely because other projects use it.
|
|
460
|
+
|
|
461
|
+
Cloudflare Access may separately protect internal applications or staging environments.
|
|
462
|
+
|
|
463
|
+
---
|
|
464
|
+
|
|
465
|
+
# 11. Realtime and asynchronous work
|
|
466
|
+
|
|
467
|
+
Use **Durable Objects + WebSockets** for:
|
|
468
|
+
|
|
469
|
+
- rooms
|
|
470
|
+
- presence
|
|
471
|
+
- collaboration
|
|
472
|
+
- connection coordination
|
|
473
|
+
- stateful realtime behavior
|
|
474
|
+
|
|
475
|
+
Use **Queues** for asynchronous jobs.
|
|
476
|
+
|
|
477
|
+
Use **Cron Triggers** for scheduled work.
|
|
478
|
+
|
|
479
|
+
Use **Workflows** for durable, resumable multi-step processes.
|
|
480
|
+
|
|
481
|
+
Use **Containers** when suitable workloads require:
|
|
482
|
+
|
|
483
|
+
- Linux binaries
|
|
484
|
+
- native dependencies
|
|
485
|
+
- heavier compute
|
|
486
|
+
- isolated processing
|
|
487
|
+
|
|
488
|
+
Define retries, idempotency, concurrency, and failure handling where applicable.
|
|
489
|
+
|
|
490
|
+
---
|
|
491
|
+
|
|
492
|
+
# 12. AI
|
|
493
|
+
|
|
494
|
+
Normal choices:
|
|
495
|
+
|
|
496
|
+
### OpenAI SDK
|
|
497
|
+
|
|
498
|
+
Use when directly integrating OpenAI.
|
|
499
|
+
|
|
500
|
+
### AI SDK
|
|
501
|
+
|
|
502
|
+
Use when the application benefits from:
|
|
503
|
+
|
|
504
|
+
- streaming
|
|
505
|
+
- tool calling
|
|
506
|
+
- provider abstraction
|
|
507
|
+
- structured AI UI patterns
|
|
508
|
+
- established templates/examples
|
|
509
|
+
|
|
510
|
+
Prefer official examples and suitable Next.js templates over unnecessary custom infrastructure.
|
|
511
|
+
|
|
512
|
+
### Workers AI
|
|
513
|
+
|
|
514
|
+
Optional.
|
|
515
|
+
|
|
516
|
+
Use when Cloudflare-hosted inference provides a concrete project advantage.
|
|
517
|
+
|
|
518
|
+
AI Gateway and related Cloudflare AI services may be selected when their routing, observability, control, or cost features justify them.
|
|
519
|
+
|
|
520
|
+
---
|
|
521
|
+
|
|
522
|
+
# 13. Email
|
|
523
|
+
|
|
524
|
+
Use:
|
|
525
|
+
|
|
526
|
+
```
|
|
527
|
+
Outbound application email → Resend
|
|
528
|
+
Inbound email → Cloudflare Email Routing
|
|
529
|
+
Business mailbox → existing provider
|
|
530
|
+
```
|
|
531
|
+
|
|
532
|
+
Treat these as separate concerns.
|
|
533
|
+
|
|
534
|
+
Do not migrate business email solely for provider consolidation.
|
|
535
|
+
|
|
536
|
+
Reconsider Cloudflare business email when its offering is generally available or free and actually preferable.
|
|
537
|
+
|
|
538
|
+
---
|
|
539
|
+
|
|
540
|
+
# 14. Payments
|
|
541
|
+
|
|
542
|
+
Use **Stripe** for web payments and subscriptions.
|
|
543
|
+
|
|
544
|
+
Add **RevenueCat** when subscriptions span web, App Store, and Play Store ecosystems and unified entitlement management is useful.
|
|
545
|
+
|
|
546
|
+
Keep separate concepts for:
|
|
547
|
+
|
|
548
|
+
- billing
|
|
549
|
+
- subscriptions
|
|
550
|
+
- entitlements
|
|
551
|
+
- credits
|
|
552
|
+
- quotas
|
|
553
|
+
- seats
|
|
554
|
+
- consumption
|
|
555
|
+
|
|
556
|
+
Paid-unit consumption must be transactional and idempotent.
|
|
557
|
+
|
|
558
|
+
---
|
|
559
|
+
|
|
560
|
+
# 15. Analytics and observability
|
|
561
|
+
|
|
562
|
+
## Operations
|
|
563
|
+
|
|
564
|
+
Use **Cloudflare Observability** for:
|
|
565
|
+
|
|
566
|
+
- logs
|
|
567
|
+
- errors
|
|
568
|
+
- traces
|
|
569
|
+
- latency
|
|
570
|
+
- deployments
|
|
571
|
+
- request behavior
|
|
572
|
+
- operational investigation
|
|
573
|
+
|
|
574
|
+
Add **Sentry** when additional runtime or crash diagnostics are required.
|
|
575
|
+
|
|
576
|
+
## Product analytics
|
|
577
|
+
|
|
578
|
+
Use **Basin** for:
|
|
579
|
+
|
|
580
|
+
- application events
|
|
581
|
+
- analytical datasets
|
|
582
|
+
- analytical queries
|
|
583
|
+
|
|
584
|
+
Add **PostHog** when requirements such as:
|
|
585
|
+
|
|
586
|
+
- session replay
|
|
587
|
+
- funnels
|
|
588
|
+
- experiments
|
|
589
|
+
- specialized product analytics
|
|
590
|
+
|
|
591
|
+
justify it.
|
|
592
|
+
|
|
593
|
+
Do not install every analytics platform by default.
|
|
594
|
+
|
|
595
|
+
Operational telemetry and product analytics are separate concerns.
|
|
596
|
+
|
|
597
|
+
---
|
|
598
|
+
|
|
599
|
+
# 16. TypeScript/JavaScript auditing
|
|
600
|
+
|
|
601
|
+
Use **Fallow** as the standard TypeScript/JavaScript codebase auditing tool.
|
|
602
|
+
|
|
603
|
+
Fallow complements linting, typechecking, testing, builds, and runtime verification.
|
|
604
|
+
|
|
605
|
+
Use it for:
|
|
606
|
+
|
|
607
|
+
- unused code
|
|
608
|
+
- unused dependencies
|
|
609
|
+
- circular dependencies
|
|
610
|
+
- duplication
|
|
611
|
+
- complexity
|
|
612
|
+
- architecture-boundary problems
|
|
613
|
+
- dependency issues
|
|
614
|
+
- styling/design-system drift
|
|
615
|
+
|
|
616
|
+
During development:
|
|
617
|
+
|
|
618
|
+
```
|
|
619
|
+
pnpm exec fallow
|
|
620
|
+
```
|
|
621
|
+
|
|
622
|
+
For PR/change auditing:
|
|
623
|
+
|
|
624
|
+
```
|
|
625
|
+
pnpm exec fallow audit
|
|
626
|
+
```
|
|
627
|
+
|
|
628
|
+
Use `fallow audit` in PR checks where applicable to identify problems introduced by the change.
|
|
629
|
+
|
|
630
|
+
The deterministic gate should generally include:
|
|
631
|
+
|
|
632
|
+
```
|
|
633
|
+
format / lint
|
|
634
|
+
↓
|
|
635
|
+
typecheck
|
|
636
|
+
↓
|
|
637
|
+
Fallow audit
|
|
638
|
+
↓
|
|
639
|
+
tests
|
|
640
|
+
↓
|
|
641
|
+
build
|
|
642
|
+
↓
|
|
643
|
+
integration checks
|
|
644
|
+
```
|
|
645
|
+
|
|
646
|
+
`pnpm check` should run the project's required deterministic gate.
|
|
647
|
+
|
|
648
|
+
Fix legitimate findings. Use narrow documented exceptions for intentional behavior rather than broad ignores.
|
|
649
|
+
|
|
650
|
+
---
|
|
651
|
+
|
|
652
|
+
# 17. Anhedral developers
|
|
653
|
+
|
|
654
|
+
Anhedral development is **agent-driven on macOS**.
|
|
655
|
+
|
|
656
|
+
The core environment is:
|
|
657
|
+
|
|
658
|
+
```
|
|
659
|
+
macOS
|
|
660
|
+
├── OpenAI / Codex
|
|
661
|
+
├── Computer Use
|
|
662
|
+
├── Control Chrome
|
|
663
|
+
├── terminal + development servers
|
|
664
|
+
├── native apps / simulators
|
|
665
|
+
├── provider plugins
|
|
666
|
+
├── APIs / MCP
|
|
667
|
+
└── CLIs
|
|
668
|
+
```
|
|
669
|
+
|
|
670
|
+
## Developer tooling
|
|
671
|
+
|
|
672
|
+
|Tool|Primary use|
|
|
673
|
+
|---|---|
|
|
674
|
+
|**OpenAI / Codex**|Primary coding and reasoning agent: planning, implementation, debugging, review, testing, and operations.|
|
|
675
|
+
|**Computer Use**|Dynamic testing, fast iteration, macOS interaction, application testing, setup automation, task automation, debugging, and cross-application workflows.|
|
|
676
|
+
|**Control Chrome**|Browser development, rapid UI iteration, authentication flows, integrations, console/network inspection, dashboards, and deployed-app verification.|
|
|
677
|
+
|**Cloudflare plugin + `cf` + API/MCP**|Cloudflare provisioning, configuration, deployments, logs, observability, analytics, and operations.|
|
|
678
|
+
|**GitHub plugin**|Repositories, branches, worktrees, PRs, issues, checks, reviews, and releases.|
|
|
679
|
+
|**Neon integration/API**|PostgreSQL projects, branches, databases, migrations, and operations.|
|
|
680
|
+
|**Stripe plugin**|Products, prices, payments, subscriptions, test transactions, and billing operations.|
|
|
681
|
+
|**RevenueCat integration**|Products, offerings, subscriptions, and entitlements.|
|
|
682
|
+
|**Email integrations**|Application email and supported mailbox/email workflows.|
|
|
683
|
+
|**Slack plugin**|Project context, communication, decisions, notifications, and workflows.|
|
|
684
|
+
|**[Cloudflare security audit](https://github.com/cloudflare/security-audit-skill)**|Repository security reviews and verified vulnerability findings.|
|
|
685
|
+
|**Next.js skills/tools**|Framework conventions, implementation, routing, rendering, debugging, and optimization.|
|
|
686
|
+
|**Vercel plugin**|Projects, deployments, environments, logs, and operations when Vercel is selected.|
|
|
687
|
+
|
|
688
|
+
---
|
|
689
|
+
|
|
690
|
+
# 18. Accounts and access
|
|
691
|
+
|
|
692
|
+
Configure only the services selected by the project.
|
|
693
|
+
|
|
694
|
+
- **Cloudflare:** client-owned account, account ID, authorized plugin/OAuth or scoped API token, and a plan supporting the selected services. Add billing or DNS access only when required.
|
|
695
|
+
- **Neon / Hyperdrive:** authorized Neon project access, database connection credentials, separate migration/runtime roles, and Hyperdrive origin configuration.
|
|
696
|
+
- **Private R2 / Pipelines:** Worker bindings for application storage; authorized sink writes to the selected private bucket. Cloudflare's managed setup requires the Workers Pipelines app's **Pipelines Setup** grant. Keep ingestion private unless an authorized public endpoint is required.
|
|
697
|
+
- **Auth and optional providers:** Better Auth secret/URL or Clerk keys; selected AI, email, payments, analytics, and observability credentials, domains, and webhooks.
|
|
698
|
+
- **GitHub / CI:** repository access, protected deployment secrets, and environment-specific resource identifiers.
|
|
699
|
+
|
|
700
|
+
Keep secrets server-side and out of source control. Obtain approval for paid activation, broader access, and required terms. Configure resource bindings, verify selected integrations in the deployed application, and record remaining setup before production approval.
|