create-claude-workspace 1.1.75 → 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/profiles/angular.md

@@ -240,11 +240,46 @@ export class LoginForm {
 - `withViewTransitions()` — smooth page transitions
 - Route-level code splitting: each page is a separate chunk
 
-## i18n (Internationalization)
+## i18n (Internationalization) — MANDATORY
+
+All Angular projects are set up with multi-language support from day one. **Every user-facing text MUST be marked for translation — no exceptions.**
 
 - `@angular/localize` with build-time XLIFF — zero runtime cost
-- `$localize` in TS, `i18n` attribute in templates
-- Keep translation keys stable
+- Project setup: `ng add @angular/localize` (or ensure `@angular/localize/init` is in polyfills)
+
+**Template texts — `i18n` attribute (STRICT):**
+```html
+<!-- EVERY visible text gets i18n attribute -->
+<h1 i18n="page title|Main heading on login page">Welcome back</h1>
+<button i18n="action|Submit login form">Sign in</button>
+<p i18n="hint|Password requirements hint">At least 8 characters</p>
+
+<!-- Attributes with user-facing text -->
+<input i18n-placeholder="form|Email placeholder" placeholder="Enter your email" />
+<img i18n-alt="image|Profile photo alt text" alt="Profile photo" />
+
+<!-- Plurals and select -->
+<span i18n>{count, plural, =0 {No items} =1 {1 item} other {{{count}} items}}</span>
+```
+
+**TypeScript texts — `$localize`:**
+```typescript
+const title = $localize`:page title|Dashboard heading:Dashboard`;
+const error = $localize`:error|Login failed message:Invalid credentials`;
+```
+
+**Key rules:**
+- EVERY user-facing string in templates MUST have `i18n` attribute — headings, labels, buttons, links, placeholders, tooltips, alt texts, ARIA labels
+- Use `i18n-placeholder`, `i18n-title`, `i18n-alt`, `i18n-aria-label` for attribute translations
+- Format: `i18n="meaning|description"` — meaning groups related translations, description helps translators
+- EVERY user-facing string in TypeScript MUST use `$localize` with description
+- Keep translation keys stable — don't change meaning/description without updating XLIFF files
+- NEVER hardcode user-facing text without i18n markup — even "OK", "Cancel", "Back" must be translated
+
+**NEVER:**
+- Bare text in templates without `i18n`: `<button>Submit</button>` → WRONG
+- String literals for UI text without `$localize`: `this.error = 'Failed'` → WRONG
+- Interpolated text without i18n: `<p>Hello {{name}}</p>` → needs `<p i18n>Hello {{name}}</p>`
 
 ## Theme System — @themecraft
 
@@ -446,4 +481,5 @@ When reviewing Angular code, check:
 - SCSS imports: via package name (no relative paths), no redundant `as` aliases
 - Lazy loading via loadComponent/loadChildren, no eager page imports
 - @defer for heavy below-fold components
-- Naming: PascalCase components, lib- selectors, kebab-case files
+- Naming: PascalCase components, lib- selectors, kebab-case files
+- i18n: ALL user-facing text has `i18n` attribute (templates) or `$localize` (TS) — no bare text

package/dist/template/.claude/profiles/react.md

@@ -142,12 +142,35 @@ src/
 - Route-level code splitting: each page is a separate chunk (automatic with Next.js App Router)
 - Prefetch critical routes: Next.js `<Link>` prefetches by default; for React Router use `route.lazy`
 
-## i18n (Internationalization)
+## i18n (Internationalization) — MANDATORY
+
+All projects are set up with multi-language support from day one. **Every user-facing text MUST use translation functions — no exceptions.**
 
 - **Next.js**: `next-intl` for type-safe translations with App Router support (server + client components)
 - **SPA**: `react-i18next` with namespace-based splitting
-- Keep translation keys stable and descriptive
+
+**Usage (STRICT):**
+```tsx
+// In components — EVERY visible text goes through t()
+const { t } = useTranslations('login');  // next-intl
+// or: const { t } = useTranslation('login');  // react-i18next
+
+return (
+  <h1>{t('title')}</h1>
+  <button>{t('submit')}</button>
+  <input placeholder={t('emailPlaceholder')} aria-label={t('emailLabel')} />
+);
+```
+
+**Key rules:**
+- EVERY user-facing string MUST go through `t()` — headings, labels, buttons, links, placeholders, tooltips, alt texts, ARIA labels
+- Keep translation keys stable, descriptive, and namespaced by feature
 - Co-locate translations near features when possible
+- NEVER hardcode user-facing text — even "OK", "Cancel", "Back" must be translated
+
+**NEVER:**
+- Bare text in JSX: `<button>Submit</button>` → WRONG, use `<button>{t('submit')}</button>`
+- String literals for UI text: `setError('Failed')` → WRONG, use `setError(t('error.failed'))`
 
 ## Theme System — @themecraft
 
@@ -318,5 +341,6 @@ When reviewing React code, check:
 - Code splitting: `React.lazy` + `Suspense` for heavy routes/components, no eager imports of page-level components
 - Dynamic imports for heavy third-party libraries
 - Naming: PascalCase components, camelCase hooks, kebab-case files
+- i18n: ALL user-facing text goes through `t()` — no bare strings in JSX or UI logic
 - No unstable nested component definitions (components defined inside render)
 - `React.memo` only on components with measured re-render cost — not as a default

package/dist/template/.claude/profiles/svelte.md

@@ -144,11 +144,33 @@ SvelteKit file-based routing:
 - `+page.svelte` components are automatically code-split per route by SvelteKit
 - Dynamic imports (`import()`) for heavy components not tied to routes
 
-## i18n (Internationalization)
+## i18n (Internationalization) — MANDATORY
+
+All projects are set up with multi-language support from day one. **Every user-facing text MUST use translation functions — no exceptions.**
 
 - `paraglide-sveltekit` (recommended) — compile-time, tree-shakeable, type-safe messages
 - Alternative: `svelte-i18n` — runtime-based, ICU message format
+
+**Usage with paraglide (STRICT):**
+```svelte
+<script>
+  import * as m from '$lib/paraglide/messages';
+</script>
+
+<!-- EVERY visible text goes through message functions -->
+<h1>{m.loginTitle()}</h1>
+<button>{m.loginSubmit()}</button>
+<input placeholder={m.emailPlaceholder()} aria-label={m.emailLabel()} />
+```
+
+**Key rules:**
+- EVERY user-facing string MUST go through translation functions — headings, labels, buttons, links, placeholders, tooltips, alt texts, ARIA labels
 - Keep translation keys stable, co-locate message files with features when possible
+- NEVER hardcode user-facing text — even "OK", "Cancel", "Back" must be translated
+
+**NEVER:**
+- Bare text in templates: `<button>Submit</button>` → WRONG, use `<button>{m.submit()}</button>`
+- String literals for UI text: `error = 'Failed'` → WRONG, use `error = m.errorFailed()`
 
 ## Theme System — @themecraft
 
@@ -320,6 +342,7 @@ When reviewing Svelte code, check:
 - Theme compliance: generated @themecraft SCSS variables — no hardcoded colors/sizes, no direct `color-var()`/`size-var()` calls
 - SCSS imports: via package name (no relative paths), no redundant `as` aliases
 - Lazy loading: routes auto-split, dynamic `import()` for heavy non-route components
+- i18n: ALL user-facing text goes through translation functions — no bare strings in templates
 - Accessibility: all Svelte compiler a11y warnings resolved (not suppressed)
 - No `{@html}` without sanitization
 - Callback props for outputs (not `createEventDispatcher` — that's Svelte 4)

package/dist/template/.claude/profiles/vue.md

@@ -167,13 +167,37 @@ src/
 - Nuxt auto-imports and auto-splits by page — leverage this by default
 - `<Suspense>` with async setup for loading states on async components
 
-## i18n (Internationalization)
+## i18n (Internationalization) — MANDATORY
+
+All projects are set up with multi-language support from day one. **Every user-facing text MUST use translation functions — no exceptions.**
 
 - `@nuxtjs/i18n` for Nuxt projects — lazy-loaded locales, SEO-friendly routes, auto-detection
 - `vue-i18n` for non-Nuxt projects
-- `$t('key')` in templates, `useI18n().t('key')` in `<script setup>`
-- Keep translation keys stable and organized by feature/domain
+
+**Usage (STRICT):**
+```vue
+<template>
+  <!-- EVERY visible text goes through $t() -->
+  <h1>{{ $t('login.title') }}</h1>
+  <button>{{ $t('login.submit') }}</button>
+  <input :placeholder="$t('login.emailPlaceholder')" :aria-label="$t('login.emailLabel')" />
+</template>
+
+<script setup lang="ts">
+const { t } = useI18n();
+const errorMsg = t('login.error.failed');
+</script>
+```
+
+**Key rules:**
+- EVERY user-facing string MUST go through `$t()` / `t()` — headings, labels, buttons, links, placeholders, tooltips, alt texts, ARIA labels
+- Keep translation keys stable, organized by feature/domain
 - Locale files: JSON format, one per language (`en.json`, `cs.json`)
+- NEVER hardcode user-facing text — even "OK", "Cancel", "Back" must be translated
+
+**NEVER:**
+- Bare text in templates: `<button>Submit</button>` → WRONG, use `<button>{{ $t('submit') }}</button>`
+- String literals for UI text: `error.value = 'Failed'` → WRONG, use `error.value = t('error.failed')`
 
 ## Theme System — @themecraft
 
@@ -350,3 +374,4 @@ When reviewing Vue code, check:
 - Props defined with TypeScript types via `defineProps<{ ... }>()` — not runtime-only validation
 - Emits declared via `defineEmits<{ ... }>()` — not untyped string arrays
 - Naming: PascalCase components, `Base` prefix for atoms, `use` prefix for composables
+- i18n: ALL user-facing text goes through `$t()` / `t()` — no bare strings in templates or script

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.75",
+  "version": "1.1.77",
   "description": "Scaffold a project with Claude Code agents for autonomous AI-driven development",
   "type": "module",
   "bin": {