# CLAUDE.md
This file provides guidance to Claude Code when working with this codebase.
Generated by [sourcebook](https://github.com/maroondlabs/sourcebook). Review and edit — the best context comes from human + machine together.
## Quick Reference
- **routing:** API endpoints use Hono routes
- **testing:** Tests use Vitest.
## Commands
- **Build:** `bun run --shell bun remove-dist && bun ./build/build.ts && bun run copy:package.cjs.json`
- **Test:** `tsc --noEmit && vitest --run`
- **Lint:** `eslint src runtime-tests build perf-measures benchmarks`
## Critical Constraints
- **Testing:** Tests are co-located with source files (*.test.ts next to *.ts). Keep this pattern -- don't create a separate test/ directory.
- **Core modules:** Hub files (most depended on): src/types.ts (imported by 47 files); src/context.ts (imported by 41 files); src/jsx/base.ts (imported by 25 files); src/router.ts (imported by 21 files); src/utils/html.ts (imported by 18 files). Changes here have the widest blast radius.
- **Circular dependencies:** Circular import chains detected: request.ts → body.ts; compose.ts → types.ts → hono-base.ts; jws.ts → types.ts. Avoid adding to these cycles.
## Stack
React, Express, TypeScript
## Project Structure
- `docs/` — Documentation
## Core Modules (by structural importance)
- `src/context.ts`
- `src/types.ts`
- `src/router.ts`
- `src/utils/http-status.ts`
- `src/utils/html.ts`
## Conventions & Patterns
- **Import conventions:** Project uses barrel exports (index.ts files that re-export). Import from the directory, not from deep paths.
- **Dominant patterns:**
- API endpoints use Hono routes. Follow this pattern for new routes.
- Tests use Vitest.
## Before Making Changes
- **Check file importance** before editing. Hub files (listed in Core Modules) affect many other files — changes here have the widest blast radius.
- **Follow existing patterns.** This project has established conventions (listed above). Match them instead of introducing new approaches.
- **Respect constraints.** Review the Critical Constraints section before making structural changes.
If the sourcebook MCP server is available (`sourcebook serve`), verify before acting:
- `get_blast_radius` — check what breaks if you edit a hub file
- `query_conventions` — confirm the right pattern before adding new code
- `get_pressing_questions` — get a briefing before editing an unfamiliar file
## What to Add Manually
The most valuable context is what only you know. Add:
- Architectural decisions and why they were made
- Past incidents that shaped current conventions
- Deprecated patterns to avoid in new code
- Domain-specific rules or terminology
- Environment setup beyond what .env.example shows