# CLAUDE.md ## Project overview Crumbs by Bretzel — self-hostable note-taking app. Multi-user with password auth + OAuth/SSO, offline-first PWA with CRDT-based sync. ## Tech stack - **Framework**: SvelteKit with Svelte 5 (runes: `$state`, `$derived`, `$props`, `$effect`) - **Adapter**: `@sveltejs/adapter-node` (builds to `build/`, runs via `node build`) - **Styling**: Tailwind CSS v4 (via `@tailwindcss/vite`) - **Database**: SQLite via better-sqlite3 + Drizzle ORM (WAL mode, schema at `src/lib/server/db/schema.ts`) - **Auth**: Multi-user with password auth (Argon2) + OAuth (Google, GitHub, OIDC), role-based (admin/user), session cookies (30-day expiry) - **PWA**: `@vite-pwa/sveltekit` for service worker and offline caching - **Package manager**: pnpm ## Design system: Retro Parchment The UI follows a **parchment + 8-bit retro** aesthetic. All design decisions must preserve this character. ### Color palette All colors are CSS variables in `src/app.css`. Never use hardcoded Tailwind colors (e.g. `text-gray-500`, `bg-red-600`) — always reference CSS variables: | Variable | Value | Usage | |---|---|---| | `--bg-base` | `#f0e6d3` | Page background (warm parchment) | | `--bg-surface` | `#faf5eb` | Cards, panels, inputs | | `--primary` | `#C8860A` | Brand gold — links, active states, accents | | `--primary-hover` | `#E8A020` | Gold hover state | | `--text` | `#1a1a2e` | Primary text (near-black) | | `--text-muted` | `#6b6272` | Secondary text, placeholders | | `--border` | `#1a1a2e` | Strong borders (editor, login card) | | `--border-subtle` | `#d4cabb` | Default card borders, dividers | | `--destructive` | `#a63d2f` | Delete actions, error icons | | `--error-bg/border/text` | warm reds | Error states (themed, not clinical red) | | `--success-bg/text` | warm greens | Success states | | `--card-shadow` | `2px 2px 0px` | Hard-offset retro shadow (no blur) | | `--card-shadow-hover` | `3px 3px 0px` | Hover shadow in primary gold | | `--accent-check` | `var(--primary)` (light) / `#c8a44a` (dark) | Checkbox accent color — dimmed gold in dark mode so a long done-list doesn't shout | | `--hover-wash` | `var(--border)` (light) / `#ece3d3` (dark) | Tint source for hover/active washes (`bg-[var(--hover-wash)]/N`) — kept cream in dark mode since `--border`'s mid-grey is invisible at low opacity | Note colors for cards are defined in `src/lib/utils/colors.ts`. ### Dark theme Dark mode overrides every colour variable in `[data-theme="dark"]` (`src/app.css`). It is not a mechanical inversion of light mode — two differences are deliberate: - **`--primary` differs per theme.** `#C8860A` on parchment, `#e0a030` on ink. The light gold reads mustard on a dark background. - **`--border` is a warm mid-grey (`#57514b`), not mirrored cream.** A bright 1px line on a dark background reads as glare rather than structure; the hard offset shadow carries the retro framing. Note colours have two representations, and they are not interchangeable: | Map | Function | Used by | Role | |---|---|---|---| | `NOTE_COLORS` / `NOTE_COLORS_DARK` | `getNoteColor(color, isDark)` | Cards, editor, share page | Quiet **surface** you read text on | | `NOTE_CHIPS_DARK` | `getNoteChip(color, isDark)` | `ColorPicker` only | Vivid **label** you identify at a glance | A dark card sits at low lightness, where a 28px picker circle would read as a grey dot — small patches lose apparent saturation. Never fill a picker swatch with `getNoteColor()`. In light mode `getNoteChip()` returns the pastel card colour, because there the pastels *are* the cards. When changing any dark note colour, keep the invariants asserted in `src/lib/utils/colors.test.ts`: AA contrast (4.5:1) against both `--text` and `--text-muted` on every dark surface, no two dark card surfaces closer than an RGB distance of 8, no two dark chips closer than an RGB distance of 25, and `getNoteChip()` returning the card colour in light mode but a distinct chip in dark mode. `--bg-base` is duplicated as a literal in `src/app.html` (FOUC script) and `src/lib/utils/theme.svelte.ts` (`DARK_THEME_COLOR`) for the browser theme-colour. Update all three together. ### Typography - **Body**: `JetBrains Mono` (monospace) — the hacker/dev aesthetic - **Brand / empty states**: `Press Start 2P` (pixel font) — the 8-bit accent - These two fonts are intentional. Do not replace them or add others. ### Visual rules - **Shadows**: Always hard-offset (`2px 2px 0px`) with zero blur. Never use `shadow-sm`, `shadow-md` etc. — they look too modern. - **Corners**: `rounded-sm` everywhere. Sharp, not rounded. Exception: color picker circles use `rounded-full`. - **Borders**: Default card borders use `--border-subtle`. `--border` is for strong emphasis (editor, login card). Hover borders use `--primary`. - **Animations**: Crisp and fast (150ms `ease-out`). No spring physics, no bounce. The retro feel comes from snappy transitions. - **Background texture**: A subtle 4px pixel grid overlay at 3% opacity (defined in `body::before`). - **Checkboxes**: Use `accent-color: var(--accent-check)` globally — resolves to `--primary` in light mode and to a dimmed gold (`#c8a44a`) in dark mode so a long done-list doesn't shout. - **Icons**: Lucide icons throughout. Keep at 16-20px size. - **Hover actions**: Never use `hidden group-hover:block` for action buttons — they're invisible on mobile (no hover). Use the opacity pattern instead: `max-md:opacity-100 md:opacity-0 transition-opacity md:group-hover:opacity-100`. This keeps actions always visible on touch devices and hover-revealed on desktop. ### Layout groups - `(auth)` — Login/setup pages: minimal centered layout, no app chrome - `(app)` — Main app: header, sidebar, footer, toast notifications ## Project structure ``` src/ routes/ +layout.svelte # Root layout (imports CSS only) (auth)/ # Layout group: login/setup (minimal, no app chrome) +layout.svelte # Centered parchment background login/ # Login page setup/ # First-time password setup (app)/ # Layout group: main app (header, sidebar, footer) +layout.svelte # App shell with Header, Sidebar, Toast +page.svelte # Main notes view archive/ # Archived notes view trash/ # Trashed notes view tag/[name]/ # Notes filtered by tag settings/ # Settings with tabbed layout (profile, MCP, users) api/auth/ # Login, logout, setup, OAuth endpoints api/admin/users/ # Admin user management (CRUD, role, sessions) api/notes/ # CRUD + attachments api/search/ # Full-text search api/sync/ # Offline sync api/tags/ # Tag management lib/ components/ # Svelte components (NoteCard, NoteEditor, TagChip, etc.) stores/ # Svelte stores (notes.ts, theme.ts) server/db/ # Drizzle schema + connection (schema.ts, index.ts) server/ # Auth logic, attachment handling sync/ # Client sync (idb.ts), CRDT merge (crdt.ts), server sync types/ # TypeScript interfaces (Note, Attachment, Tag, etc.) utils/ # Colors, markdown, tags, debounce hooks.server.ts # Auth middleware (redirects unauthenticated users) tests/ unit/ # Vitest unit tests e2e/ # Playwright e2e tests (Gherkin-style) helpers/fixtures.ts # Shared authenticatedPage fixture website/ # Static landing page (crumbs.bretzel.app) index.html # Landing page with feature cards, screenshots, deploy section styles.css # Landing page styles (retro parchment theme) assets/ # Favicon, screenshots ``` ## Commands A `Makefile` wraps all common tasks for tool-agnostic usage. Run `make help` to list targets. | Make target | pnpm equivalent | Description | |---|---|---| | `make dev` | `pnpm dev` | Start dev server | | `make build` | `pnpm build` | Production build | | `make preview` | `pnpm preview` | Preview production build | | `make check` | `pnpm check` | Svelte type checking | | `make test` | `pnpm test` | Run all tests (unit + e2e) | | `make test-unit` | `pnpm test:unit` | Run unit tests only | | `make test-e2e` | `pnpm test:e2e` | Run e2e tests only | | `make lint` | `pnpm lint` | Run linter | | `make db-push` | `pnpm db:push` | Push schema to DB | | `make db-generate` | `pnpm db:generate` | Generate migrations | | `make db-migrate` | `pnpm db:migrate` | Run migrations | | `make db-studio` | `pnpm db:studio` | Open Drizzle Studio | | `make docs-api` | `pnpm docs:api` | Regenerate API docs from OpenAPI spec | | `make install` | `pnpm install` | Install dependencies | | `make docker-build` | — | Build Docker image | | `make docker-up` | — | Start containers | | `make docker-down` | — | Stop containers | | `make docker-logs` | — | Tail container logs | | `make clean` | — | Remove build artifacts + test DBs | | `make release` | — | Auto-bump version from commits, tag, and push | | `make release-patch` | — | Bump patch version, tag, and push | | `make release-minor` | — | Bump minor version, tag, and push | | `make release-major` | — | Bump major version, tag, and push | ## Git conventions - **Conventional commits**: Use `feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, `test:` prefixes - **Commit regularly**: Bundle related changes into logical commits after each step or feature slice — don't accumulate a large diff - **Main branch**: `main` — use as base for all PRs and feature branches - **Feature branches**: Use `feat/` branches with worktrees for isolation - **Rebase before PR**: Always `git rebase origin/main` (not merge) before pushing or creating a PR to keep a clean linear history and avoid merge conflicts in the PR ## CI/CD GitHub Actions with two workflows: **CI** (`.github/workflows/ci.yml`) — runs on push to `main` and PRs to `main` (branch work is validated once via the PR event, avoiding duplicate push+PR runs): 1. **Lint & Type Check** — `pnpm check` 2. **Unit Tests** — `pnpm test:unit` 3. **Build** — `pnpm build` (depends on steps 1+2) 4. **E2E Tests** — Playwright with Chromium (depends on step 3, uploads report on failure) 5. **Docker Build** — validates the Docker image builds (depends on step 3) **Bump & Release** (`.github/workflows/bump.yml`) — workflow_dispatch (primary release method): - Runs `scripts/release.sh` to bump version in `package.json` + `docker-compose.yml`, tag, and push - Runs full CI pipeline, then builds + pushes Docker image to `ghcr.io` - Creates a GitHub Release with auto-generated notes **Release** (`.github/workflows/release.yml`) — runs on `v*` tags (fallback for manual/local tag pushes): - Same as above: CI pipeline, Docker build/push, GitHub Release **Docker**: Multi-stage Dockerfile (node:22-slim), exposes port 3000, persists data to `/data` volume. ## Database schema changes When adding or modifying tables in `src/lib/server/db/schema.ts`: - **If the table has a foreign key to `users`**: update `deleteUser()` in `src/lib/server/auth.ts` to delete from the new table before the user row is removed. Order matters — delete child rows before parent rows. - **If the table has a foreign key to `notes`**: either add `onDelete: 'cascade'` in the schema definition, or add explicit cleanup in the note deletion logic. ## Testing philosophy: BDD/TDD Write tests first or alongside features. Tests serve as living documentation of expected behavior. ### Unit tests (Vitest) - Location: `tests/unit/*.test.ts` - Config: `vitest.config.ts` (node environment) - Cover pure logic: markdown parsing, tag extraction, auth, search, sync ### E2E tests (Playwright) - Location: `tests/e2e/*.spec.ts` - Config: `playwright.config.ts` (Chromium only, builds + previews app on port 4173) - Test database: `./data/test-crumbs.db` (cleaned via `global-setup.ts`) - Auth fixture: `tests/e2e/helpers/fixtures.ts` provides `authenticatedPage` (handles setup/login race conditions across parallel workers) - Auth tests use `test.describe.serial` because they depend on sequential database state - **Offline/online tests**: After `setOffline(false)`, always manually dispatch the `online` event via `page.evaluate(() => window.dispatchEvent(new Event('online')))` — Playwright doesn't reliably emit it in headless/CI environments, causing flaky `waitForResponse` timeouts ### Gherkin-style Given/When/Then E2E tests follow Cucumber BDD conventions via comments. Follow the [Better Gherkin](https://cucumber.io/docs/bdd/better-gherkin) guidelines: **Declarative, not imperative** — describe *what* the system does, not *how* the user interacts with the UI: ``` // Good: "When the user trashes the note" // Bad: "When the user hovers over the note card and clicks the trash button" ``` **Given describes state, not navigation:** ``` // Good: "Given a note titled 'Delete Me' exists" // Bad: "Given the user clicks the new note button and fills in the title" ``` **Collapse multi-step UI actions into a single intent:** ``` // Good: "When the user creates a note titled 'My Note' with content 'Hello'" // Bad: "When they click new note / And fill in the title / And fill in the content / And close the editor" ``` **Scenario names describe outcomes/behavior, not actions:** ``` // Good: "Scenario: Trashed note disappears from the main view" // Bad: "Scenario: User moves a note to trash" ``` **Resilience test** — ask: *"Will this comment need to change if the UI implementation changes?"* If yes, rewrite it to remove implementation details. The Playwright code underneath handles the *how*; the comments describe the *what*. ## Documentation Keep docs in `docs/` up to date when making changes. If a feature, API endpoint, deployment config, or architectural decision changes, update the relevant doc file in the same commit or PR: | Doc | Covers | |-----|--------| | `docs/FEATURES.md` | User-facing feature list | | `docs/ARCHITECTURE.md` | System design, data flow, schema, tech stack | | `docs/AUTH.md` | Authentication setup, OAuth/SSO provider guides (Authentik, Keycloak, etc.) | | `docs/DEPLOYMENT.md` | Docker, env vars, reverse proxy, backups | | `docs/openapi.yaml` | API spec (run `pnpm docs:api` to regenerate `docs/API.md`) |