create-claude-workspace 2.3.4 → 2.3.5

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

@@ -63,304 +63,18 @@ Ensure these are in `.gitignore`:
 
 [Add any special tech from user answers]
 
-### App Separation Principle
-
-- **`apps/` are thin shells** — each app is just configuration + routing + bootstrap. Minimal code.
-- **`libs/` contain all logic** — each domain/feature has its **own library group** with sub-libraries per layer. Apps import only from entry points.
-- **Feature-first library organization (STRICT)** — every distinct feature/domain gets its own group of libraries:
-  ```
-  libs/
-    scan/           # feature: scan
-      domain/       # scan types, schemas, interfaces
-      ui/           # scan UI components
-      feature/      # scan smart components
-      data-access/  # scan HTTP/DB services
-    streak/         # feature: streak
-      domain/
-      ui/
-      feature/
-    achievement/    # feature: achievement
-      domain/
-      feature/
-    shared/         # ONLY truly cross-domain code
-      ui/           # generic UI primitives (buttons, modals)
-      domain/       # cross-domain types (if any)
-      infrastructure/
-  ```
-  **NEVER dump multiple features into a single library** (e.g. `shared/types` with `scan.ts`, `streak.ts`, `achievement.ts`). Each feature owns its types in its own `domain/` library.
-- **Frontend and backend are separate apps** with separate build configurations per environment:
-  - `apps/[APP_NAME]/` — Frontend application
-  - `apps/api/` — Backend API (if applicable)
-- **Environment configs**: each app has per-target settings via Nx `configurations` in `project.json` (API URLs, feature flags, etc.)
-- **Entry point pattern**: each domain lib has a root `index.ts` that re-exports the public API. Apps and other libs import ONLY from `@[PREFIX]/<lib-name>`, never from deep paths like `@[PREFIX]/<lib-name>/src/lib/internal/...`
-
-### CLI-First Principle
-
-**ALWAYS prioritize CLI commands and generators over manual file creation.** This applies to:
-- Nx workspace scaffolding (`create-nx-workspace`)
-- Libraries, components, applications (`nx generate`)
-- Adding plugins (`nx add`)
-- Package installation (package manager CLI)
-- Git operations (`gh`, `glab`)
-
-NEVER manually create `project.json`, `tsconfig.*`, or boilerplate files that a generator would produce. Generators configure dependencies, paths, and targets correctly.
-
-**NEVER use `nx:run-commands` executor** in project.json. Always use the proper built-in executor (`@nx/js:node` for serve, `@nx/vite:build` for build, `@nx/eslint:lint` for lint, etc.). `nx:run-commands` is an escape hatch for one-off scripts, not for standard targets.
-
-### Nx Generators
-
-[If Nx monorepo:]
-
-**Generator defaults** are configured in `nx.json` — no need to repeat flags like `--unitTestRunner`, `--linter`, `--style` in every command. See `.claude/profiles/frontend.md` for framework-specific generator commands.
-
-**Creating libraries:**
-```bash
-# Plain TypeScript library (for domain models, business logic, shared utils)
-nx g @nx/js:library --directory=libs/[domain]/[layer] --no-interactive
-
-# Framework-specific library — see frontend profile for the correct generator
-```
-
-**Bundler rule (STRICT):** Internal monorepo libs do NOT need a bundler — Nx handles compilation. NEVER install or configure tsup, tsdown, rollup, or any standalone bundler for internal libs. Only add `--bundler=esbuild|tsc|swc` to `nx generate` for **publishable** libraries (npm packages). If `nx generate` created a lib without `--bundler`, do NOT retroactively add one.
+### Standards
 
