create-claude-workspace 1.1.76 → 1.1.77

package/dist/template/.claude/agents/backend-ts-architect.md

@@ -61,13 +61,14 @@ Always prefer `@cibule/*` packages over custom implementations:
 - NEVER use Node.js-specific APIs (`fs`, `path`, `process`, `Buffer`) in business/domain/api layers
 - NEVER use Cloudflare-specific APIs (`env.DB`, `ctx.waitUntil()`) in business/domain layers
 - Platform-specific code lives ONLY in `infrastructure/` layer behind abstract repository interfaces
+- **Platform-specific code MUST be in separate libraries** — NEVER mix Node.js and Cloudflare implementations in the same library. Barrel exports pull both platforms into the bundle, causing compilation errors (e.g. `better-sqlite3` in Cloudflare). Split into: `infrastructure-d1/` (Cloudflare) and `infrastructure-sqlite/` (Node.js). Same applies to shared providers: `shared/infrastructure-d1/` vs `shared/infrastructure-sqlite/`.
 - Use Web Standard APIs: `fetch`, `Request`, `Response`, `URL`, `crypto`, `TextEncoder`/`TextDecoder`
 - Hono is inherently platform-agnostic — inject platform bindings via DI, not `c.env` in routes
 - **OpenAPI-first**: All API routes MUST use `hono-openapi` with `openAPIRouteHandler` — generates OpenAPI spec from TypeBox schemas. Serve API docs via `@scalar/hono-api-reference` at `/reference`. Never define routes without OpenAPI metadata.
-- Entry points handle platform wiring:
-  - Worker entry: exports `default { fetch }` with Hono app + D1 bindings
-  - Node entry: `serve()` with Hono app + SQLite/better-sqlite3 bindings
-- When planning, always structure FILES to keep platform-specific code isolated in infrastructure
+- Entry points handle platform wiring (each imports ONLY its platform's infrastructure library):
+  - Worker entry: exports `default { fetch }` with Hono app + D1 bindings → imports `infrastructure-d1`
+  - Node entry: `serve()` with Hono app + SQLite/better-sqlite3 bindings → imports `infrastructure-sqlite`
+- When planning, always structure FILES to keep platform-specific code in separate libraries per platform
 
 ## Task Approach
 

package/dist/template/.claude/templates/claude-md.md

@@ -323,9 +323,18 @@ Key rules enforced (do NOT weaken):
 - NEVER use Cloudflare-specific APIs (`env.DB`, `ctx.waitUntil()`) in business/domain layers
 - Platform-specific code lives ONLY in `infrastructure/` layer behind abstract interfaces
 - Use Web Standard APIs where possible: `fetch`, `Request`, `Response`, `URL`, `crypto`, `TextEncoder`/`TextDecoder`, `Headers`, `FormData`, `ReadableStream`
-- Database access through repository interfaces (domain layer) — implementations in infrastructure:
-  - `libs/[domain]/infrastructure/` — D1 implementation (Cloudflare)
-  - `libs/[domain]/infrastructure/` — SQLite/better-sqlite3 implementation (Node dev)
+- **Platform-specific code MUST be in separate libraries (STRICT)** — NEVER mix Node.js and Cloudflare code in the same library. Barrel exports (`index.ts`) would pull both platforms into the bundle, causing compilation errors (e.g. `better-sqlite3` in Cloudflare, or D1 bindings in Node.js):
+  ```
+  libs/[domain]/
+    infrastructure-d1/     # Cloudflare D1 implementation ONLY
+    infrastructure-sqlite/  # Node.js SQLite implementation ONLY
+  libs/shared/
+    infrastructure-d1/     # shared D1 providers (provideD1Database)
+    infrastructure-sqlite/  # shared SQLite providers (provideSqliteDatabase)
+  ```
+  Each entry point imports ONLY its platform's library:
+  - Worker entry → `@[PREFIX]/shared-infrastructure-d1`
+  - Node entry → `@[PREFIX]/shared-infrastructure-sqlite`
 - Hono is inherently platform-agnostic — use its standard APIs, avoid `c.env` directly in routes (inject via DI)
 - Entry points handle platform wiring:
   - `apps/api/src/main.ts` — Node.js entry (optional, for local dev)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-workspace",
-  "version": "1.1.76",
+  "version": "1.1.77",
   "description": "Scaffold a project with Claude Code agents for autonomous AI-driven development",
   "type": "module",
   "bin": {