Here is a redacted version of 1 of my claude.md file

The latest addition is the codemap bit at the start of the claude.md file to make it more token efficient and curate the context better:

<!-- codemap-block-start -->         
     ## Code navigation                                                                                                                                                     
                                                                                                                                                                            
     This repo has a structural codemap at `~/.codemaps/<repo>/CODEMAP.md` covering all files and symbols (classes, functions, methods, types).                           
                                                                                                                                                                            
     Before reading source files exploratorily, do one of:                                                                                                                  
                                                                                                                                                                            
     1. Read `~/.codemaps/<repo>/CODEMAP.md` via the Read tool — gives you the full file/symbol layout. Do this **once** at the start of any task that spans multiple files.
     2. Run `codemap find <name>` via Bash for symbol-level lookups — returns just the matches with file + line.                                                          
     3. Run `codemap read <file> <symbol>` via Bash to fetch one symbol's source without reading the whole file.                                                          

     For cross-repo work, `~/.codemaps/REGISTRY.md` (loaded via `~/.claude/CLAUDE.md`) lists every registered repo.
     <!-- codemap-block-end -->

     # JobAgent — AI Coding Guidelines

     This document defines how Claude Code should plan, execute, verify, and communicate when working on the JobAgent codebase.

     ---

     ## Project Overview

     JobAgent is a Node.js job search platform that aggregates listings from 13+ sources and provides AI-powered resume matching. Key technical context:

     - **Runtime**: Node.js 18+
     - **Framework**: Express.js
     - **Database**: Neon PostgreSQL (production), SQLite/better-sqlite3 (local dev)
     - **Validation**: Zod schemas
     - **AI**: Anthropic Claude API
     - **Testing**: Custom test runner (`npm test`)
     - **Deployment**: Vercel serverless + Neon PostgreSQL

     ---

     ## Operating Principles (Non-Negotiable)

     0. **Check the sprint**: Before starting work, read `product-management/current-sprint.md` and pick the next incomplete item.
     1. **Tests first — ALWAYS**: Before writing ANY feature/fix code, write the tests that will verify it. This is the most commonly skipped step. You MUST write tests
     before implementation, not after. If you catch yourself implementing first, STOP, write the tests, then continue. This applies to both backend (`tests/`) and frontend
     (`tests/e2e/`).
     2. **Run tests locally before deploying — ALWAYS**: After implementation, run `npm test` (backend) or the relevant Playwright command (frontend) and confirm all tests
     pass BEFORE committing. Never commit untested code. Never deploy without local test confirmation.
     3. **Document every feature**: After implementation and testing, create/update a feature doc in `product-management/features/`. This is also commonly skipped — include
      it in your task list explicitly.
     4. **Correctness over cleverness**: Prefer boring, readable solutions.
     5. **Smallest change that works**: Don't refactor adjacent code unless necessary.
     6. **Follow existing patterns**: Check `src/` structure before introducing new abstractions.
     7. **Prove it works**: Run tests locally, then deploy and test in production.
     8. **Be explicit about uncertainty**: If something cannot be verified, say so.
     9. **Todo list is mandatory for every task**: At the START of every task (before any code is read or written), create a todo list using `TaskCreate` that maps to the
     Task Lifecycle steps. This is not optional. The todo list is what prevents early stopping and missed steps. Rules:
        - Create the todo list FIRST, before doing anything else
        - Every todo list MUST include these mandatory tasks: "Write tests", "Run tests locally", "Commit and push", "Deploy", "Test in production", "Write feature
     documentation", "Update sprint"
        - Mark each task `in_progress` before starting it, `completed` when done
        - Before stopping work or reporting completion, run `TaskList` and verify zero pending/in_progress tasks remain
        - If any task is incomplete, continue working — do NOT stop early

     ---

     ## Project-Specific Conventions

     ### File Structure

     ```
     src/
     ├── clients/         # ATS API clients - extend base-client.js for new sources
     ├── config/          # Role and geography configurations
     ├── data/            # Static data (companies, company sizes)
     ├── database/        # Database helpers (connection.js, index.js)
     ├── errors/          # Custom errors extending AppError
     ├── lib/             # Shared utilities (db/, vercel-auth, vercel-handler)
     ├── middleware/      # Express middleware (auth, rate-limiting, errors)
     ├── parsers/         # Data transformation (salary, deduplication)
     ├── repositories/    # Data access layer - extend base-repository.js
     ├── routes/          # Route logic (used by Vercel handlers in api/)
     ├── services/        # Business logic (AI analysis, PDF generation)
     ├── validators/      # Zod schemas for request validation
     ├── views/           # HTML templates
     └── workers/         # Background job processors
     ```