-After generation, the architect's plan specifies what code to write IN the generated files. The generator handles project.json, tsconfig paths, and build targets.
-
-### Onion Architecture (per domain)
-
-```
-+-----------------------------------------------------+
-|                     apps/[app]                        |
-|  App shell — assembles features into routing          |
-+-----------------------------------------------------+
-|                      feature/                         |
-|  Smart components, orchestrate UI + data              |
-+-----------------------------------------------------+
-|         ui/                |       data-access/       |
-|  Presentational components |  HTTP / DB services      |
-|  (dumb, input/output)      |                          |
-+-----------------------------------------------------+
-|                       api/                            |
-|  API routes, validation (if backend)                  |
-+-----------------------------------------------------+
-|                     business/                         |
-|  Use cases, business logic                            |
-+-----------------------------------------------------+
-|                      domain/                          |
-|  TypeBox schemas (single source of truth), types,     |
-|  repository interfaces, value objects                 |
-+-----------------------------------------------------+
-|                   infrastructure/                     |
-|  Repository implementations (database, API, mock)     |
-+-----------------------------------------------------+
-```
-
-Dependency rules:
-- domain -> only shared/domain
-- business -> domain, shared/infrastructure/di
-- api -> business, domain
-- infrastructure -> domain, shared/infrastructure
-- data-access -> domain (for types)
-- ui -> shared/ui, domain (for types)
-- feature -> ui, data-access, shared/ui
-
-**TypeBox as single source of truth**: Define TypeBox schemas in `domain/` layer (`libs/[domain]/domain/`). These schemas are the canonical definition — derive everything from them:
-- **TypeScript types**: `Static<typeof MySchema>` — no separate interface definitions
-- **API validation**: `openAPIRouteHandler` uses the same schemas for request/response validation + OpenAPI spec
-- **Frontend types**: Frontend imports types from domain lib via `@[PREFIX]/[domain]-domain` — no copy-paste
-- **DB mapping**: Infrastructure layer maps between DB rows and domain types
-- NEVER duplicate type definitions. If a type exists as a TypeBox schema, use `Static<>` everywhere.
-
-### @cibule/* Ecosystem (Preferred Libraries)
-
-[Include only if project uses backend or fullstack architecture]
-
-**ALWAYS prefer `@cibule/*` packages** over custom implementations or third-party alternatives for: DI, database access, file storage, image processing, and Nx workspace scaffolding. These are driver-agnostic abstractions designed for the onion architecture pattern.
-
-| Package | Purpose | Replaces |
-|---------|---------|----------|
-| `@cibule/di` | Dependency injection (InjectionToken, Injector, inject()) | Custom DI |
-| `@cibule/db` | Database abstraction (Kysely-based, driver-agnostic) | Raw Kysely |
-| `@cibule/db-d1` | Cloudflare D1 driver for @cibule/db | kysely-d1 |
-| `@cibule/db-sqlite` | SQLite driver for @cibule/db (better-sqlite3) | Direct better-sqlite3 |
-| `@cibule/db-migrate` | Migration orchestrator (Prisma + D1 PRAGMA fixes) | Manual migrations |
-| `@cibule/storage` | File storage abstraction (upload, download, presigned URLs) | Custom storage |
-| `@cibule/storage-r2` | Cloudflare R2 driver for @cibule/storage | Direct R2 API |
-| `@cibule/storage-s3` | AWS S3 driver for @cibule/storage | Direct AWS SDK |
-| `@cibule/image` | Image transformation abstraction | Custom image processing |
-| `@cibule/image-sharp` | Sharp-based driver with FileStorage caching (Node.js) | Direct Sharp |
-| `@cibule/image-cf` | Cloudflare Image Resizing driver | Direct CF API |
-| `@cibule/wiring` | Per-request DI middleware, AsyncLocalStorage helpers | Custom middleware |
-| `@cibule/devkit` | Nx generators for onion architecture scaffolding | Manual Nx setup |
-
-**DI core API** (`@cibule/di`):
-- `InjectionToken<T>` — typed token, `Injector.create({ providers, parent? })` — container
-- `inject<T>(token)` / `inject<T>(token, { optional: true })` — resolve from context
-- `runInInjectionContext(injector, fn)` — scoped execution
-- Provider types: `useValue`, `useClass`, `useFactory`, `multi: true`
-
-**Database pattern** (`@cibule/db` + driver):
-```typescript
-// Domain layer — driver-agnostic
-import type { Db } from '@cibule/db';
-import { DB_ACCESSOR, UNIT_OF_WORK_FACTORY } from '@cibule/db';
-
-// Infrastructure — pick driver per platform
-import { provideD1Db } from '@cibule/db-d1';       // Cloudflare Workers
-import { provideSqliteDb } from '@cibule/db-sqlite'; // Node.js local dev
-```
-
-**Workspace scaffolding** (`@cibule/devkit`):
-```bash
-nx g @cibule/devkit:preset myorg        # Initialize workspace with onion layers
-nx g @cibule/devkit:scope market --frontend  # Create domain scope
-```
-
-**Dependency bug handling**: If a bug is caused by a third-party dependency (not by project code), mark the task as `[~] BLOCKED` with the bug details and the package version. Continue with other tasks. The dependency freshness check at phase transitions will detect new versions — re-attempt blocked tasks after the package is updated.
+Shared coding standards are in `.claude/standards/` — agents read them on demand:
+- `coding-standards.md` — file organization, TypeScript config, coding style, code cleanliness, modern JS/TS
+- `architecture.md` — app separation, CLI-first, Nx generators, onion architecture
+- `backend-patterns.md` — @cibule/* ecosystem, platform-agnostic backend, Hono/OpenAPI patterns
+- `testing-standards.md` — test coverage, VRT setup, code quality & linting
 
 ### Frontend Profile
 
 Framework-specific best practices, component architecture, state management, SSR patterns, theme system, and UI component library conventions are defined in `.claude/profiles/frontend.md`. This file is read by `ui-engineer`, `senior-code-reviewer`, and `test-engineer` agents — not by backend or infrastructure agents.
 
-### File Organization & Size Limits
-
-**Single-purpose files (STRICT):**
-- Each `.ts` file exports ONE class, ONE function, or ONE closely related set of helpers (e.g., a type + its factory)
-- Name files after their single export: `get-image.ts`, `parse-html.ts`, `price-calculator.ts`
-- NEVER bundle unrelated exports into a barrel file like `utils.ts` or `helpers.ts` — split into individual files
-- Index files (`index.ts`) are the ONLY exception — they re-export the public API of a library
-
-**File size limits:**
-- MAX 200 lines per TypeScript file — split into types, utils, sub-components if larger
-- MAX 200 lines per SCSS file — split into partials
-- MAX 100 lines per HTML template — decompose into child components
-
-**Co-located tests:**
-- Test files live next to the source file: `price-calculator.spec.ts` beside `price-calculator.ts`
-- NEVER create `__tests__/` directories — tests are always co-located
-- One test file per source file — do NOT bundle multiple files' tests together
-
-### TypeScript Config
-
-- `moduleResolution: "bundler"` in `tsconfig.base.json` — all code goes through a bundler, so use bundler-style resolution
-- NEVER add `.js` extensions to TypeScript imports — write `import { Foo } from './foo'`, not `'./foo.js'`
-- `module: "ESNext"` + `target: "ES2022"` (or as appropriate)
-- `strict: true`, `noUncheckedIndexedAccess: true`
-- Path aliases via `compilerOptions.paths` in `tsconfig.base.json` — managed by Nx generators, do not edit manually
-
-### Coding Style
-
-- No comments in code — write self-explanatory code
-- Explicit access modifiers: `public` for API, `protected` for template-used, `private` for internal
-- Import order enforced by `eslint-plugin-simple-import-sort` (automatic)
-- Use `type` imports for type-only imports (`import type { Foo }`)
-- DRY: 3+ repeats = extract to shared utility/component/directive
-- Prefer composition over inheritance
-- `readonly` on all fields that don't need reassignment
-- No `any` — use `unknown` + type narrowing
-- No non-null assertions (`!`) — handle nullability explicitly with narrowing, `??`, or early returns
-- No `as unknown as T` double-casting — if types don't align, fix the types or use proper type guards
-- No `eslint-disable` comments — NEVER suppress linter rules. If ESLint flags an error, fix the code instead of disabling the rule. This includes `eslint-disable-next-line`, `eslint-disable-line`, and block `eslint-disable` comments.
-
-### Code Cleanliness (STRICT — clean code enables high coverage)
-
-- **Pure functions first**: business logic and domain operations are pure — same input, same output, no side effects. This makes them trivially testable.
-- **Minimal branching**: avoid nested conditionals (max 2 levels). Prefer early returns, lookup maps/objects, `??`/`?.` chains, polymorphism. If a function has 4+ branches, split it.
-- **Side effects at boundaries**: I/O (HTTP, DB, logging, DOM) happens at the edges — infrastructure layer, entry points. Business and domain code stays pure.
-- **Data transformations over mutations**: prefer `map`/`filter`/spread/new objects over `push`/`splice`/`delete`/mutation. Immutable data is predictable and testable.
-- **Small focused functions**: each function does ONE thing. Max ~20 lines of logic. Extract complex expressions into named pure helpers.
-- **Declarative over imperative**: describe WHAT, not HOW. Prefer expressions over statement sequences.
-
-### Modern JavaScript Syntax (STRICT — enforced by ESLint)
-
-- `for...of` over `.forEach()` — clearer, supports `break`/`continue`/`await`
-- `const` by default — `let` only when reassignment is needed, NEVER `var`
-- Arrow functions in callbacks — `array.map(x => x.id)`, not `array.map(function(x) { ... })`
-- Template literals — `` `Hello ${name}` ``, not `'Hello ' + name`
-- Object shorthand — `{ name, age }`, not `{ name: name, age: age }`
-- Destructuring — `const { id, name } = user`, not `const id = user.id`
-- Nullish coalescing `??` over `||` for defaults (avoids falsy pitfalls)
-- Optional chaining `?.` over nested `if` checks
-- `Promise.all()` for parallel async, `for await...of` for async iteration
-
-### Test Coverage
-
-80% minimum for statements, branches, functions, lines (enforced in CI).
-
-- **Config template**: `.claude/templates/vitest.coverage.ts` — merge into each project's `vite.config.ts` or `vitest.config.ts` during scaffolding. Replace `[PROJECT_NAME]` with actual name.
-- Reporters: `cobertura` (GitLab/GitHub MR coverage), `html` (browsable), `text-summary`
-- Coverage aggregated at workspace root under `coverage/` (add to `.gitignore`)
-- Run: `nx test [PROJECT] --coverage` or `nx affected --target=test -- --coverage`
-
-### Visual Regression Testing
-
-Page-level VRT using Playwright `toHaveScreenshot()` at 3 viewports (375px, 768px, 1280px). Catches unintended visual regressions across pages.
-
-- **Files**: `*.vrt.spec.ts` in E2E project (co-located with functional E2E tests)
-- **Baselines**: `*-snapshots/` directories — committed to git
-- **Threshold**: `maxDiffPixelRatio: 0.01` (1%), animations disabled
-- **Update baselines**: `nx e2e [APP]-e2e -- --update-snapshots` after intentional visual changes
-- **CI**: use Playwright Docker image (`mcr.microsoft.com/playwright`) for consistent rendering
-
-### Code Quality & Linting
-
-Config templates are in `.claude/templates/` — copy to project root during Phase 0 scaffolding:
-- **ESLint**: `.claude/templates/eslint.config.js` → `eslint.config.js` (flat config, `@typescript-eslint/strict-type-checked` + `@nx/eslint-plugin` + `eslint-plugin-simple-import-sort` + `eslint-plugin-prefer-arrow-functions`). Add framework-specific rules from `.claude/profiles/frontend.md`.
-- **Prettier**: `.claude/templates/.prettierrc` → `.prettierrc`, `.claude/templates/.prettierignore` → `.prettierignore`
-- **Stylelint**: `.claude/templates/.stylelintrc.json` → `.stylelintrc.json` (SCSS only, forces theme tokens over hardcoded colors)
-- **Pre-commit hooks**: `.claude/templates/.lefthook.yml` → `.lefthook.yml`
-
-Each library's `project.json` must declare tags: `"tags": ["type:domain", "scope:auth"]`
-
-Key rules enforced (do NOT weaken):
-- `prefer-arrow-functions/prefer-arrow-functions` — const arrow over function declarations
-- `max-classes-per-file: 1`, `max-depth: 4`
-- `@typescript-eslint/explicit-member-accessibility` — explicit public/private/protected
-- `@typescript-eslint/prefer-readonly` — readonly where possible
-- `@typescript-eslint/no-non-null-assertion`, `no-explicit-any`, `consistent-type-imports`, `strict-boolean-expressions`
-- `no-warning-comments: ['eslint-disable']` — no eslint-disable comments
-- `@nx/enforce-module-boundaries` — onion architecture layer constraints
-- `eslint-config-prettier` installed to disable conflicting rules. Do NOT use `eslint-plugin-prettier`.
-
-**Enforcement:**
-- All three tools run in CI pipeline (fail on violations)
-- `nx affected --target=lint` for incremental linting
-- Pre-commit hooks prevent committing violations
-
-### Backend Patterns (if applicable)
-
-[Include only if the project has a backend]
-
-- Hono routes with validation (**TypeBox** — `typebox` for schema + type inference, `TypeCompiler` for runtime validation). **NEVER use `@sinclair/typebox`** — the correct package is `typebox`.
-- **OpenAPI-first**: Use `hono-openapi` with `openAPIRouteHandler` for all API routes — generates OpenAPI spec from TypeBox schemas automatically. API docs served via `@scalar/hono-api-reference` at `/reference`.
-- `@cibule/di` for dependency injection (see @cibule/* Ecosystem section above)
-- `@cibule/db` + driver for database access, UnitOfWork for atomic writes
-- `@cibule/storage` + driver for file storage, `@cibule/image` + driver for image processing
-- `@cibule/wiring` for per-request DI middleware
-
-**Platform-Agnostic Backend (STRICT):**
-- Backend code MUST run on both Node.js and Cloudflare Workers without modification
-- 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 interfaces
-- Use Web Standard APIs where possible: `fetch`, `Request`, `Response`, `URL`, `crypto`, `TextEncoder`/`TextDecoder`, `Headers`, `FormData`, `ReadableStream`
-- **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)
-  - `apps/api/src/index.ts` — Cloudflare Worker entry (production)
-- Default deployment: **Cloudflare Workers** (production), **Node.js** (local development via `@nx/js:node` executor + Node.js entry point). Wrangler is deployment-only — NEVER used for local dev or in Nx targets.
-
 ### Project-Specific Details
 
 [Add critical implementation details, key patterns, special requirements from the discovery conversation and codebase exploration. This section is expanded by architect agents as they make technical decisions during development.]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-workspace",
-  "version": "2.3.4",
+  "version": "2.3.5",
   "author": "",
   "repository": {
     "type": "git",