# 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.
## Commands
- **Dev:** `go run .`
- **Build:** `go build ./...`
- **Test:** `go test ./...`
## Critical Constraints
- **Project structure:** Feature-based architecture. Group new code by feature, not by type (don't put components in a global components/ folder).
- **Circular dependencies:** Circular import chains detected: livereload.js. Avoid adding to these cycles.
## Stack
Tailwind CSS, Go
## Project Structure
- `scripts/` — Build / utility scripts
- `modules/` — Feature modules
- `helpers/` — Helper functions
- `docs/` — Documentation
- `config/` — Configuration files
## Core Modules (by structural importance)
- `livereload/livereload.js`
- `docs/assets/js/alpinejs/stores/nav.js`
- `internal/warpc/js/common.js`
- `docs/assets/js/helpers/index.js`
- `docs/assets/js/alpinejs/stores/index.js`
## Conventions & Patterns
- **Go module:** Module path: github.com/gohugoio/hugo. Use this as the import prefix for all internal packages.
- **Go visibility:** internal/ packages cannot be imported by external modules. Keep private code here.
- **Dominant patterns:** Tests use Go testing. Test utilities in: resources/testhelpers_test.go.
## Additional Context
- **Go conventions:** Project uses interface-first design (20 interfaces). Define interfaces at the consumer, not the producer.
## 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